Posts made by Derp

I want a Dark Sun game that isn't a) a MUD or b) house ruled so heavily as to be practically unrecognizable or c) using some weird alternate history theme.

Just straight Dark Sun, at whatever point in the timeline.

@Griatch said:

@Derp said:

multidescer

Now you are talking over my head ;). Could you elaborate on what a multidescer is and how it should work? I could then take a stab at explaining how it would be implemented from the Evennia perspective of things.
.
Griatch

Ok, so... let's pretend, for a second, that Evennia comes with only your basic hardcoded mush commands.

Everyone is familiar with @desc, and how it works. You set an attribute on something wherein you can see a description of it using a look command. However, there is only one available desc attribute at any given time -- to change it, you have to delete the old one and put in a new one.

Well, a multidescer allowed you to take various descs and save them in other attributes, changing them up as you see fit, using whatever command syntax makes sense to you. You can even store pieces of descs, which are then compiled into a larger paragraph.

So you might see something like:

+desc Formal Attire

or

+desc Red Hat & Blue Hoodie & Faded Jeans & Work Boots

all of which are stored in their own various places and swapped out with the current desc, which is stored in its own 'save location' attribute.

Another is the ability to create very simple objects that do very simple things, like, give you a random spread of tarot cards and a keyword list of associated meanings.

But really, focusing on the one thing is missing the forest for the trees. The point is that in many branches of MU, players have the capability to create these things for themselves right out of the box and they are portable between any game using the same MU version without having to go through what is almost assuredly the tedious process of having to vet this thing through your primary developer. Things that are NOT, by default, a part of the hardcode, and so are not available to them unless they choose to create it.

Sure, they could vet it through the dev, but each of them has a various preference on which one to use and even how it's used (this is a classic example of how softcoding is used to highly personalize an experience).And a developer might not agree that it's important enough to turn into a globally accessible command. Even if they do, you could end up with eighteen versions of a thing that does something in similar but different ways, which doesn't simplify your process at all -- it just creates command bloat.

This type of end-user personalization is what I'm talking about -- the ability to create things for their own personal use, which does not necessarily have any larger impact on the game world. MUX can do this with its softcode implementation -- how, then, can Evennia do something similar?

Evennia relies on a completely different code implementation, which doesn't use softcode nor does it offer anything similar to it right out of the box.

@Thenomain said:

My First World Problem:

New Corsair headset. Nicer than anything I've had before. Software to mess with the color pulses on the side of the headsets. Cool.

Update box pops up. Has a link to the download page for this instead of downloading the update itself. Well ... okay.

Download link goes to generic "downloads" page, not the one for this program. O...kay?

Installer program does not know that it's already installed, so does not offer to install new version in the same place as the older version.

This is a high-end game-machine peripheral company what now? Is this the 90s? Geeze.

In a similar vein:

Bought a Lenovo Y70. NVidia Geforce Experience constantly reminds me that I need to install the updated driver. I check for updates. It tells me that it's good to go, and starts to install... only to fail to install.

The same thing happens when I try to install the software to take fuller advantage of the high end mouse I just bought.

Sigh.

@Griatch said:

I presume I'm the one writing posts that "talks technology above their head". I'm sorry if that's the impression but when people are commenting on a particular aspect of Evennia design (such as my first post was replying to the length of Evennia command code), it sort of makes sense that I reply explaining that design from a technical standpoint.

It's not just you, man. There seems to be a lot of this going on. See also:

@Reason said:

Yeah. Well, it's tough for me to continue here because you don't have a frame of reference beyond soft-code.

So I can talk about "accessibility" and "utility" and attach shiny buzz words next to the modern programming capabilities that surround Evennia, but that's just really words on a page that you don't understand in a tangible sense.

Because your experience as an aspiring coder is limited to a whitespaceless functional paradigm, typed into a chat client.

So if people seem a bit defensive, it's because ... we are. Some of us are trying to talk about there being actual drawbacks to these things that don't appeal to current members of the community when this is supposed to be a tool for the advancement of that community. One of the shared values of this community is for multiple people to be able to functionally contribute meaningful things to the game on a large scale as well as develop more personalized things for their own use. There is a very high degree of customization that you can do with data manipulation using softcode, even if people don't realize that the multidescers and tarot decks and cell phone objects and vehicles and such are part of that softcode.

