@thenomain said in [The Death Of Telnet: Is It Time To Face The Music?]
If you name the OP as one of them, I'll know that you're trolling.
It sure was Moon, absolutely.
Now exuse me as I finish writing this post...
@thenomain said in [The Death Of Telnet: Is It Time To Face The Music?]
If you name the OP as one of them, I'll know that you're trolling.
It sure was Moon, absolutely.
Now exuse me as I finish writing this post...
@surreality said in Hobby-related Resolutions/Goals for the coming year... ?:
@ashen-shugar I am beginning to believe this is how nearly all code is actually created, you realize.
@faraday said in The Death Of Telnet: Is It Time To Face The Music?:
@thatguythere said in The Death Of Telnet: Is It Time To Face The Music?:
I think a lot of the rancor by myself and others is some of the we must move forward stuff involved a direct repudiation of what we like about the hobby.
If the thing you like about the hobby is having to type +bbpost Board=Subject/Message then yeah, I can't help you. Keep playing Penn/Tiny I guess.
But other than that, I don't see how making it easier to do things people are already trying to do is a repudiation of anyone. Nobody in this thread is talking about radically changing the fundamental style of gameplay. Folks already link to their character profile images from +finger or @desc. They already insert image links into room descs. Don't want to see them? Hey, that's a perfectly fine feature request, which is already common in some chat clients.
@Faraday, that's something that you, @Griatch, myself and others have faced and will continue to face. The evil face of change.
A larger portion than normal just hear the following:
So, I have this new feature that changes WOOF WOOF BOW WOW MOO MOO OINK OINK OINK WOOF WOOF WOOF. So what do you all think?
Anything after the word 'changes' they tend to tune out.
Got a ton of green coffee beans for Christmas.
So my New Years resolution.
@admiral said in The Death Of Telnet: Is It Time To Face The Music?:
I think just moving over to web-based interfaces would be all the hobby needs.
People don't want to download a program and then connect through ports and blahblah.
They want to click a website. Click click. Done.
I think Polk is using the Rhost API to do exactly that.
Essentially driving the entirety of the game as a an entirely web driven interface.
I believe Rook may be looking to do something similar.
I also saw backspam of the, well, spam, in debugging mush code.
It's why I went to such lengths to add debug labels, color-coded grepping, and match algos galore to the debug output.
It's not an IDE by any stretch of the imagination, but it actually makes trace output worthwhile and not walking into a vomit contest by a pair of trolls.
Ixokai can cover more on the @label goodness as he's actively used it in several projects. I just coded it. I mean, use it as well? Hah!
This all does go to what I've said a few times. Empower the user to use what tools they find easiest, and you'll find a greater amount of adaptation.
@templari said in Forum Game: You Remind Me of the GIF...:
@auspice said in Forum Game: You Remind Me of the GIF...:
So that no one feels pressured on coming up with something for me- first responder is first on the block.
Did someone say First Responder?
But aren't reality levels normally wizard only? Cool idea, but how does that help a player who just wants to ignore one other player in a specific room? Which is what I assume is being asked?
Reality levels are controlled by three methods.
The solution would be to encode some softcode wrappers in the master room to allow people to join/leave the snuff reality.
Hey all, is it possible to - in TinyMUX - set a conditional lock that prevents me from seeing someone's poses/says/@emits when in certain rooms? I want to block any incoming stuff from people in certain OOC rooms but not interfere in their input elsewhere.
Or am I just gonna have to do this through hella LUA scripting?
You gotta do this through client side gagging. And separating it out from IC vs OOC rooms is a little hard to the point at at midnight I can't think of a way to actually accomplish it off the top of my head.
Actually have an idea.
MUX2 does have Reality Levels.
Set up a unique reality level for yourself and just put the room in that reality and make sure you're -not- in that reality, but everyone else is, then they see as normal, but to you they don't even exist to you while in that room.
@thenomain said in Questions About Evennia:
It smacked me of system conceit which I know happens a lot in open source, even by accident (vis a vis @Ashen-Shugar's post, which assumes Rhost compatibility, because That's His Thing).
Hope I wasn't coming off as arrogant, wasn't my intention. Was just trying to point out that all languages have their measure of learning curve, and not everything is as cut and dry as 'easy' or 'difficult'.
Python and Ruby has the benefit of being main-stream languages and being useful to use out of the mush arena. Mushcode does not.
For MUX it's about the same, just as a FYI:
$+mywhere:@pemit %#=[setq(0,setdiff(iter(lwho(),loc(##)),#-1))][list(%q0,[ljust(name(##),40,.)].. [wrap(itemize(iter(lcon(%i0,connect),name(%i0),,|),|),
35,l,,,43)])]
tl;dr: Evennia and Ares are the right direction, period, no questions. Thenomain still doesn't like it when people misrepresent his favorite flavor of <fill in blank>.
I wouldn't say it was the 'right' decision. Honestly, I think for the world of mushdom, the 'right' decision is to bury it and rebuild it from the ground up, as a mixed environment of text, graphical, web, and everything else.
Ergo, build it as an engine API and allow the method they want to connect up to the end user. But who the hell has the time for that?
@thenomain said in Questions About Evennia:
@faraday said in Questions About Evennia:
@griatch said in Questions About Evennia:
it's not our intention to make misleading comparisons so if the example comes across as disingenuous we can remove it.
I think that a MUSHcode vs new code example is helpful. If the existing one isn't good, maybe @Thenomain could point do / provide a good tutorial-worthy example in MUSHcode and then someone can make an Evennia version.
+finger, +who, +where, in that order. These are the base three Learning To Mush Code systems that everyone should do. As +where is a nightmare in Mu*, I think that it would be a good example of why not to learn Mushcode.
Depends entirely how much detail you want +where to offer and what restrictions you have on it.
$+mywhere:@pemit %#=[setq(0,setdiff(iter(lwho(),loc(##)),#-1))][list(%q0,printf($-40:.:s $-"|30s,name(##)%b,elist(lcon(%i0,connect),and,,,,
cname(%0))))]
Not that difficult for a generic one
A fun idea I wanted to toss out there.
How would people feel about having a 'hackathon' with mushing?
Essentially, we set up a TinyMUSH3, a MUX2, a PennMUSH and a RhostMUSH.
We get set teams.
We have a team that defends the mush.
We have a team that attacks the mush.
We have pre-determined methods (that can be accomplished on each codebase) to mark when a system was 'comprimised' to establish a winning scenario.
I figure this will be a good learning experience for everyone to give people a bit more hands-on experience administrating mushes, stop real-time problem players and trolling, and so forth.
The only caveats with this would be:
Keep in mind, this is just something rolling in the back of my head. No plans, just tossing it out there.
What do people think?
And this pretty much is what I think of the holidays...
@rook said in Alternative Formats to MU:
You're right, but if we're honestly talking about something to replace telnet, I think that our 'core' needs to be broader than 'every game uses this'. It needs to have a full enough list of features that people go 'that looks better', and that's going to include, IMO, logging and conflict resolution.
Point of order... I am confused by the constant usage of the word 'telnet' in this conversation. Telnet is a protocol, like HTTP or SMTP or SSH. This misunderstanding has clogged a lot of this conversation from a technical perspective.
I think the better term to be using here would be 'server codebase', which is the application like PennMUSH or RhostMUSH or TinyMUX or AresMUSH that people are logging into. That is what provides the features that you are discussing.
Not picking on anyone, but please. Unless you are speaking to the specific carrier protocol that people use to log into the server, don't use the word 'telnet'.
What is being discussed here is design for the server, not the protocol.
Also? Please don't just say "Whatever Rook", because it is important when you are engaging people from a technical perspective. God help us if @Ashen-Shugar sees this.
Whatever Rook.
You deserved that for the Ashen-Shugar comment
For what it's worth, it's again why I made the API in Rhost. Why I'm having people help me in making a completely code-independent API parser into the main engine.
If people don't want to use telnet, don't.
If people don't want to use web interfaces, don't.
If people don't want to log, don't.
If people want to log everything, go for it.
Right now, with the existing Restful(like) API, Rhost allows you to interface, connect, query, and push and pull data from the game, without using telnet. Without logging in a player. Without anything more than an active end-point dbref#. And that dbref# can be any data type. Room, exit, object, it just doesn't care.
You use the a url call (any language that can do a header based url call can use this, any web page, program, command line, graphical application... anything that handles web headers.
Game developers hear you when you ask for options.
Game developers hear you when you ask to be able to enable and disable anything you can think of.
Game developers hear you when you ask for more.
But the funny thing is?
All I hear is the people too busy complaining about how something doesn't work to bother discovering the issue has already been resolved in some of the codebases.
And this is why @Rook didn't want me to see it I guess.
Meh handwaves do whatever. I'm tired.
@meg said in Alternative Formats to MU:
@rnmissionrun said in Alternative Formats to MU:
I honestly do not think that simply moving from MUSHcode to Python (or Ruby) will make it 'orders of magnitude' easier. Sure, it might help some folks, but IMO if you don't have the aptitude for coding, simply switching languages isn't going to make any difference. The problem is that doing anything non-trivial in /any/ programming language requires real skill. Non-coders probably won't have those skills, or be interested in developing them.
Lol. I once showed a real coder (a man who has worked as a systems architect in C, C++, and C# and node.js and all kinds of languages for 20+ years) some MUSH code and he stared at it in horror and couldn't figure it out.
He could probably learn Python in a day.
And that's an /experienced coder/ learning. Not an inexperienced one.
Meh.
Depends on the person and their way of thinking.
Likely, the C, C++, C#, node.js developer learned in a structured environment and learned programming in a very orthodox and strucured way.
Going from that to mush is always going to cause problems.
Because while mushcode could be semi-structured, how it's layed out with attributes and not lines, and the fact it's interpreted and not compiled leads to a brain-fart when trying to go from one to the other.
It would have made more logical sense if you were saying:
So, I showed this person who graduated in language history and computer language design MUSH code and he caught on pretty quickly!
That would be more the background of knowing MUSH, because MUSH was an inspired language as a college project, based in language history and language design.
Pulling someone from a structured language and expecting them to just catch onto MUSH really doesn't have much weight.
Because again, MUSH isn't a typical structured language.
@rnmissionrun said in Alternative Formats to MU:
I honestly do not think that simply moving from MUSHcode to Python (or Ruby) will make it 'orders of magnitude' easier. Sure, it might help some folks, but IMO if you don't have the aptitude for coding, simply switching languages isn't going to make any difference. The problem is that doing anything non-trivial in /any/ programming language requires real skill. Non-coders probably won't have those skills, or be interested in developing them.
And this is something we plan to have a unique solution to for RhostMUSH.
We're in the process of (hopefully) making a fully independent API language processor into the game. This is separate from the Restful(ish) API that we currently have available.
What the language API will (hopefully) do is allow you to plug in, quite literally, nearly any external programming language (ruby, python, perl, etc) and have it work as if it was a native language plugin (ergo, native C) for all intents and purposes to the mush.
Meaning, you would have tie-in into the internals of the codebase and be able to interactively use it in your language of choice.
While we can't make coding any easier, we can empower a user to use the language they know best.
That's about the best we can do for you
@faraday said in Alternative Formats to MU:
This really doesn't strike me as a problem.
Evennia is pitched as just a building kit, so you can build whatever you want. I'd say it has the opposite problem, where you have to cobble together building blocks for even basic stuff like finger, bbs, jobs, etc.
Ares comes with more stuff built-in, but it's designed with a plugin system so you can add/remove things. Of course, if you start stripping things out, now you're getting into the realm of custom coding. You can take out FS3 pretty easily, but now you've got to code up something to replace it - and that's not trivial.
The problem isn't in the tool, so much, as the experience to use the tool or the time available for the end-point person to spin up on the knowledge to use the tool.
Ares with the Ruby/rails integration.
Evennia with the Python/django integration.
RhostMUSH with the restful(ish) API.
MOO with its built in language system.
MUCK with it's FORTH integration.
All have tools available to do some fairly amazing things both internal and external.
But it has the base expectation for the end-user who wants to make it happen to be comfortable with the tools to do so.
We're not there yet.
And honestly I'm not sure it's our job to get there. The best we can do is provide tools, documentation, examples, and empower the end-user to actually use it. But them to actually use it is not our decision.
It's theirs.
And that's the problem
@rook said in Alternative Formats to MU:
Unless you are actively participating in a development effort (like Griatch and team seem to be), I wouldn't hold my breath. Seems like something that will eventually go the way of pay-to-play, and you'll lose a lot of the current crowd with that.
Exactly this.
I and others have worked on RhostMUSH for, what will by start of 2019 be 30 years.
Moving MUSH into mainstream runs into some very real issues. They are (but not limited to):
To make changes to that we have:
This is why you won't see much effort.
The majority of mud developers (like myself) are frankly burnt out, jaded, and cynical.
We've been doing this for 30 years, half our lives, and likely longer than a fair portion of you have been alive. We're tired.
We did what we did for the love of it. Not for what people may or may not appreciate, love, or hate. We did it for our own love and interest. We did it because we hoped others would find the same love in it we did.
We would love to take mudding to the next level, but did I mention we are tired?
So if you all want to see it happen, you all are going to have to help us with it. We just don't have the time we used to. We have families now, some of us have grandchildren. I myself have great-great-nephews and nieces. I find staying up after 10pm is hard as hell now, where when I originally wrote on Rhost I could do 48 hour stints with a glass of mountain dew and some anime on TV and maybe a bucket of hot wings.
Frankly put, we just can't keep up anymore.
To quote Futurama: Our minds are willing, but our bodies are weak and flabby.
@ixokai said in TinyMUX: Info Storage:
@rook said in TinyMUX: Info Storage:
Port to Rhost. <no, seriously>
Use clusters.
With 32K LBUFS, at the absolute ceiling of 10,000 attributes per object, this would allow you with a @cluster of... hum... somewhere in the realm of an absolute maximum of 60 million attributes seen by a single entity.
For those not in the know, this is what @cluster is in RhostMUSH
@CLUSTER
Command: @cluster[/<switch>] [[<arguments>][=<values>]]
The @cluster command is used to 'cluster' or link together a set of 2 or
more dbref#'s into a single entity to be used and accessed by a set of
clustering commands and functions as the aforementioned single entity.
This is used to allow more flexability of data storage, better organization
and a way to allow better data handling of the database as a whole.
For more help on what @cluster can do, please refer to the following
switches available. Individidual help is available with
'help @cluster <switch>'
Switch Description Switch Description
--------- -------------------------- ----------- -----------------------
/new - start new cluster /add - add dbref# to a cluster
/del - delete dbref# from cluster /clear - purge cluster
/list - list cluster specifics /threshold - set threshold limit
/action - set threshold action /edit - edit attr on cluster
/set - set/unset attr on cluster /repair - repair cluster
/grep - grep cluster for match /reaction - edit action on cluster
/cut - 'cut' dbref# from cluster /trigger - trigger attr in cluster
/func - Specify function action /regexp - use regexp pattern match
/wipe - Wipe attrib(s) in cluster /owner - Owner check for /wipe
/preserve - Preserve /wipe pattern
See Also: clusters, cluster functions, cluster commands, >