Posts made by Griatch

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

Having thought a little bit more about what tools might be extremely useful for organizing plots, it occurred to me that a lot of the common issues facing staff and non-staff storytellers aren't really all that dissimilar from a design perspective as version control, like in coding. The games usually aim to have one big central continuity and story state, so characters can interact with one another, but there can be any number of contributors each starting their own branch with a story that potentially forks it off when things become mutually contradictory.

So it seems like we could use the same principles in creating overview tools that would let any storyteller have a much, much easier time of seeing what all story elements are currently in play in plots (and would present potential collisions/contradictions), what all is being decided, and just when a plot is being resolved and could be merged/pulled back into the overall plot of the game. So not unlike what @surreality was thinking about with wikis, but for my case, would just be using django to create a hierarchy tool with the current existing plots, sorted by their different plot category elements, whether they are resolved or ongoing, who's running them/who is participating, and whether any elements need resolution due to conflicts with other plots. Hell, could even automate it with categories for plot elements, like in a wod game if someone put in a plot that was involving the police or an antagonist group, the tool would just check what other ones currently were ongoing, to see if there would be potential story conflicts. Just things to make communication between storyrunners a lot easier and simpler.

This sounds very interesting in principle. I can see the overall gist of using a version control paradigm but I have a harder time seeing how to efficiently break up a plotline in a way to make it easy for players to branch and merge without a lot of manual management. Could you give some example of how this could work, in practice?
.
Griatch

@Lotherio

A tool that isn't code based but is necessary is policy or understanding of what non-staff players can actually run on their own versus stuff Staff are likely to retcon (and thus lead to falling out and game death in the other thread).

Yeah, clarity from staff is undoubtedly something that must be assumed before going into the mechanical contrivances.

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

@Griatch I like that escalation system - as long as the interface for the players can be non-nightmarish. It can be a simple flag, marking a particular post as needing staff intervention.

The process then would be like this?

1. ST runs stuff, it resolves, people have off-screen things to do about it.
2. Someone (the ST or a player) creates a thread, tagging everyone else into it.
3. If possible all things happen internally, the ST asks for relevant rolls, people pose questions, it's done and the original owner can close it (plus anyone can leave the thread at any time to stop getting spammed if they lost interest). It'd be ideal if the ST can make posts visible to just a subset of the players tagged in the thread.
   3a. Someone asks a question that's not the ST's call to make on post #13 on that thread. The ST answers that and flags post #13 (which staff can see - I don't know how Evennia's staff interface works so I can't help there )
   3b. Staff has whatever time to answer it. They can answer to the ST only or make it visible to everyone tagged. If staff do not answer in the default time, the ST gets a notice about it and acts accordingly