The answers given so far seem to be a lot more along the lines of 'ugh, why would you want to do that, that's stupid' and a lot less along the lines of 'oh hey, I see where you're coming from and why it's important to you, and I think I have a solution as to how we can get something that might appeal to you'.

Bring it down to the level of the people the discussion is aimed for. It's far more realistic to go to the mountain than to expect the mountain to come to you.

Because it bears repeating:

@Thenomain said:

Someone could answer with, "It can already do that. Look here: <link>", and render the complaints moot and turn it back into a discussion. That person is not yet me.

(implication/translation: turning information gathering into concrete project goals is not up to the end-user.)
(another implication/translation: educate these poor people to get them excited in the project, don't blame them for not trying!)

See, like... the problem that I'm having with wrapping my head around this is... what sort of 'new advanced things' are we talking about?

It's a MU. It's, fundamentally, text manipulation and basic math. I mean, yes, you have some more advanced options in the form of selecting how text appears and who it goes to, etc, but no matter how advanced and shiny you make it, the fundamental things you need are some way to print entered text, and some way to manipulate numbers.

Some of the suggestions made just seem like adding features simply for the sake of adding features, even if they don't actually improve upon anything. Sort of like this idea of buttons for all the commands. What does that accomplish that your welcome screen on a mush can't? 'Hi player, we assume you're new, here's what you need to get started.'

I mean, think of your most commonly used things. Pose, Say, Emit. The only things they do, literally, is change how the thing sent to the room you're in starts, and of course they can trigger certain side-effects with advanced foo (that no one ever uses). But even if you have a button for all three of those, seriously, how would it even be used? Do you hit the button and then type what you want to send, and hit enter? Do you type what you want to send and then hit the button to do it? Even the 'get' thing earlier, if you know what you're wanting to get, why do you need a button that does it?

Sure, you can throw some fancy things in with all the things we've done in the last few decades. You can watch dice roll across the screen with nifty graphics, and maybe throw some rich text in there (god help us all, it'll be Papyrus and Comic Sans just splattered all over the place...)

Yes, we've made lots of advances, but how advanced does it really need to be to do something that's essentially a glorified skype window with an internal calculator?

@HelloProject said:

What the hell is Beast? Are you literally playing the vampire's Beast now?

It's some manner of primordial dream-demon reverse changeling... thing. I kind of don't get it. You play some sort of ancient monster who takes human form and is supposed to feed on people's fears, or nightmares, or something, and in doing so there is... profit, of some manner.

I've read the things for it half a dozen times now, and I'm still lost as to how it's supposed to function, but it seems like a whole big pile of weird to me. I'm sure that someone else has a more thorough explanation that probably makes it make sense. At least, I hope someone does. I'm totally lost.

@Tempest said:

Is 'post-editing development' code for almost done or barely started?

It's the last stage before release.

@il-volpe said:

A MU client that detected the type of MU you were on and correctly determined the commands for most ordinary actions and made them into buttons you could click (while still allowing you to enter the command directly if desired) would probably be awesome. It'd turn the learning-to-function-in-MUSH experience from a 'what the fuck do I do at the DOS prompt?! Tell me! Ffffff!!!' experience into a learning-hotkey-combos-for-a-GUI sort of experience.

How would that work, though? I mean, you can make buttons for every command, sure, but unless you know what goes after the start of the command, it's not that much more useful. You still have to know what each of them does, and when to use them, and what goes after the thing that initiates what you're trying to do.

I mean, there could be a way that it could work. I'm just not sure what use turning the commands into buttons over typing them into the send window is. Can you give an example?

@HelloProject said:

@Groth said:

I think the main reason there's not more prompts at least in PennMUSH is because PennMUSH does as far as I'm aware not have any real support for prompts. Having back-end support for prompts would help a lot in that regard.

Yeah but I never said anything about doing this in PennMUSH, or MUX, or anything along those lines.

@Derp said:

See, what you're talking about here is something more properly covered under something like @program, wherein you type a thing and a series of prompts comes up asking you for input. That's more than just a single command, though, it's a series of things executed in order that then compiles a final result.

