Belatedly - Evennia does check and store NAWS info during telnet negotiation. In practice we have not been making much use of that value in our default command set though - before we supported NAWS or a centralized width, a width of 80 (or even 78) was used and that is still in the code for the most part, just haven't gotten around to generalizing it in many places.
.
Griatch
Do/did you play in a tabletop game now or in the past?
Indeed I did. Still do.
What games(s) do/did you play as tabletop?
For GM:ing, I started out with Drakar och Demoner (something like the Swedish variation of D&D). Moved onto GURPS (made my own Aliens setting that was popular for a while) and Unknown Armies (awesome system). These days I almost exclusively run home-brew near-freeform systems although I've done run Fiasco, Paranoia and various independent games.
Are/were you the GM/ST/DM at your tabletop?
I was and still am, almost exclusively a GM.
Would you tabletop if you had the opportunity?
Yes sure, still do. Things like roll20 helps for remote-gaming and getting people together these days too.
Do you have the opportunity but choose NOT to tabletop?
Generally I try to tabletop if the chance is given. It's a matter of time and getting people together.
.
Griatch
XKCD is as always spot on. There is a lot of useful resources in Python's standard library, sometimes it does feel quite empowering to just do import X and instantly have the tools needed to solve whatever it was one was working on.
.
Griatch (flying to a new location for better reception)
@Tyche said:
If it's really a framework, it won't be just one way. There ought to be formatters/translators and generators or some such abstract arrangement. Your formatter will take in html, bbcode, mushlike format, diku/merc format, cml, or whatever and store it in some intermediate format.
When it comes time to process and send it to the VT100 terminal or WebClient it will generate VT100, html, MXP or whatever the client wants. When it comes to editing or setting it, it ought to show in the format the user wants to use.
@set my formatter=mush
or
@set my formatter=html
or
@set my formatter=bbcode
followed by
@edit my description
That is a neat concept. We don't have formatter changes on the command line out of the box but you can plop in your own Python parser in the message parsing chain if you wanted to (just overload the msg() method on your custom objects, through this goes all outgoing text). If you wanted multiple styles as you suggest you could make a command to do so (just have it set some flag and have your addition to msg() check the flag to decide which parsing to go for).
The Evennia markup syntax is converted to client-specific code at the protocol-level (so a "red" marker (currently {r) will be translated to the red ANSI sequence if you are sending over telnet to an ANSI-capable client or to a HTML span if sending to the webclient etc).
.
Griatch
DeviantArt is very big, I've bought art from there in the past (including my own artwork for framing). Can't imagine you need an account to buy but you may need one if you want to contact an artist and commission something.
.
Griatch
There seems to be a misconception as to what Evennia is. The folks over at OR are using Evennia as the game engine to make their new game. And we love that they do! But that their game happens to be an RPI is only because that's the style of game this particular dev team likes to create.
Evennia is an open-source project that existed long before OR and Planet redshift. I don't think there is any particular overlap in our manpower - nor is theirs the only development team using Evennia. Our involvement in their project is technical support on Evennia specifics and them reporting (and sometimes fixing) bugs in the core if they find any during development. We have nothing to do with whatever choices they decide to take on staff-player policies, nor is that any business of ours.
.
Griatch
RPI's and perhaps Evennia I've noticed, seem to be in constant risk of slipping further and further down the corruption hole.
Not sure how Evennia suddenly got clumped into a discussion on ethics and staff corruption. 
One of the mentioned things above is a specific style of text-based game, the other is a computer program, not even targeted specifically at making RPIs?
.
Griatch
@Arkandel said:
My personal barrier to entry (others might have the same issue, not sure) has always been that implementing the basic web interface over say, websockets with multiple rooms, PMs, boards, and all of that with some semblance of security baked in was a lot of work. If you guys have cleared the basics enough to build on - say, your sample web implementation is pluggable enough to make some small changes and see how basic things are supposed to be done - and things are semi-documented so playing around isn't too painful I'd take a shot at it.
If you are asking about having in-client gui elements for those things then no, we don't yet provide ready-made elements for this. I plan to add a more formal javascript backbone (for the evennia communication) so people can use a standard js gui kit on top, but that is not ready at this point.
As for web page interaction, Evennia uses Django, which is a professional and very well documented web framework (similar to Ruby on Rails but for Python). Django has a package repository with plenty of things to build from. That said, I'd think all django apps will probably need some extra work in order to fit with Evennia (a MU* is after all not the standard table structure used for web).
It would be interesting to hear what kind of minimal functionality you would be aiming for in your MU(SH?) webclient gui more specifically. Not the ideal, dream set, but the minimal one (or at least minimal beyond a simple telnet-like flow of text). Most usage from the MUD world centers around things like health bars, an inventory graphic and, if people are creative, separate windows for in-game text flow and tells/look/examine/system messages.
.
Griatch
@Arkandel said:
You're still building over the telnet protocol, which was never meant for gaming in the first place and is ancient, so too many potential features are missing from the toolbox.
So I'm talking about features like using rich text without the need to run a special client (such as saaay a web browser), offering a point and click interface for certain things (such as setting +sheets), showing images, a simple interface to handle PMs and channels, etc. Then if the basic functionality is there future developers could expand and build features from that point on.
Ah. This seems to be a common misconception. Telnet is only one of Evennia's supported protocols . Nothing is running "on top of" telnet: the server is actually completely agnostic as to what protocol people use to connect to it.
People can for example connect to the same server over websockets. To this end Evennia comes with a HTML5 web client and even serves its own web site out of the box (Evennia is its own web server, allowing you to use the same database for your game as for your website).
Our web client has at this point a pretty simplistic gui that mimics the telnet look. There is work ongoing to expand this and make it more pluggable. But it's really just a javascript program sending JSON to Evennia. This data does not have to be only player input but through out-of-band communication the server and client can communicate and update in all sorts of ways behind the scenes.
.
Griatch
And right now, you're telling me that nested function calls, something which are relatively straightforward and simple in the in-line language of MU's, can't be replicated in Evennia because it makes for too much complexity under the hood with the new and improved programming language.
There is no particular technical problem with adding such functionality. We didn't have a compelling enough use-case to implement it since we don't explicitly support softcode and no user had so far felt that nesting was a must-have. With enough good arguments brought forward we might well expand the design to support it. 
Do I think Evennia is it? Possibly not (it doesn't add enough to the current way of things for my tastes)
This sounds intriguing! Is this with concern to softcode or are there some other respects you feel we don't go far enough/add enough at this point?
.
Griatch
@faraday said:
though. My point was more about the pattern that @WTFE suggested of using a beginning markerandor any other permutation you desire.
Yep, @WTFE's comments are well taken, for nesting, correctly and uniquely closing scope is very important.
.
Griatch
@Derp said:
But see, that doesn't make much sense.
Okay, so I have a function r() that turns all of my text within it red. But it can only turn text red. It can't underline it. If I want to underline it, I have to use u(). But u() can't make it red like r() can. If I want to make it red and underline it, I have to create a new function, ru(). But then what about green? Well, then I would need g() and gu(). Can I make it bold on top of that? Surely you can see where this is going.
This particular example is not relevant with the current functionality, since ANSI colors work like switches. {r (which is currently the equivalent to %r) would "turn on" red until it's turned back off again with {n. This works fine to group into a {center() call if you want, or to combine with an underline ANSI instruction. But sure, your general point is true - it's not as fully flexible as a properly nest-able system.
.
Griatch
@faraday said:
I think it would be good to stick to the style of interpolation markers that are increasingly common in programming languages, whether that's #{x} or %{x} or ${x} or even |{x}.
That said, I'm not convinced that having a simple shortcut for some of the more common MUSH substitutions like %r would be a big deal. Ares is able to tell the difference between %r and 75% without forcing you to escape things all over the place. Given Evennia's model, something like that probably belongs in a MUSH-specific addon, though.
We try to avoid {...} since this is already a templating marker in raw Python. Not that Evennia gets confused or antyhing, but when you create strings in Python code, it's a bit unnecessary to have chosen an arbitrary color marker that actually clashes with Python formatting tags (and so you need to escape it to combine them). The % is also a positional marker in Python, which is why we avoid it for the same reason. So if we are changing it, might as well pick something not used in Python - hence the suggestion of |. I guess $ would work too. But you are right that separating %r from 75% is not in itself a problem with regexes.
While you could plug in different markup if you prefered, we try to homogenize this a bit as far as default Evennia goes, to offer a sane default - which is what the current proposal is about.
@Derp said:
Why? I mean, this is a serious question. Why on earth would you ever have a function call that you could only call with a single function, and not allow for nested function calling? What purpose would this serve? If you're savvy enough with the code to do a function call, you should know that functions could be nestable. So why not provide that functionality from the start?
As far as the original design goes, inlinefuncs were a way to add custom text markup based on something similar to giving a ansi color code marker. Players were never intended to be able to do anything more complex with it - as mentioned there is a distinct separation between developers and players in default Evennia.
Since all advanced functionality goes into the full python function (supplied by the developer under the hood), no actual "coding" (and choosing your nesting is a form of coding) was intended to take place on the command line. Simplicity was certainly a reason as well - there is no denying that allowing for the handling of arbitrarily nested structures adds complexity under the hood (as well as an increased need to check for resource usage), and so far no one had actually expressed any desire or need for it.
.
Griatch
I think @thenomain should probably have referenced this feature request which actually provides the context for the discussion.
You make some good points here - for a much more elaborate system. Evennia's inlinefunc system (which Thenomain refers to in the function-call bits) was never intended to be a full nestable language construct, it was meant as a way to allow coders to offer customizable replacements by safely parsing and calling functions supplied by the developer - this was meant to always be a single call, the return of which replaces the function call within the string. Any code trickery was meant to be done in that function, not in the input - the user's agency is only to choose which function to call, potentially with arguments. Without any intent to support nesting, having an ending bracket-type thing was superfluous except as a visual cue.
So nesting/scoping is/was not in this proposal at this time. If people are seriously wanting to build off this for something more softcode-capable though, maybe we should expand its purpose to be more general though. Then proper scoping is indeed paramount, as you point out.
Not so convinced about the need for such scoping for normal color markers (and although I agree % is a bad token name, so is $ is you are looking for something never ever used ... that's just a detail though). While computer-science sound, outside of mushing, this is "coding" intended to be used by "normal" users too, and by people not used to the mush way of things. I would mainly consider something like $(r) only if it was done with the goal of homogenizing the syntax of colors and function calls across the board - which is by all means a possibly worthy goal.
.
Griatch
I think I misunderstood you then. You are describing the experience of a MU* player. Then no, MSSP is certainly not for them, that's for people running the server itself.
What you are describing is more reminiscent of http://www.mudportal.com/play . Note though that making buttons available is something that is game-specific; each game in such a "list" needs to support UI enhancements specifically as soon as you go beyond simple stuff like a button for look and the like.
.
Griatch
.
Griatch
Thanks for the elaboration!
From our perspective the "framework" term is actually the more honest one. Evennia is a MU* server too, which is confusing the issue, but the problem is that traditional MU* people expect something different from a "server/codebase": to many traditional devs it suggests something like Diku or a mudlib containing more game code and aiming to a particular game style. "Framework" better fits what Evennia actually is. Regardless of what we call it, the actual concept of Evennia actually hasn't changed much along the way though: The default commands you get from a vanilla install are still very much remniscent of MUX for example. We've just gradually expanded Evennia's capabilities and made it easier for people to rip out things and replace it with things of their own (if they feel so inclined).
There is no denying that to make the most of Evennia it requires you to read up on what it offers. There is a reason we spend so much time on our documentation. If you are completely new to python there will be a definite learning curve. The amount of complete Python newbies using Evennia does suggest it's not impossible however.
Simple examples are always potentially misleading, but if you are completely new to Evennia you might want to try something simple. So here are the lines for adding a trivial echo command: it requires the modification of two files already prepared for you when you initialize your game directory:
# mygame/commands/command.py
class MyEcho (Command):
key = "echo"
def func(self):
self.caller.msg("You hear your own echo: '%s'." % self.args.strip())
To add it to your game you need to put your command into a command set. This could be all in the same file if you wanted to, but by default we separate them for cleanliness. Doing so requires two additional lines in another pre-created file:
# mygame/commands/default_cmdsets.py
from commands.command import MyEcho
#...
# (inside the pre-created default cmdset class)
self.add(MyEcho())
After a server @reload, you can use echo Hellooooo in game to see your argument returned to you. My impression is that this doesn't represent unsurmountable complexity even for beginner Python users (and we have a lot of those). Admittedly this is a trivial example, but you can get very far from this point by "just" knowing Python along with some of the properties Evennia makes available in the command body.
But at the end of the day: Can you "just go learn Python and then use Evennia"? No of course not, in the same way you can't "just go learn C++/Lua and then use the Cryengine"; The language and the libraries on top of it represent different ecosystem levels.
I admit it can be very hard for me/us as developers to actually determine what is hard for a newbie however. We are constantly trying to improve in this respect, so if you have any particular ideas for how you think Evennia could/should improve I'm happy to milk you for them. 
.
Griatch
I'm not familiar with the languages you refer to and will thus not attempt to comment on them. At least in the case of Python, you generally don't do null-checks. In fact, null (or None in Python lingo) is not anything special - it's just an object like any other, used as the default return from functions if you don't give an explicit return (and don't want any). Storing None, for example at an index in a list can in itself be a useful piece of information in some cases.
The Python philosophy is otherwise "duck typing" or "leap before you look", meaning that you should generally not validate data before trying to use it. Rather you catch errors only if they actually happen. This cuts down dramatically on validation checks. This is not alway practical and you can do stupid things here - it's true that it's not something explicitly enforced by language design.
In the case of Evennia, we use asynchronous callback mechanisms which will indeed only be called when there is actually something there - repeatedly checking for a result to be around is a silly way to do things any day.
.
Griatch
@il-volpe said:
It also should have some sort of connection to a MUDlist such that you can essentially click 'add this game' and away you go.
This exists, it's called MSSP (Mud Server Status Protocol). It's not a single button, since you need to fill in your game's details, genre, codebase and so on, as well as register with the list in question, but from there on it will keep updating game listings with current player count, server status and so on automatically.
.
Griatch
@WTFE said:
You can't get away from null ... and yet entire language environments exist in which there's not a nil/null/whatever check in sight.
I think you might be thinking of a different type of problem? For example In C/C++, with explicit pointer management, failing to handle null-pointers is a serious issue.. High-level, garbage-collected languages like Python and Ruby manage such things for you, making that particular aspect a non-issue. Null/None/Nil remains a very useful property in any language though, to represent nothingness as @Tyche said. Which language environments are you referring to?
.
Griatch