Posts made by Griatch

@Glitch

On the road, so need to keep I brief. What you send in msg(oob=...) is not a string. It's an OOB-command call + arguments, sent as a tuple. The available oob-commands server-side is specified and registered with the oob handler as normal Python calls. This is then sent on to the protocol (telnet or json/websocket). In the case of the current webclient, the oob function name is generally associated with a js function in your client code, which is then called with the specified arguments.
You are correct however that the default commands universally tends to use the text channel over the oob channel. This makes a lot of sense for telnet, where oob happens via subnegotiation; for the webclient it makes less sense and the text channel will soon (tm) be collated as just another oob instruction.
.
Griatch

@Arkandel

I wrote a rather lengthy tutorial that covers most of the things you want. Alas I'm traveling for Christmas and won't have time to work on it before New Years ... so it's thus not fully complete nor tested and may likely contain bugs in example code. But if you keep in mind these caveats you can peek at the current state here:
https://github.com/evennia/evennia/wiki/Evennia-for-roleplaying-sessions

It will have to do for now. Enjoy!
.
Griatch

@Arkandel

This would all be Python.

Is the plan to only have a single group of players or multiple groups working independently in different parts of the grid?
.
Griatch

@Arkandel said:

No, no need to be graphical at first (although I could add it later so there's a visual way to move around that doesn't require a CLI of any sort). Just a standard set of commands to move manually around, 'teleport' to a specific room and summon people over would be more than sufficient.

Digging rooms, moving between them, creating/destroying objects as well as things like @teleport is in the default command set. There is no "summon here" out of the box, but having a custom command to teleport a list of people over would not be hard to add.

Great! Ideally this could include custom made channels - one of the most annoying things about paging is CCing multiple players at once.

As I recall, the default emit command can target any number of recipients at the same time. Since the server does nick-replacement on the command line, you could (using the @nick command) make a nick for a group of players and use that to address them (the emit command will get all the target names as usual).
Channels are otherwise included by default. In fact, the messages are standardized, so you send the same "type" of message object both as PMs and to channels, only difference is how they are redistributed.
.
Griatch

@Alzie said:

@Griatch I'm not sure why, but a lot of things got reverted. I'm probably the cause of this. But the web socket client was disabled. I'm also not sure why it doesn't work but I don't really have the inclination to fix it.

If you do decide you want the web client, it's likely a simple fix; the client even reports the error and the suggestion for how to fix it.
.
Griatch

@Arkandel said:

I've been thinking about relaunching my web-MU project. So let's see:

1. A web-based interface supporting a 'grid' - i.e. multiple rooms players can pose in.

Hm. So what do you mean by "grid"? A graphical map? Or just the ability to move between multiple rooms using move commands? If the former, that would require some custom javascript coding in the client, it's not something in there at this time. If the latter, this is standard out of the box in Evennia.

2. Permanent sheets per character with customizable stats and a way for admins to view and set them.

This would be handled by a few custom admin-commands coupled to a sheet display that can be created using one of our utilities. A nice little project.

3. PMs between players.

Already in there.

If there's a tutorial supporting that for Evennia, @Griatch, then I could figure out the rest from there. I haven't coded in python in forever but it could be fun.

I'll probably not make a tutorial for extending the web client with a graphical map at this point (if this is what is desired) but I'll look into a tutorial on how to combine the various parts of Evennia into something fitting this particular (and comparably straight-forward) use-case.
.
Griatch

@Alzie

Just so you know, it seems your websocket url is not set up right; the webclient does not seem able to connect. If you don't want to support webclient connections, you should probably deactivate it completely in settings and remove it from your http://radialblur.vertinext.com/ homepage.
.
Griatch

You could try a vanilla Evennia install. Without further modification you'll have
chat/pose capabilities, can build/describe rooms. You also have npc puppetting, channels etc but it sounds like you more want the writing parts.