As far as a single command goes for digging, @dig is about as simple as it gets for what it does.

I just explained how it can be exactly way more simpler than that, by doing it exactly the way I described.

Right, but what you described is a program, not a command. Yes, a digging program could make digging simpler by using an interface like that, assuming it's set up in such a way to allow for all the things that the single-line command can do, but it's still a program that just takes what you feed into it and puts it back into the single line command above.

I get what you're saying, it's just that it's not actually accurate.

Think of it like this:

@dig Kitchen=Kitchen;K,Out;O

Under your version:

dig

$ Name of the room you're digging?

Kitchen

$ Return Exits?

Yes

$ Number of Exits?

1

$ Name of Exit?

Out

$ Alias(es)?

O

And then it just takes and plugs all of that information back into the thing from the start. The reason that we don't do this (IMO) it because it's not as fast to do it that way, and tends to lead to some confusion on things like ... where these exits go, unless you already know how the first command words and what you're feeding into it, or an extraordinarily detailed help file was written describing basically all the things that help @dig already does.

This is what I mean when I say things like 'coding for the LCD is not necessarily the best option'. There is a certain level of investment that you have to expect from the end user in these things, or else you end up with nightmarish systems and books full of information on how to use them.

Edit: Forum formatting grrr.

@HelloProject said:

@Groth I guess I should say complicated syntax, then. But either way, an extremely simplified dig command would be:

dig

And then prompts pop up asking what you wanna do and what to type in to do it. Preferably something like north/south/west/etc. Then prompts like what you want the name to be, etc. Dig would initiate a series of prompts, so the only thing you'd need to remember is to type dig to begin with, and everything else is just handed to you.

See, what you're talking about here is something more properly covered under something like @program, wherein you type a thing and a series of prompts comes up asking you for input. That's more than just a single command, though, it's a series of things executed in order that then compiles a final result.

As far as a single command goes for digging, @dig is about as simple as it gets for what it does.

@Reason said:

Yeah. Well, it's tough for me to continue here because you don't have a frame of reference beyond soft-code.

So I can talk about "accessibility" and "utility" and attach shiny buzz words next to the modern programming capabilities that surround Evennia, but that's just really words on a page that you don't understand in a tangible sense.

Because your experience as an aspiring coder is limited to a whitespaceless functional paradigm, typed into a chat client.

So we can just agree to disagree.

Alright. Since your knowledge of programming is obviously so much more advanced than mine, answer me this -- if the Evennia solution is everything it's cracked up to be, why can't something similar be done with it? Why can't people who want to learn Python upload their own things into it, strictly for their own personal use, on whatever game they want to go play at? If this is the Thing of the Future, and is all shiny and awesome, why can't it duplicate functionality that the 70's era un-intuitive softcode aspects are capable of doing?

I talked about an actual drawback, and you brushed it off as 'silly baby coder, you don't know what real code is. Witness the awe and glory that is python, even if your feeble mind cannot comprehend it'.

Simple Problem: I desire to be able to go into one of these games and create a customized thing that I can use for my own convenience so long as it doesn't mess with the 'big game things' and allow for blatant cheating, which I can currently do with minimal hurdles to jump through, but which under Evennia's system I've been told is impossible.

So if it's such the thing of the future, then why can't something similar be implemented? Part of MUX's draw, for some of us, is the ability to do exactly that, so rather than dismissively telling me that I don't understand what its like to code in an awesome whitespace outside of a functional paradigm, why don't you tell me how this grand new system can address the concern that I have about using it?

@Reason said:

@Derp said:

Which... doesn't mean that it isn't open to anyone who wants to learn, that just means that it's something that they'll have to put some actual work into, and maybe seek a mentor. Much like anything else anyone could ever hope to learn. But all of the documentation for it is included in the help files, along with examples and such, and outside of a few concepts which are rather buried, you need not ever really seek an outside mentor. It's all self-contained. But more importantly, it can be used within the game itself without having to worry overly much about server access. Ergo, open to anyone who wants to learn.

