Posts made by Griatch

@surreality said in What is out there? Hard and soft codebases of choice.:

@Griatch said in What is out there? Hard and soft codebases of choice.:

@surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]

This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia.

Is this in the game, or from outside of it, though?

Are all of the interplayer communication commands already established? (Say, pose, page, whisper, emit, etc.? -- I'm asking because I don't know.) This stuff is pretty big, really.

Yes, it's in the game, out of the box. Evennia is basically a "talker" by default. It comes with about 90 default commands related to server management, building and social play. They can all be modified and replaced (outside the game). What we don't offer in core are very game-specific things, with the notion that this will be dependent on the type of game you want to do and easy to add if you know your players will expect it.

Here is the list of default commands:
https://github.com/evennia/evennia/wiki/Default Command Help
Here is the starting building tutorial:
https://github.com/evennia/evennia/wiki/Building Quickstart

I would also point to the "Evennia for Mushers" article I wrote here on Musoapbox. It's linked earlier in this thread.

You can also go to http://demo.evennia.com (telnet: silvren.com port 4280) to see an almost-vanilla install in action.
.
Griatch

@Thenomain

People like you and I can do some amazingly complex things in Mushcode, but it takes a level of effort that oustrips Mushcode's standard use case.

This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

(Note that I'm not talking about plugging in a pre-made system here. That is obviously a great boon of the mushcode ecosystem but has less to do with its inherent "bridging power" and more to do with a backlog of decades of people using it for a very specific set of game styles. For Evennia (or Ares) to catch up with that aspect comes down to adoption and time.)

• You can't do the old trick of testing your code in development in that bizarre but delightful way Mushes allow you to localize code. If you make a change, it's to the server. (New tactic: Lock the code until it's tested.)

This is what version control is for, but no, it doesn't work in the same way as mushcode.

• You have to have server access to test code. You can't test concepts on someone else's server ("how does Penn do this, again?"), and you can't do it without your own complete server installation.

That sounds like a correct observation.

The problem with my communications here is that I'm talking in what sounds like absolutes, but is a matter of degrees. I don't have the language to explain what I'm thinking of, only examples. As you and @Griatch are taking those examples as specific issues and/or complaints, cross-purposes are being attained.

Let me give one more example.

Yes, I have to install the entirety of Python to play around with it (let's ignore online tools for a moment), but I can get into a limited development shell to, well, I could create a whole Python program in it, but it's not designed for that. It's designed to "play".

Are you here comparing "playing" in the raw Python shell to "playing" with code in Evennia? The latter you do (and people commonly do) with the @py command, which allows you to modify the running game in raw Python from in-game. But no, it's indeed not as easy as a full python input line. It's a lot more convenient to just test out Python snippets in the real python interpreter shell (in a separate window).

This is the specific part I was talking about earlier that I think needs help to make Evennia more accessible. (does not say to run vitualenv first, nor how)

Thankyou, that is good and useful feedback. The page was updated to make this clearer, check it out.

Actual Game Dev

This (to me) is a person willing/interested in creating a text-based MMO. In the hobby-world of MU* it generally also means running and maintaining said game. This is accomplished using whichever tools they choose. If they also play the game is irrelevant to the definition. If you are using the build tools (however they may look) in an official capacity to expand and improve the game, you are also a game dev.

If you are a regular player that are using the build tools to expand the game world/game experience on your own volition you are not a game dev IMO - you are then a content creator or maybe a modder. Which can be super-important and something an individual game may really want to support by adding resources to make such activities easier.

@surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]

This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia.

@WTFE

Given that the process in Evennia is, as you yourself admit,

1. Come up with a crazy idea.
2. Type in the code for that crazy idea in your code editor.
3. Switch to game and run @reload to watch it crash and burn.
4. Repeat until this doesn't crash and burn.

Yet, I would far rather try setting up a MUSH server--despite hating the technology it's based on!--over setting up a game on Evennia. Why? Because the barrier between conceiving of something and seeing it work is far, far, far smaller.

Firing up a text editor, editing code there, then switching to your game and typing @reload isn't as onerous a task as the horrible, horrible, horrible steps I take to get my C code working on an MCU, but it's a far cry from "the point of entry is the point of output" that fosters the best exploratory work. You're still switching out of your concept space and worrying about the plumbing. When you factor into that the API I linked to earlier with its myriad of StateManagerFactoryManagerStateManager types and other crud from shitty OOP methodology you have something that divorces you so far from the actual game design that it's actually kind of comical to see.

A proper Python text editor will make all of Evennia's API directly available to as you type, with inline documentation, auto-completion and direct syntax checking and testing. It's quite clear your dislike for OOP is the main beef here. Fair enough - if you prefer Mushcode over Evennia's solution that's your call.

@faraday

Evennia runs within about 40MB from the onset, but yeah, it will scale up considerably for a production game so you are probably right that the deluxe package is still too low in practice. Most users run on AWS or DigitalOcean or other on-demand services. As for the web port, sure it's rare for port 80 to be available on anything but your own self-hosted server so most often it runs on something higher. We default to port 8000.
.
Griatch

@Thenomain

Making Mushes--sorry, an online multiplayer game--is simple. Evennia can have that middle ground. Here's how: Hire @Volund to write your installation and initial help documents. I don't know if he has the temperament(I don't!), but he's self-taught and taking off with the hobby possibilities and I keep hearing his name come up in the sentence "Volund helped me set up..."

@Volund is a great guy. He is also very knowledgeable about Evennia. And he originally learned to use Evennia from zero Python knowledge (he only knew mushcode) by reading our documentation and by asking questions in the community. I don't know if this has granted him the magical touch to make everything easy to use for "hobbyists", but I'll ask him.

If you're going for just the professional set, fine, but MySQL manages fine with the middle ground PHP manages fine, there's no reason Evennia can't except that the current project lead designer pushes back every time it's mentioned.

I find it a little bit unfair to say that "the lead designer pushes back", when I'm just asking for clarification on what you mean. It's not easy to know what others find hard so discussions like this is invaluable. People's backgrounds and experiences are very different between the different branches of MU*-dom.

@faraday

Have you tried it? I am seriously doubtful given that you don't have root and there are serious memory
and processing constraints. And I didn't think it came with stuff to run a web app but that may have changed. Been awhile since I used them or any othe mush host.

Maybe they'd help you set it up, I dunno. My point was that you can't just hit the ground running the way you can with penn or tiny or rhost.

I have not personally tried it, no. But from the description it seems like a pretty standard host. I'd agree it's likely not the cheapest or best option, considering you'd likely need at least the "Deluxe" option memory-wise (more for a large production game). Python and GIT are standard packages for any server though and one should reasonably be able to expect them to be available, or ask them to be. As for web services, Evennia is its own web server and runs its own SQLite3 database-as-a-file (unless you want to use MySQL/PostGreSQL/Oracle you don't have to), so it needs no other programs server side and no further root access.

I see your point though, sure. It's great to have an obvious place to go to host and start your game, no denying that.
.
Griatch

@faraday said in [What is out there? Hard and soft codebases of choice.](/post

I am a programmer. I am not a system administrator. When you tell me: "Oh, you 'just' need to install SQL, and install Django, and install Python, and do this, and do that, and configure the web server, and get a DNS name if you want one, and oh by the way don't forget about all the security updates..." I just want to run screaming in the other direction.

Contrast that with a typical MU* host where you go to genesismuds, click on a few things, and now you have a shell account for mymush.genesismuds.com where all you have to do is install the game itself with a couple make commands.

(This is not a problem unique to Evennia, btw... I'm struggling with the same thing on AresMUSH. Trying to make the install/config as painless as possible is my #1 goal.)

Well, genesismuds could be used for Evennia (and Ares, I presume) too, it's not like that has anything to do with MUSH per se - it's just a shell account marketed to mu*ers.
Presumably they have Python (and Ruby) installed on their servers or one could ask for it to be. And you don't need to install SQL, nor Django for Evennia yourself. At that point of the install you do pip install -e evennia and it fetches all the dependencies and install them for you.
.
Griatch

@Thenomain said in What is out there? Hard and soft codebases of choice.:

I still don't know Django. Installing Evennia, more than just getting the raw code on my computer, is still daunting as hell. I strongly support @faraday's notion that it's a rough toolkit, maybe a framework, and little else.

We often refer to it as a framework too, although Evennia is pretty fleshed out for a framework, with a lot of resources and a full server+webclient+website out of the box. Could you elaborate more on what you feel is "daunting as hell"? Are you referring to how to start doing stuff in general or how to install with this particular statement?

Compare to, e.g., the Mushlikes, where once installed you can log in, and roll up your sleeves and get immediately to work. Look at nearly every web-based service that you can try for free, too. Sure, none of these may do much, but you can monkey around and build monstrosities on your way to build more complex monstrosities.

This concept of "being able to just jump in" appears to be a common notion here. For a person who wants to create a text-mmo but is not knowing any programming (or those that do but never saw mushcode before), is a mush server really that much easier as a starting point? Learning a new system is never easy. In Evennia's case you need to read documentation and if you are wise you ask questions in our community. In Mush world you likewise need to read docs and talk to people in the community for help. For a beginner there is still a language to learn and idiosyncrasies to get used to, either way.

They also try to keep the metaphors simple. Here are CONTACTS. You can MESSAGE one. You can MESSAGE many; we call this a CHAT. Here's a PLAYER, here's a ROOM, here's a THING, these are all OBJECTS. You link rooms using EXITS. Before you know it, you have learned some basic hierarchical object-lists.

I don't really know if this is a general observation or something I should reply to. All those concepts are almost verbatim present in Evennia at any rate.

The Mudlike mentality went the other way. "Oh, you know C and C++, just mess around with the server until it does what you want." Evennia is very much like this.

I don't see a difference between your two examples. One says "mess around in mush code" , the other says "mess around in these other languages". If you previously know one and not the other, obviously that one will be easier. Plus hardcode allows you to use a real text editor rather than being locked to the telnet command line (depending on your bias that last sentence could be written as "hardcode forces you to use a text editor instead of being able to modify the code in-game", I guess.).

"You don't need to know Django, but run it and do this and this to set it up."
Okay, what do I do once it's set up? "The same thing but don't install it." Um, what?

I'm not sure exactly what you referring to here; A wild guess is the use of the virtualenv (correct me if that's not it). Brief tutorial-mode voice: You start a "virtualenv" when you install. This is a virtual python environment containing all dependencies of Evennia in a separate folder. This allows you to install everything Evennia needs also on a remote computer/server without root access. It also makes it easy to update requirements without affecting the version of the same libraries installed globally on your system (those are often older). This means that when you start Evennia in the future you must make sure this virtualenv is active first, but you obviously don't need to reinstall everything anew every time - that may be the source of the "same thing but don't install it"-comment.

What I'm getting at here is Evennia has no middle ground. There's no playground for it, no toys, and while it's easier to follow than Mush server code it's still not terribly, oh, what I'd call simple. It's an end-point, by design.

It's not simple, no. Evennia's a full-fledged development "framework", to borrow your term from above. Making a multiplayer online game will never be truly "simple" I think. We do offer contribs with pre-made code to build from. This library is slowly growing but could certainly be more comprehensive.

I disagree with Evennia having no toys though. It's all toys. Toys you put together with great freedom to create your own game. Python is very good for creating cool stuff with little code. But yes, if Python is completely new to you, you will likely start by following tutorials and copying examples or code snippets handed to you by the old-timers. I can't imagine this being any different from how most learn in a mush environment either.

What I'm also getting at here is that Mushlikes have no higher ground. They're getting there; Muck started it, Penn dabbled, Rhost is making a stronger push, but building a web-side interface is... okay, Muck has been able to do that for a decade, but I'm not learning Fortran.

As someone using Fortran professionally on a daily basis, I would agree that noone should have to use it for recreational coding ...
.
Griatch

Sorry for the double-post, but the other post got a bit long.

@Ashen-Shugar said in What is out there? Hard and soft codebases of choice.:

As @Griatch can attest to, the devs of RhostMUSH are pretty open on interoperability. In so far as even opening a dialog with @Griatch once we get around to finally writing our Python API so that Evennia and Rhost can talk to each other on some level. Cross-compatible python modules for the win!

Yeah, it's a cool idea, it will be interesting to see if we can get some cross-compatibility going there and how big the differences will end up being once your API is in place.

@faraday

Yeah, I'm with you on that one. On many games, players aren't allowed to code much (if anything) anyway.

This is my impression too, but I guess the mileage varies.

I think this is the core difference between Evennia and AresMUSH, which is my MUSH server in development. Evennia seems to be more of an open framework - "build whatever you want" - with a presumption that you are tech-savvy enough that you've either started with a Python dev environment or can figure it out.

This is probably true, from our previous discussion of the differences. Of course, once you have the server running, the minimal "Python dev environment" in Evennia's case is basically a text editor and that's it.
.
Griatch

@WTFE

Go there. Count the noun objects. Count the managers, factories, models, etc. Some of that kind of stuff is useful and necessary, but what I see in that API reference is a shopping list of design patterns. Of nouns and only nouns.

Professional developers steeped in (the utterly broken and failed) modern OOP software methodology will not find this a problem.

HOBBYISTS will.

That is a ludicrous number of noun objects there.

Which is not very relevant for Python that has no problem to support functional programming …

BWAAAAAAAAAAAAAAAAAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!

Python certainly has limited functional programming paradigms compared to something like Lisp. It does support many aspects of it though, especially compared to Java which is used in that example. And Evennia is using functional paradigms a lot even though you are certainly right that entities in the database are represented by classes and there are many situations where we use class-based handlers for managing data.
Anyway, if you hate OOP and think "hobbyists" as a whole can't enjoy it, I guess we just have to agree to disagree.

Linux.

That is curious, it's usually a very smooth process on Linux, even for those claiming to blindly follow the quick-start instructions with little understanding. Guess you found some edge case. Sorry about that.

There is a briefer point-by-point summary up top but the main install text is indeed pretty lengthy. It's possible we can cut down on that; the text is explaining how to set up things also for those without any previous Python environment.

Look to Textadept for how to do this right. Textadept is a code editor built on Lua, GTK, etc. Its build process downloads all the stuff it needs and builds a local copy, thus guaranteeing that the correct (compatible) version is installed and ready to rock. (The documentation for building Textadept is atrocious -- it's by no means a perfect package! -- but the bit about bringing in its own prerequisites and building them in a local copy is dead perfect.)

I looked at Textadept, thanks! Textadept is a compiled C program with embedded Lua. It does fetch Lua script libs (it looks like) during the install setup process but you still need to download the actual dependencies (GTK, ncurses, gcc compilers) before you do that. Their documentation is brief and to the point, presuming one knows the GNU compilation process beforehand.
It's a fundamentally different type of program than Evennia (Textadept is a stand-alone binary with no particular wish for you to dive into their code) but I concede that for me, who already had all the dependencies, it's indeed a breeze to compile from source.

Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running pip install -e evennia.

If it's a "standard practice" WHY THE FUCKING FUCK IS IT NOT AUTOMATED!?

It's a good notion, we could by all means look into offering a build script for setting up the virtualenv for those not keen on organizing their own development environment on a particular OS. Any way to quicken the route for newcomers to check things out is beneficial.

Again you're acting as if your users are professional Python developers. If this is, in fact, your target audience, feel free to ignore my critique. But holy fucking shit, if this is your answer to fucking HOBBYISTS you really, really, really, really, FUCKING REALLY need to take a semester or ten of human/machine interaction courses!

No, your critique is appreciated! Many of our users are indeed professional programmers but that does not mean those are the sole target audience - the MU* world is not big enough for that. We have a slew of people learning Python and even learning programming in general on Evennia. If the install process is perceived as "utterly god-awful" by someone new to it, it's worth looking into (it's the first time I hear that, which is why it's a little surprising to me).

Evennia does not allow unprivileged players access to programming tools out of the box, this is true (see also Evennia for MUSHers for some more elaboration on this). I can see the value of this argument if you want your players to explore coding as part of your game design.

Fuck the game design, the question is how do you get people from being players to being people who build games with your framework?

Presumably by being a good codebase that developers like to use? As I've said before, I can see the advantage of softcode in the sense of fostering immediate experimentation directly in-game. The validity of the argument comes down to how many players actually make use of this functionality for more than copy&pasting a snippet or making very primitive improvement-of-life things. Such uses Evennia supports too, and without resorting to full softcode.

I have no doubt that softcode will remain strong for a long time to come. And if building an entire complex game system (not just simple things) line-by-line over a telnet bridge is a requirement for your enjoyment and learning, Evennia will likely never fill your need.

I'm pretty sure every one of the semi-legendary MUSHcode softcoders out there started off just playing around with softcode on MUSHes, making dumb little functions and commands like my random ANSI example above. This is stuff that has no material impact on the game, but is a) fun to do, b) engages users as they find ways to write things that are convenient for them in your game, and c) acts as a gateway to more serious development.

I have no doubt this is one avenue into programming. Conversely you can of course argue that DIKU is the more popular codebase out there by far (definitely in the amount of games it has spawned). And that is despite it having no concept of softcode and requires the budding game creator to learn and code in (archaic) C outside the game.

I'm not sure it's all that relevant for you downloading Evennia though? After all, you have all the exploratory tools available at your fingertips.

I'm looking at a far wider picture than you're looking at. You persist in looking at "only professional Python developers" in effect. I'm looking at "how do you make people who aren't professional Python developers interested in using your product?"

(Hint: if it's "read this document and follow the 18,000 lines of instructions in it to run your very own server, that's a non-starter.)

The beginner's perspective is always useful, it's indeed hard to know what is difficult or not with something you are inherently familiar with. It is the first time I hear that much vitriol against the install process so it's worth to consider. Evennia seems to be considered to be a pretty easy system to use by most beginners, but maybe there is a selection effect with critical voices failing at the install process and not telling us, I don't know.
.
Griatch

@WTFE said in What is out there? Hard and soft codebases of choice.:

@Griatch said in What is out there? Hard and soft codebases of choice.:

An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?

I won't elaborate on it. I'll let the guy who coined the phrase do it for me.

The way I interpret that is he doesn't think objects should make the work of functions. Which is not very relevant for Python that has no problem to support functional programming where it makes more sense. Evennia uses objects for example for Commands for a very specific reason - functions are too limited for the functionality of Commands. In other places (such as for creating menus or spawning mechanisms) we instead rely on functions because the complexity of an object is not needed.

I would need a more concise example of what you mean here to reply.

As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!

Well, item #1: the Evennia installation process is terrible. I mean utterly God-awful. When I finally got something that worked, I was never actually quite certain if I'd done it right or if I'd merely stumbled accidentally over a configuration that would work right up to the point it stops. Work on your installation process and please, PLEASE, PLEASE, PLEASE, MOTHERFUCKING PLEASE cut down on the number of "install this, then install this, then install this, then configure this, then do this, then do that" steps. An ideal setup process should involve one step: ./setup (or equivalent). You're not making enterprisey software here. Enterprise management are idiots and will tolerate things like Entrust's fifteen-stage (with three reboots!) installation process. Hobbyists ... not so much.

I'm sorry to hear you had issues with the install process. Which OS did you install on?
There is a briefer point-by-point summary up top but the main install text is indeed pretty lengthy. It's possible we can cut down on that; the text is explaining how to set up things also for those without any previous Python environment. It also helps to troubleshoot known issues . Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running pip install -e evennia.

While we will eventually also put the package on pypi (so you can get evennia with pip install evennia), using GIT will likely remain the most convenient way for developers to access Evennia since that gives easy access to the source for reference. For the same reason we can't really distribute a monolithic binary. It's great with feedback and critique though, thanks for that, we'll try to take it to heart to make things easier!

Item #2: There's very little that can be done in the environment itself. Yet doing things in the environment itself is the very essence of explorability. Everything in Evennia is done out of band. Compare and contrast with MUSHes (terrible as they are!) where any user can go in and start tinkering around with MUSHcode like this:

&FUN_ANSIFY me=foreach(me/fun_randansi,%0)
&FUN_RANDANSI me=ansi(+[randword([colors()])],%0)
&CMD_ANSIFY_CHAT me=$.ca *=*:@chat %0=[ufun(me/fun_ansify,%1)]
&CMD_ANSIFY_PAGE me=$.pa *=*:page %0=[ufun(me/fun_ansify,%1)]
&CMD_ANSIFY_TALK me=$.a *:say [ufun(me/fun_ansify,%0)]

I mean seriously, this is an incredibly crappy programming language ... but it's a programming language available to the end-user at point of usage. This fosters explorability.

Evennia does not allow unprivileged players access to programming tools out of the box, this is true (see also Evennia for MUSHers for some more elaboration on this). I can see the value of this argument if you want your players to explore coding as part of your game design. I'm not sure it's all that relevant for you downloading Evennia though? After all, you have all the exploratory tools available at your fingertips. You can explore and code to your heart's extent without any compilation and you will see the results of your work in-game immediately after just a @reload. And you can also experiment directly in-game by executing Python directly from the command line with @py.

In my youth BASIC was the gateway drug that led to an explosion of people learning to program. BASIC is a shit language, just like MUSHcode, but it was better than any of the alternatives available at the time because it was a shit language that was there in front of you. You typed at it and it gave you its (sometimes insane) response. It was BASIC and this explorability that led to where I am now almost casually doing R&D work in embedded systems. If I'd grown up in the Dark Ages of Exploration (the '90s and '00s) I'd never have gotten to where I am now.

BASIC was great on the Commodore 64 in the 80's (which is when I came into contact with it). And I can see the argument about having the code at hand if you want a game where unprivileged players can get creative with code. I cannot really relate to this notion (anymore) as a game developer though - the immediacy of the telnet just doesn't outweigh the advantages of a proper development environment (to me).
.
Griatch

@Groth

My main issue when I tried out Evennia is that it felt a lot easier to just ignore most of the Evennia abstraction layers and use Django directly because the Evennia storage obfuscates the data relationships.

I can certainly see this, especially if you are coming from a background where you are used to manipulating sql directly. Evennia allows you to write a game writing mostly plain Python with little knowledge of Django. The ability to extend with your own storage/web solutions through Django is not anything obscure or hackish in Evennia though; it's covered in some detail in our documentation for those that need it for their particular design.

@Hexagon
Aye, it's indeed always a good idea to look around to see how different people have tackled a problem independently of each other.

@WTFE

An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?

As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!

OP: sorry for what may be a bit of a derailment of the thread...
.
Griatch

The way I've seen pose order (on muds) has been as a command people can invoke as needed ("turns"). When that's called, emoting turns is enforced in that location. I've only seen it used in very crowded scenes to manage a chaotic rate of emotes; this is when people's varying writing speeds become an issue. People would use it to stem the tide and avoid being overwhelmed or stressed out. Has worked fine far the times I saw it implemented.

A blog summary of the latest stuff happening in Evennia-land, including referencing Arx Mush.

http://evennia.blogspot.se/2016/10/season-of-fixes.html?m=1

(Evennia is a mu* development framework used by for example Arx)
.
Griatch

@Jennkryst said in Issues with SimpleMu:

@Griatch Spawns are separate windows with only certain things in them. You could have your primary window with the majority of your stuff in it, and have, say... Channels as a spawn window. So any line that begins with [Public], [Wiki], [Rules] or [(anything else)] automatically gets sent to that window, instead of your primary window. You pick the trigger that sends it to the spawn.

Ok, thanks!
.
Griatch

@Arkandel said in Issues with SimpleMu:

I paid for SimpleMU* back in the day but I'd be happy to ship out a few $$ again for something I use every day, it's just that other clients either don't have as-you-type spell checking (which I find very handy) or spawns (which I find absolutely essential).

Without having used SimpleMu, what does "spawns" do and what makes them essential?
.
Griatch

@Thenomain said in Necessary tools for running plots as a non-staff player?:

@Griatch said in Necessary tools for running plots as a non-staff player?:

@Apos said in Necessary tools for running plots as a non-staff player?:

@Arkandel Yeah I agree 100%, I mean if a tool is too complicated then at best it won't be used, at worst it'll discourage people from not even trying to PRP since it'd turn them off from it.

It sounds like a prime candidate for using EvMenu actually.
.
Griatch

Do you have any links to same? Thanks.

Yes, sorry - EvMenu is the name of Evennia's in-game menu builder tool: https://github.com/evennia/evennia/wiki/EvMenu . People use it for everything from NPC communication trees to character generation, custom login menus and other in-game interfaces.
.
Griatch

@Apos said in Necessary tools for running plots as a non-staff player?:

@Arkandel Yeah I agree 100%, I mean if a tool is too complicated then at best it won't be used, at worst it'll discourage people from not even trying to PRP since it'd turn them off from it.

It sounds like a prime candidate for using EvMenu actually.
.
Griatch

@Apos said in Necessary tools for running plots as a non-staff player?:

I see what you mean, I guess if one codified the overarching metaplot enough - into locations, characters as well as critical story elements like "the plague" or "The murder of X" one could track their use using such a system.

So to follow the VCS analogy, do I understand you right that people sort of "check out" story elements that they intend to use in their plots and "merge them back in" once they are done? With the added feature (going beyond VCS) that people could also find out what is "checked out" at any given time ...?
.
Griatch

@Fantom

I must say that's a very nifty and thematic website.
.
Griatch

@Apos said in Coming Soon: Arx, After the Reckoning:

Updated to the new version of Evennia to finally merge that ancient fork, and on a new VPS- 45.33.87.194 port 3000. Think we fixed most of the bugs related to the swap but yell if you see anything, and channels will need to be readded.

Congrats on getting through the update! Also thanks for the input, fixes and discussions the conversion spawned on the Evennia side; beneficial developments for all!
.
Griatch