While it could be (pretty easily) added, there is no rp logging out of the box, but if you are willing to use a separate mu client, that could be handled that way (currently our web client doesn't log).

If you could succinctly list what kind of features you'd want from your environment I could look into making an Evennia tutorial for how to add in eventual missing features.
.
Griatch

Good replies, thanks. I was not aware SimpleMU was still such a commonly used client.
.
Griatch

@Bobotron said:

There's also BeipMU which I've seen people use.

That was a new one for me.
.
Griatch

@DnvnQuinn said:

Sometimes for the flashing text setting the server display to color256! (or whatever that command is) will fix it.

Not sure about the overlapping text. It appears to pick random words/sentences to overlap. Most will appear fine but in each paragraph theres a bit that overlaps, if you select it, like you're going to ctrl-c it, it desplays normally.

Sounds weird indeed. I'm not involved in mudlet but it sounds like something worthy of making a bug report to them about. I don't recall seeing similar artifacts on Evennia, but I haven't used mudlet extensively for testing, worth to check.

@TNP said:

@Griatch said:

Huh, is it correct that SimpleMu is a $20 shareware program? Interesting.

No. It's no longer being updated. It's a free download and it's impossible to register. You need to get an existing key from someone.

Ah, I see. What is the advantage of the registered version? Or will it simply stop working after a while without the key? If so we might need to scout around a bit when setting up our future testing grid (heck, I don't even use Windows... )
.
Griatch

Huh, is it correct that SimpleMu is a $20 shareware program? Interesting.

@Alzie

Thanks, that's useful and specific. Is really flashing ANSI text encountered often enough in games for this to be a real client-changing issue though? It sounds ... like a horribly annoying design practice.
.
Griatch

@TNP said:

I use SimpleMu. I know many do.

Hm, not familiar with SimpleMu (I think), should check it out.

@Alzie

your first mistake was assuming people updated their telnet clients. Your second mistake was assuming there aren't people who use zmud.

No such mistakes. It's well known Z/Cmud is still used and that players don't bother updating or change a client even when they probably should. Listing the actual uses is what you guys are for. The ones you list are all the ones I would expect from the MUD-end too, which is fair enough.

@DnvnQuinn said:

Mudlet doesn't like...something...All kinds of flashing text and overlapping text and none of the fixes work.

I just use Zmud because at least I know that works.

Using one of the MUSH-based servers, I take it? You see errors with text representation itself or is it ANSI that is messed up?
.
Griatch

As a server developer (Evennia) it's hard to get a feel for the actual statistics of telnet mu* client use. I expect MUSHclient has a big following on this site. But it would be interesting to hear what people’s impressions are about which mu* clients are still in common use (so not only your own preference but what you know of the preference of others).

Examples of clients that are still being updated and also are in decent shape when it comes to telnet communication standards are

• MUSHclient
• tintin++
• Mudlet

Zmud was not updated for a while but I think it’s pretty standards-comprehensive. On the other end is Gmud which frankly supports no telnet standards at all as far as I can tell. Such standards are used by the server to, for example, establish a client's support/non-support for ANSI-color or Xterm-256 colors, determine if a screen reader is used or for out-of-band communication for more elaborate client GUIs.

While Evennia has its own HTML5-webclient using its own JSON-based protocol, we support telnet in parallel. There is an Evennia Feature Request up for trying to build a grid for testing of telnet client compatibility. While it’s not hard to just dig out all possible clients it would be interesting to see what people actually use or know others to be using in their player communities.
.
Griatch

Not much interest in trying out the development branch in the interim it seems. So at any rate, the nested form of inlinefunc is now merged. After some pondering, I went with parentheses for the inlinefunc form anyway, making the syntax

$funcname(arg1, arg2, ...)

Where any argument can itself be an inlinefunc call. Escaping ) and commas is done either by \) or \, or by escaping everything inside python triplet-quotes, like '''..''' or """...""".

The functions to make available are simply Python functions in a module Evennia is told to contain inlinefunc-ready functions. Here is an example of the Python function behind an inlinefunc that "crops" a string if it is too wide:

from evennia.utils import utils
def crop(*args, **kwargs):
    "Call signature is $crop(text, width)"
    text, width = "", 78 # defaults, if args are missing
    nargs = len(args)
    if nargs > 0:
        text = args[0]
    if nargs > 1 and args[1].strip().isdigit():
        # only accepts digits as the width 
        width = int(args[1]) 
    return utils.crop(text, width=width)

As seen, this basically only consiststs of argument validation and then a call to an utility function to perform the crop (this particular utility function will crop to a string that in the width includes a suffix [...] to show it was cropped). This will now be usable in-game, for example as

say This is a $crop(very\, very long text, 12) that we have.

which will output

You say, "This is a very ve[...] that we have."

The number of inlinefuncs available out of the box is limited at this point but there is also an inlinefunc $clr(startcode, text, endcode) for those prefering to use that form to declare colors as $clr(r, redtext) (if no endcode is given, the reset-color code will be inserted automatically). As part of the same branch merger were also the variant of ANSI-coloring using |r etc to mark color codes.

Please report issues/bugs go to the Evennia issue tracker.

Enjoy, you guys are after all the ones saying the nested functionality was needed.
.
Griatch

@Jaunt

Some sort of notification notice/update on the OR address about what is happening would be useful whenever technically possible.
.
Griatch

@Thenomain, @WTFE, others

I pushed a development branch of Evennia that implements nested inline-functions as discussed in the last few pages of this thread. If people want they can check out the implementation and test it.