Except that any MU user can create their own softcode to do specific things they want it to do that might not be important enough to implement game-wide, and they can do so without having to worry about server access, etc. Anything that could super easily break things is largely denied due to permissions. The same cannot be said of Evennia. It might not be something that a great many users ever pursue, but it's something that I find important enough to dissuade me from looking into Evennia.

You've mentioned server access twice. You understand that "server access" in Evennia's case means a desktop, 2 minutes spent downloading a Python distribution, and a pulse. Right?

There are literally thousands of hours of youtube videos explaining how Python works. There's absolutely no comparison. MU* softcode is as approachable as a purple, pulsating vomitorium.

I appreciate your interest in softcode, mind you. I think that the world would be a better place if more people took a moment to think about functional programming. W.W.H.D., that's my moto.

But it just isn't tenable to hold up 'accessibility of code resources' as the primary thing holding MU* softcode at the forefront of text based online game dominance.

I think this depends highly upon your outlook on a thing. In this case, I value this a great deal. Moreso than whatever snazzy innovation someone can fetch for me with Evennia -- and with softcode, I can do it with nearly -any- game, not just the ones that I choose to run myself. Something which Evennia cannot do, or match, without the softcode aspect.

So no, server access is still important (or, more specifically, the lack of need for it on a MUX to make toys that do simple things), because ultimately you're going to want to make tools for the game you're playing on. Softcode allows you to do that without having to put something in the guts of the beast, in a lot of cases.

@Jaunt said:

@HelloProject said:

This reminds me of how YouTube and Facebook are horrifyingly bloated sites now, rather than focusing on being simple and functional. They're complicated and more difficult to understand than ever.

Yeah, I definitely think that innovation needs to be geared towards making things easier to design for newcomers, easier to learn to play for newcomers, more aesthetically sleek and appealing (to attract more newcomers), and any feature enhancements need to be more intuitive to use than legacy commands. It's relatively easy for MU* veterans to learn new syntax (especially if they're intuitive). Legacy engines rely on some pretty non-intuitive mechanics and commands to manipulate things, and that's definitely a hurdle for new players who aren't used to text interfaces.

See, I think I have to disagree with you here. Yes, these things are good... to a point. Most of the games that I enjoy playing are games that are definitely something that has complexity already built into the gaming system that you're playing, and there is only so far that you can simplify things and code for the least common denominator before you start to double back on yourself, or the quality and robustness of other things start to suffer.

Take WoD dice for example. It's a terribly complex system even before you get into the coding aspects of it. Roll X Ten-sided dice Y times, and re-roll on a 10, unless you have 9-again, at which point roll 9's and 10's again, except with 8-again, and oh, don't forget rote, weakness, etc, etc, on down the line.

With this, you have two options. One command with in-line features that tell the thing what it is you're trying to do, or a bunch of different commands to offer the various styles in which it can be done.

The simplest way, of course, is to just have it to the 10-again, and then have players track what needs to be re-rolled. One command, and done. Easy peasy, right? Except if you don't want them to have to track that...

It goes on from there.

Sometimes, coding for the LCD is not the most viable option, and expecting players to put some investment into learning the system and the command structure does, in fact, end up being your best option, even if it's not perfectly intuitive for a newbie or is somewhat complex.

@Reason said:

@Derp I would have to respectfully disagree with your characteristic of MU* code being open to anyone who wants to learn. MU* code is open to anyone who wants to search archaic remnants of an age long since past, and invoke an animal spirit code guide with a mix of peyote and pleasant page-chats.

Which... doesn't mean that it isn't open to anyone who wants to learn, that just means that it's something that they'll have to put some actual work into, and maybe seek a mentor. Much like anything else anyone could ever hope to learn. But all of the documentation for it is included in the help files, along with examples and such, and outside of a few concepts which are rather buried, you need not ever really seek an outside mentor. It's all self-contained. But more importantly, it can be used within the game itself without having to worry overly much about server access. Ergo, open to anyone who wants to learn.

Which isn't to diminish the importance or joy or learning MU* code anymore than the importance or joy of learning Haskell (or really any functional programming paradigm, for that matter) -- just that hanging your hold-ups on the accessibility of MU* code is odd when it is 1) Not actually accessible afterall 2) Less accessible than a number of modern languages (by orders of magnitude), including the direct contrast of Evennia's Python.