Yes, sounds like what I had in mind. Since you mention Evennia, I would likely consider the "thread" here as a type of "channel" (I presume you don't mean quite the same thing?). A channel is, the way I use the term, nothing more than a message re-distributor; you could use a channel to send a mail to multiple recipients as much as you could use it for chatting.

A "message" in Evennia is a rather generic object that can represent mail as much as a line in a channel chat or a tell. Each message can in principle have its own meta properties and tags as well as be database-persistent. Thus you could easily create a message object with any set of recipients, from channels to groups of players/staff. You could for example have a message that goes to an admin-only channel at the same time as it goes out to a small sub-group of players or to the main plot channel.

To answer your addendum though about needing a paradigm shift, the current +job system doesn't always work optimally. For example on Fallen World we ran into several issues and in the end had to get @Thenomain's intervention to help out; for instance we couldn't CC players to a job without staff doing it, then the comments we made had to be manually published else they were invisible to non-staff (which is what he fixed for us). In the end that was obviously not very optimal.

There are additional things that could be improved - there's no obvious way to flag a +job as being potentially interesting to staff for example. Or to mark them as private (maybe staff have alts, and they wouldn't want to see information that might be sensitive, both for their benefit and other players'). A common issue, too, is if one player runs an investigation and I give them the results - now there's no systemic way for me to announce them to just that player, which means they can't (for example) fake the results, or only report partially on their findings.

To continue the Evennia example above, if one didn't want to use the strict sender-recevers paradigm, one could instead use tagging, where messages are stored in a pool that is filtered by the tags set on each message. It'd be a simple thing to make a command for viewing the "job pool" based on the permissions of the players/staff and the tags/locks set on individual messages by STs. Players would have permissions to view only messages with the tag of the plot they are in and/or messages particularly tagged to them while admins would default to seeing only those particularly flagged for them to handle. Such a system sounds like it should be general enough to handle most custom cases mentioned - it's just a matter of allowing more tags to be set in combination with more ways to filter the pool.

Finally, the fact this is over telnet itself is a limitation - a thread can get pretty long, but if it's over the web maybe we can have nested comments and sub-threads, making it far more convenient for future reference.

The telnet text limitation is something that can be worked around with OOB telnet instructions using a client aware of, say GMCP or MSDP to put such things in separate windows with custom GUI elements. Mushclient supports this as far as I know. Mudlet is another example. Easiest is of course to handle it in a web client customized for the purpose, then you as the game developer has the control over both client and server at the same time ...
.
Griatch

@Arkandel

For example @Griatch's timeout suggestion won't work. Imagine I run that Orc invasion story and players ask to talk to the village Mayor - he's my NPC, the entire village is part of this one story, right? Then when players fire off an investigation which goes to staff and waits there while both I and the players are twiddling our thumbs, we'll end up realizing we're better off handling it ourselves without involving staff, through pages, which is the exact opposite of what a system should do. It ought to facilitate and improve, not get in the way. A system people need to circumvent is not a good system.

This is very true. You might indeed be correct that a simple one-level system is what people would actually use - a superior solution, staff control be damned. At any rate, I pictured the timed-out alternative something like this:

• Player: "I'm asking the mayor about the recent dissappearances"
• ST: "Sure, this is what he says ..." [because the mayor is the ST's NPC]
• Player: "I want to figure out if this village is actually located over the hellmouth."
• ST: "Uh, I don't know the answer to that question in the lore, I'll need to defer that to staff ... hold on"
• [ST easily forwards question up one level to staff, with appropriate meta info as to the context it comes from]
• ST (If Staff returns with the answer): "You are not sure but you think you smell brimstone ..."
• ST (If request timed out): "[well, staff tells me it's up to me so ...] yeah, the hellmouth is totally real, dude." .

... But anyway. I was just theorizing based on what I read in @Apos' post. Some games use extremely contrived systems (such as rumor systems) that get used just fine. It doesn't seem obvious to me where the simplicity-vs-features balance lies without starting to analyze the particulars of a given game, theme, style and player base.

Edit:
@Arkandel
Your mention of the need of a paradigm shift is interesting in itself though. This need suggests problems with the "old" paradigm. Maybe it might be instructive to list bad things about the way things are most often currently handled? No disrespect to those that created those systems of course - just in the interest of constructively identifying where things could improve.

.
Griatch

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

Something I've always wanted for player plots is an "overlay" system of some sort; a way of making a locale change according to events playing out.

For example, my crime family uses a dance studio as a money laundering facility. The description is … well, it's a dance studio. Normal dance studio shit. The wall of mirrors. The wooden bar. The padded flooring. Depending on time of day the students, the teachers, etc.

But …

Today the Ruprecht gang has decided to take on my funding and attacks the dance studio with flame throwers. This would tend to, you know, modify the site's @desc. But of course it can't. Because players don't have the ability to modify the grid. (WITH GOOD REASON I might add!)

What I'd really like, though, is some way to supply modified descs for rooms. Perhaps a way even of storing them locally and swapping them in and out like various clothing code some MUSHes have. +rdesc/change holy-shit-its-on-fire or something like that. This would give player plots some actual presence on the grid. It would still permit the use of rooms for other purposes (playing out time-bending scenes; background events, etc.) while making it such that player plots can have actual impact on the setting. Visible impact. People can go to their favourite corner bar and find that it's been trashed and vandalized. Or go to their classroom at the university only to find the chalk outline on the floor with the bloodstain over by where the head of the figure is. That kind of stuff.

Of course there's room for abuse with this kind of stuff, so you'd probably want to make it such that you need a permission attribute on the charbit to use it. Perhaps if people register a PRP they can temporarily get the permission bit. Perhaps you just give it to everybody but take it away from players who abuse it. Perhaps you give it to everybody after they've established themselves as decent players.

But this, to me, would be the dream feature for player-run plotting.

Some MUDs use "room poses" or "moods" for this: The main description of the room is fixed and settable only by staff. But then there is an extra field that can be set to appear after the main description. This "mood" is settable by anyone and represents the current state of the room, from a tavern being full/empty to fires and local damage. Some systems let the mood "time out" after a certain time, reverting the room to its base description.

As long as the person setting the mood is stored for staff for see it should be fine. I've not seen it abused at least.
.
Griatch

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

Yeah, I think we'd need to have something that wouldn't be able to get hung up and just sit there for forever while a half-dozen players are waiting for stories to go on. Which probably mean going immediate to players that can answer it, with the potential to be escalated to staff if needs be, rather than the reverse. The trick there, from a macro perspective, is making sure that things don't have contradictions or continuity breaks that can force the game into changing into a sandbox due to a lack of staff oversight- but even though that's something I wanna avoid it is definitely the lesser of two evils than plot just dying because it can't move forward at all.

Yes, my first thought when reading the original suggestion you wrote was essentially the same as @arkandel's - "that seems like it would be a lot of work for staff". Balancing player-ST agency versus retaining some control over game plot quality is a potentially tricky problem ...

Having a system where players/STs could, with a special command or tag, escalate certain things to staff if they deem they are stepping into parts of the lore they don't know about sounds like a pretty decent half-way solution. Depending on how restricted the setting is and how often such escalations would happen, obviously. Being able to easily get back previous replies to quickly respond to similar-sounding requests from different players sound like an excellent time saver. I keep feeling there should be some sort of automatic mechanic here as well though, to avoid lockups.

Regex-based auto-replies is a good idea but maybe hard to regularize. Another idea may be to have a policy of default timeouts from staff replies. If an ST escalates a request to staff and staff doesn't get back to it in due time, the timeout will auto-reply to the ST that no information was found. A more extreme policy would be an auto-reply telling the ST that they can now make up the answer on their own since staff haven't fulfilled their end by replying in a certain time ... maybe that would put more stress on staff, but it would avoid bottlenecks on that end at least.
.
Griatch

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

Basically the Storyteller does something like +event/create Orcs attack!=<Synopsis>/<datetime> which gives it an id, announces it game-wide and adds it to a list players can review with +events. So if it's #3, they can then sign up for it with "+event/signup 3. Once the date is past it's taken off the list.

And the event code is henceforth only available to the ST I take it, as a reference as to who signed up.

What is the mechanics behind a +job? You make a post only the ST can see specifying the tools/skills/etc they want to use, and the ST then eventually gets back to you with a result? To get a feel for it, is this more structured than, say, a message board with private sections?

Again explaining it through actual use, but a +job in this context is essentially a single thread into which anyone tagged can post messages and send rolls into.

In this case I as the Storyteller would first start the thread by giving it a title ("Orc attack investigation") and an initial text ("Hey guys, this is for your investigating needs, tell me what you'll be doing"). Then I CCing my group's characters into it and they can start posting things in there ("Alright, so I'll contact the Mayor and ask if the Orcs ever troubled the village before"), etc - stuff that wouldn't necessarily be good enough to run an entire scene for. If needed I can ask players to make rolls into the +job ("roll empathy to see if the Mayor is lying").

I see, so this moves the game from (semi-) real time on-grid to a more abstract GM-Player like thing. Potentially Play-by-post almost, since it can be managed without ST and player being online at the same time.

It's important for this to be something players can do on their own without having to bug staff about it, including to close or leave the +job if it no longer applies to them.

I can certainly see the point of that, yes.

A "temporary room" meaning that you can create and describe a locale for your plot on a whim? To what extent do you expect to be able to perform coded operations on your room? That is, do you expect players to move between multiple such room or is this mainly a way to sequester players away from the main grid?

Only that a room exists and that a custom description can be applied to it is needed. If +places can be used that's great but even that isn't too necessary - I've never had to create a multi-room temporary environment before, it's just too much effort for something that's never going to be used again.

Sometimes they can even be places that already exist on the grid, but which you want to run as a 'snapshot'; say, there may be a museum already on the grid I want to have the PCs break into and try to steal a cursed artifact at 3 am, but I don't want to take over the actual thing because what if someone walks in or is already playing there and it's noon for them?

Aha, so from the perspective of a server coder, allowing the creation of rooms with such limited features is then quite trivial to offer technically.
The concept of colliding time frames appear in more MUD-style games too, although there there is seldom a possibility to simply make a separate instance of a location and people tend to just awkwardly RP around the fact that people are still RP:ing their evening visit to the bar while the sun rises on the next day in code.

This sounds interesting, I can think of a few different ways to roll, based on the way it can be done by a tabletop GM. What is the purpose of being able to ask a person to roll for specific people though? Because the ST doesn't know the character sheet of them?

Avoiding spam, and because you might not even want everyone to see there is a roll. Say, I rolled secretly to see if anyone might suspect there a trap in the room and only one has, so I ask them to roll awareness to me only; that way the rest of the group doesn't OOC know there is something sketchy to be aware of.

Oh, I see, you are talking about one person rolling on behalf of the whole group. That makes more sense. I first thought you meant you were rolling "for them" in a more code-mechanical way.
.
Griatch

@Arkandel

Tools to manage participants and juggle timezones are extremely handy. An event-based system where people sign up (and we can see the order they signed up in) where Storytellers can include some details about what they're about to run, what time etc is valuable. The order is important as typically there are more signups than there are slots, but some players might not show up, so you want to be able to run a fair first-come first-served queue.

I see, this sounds like a reasonable way to advertise what's coming. How is this maintained efficiently across multiple sessions, is there normally some coded reference of who signed up to a given "plot event" or is this something the ST needs to keep track of manually?

A fully player-ran +job system is a must. Typically running plot isn't merely a matter of scenes but communicating past them; if we have to involve staff that increases administrative overhead and introduces delays. A common use for it is investigations - the characters survived the dungeon, now they want to see who's behind all this by asking their contacts, making rolls, etc... it's very handy to have all that in a single thread instead of having to shuffle through individual @mails.

What is the mechanics behind a +job? You make a post only the ST can see specifying the tools/skills/etc they want to use, and the ST then eventually gets back to you with a result? To get a feel for it, is this more structured than, say, a message board with private sections?

Temporary rooms can be great. Sure, you can hijack a place on the grid but that can be problematic (say, you might want to 'freeze' the scene for just the characters in it) or there might not be something exactly as you like.

A "temporary room" meaning that you can create and describe a locale for your plot on a whim? To what extent do you expect to be able to perform coded operations on your room? That is, do you expect players to move between multiple such room or is this mainly a way to sequester players away from the main grid?

+Meetme. Traveling commands in general. Events take a long time and they're spammy affairs as it is without the Storyteller having to help players figure out how they're supposed to get there.

I've read the thread and discussion on this but from the outside I've not fully discerned what +meetme does. My guess is that it invites someone else to teleport to your location, is that the correct description?

Combat-assisting aides can be invaluable. As a ST I use a text editor for table-top RPG systems but it can get pretty messy to communicate everything on demand- what's the initiative order again? How much damage has Orc #3 taken so far? And if there's a coded system (such as Arx's) then I'd need a way to spawn and control NPCs.

What kind of aides would this be? Like a command to show a critical hit table or more like commands to actually do particular rolls for you in a given system?

All sorts of rolling options. Show a roll to just one person, ask a person to roll for specific people, rolling into +jobs.

This sounds interesting, I can think of a few different ways to roll, based on the way it can be done by a tabletop GM. What is the purpose of being able to ask a person to roll for specific people though? Because the ST doesn't know the character sheet of them?
.
Griatch

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

I find public +sheets insanely helpful. This isn't something all games do or that every genre considers workable, but when it's there I find it to be a wonderful tool.

Maybe players could voluntarily list some stuff they want STs to have access to on games where this is less common, idk.

I presume the idea being that since the character sheet is visible, the plot-runner can dig into e.g. the backstory or quirks of characters and use that as part of their plot ... how much leeway would a plot-runner have in that regard - or is taking the character in unexpected directions part of the charm?

Hi,

I was reading @Arkandel's and others' posts in the Arx thread and the Game Death thread concerning the need and advantages to making it easy for non-staff to run plots. This made me interested in what kind of tools, information, resources etc you look for in a game in order for you as a non-staffer to feel comfortable/willing to run a plot the way you like it.

Coming from the Evennia side, I'm not overly familiar with the various MUSH terminology - so if you love a particular tool or concept, a brief mention of how that tool is meant to function or what the concept means would be appreciated for context.
.
Griatch

@Glitch

Okay! Too bad there weren't any more entries. The idea of contests like this is a good one to instill creativity and actually get stuff done with a deadline; ever since Optional Realities ran their contests I've pondered running something Evennia-centric along similar lines. Time will tell.
.
Griatch

@Ashen-Shugar said in Evennia for MUSHers:

pypy also doesn't cut the bill at the current base because it still has tags into the strict hardware layer itself of the server running under it.

So while it is marginally sandboxed, it still allows race conditions and jumping permissions by tagging into device drivers. So it's still half-baked as a security model.
It also has known memory leaks.

Good to know; hadn't looked too close at PyPy's sandbox in a long while.
.
Griatch

@Ashen-Shugar said in Evennia for MUSHers:

@Griatch said in Evennia for MUSHers:

@ThatGuyThere said in Evennia for MUSHers:

I was one of the big proponents of being able to use softcode in the last conversation and i still am.
Most of what I use it for basically to let me do tasks I do often quicker, such as WoD power activation, or shifting in places that did not have a shift code set up so I could make a quick shift command and have it macroed in to change my name, desc, etc to fit the new form my character had taken. Now every recent game I have played a shifter on has had shift code in place so it is less of a practical issue in that case anymore.
I have not had to really use any of my limited soft code tricks because now the games have things set up so there is less of a need to come up with them from a player side of things. though I still like having the ability to if the need should arise.

So if I understand you right, your main use case is to to alias commands to your own needs (such as entering something short to abbreviate a longer series of commands).

Out of curiosity, if you look at the example of Evennia's "nick" Command in the tutorial above, do you think that could replicate to some extent the aliasing you'd now use softcode for?
.
Griatch

Something you could look at (that I've not been able to figure out but you may have better luck than I have) is a sandboxed method to allow in-game transposing of a limited python or similar scripted language in-game.

The issue I always run across is using any mature language in-game allows too much control and allows escaping the sandbox to the server running below it. I've not yet found a clean and safe way around this. But I think that's the golden ticket for future mud based gaming. A mature language system in-game that allows a safe and configurable complexity in a completely safe sandbox.

I'm still poking at things, and if I find a solution I'll absolutely let the mud community know, but so far, no joy

Alas, I have already gone down this route and had to discard it. A few years ago I created Evlang as a plugin to Evennia. Evang was a highly stunted subset of Python where I used whitelisting to allow only very limited parts of the language to operate. For a while I was carefully optimistic about it.

The problem is that Python's awesome introspection ability is its own enemy here: the language is just so very flexible that you as a developer cannot honestly claim to have created a safe production sandbox even if you stunt it to the level I did - Python is simply not designed to be run by untrusted coders. After finding maintenance to be a big problem across Python versions and that people could use Evlang to (in an admittedly very deliberate and obscure way) build loops that ate all memory, I decided to scrap the Evlang project. I could not honestly claim to think it was safe. It's still available in one of the Evennia-organisation's github repositories if you want to take a gander.

The closest I know of a real Python sandbox is the PyPy project''s specially compiled python interpreter that offers that possibility. We have not explored this for Evennia but since you require compilation anyway it might be worth to look into.
.
Griatch

@ThatGuyThere said in Evennia for MUSHers:

I was one of the big proponents of being able to use softcode in the last conversation and i still am.
Most of what I use it for basically to let me do tasks I do often quicker, such as WoD power activation, or shifting in places that did not have a shift code set up so I could make a quick shift command and have it macroed in to change my name, desc, etc to fit the new form my character had taken. Now every recent game I have played a shifter on has had shift code in place so it is less of a practical issue in that case anymore.
I have not had to really use any of my limited soft code tricks because now the games have things set up so there is less of a need to come up with them from a player side of things. though I still like having the ability to if the need should arise.

So if I understand you right, your main use case is to to alias commands to your own needs (such as entering something short to abbreviate a longer series of commands).

Out of curiosity, if you look at the example of Evennia's "nick" Command in the tutorial above, do you think that could replicate to some extent the aliasing you'd now use softcode for?
.
Griatch

@Volund said in Evennia for MUSHers:

[...] you can count the amount of games that take full advantage of the MUSH-style on-line building these days on one hand. Most of the games I've helped make? Admin do not want people adding to the grid or making new channels or creating an NPC that wanders around the grid trolling people by listening to what they say and chatbotting back at them.

This is an interesting observation. In the first Evennia-related thread I took part in here on Musoapbox, some commenters rather sternly pointed out their need for player-accessed softcode in order to get optimal enjoyment from their game. I'm not involved enough in the mush world to have a feel for the overall statistics of this need, but it surprises me a little if, from what you say, only a minority of mushes actually offers player-open softcoding.
.
Griatch

@Apos said in Are MU* videogames:

@Griatch I've seen two definitions, the one you've quoted and this other one- "a game played by electronically manipulating images produced by a computer program on a television screen or other display screen." Which would mean text games are not considered video games, since there's no imagery to manipulate.

I would say your definition is just a slightly different way to say the same thing. The "image" your definition refers to is the screen image produced and manipulated by the computer to be sent to the video device at a certain rate. It has nothing to do with graphics or indeed what is on that screen image, just that you manipulate it in a game context (as in sending different text to it depending on your input). All in all, the definition of the term "video game" seems quite clear-cut. That some of the original video games - the text-based games - should not be included in this group is a strange notion.

And yes, playing games over skype does fall under the definition of "video game" although I agree it's not commonly referred to as such.
.
Griatch

Of course they are. "Video game" is just a term for playing a game on a video device - originally a TV, today a monitor. It's very generic and definitely includes text games.
.
Griatch

@Ashen-Shugar said in Dreams to Reality:

Eventually what I would love to do with this as well is once we got the environment set up to be able to work with Evennia and exchange python modules so that we could literally swap them on the fly between our codebases like plugins.

But that's the distant future.

That's a cool idea, a bigger body of generic MU*-related python modules can only be good for everyone. Realistically I suspect Evennia's command-system (dynamically combining cmdsets) works so differently from Rhost that it would likely be hard to use many of our command-based plugins as-is. In the same way, our objects are inherently tied to our database schema. So if one wanted to use those one would need, I don't know, some sort of emulation layer ...?

Rules-modules and text-manipulation utilities that are not tied to Evennia's commands or database could probably be adapted more easily though - and vice versa similar types of Python modules made for Rhost could probably be adapted for Evennia.

Worth to keep in mind as your development continues. Let me/us know if you want to compare notes at some point.
.
Griatch

@Ashen-Shugar said in Dreams to Reality:

Multi-threaded in that the python scripting will launch separately from the mush engine.

So you submit a request to the API and it then goes off and executes its thing then when finished returns the values and results to the mush with a notification layer.

There'll be two methods. A single-instance (works like a built in function) and a multi-instance (or multi-thread) that will work a bit like the built in semaphores.

So one instance is layer -> python -> result

The other instance is layer -> python -V -> continue -> python -^ -> result

Where you start by (V) pushing out the request to the python, and at some later point you get a notification state (^) saying the result is complete.

Thanks for the elaboration! So to translate to terms I'm more familiar with, you will offer one sequential in-process call (which is blocking I presume) and also one asynchronous version involving a call to python running in a subprocess (or even launching a new python instance per call?) with a callback for whenever it returns. Sounds good!
.
Griatch

@Ashen-Shugar

python API -- Preliminary development. There's no real backend code for it yet but the design implementation is solid and we just have to do it. This will essentially do a multi-threaded API engine that will allow a server-side python scripting to be tagged and interpreted right into the core MUSH. So all the power of python with the pre-existing mush language.

This sounds awesome, kudos for giving more Python to the people! It will be interesting to see how the Python API will look. Also, when you say "multi-threaded", how do you intend to do true multi-threading rather than asynchronous event-loops without hitting the GIL - or are you referring to launching multiple python interpreters in separate processes?

... but anyway, to stay on topic, I'm partial to Evennia but that's maybe not too much of a surprise to anyone.
.
Griatch

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

My biggest complaint about the Evennia platform so far must be the way it silently disconnects you and just swallows any commands you send instead of severing the connection.

It means at any one time you have no way of knowing if you're connected or not without manually sending something to check for response.

@Groth

I am not aware of any issues with a "silent disconnect" in current Evennia. If you do see it with a recent Evennia version (i.e. not the one Arx is running), please consider making an issue report about it.

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

Yeah, I absolutely agree and it's something we've talked about a good bit and it's on our to-do list, though unfortunately we made some changes that make a port over an extremely difficult and time intensive project (which is something I still kick myself over). A port over will still happen, since it can only make life easier in the future after it's done, so I think we'll do it as the next big project after the empire-building type systems have a basic functionality that people can play with.

The only real blocker is the custom change(s) you did to the core database schema. Once that is moved into more compatible alternatives, updating to latest Evennia will not be too bloody.
.
Griatch