These use in-game structures of the form $funcname{arg,arg2,...} (thanks to @WTFE for some of the arguments around syntax!), where one can escape commas, inlinefuncs and } inside the arguments either with \ or by wrapping verbatim text strings in the Python triple string markers (""" or ''' , this means you can add inline-funcs in normal say-quotes without them getting escaped).

New inline-funcs are added by the developer by use of a normal Python function on the form funcname(*args, **kwargs), where *args in Python means "any number of positional arguments" and **kwargs means "any number of named keywords". Here, *args (a tuple) will hold the arguments given to $funcname(arg, arg2, ...) in-game and **kwargs is left for Evennia to make relevant state-information (such as Session info) available to the function.

The |-style color codes were also put into this branch as a test, as per issue #818. The existing {- style color codes and non-nested inlinefuncs are still functional during a transitional period.

This is a development branch, so constructive feedback and testing is appreciated.
.
Griatch

@Apos said:

I registered to reply to this thread after I noticed it because of how close it is to my experiences. About six months ago, I decided to start creating a new MUSH with my room mate. I've been MU*ing for a few years with a decent amount of soft code experience but no experience at all with Python while he had very little MU experience but a pretty heavy computer science background. We had a pretty big argument since he was horrified at softcode and didn't want to learn it, while I was extremely reluctant to try something I had no familiarity with at all, but we went with Evennia.
I'm SO glad we did. While definitely a few features would have been faster to add as we stumbled, there's a good amount of features we're adding that would have been flat out impossible with softcode. Particularly on the web framework side. One nice thing is that since django is bundled into it, you can do a lot of stuff for web support rather than just use an external wikia. We're still working on this ourselves, but there's a lot of potential there to have a far more rich web experience than just wiki character sheets. When you think of how critical wikis are to most games, there's a large potential for eliminating tedious tasks players often complain about, like cleaning logs or updating things about their characters sheets that would be reflected on the web. Ultimately the game might wind up being closer to a web browser game than a true MU, but with how niche MU gaming is I think if anything Evennia will lower the bar to entry rather than raise it.

I'm very glad to hear this! Django is very powerful, there's a lot to do there and I think people have only just scratched the surface on what you could integrate with your game that way. On the client side we hope to enhance our web capabilities further and make it even easier to expand in that regime. Do you have a website or blog somewhere with information about you game/progress so far - would love to read more about it!
.
Griatch

Ah, I think I read about Jill somewhere on here.

This made it to the front page of HackerNews, funnily enough.
.
Griatch

I was just made aware of a recently presented MIT article where they use text game worlds created in Evennia.

The article tests AI natural language processing using a "deep-learning" neural network. The goal is, basically, for the system to learn to play the game in as optimal a fashion as possible based only on the text being shown to it. That is, the computer needs to discern the (hidden) game state only based on text output the same way a human must do.

The scientists first build a small test "house" in Evennia, containing four rooms. This is used to train their neural network. The house has rather formulaic descriptions and features a straight-forward "quest" of finding and eating an apple. They then apply this trained network to the actual challenge - playing Evennia's official tutorial world, which comes with Evennia out of the box.

Our tutorial world is basically a small and well-contained solo-quest to show off some of the things possible with the system. The scientists doesn't appear to have modified the actual game play but I can only presume they have tricked out the system with some extra behind-the-scenes stuff to properly monitor and analyze their results.

The paper's authors write that solving the multi-room final quest (finding the tomb of a fallen hero) was too hard a problem and beyond the scope of this article. Instead they focused their performance analysis on a much more mundane task: the AI player managing to cross a bridge.

The swaying bridge in question is actually implemented as a single Evennia room but designed so that it takes multiple actions to cross. Every step, the room description you see changes and there are also random weather messages as well as a small random chance to fall off the bridge (and end up in a different area) if you linger for too long. All you really need to do is to walk east multiple times, but for an AI having no inherent concept of what a "bridge" is, this is clearly a complex task.

The article shows that their proposed algorithm performs better than comparisons (and a lot better than random chance). The AI does figure out how to cross the bridge about 50% if the time, and it tends to score higher than the compared methods when it comes to avoiding invalid commands and similar scoring metrics. While their measure of success is limited to succeeding to cross the bridge, many of their examples are from other rooms which suggests to me that the AI is actually taking on the whole game.

So from the perspective of the scientists, this was successful. It does give some insight into the current state-of-the-art of AI research as well: There is certainly no real competition to human players on the horizon at this point but it's a small step on the way. I hope they continue expanding their work along the same lines. Using text-based games as test beds sounds like a good idea overall and from my own brief contact with the researchers (at at point where they were just thinking about using Evennia), they seem to be quite dedicated to the concept.

At least I found this interesting. I wrote up more details, including links to the original article in the Evennia dev blog here.
.
Griatch