Except that any MU user can create their own softcode to do specific things they want it to do that might not be important enough to implement game-wide, and they can do so without having to worry about server access, etc. Anything that could super easily break things is largely denied due to permissions. The same cannot be said of Evennia. It might not be something that a great many users ever pursue, but it's something that I find important enough to dissuade me from looking into Evennia.

My own concerns are much closer to the challenges of changing creatures of habit.

We of the MU* like our MU*ness to be of a certain character.

Evennia is a foreigner in that regard, who exhibits the capacity to over time learn our languages and holy customs, but has not yet made a pilgrimage to the shrine of... whatever soft-code gods we hold dearest.

I think we can agree on this.

That said, it is exciting -- I feel that it is a step in the right direction, for both the sustainability of the hobby with respect to code support (I will probably never write another line of MU* soft-code so long as I live. Maybe. Okay, probably maybe.), as well with respect to the accessibility of new players (Native web client vs. reskinned 1970s Telnet).

Potentially. We shall see.

I will admit to having some hesitation when I see this come into play.

First of all, I'm an aspiring coder. I'm very slowly learning the ins and outs of the code. I've made a few toys here and there. Nothing major -- I think my biggest project is Eldritch's idle tracker, and that doesn't even have automation. But it's a start. And it's a start that doesn't require me to have a lot of things in the way of powers and permissions and such. I even have a few 'handy little tools' that I use by way of softcode that make my job easier, like a thing that just lets me take a job number and a few bits of information and plug it in to handle wiki account requests. Those are the sorts of toys that I like to make, and one of the reasons that I like mux code.

Mux has all of the help files built into the thing, and doesn't require me to go outside of that in order to figure out what I'm doing. This, on the other hand, requires knowledge of python, programming, and other things that are currently beyond my ken, much less my permission level.

There are few enough people who do MUX code in any serious capacity as it is. With Mux, though, it's open for anyone who wants to learn. The tools are all right there for you, and you can play around with little things in the game itself to get a feel for it. With this system, I don't think that will be possible. Given the dearth of coders that we currently have, taking away the ability for an aspiring amateur to do anything reasonably sound with it by way of practice and play seems... I dunno. I don't think it'll have a good effect on things, in the long run.

So I'm hesitant to climb on board with this, no matter how shiny it is. Half of the reasons I enjoy these games so much is because they allow me to learn something like that on my own time, in a self-contained environment where I can see real effects, real examples, etc. Evennia might have all the cool things ever, but it's lacking that big draw for me in the form of not having any access to tools by which I can create my own things, unless a coder helpfully installs such things, which seems defeatist of the point of moving away from softcode.

@Thenomain said:

Skype on Windows ... advertising Skype on Windows? Skype advertising anything? What is this madness and who do I ask to get fired because of it.

It replaced Lync. I was sad.

When my fucking writing professor marks me off for using et al. correctly. I mean, I get it. It's Latin, and you Ph.D. is in english, so maybe you've managed to miss the little things with it, but goddamn, at least doublecheck before you deduct points. And of course he's the one asshole who just gets even more critical and pissy when you prove him wrong. How the man fails to grasp the difference between etc. and et al. (I was referencing a list of authors, for chrissakes) is beyond me.

So, I see two parts of this discussion that I think I'd like to address --

Effectively telling dark stuff is kind of hard. Especially on a MU, as some have already pointed out. As @AmishRakeFight pointed out above. some people have all the feels about some of the darker situations that you can find in horror literature, and taking out the psychological horrors leaves you with gore-porn, as @Thenomain stated.

Failing that, though, you do tend to have an awful lot of people wanting to play Superheroes with Fangs/Magic/Claws/SparkleFairyStuff. Which then branches off into its own problem. How do you get players to keep to the feel of the game you are wanting to create without telling them that their fun is WrongFun? And if you really do want to push for some of the darker stuff, how do you get away from the things that people have Feels about, and still make it horrifying?

It's weird. We are a bunch of people with a bunch of issues playing games revolved around horror and looking for happiness and hope, a lot of the time, and as a community a lot of us don't want to approach some of the most terrible things humans do to each other because in many cases they are the source of the issues that make us more than a little socially reclusive/awkward/damaged. I'm not sure this is an issue that we'll ever actually work out.

But more than that, random scene-dropping un-ignorable grid patrols don't tend to actually work, for two reasons:

1. Players have their own goals with the times that they are online. If an ST comes in and derails what they were attempting to do, even with the best intentions of making fun for the players, it can result in people getting irritated. So ST's back off from that kind of thing, and then -- well, you've seen the things posting stating where plot is lacking. It's a delicate balance, that is mostly resolved by just scheduling things, but then you're scheduling things, and it's not at all random.

2. In horror things especially, you do have to go for the slow buildup, rather than 'oh look at that, monster down the street'. 'Cept, lots of times, people don't have the kind of time it takes to invest in that, which is doubly true if you're dropping a random scene on a group already in progress. Fifteen minutes in, just as the monster is slithering out of its <insert dwelling here>, someone is like 'welp, fun, gotta go, try to not die', which leads to all sorts of awkward complication. You either have to pause and pick up later which causes time-jumpy goodness they have to explain OR you wrap it up with who you got and try to figure out what happened to Amanda Sue or Bobby Joe without violating their agency and still creating a believable story.

TL;DR - Horror is hard, yo.

@HelloProject said:

@surreality I could see myself enjoying things significantly more if a MU*'s rules specifically treated social combat as equal to physical combat in terms of needing an ST. It's ridiculous that we have disputes like people literally treating social rolls like telepathy, which would be easily solved if ST intervention was accepted as a normal aspect of social combat.

I'm still not sure where a lot of this comes from, to be honest. In any situation in which two players are rolling dice at each other, you should be able to call for an ST. That, like, basic gaming common sense. Hell, if someone asked me to come and adjudicate something social, I'd be there in a heartbeat. Combat, too. Or maybe they're writing a dissertation and want to write out that little story and find kinks and flaws or something. Mental stuff is no different.

Dice involved = ST can be called to be present if the players wish.

@surreality said:

@Derp said:

But the problem with the system, in the developer's eyes, is that characters should keep some control over their actions, particularly because they tend to be working together or toward the same goals. The groups in question, around the table, are all on the same team. This cannot be said for those in the MU environs, and again, we need to distinguish what is meant by NPC in the books versus NPC in something as wide as a MU.

Oh that's what they said? Except it just fucking isn't.

Under a strict reading of these rules, one character could use Social maneuvering to get another to do whatever she wants. That’s not quite right, since it’s the persuader’s player making the rolls. His victim doesn’t get any option to say “no.” As such, this system should only be used by player-controlled characters on Storyteller characters. Leave the manipulation of other player’s characters to roleplaying, and let the players determine their characters’ respons- es.

• (WTF2e Final.)

It is not always possible to get someone to do what you want. For instance, no amount of Social maneuver- ing is going to convince the chief of police in a large city to hold a press conference and admit to murder, even if the player has a dice pool impressive enough to make it happen. This system is designed to allow characters to manipulate or convince other characters to perform favors or undertake actions, but it does raise the question: Is one character dictating another’s actions, and how much of that should be allowed in a role-playing game? Or, put a different way, can one character seduce another with this system?
Under a strict read of the rules, yes. The goal is “get that character to sleep with my character,” the number of Doors is decided as explained below, and impressions and other factors play into the final result. This is not too different from how se- duction and other, less carnal, forms of persuasion actually work — the persuader tries to make the offer as enticing as possible.
But because it’s the persuader’s player making the rolls, the target is left without a way to say “no.” As such, it’s our recommendation that this system be used by player-controlled characters on Storyteller characters rather than on other players’ characters. If one player’s character wants to seduce, persuade, convince, or intimi- date another, leave it up to roleplaying and let players make their own decisions about what their characters do.

• (GMC.)

Funny how their why and your why bear zero fucking resemblance to one another.

Except see the part I quoted above, which comes after that part in the GMCRU, about using it with other players.

Damn. Funny how that works, huh? If you're going to get all frothy at the mouth and tell me I'm wrong, at least read what the hell I write and then go reference the later part of it. Goddamn.