Posts made by Chime

So, ultimately, what I am asking is: can MUSHers live without access to SoftCode? I'm talking about things like time(), elock(), and similar.

Yes.

What do you guys think? If the COMMANDS you use for everyday roleplay were available, but you could not do any evaluation other than the occasional %-substitution, would you even notice?

An equivalent for %r and likely %t are a good idea. New conventions for color/italic/bold/underline/etc are probably very feasible.

I would, but I'm a coder. What about the rest of you?

Before I got involved in the mushcoding side of things, I had set up a small sandbox for various friends to RP out scenes while we were waiting for various games to open.

I took MOO with Minimal.db (3 objects, no concept of players, exits, doors, rooms, say/pose/ooc/page/mail or anything, really) and stood up a rudimentary system that met their expectations well enough to get the job done. Most of them never noticed it as anything particularly different. (But then I did softcode implement all of the %-codes, including color, so...)

tl;dr I wrote code 5 miles through the snow and it worked out fine and no one noticed.

Back up. Sorry for the trouble.

MPM-ITK (the thing that lets me host php inside a mod_php but with different sites owned by different users rather than that horrid common wwwdata heresy) still has some odd glitches now and then. The nightly apache2ctl graceful (for log rotation) apparently got stuck. Fixed now!

Back up. Sorry for the trouble.

MPM-ITK (the thing that lets me host php inside a mod_php but with different sites owned by different users rather than that horrid common wwwdata heresy) still has some odd glitches now and then. The nightly apache2ctl graceful (for log rotation) apparently got stuck. Fixed now!

Cool! I still don't have any iOS devices, but plenty of others do that can probably help with things.

Well. It's working as designed. I agree, it's a problematic design for getting random people to write secure code.

I've not had any problems with u() because my default assumption is to use v() or get() (for other objects), and if I really do need to invoke off-object code, then I'm mindful of the execution privileges. For example, in my hooks code for handling pose-breaks-- which really does need to run use-code on user-objects-- I used objeval(). This drops privileges and runs things as the specified user, which makes it even more clear exactly what's going on. Grant you, this is on code already marked INHERIT to a WIZARD code holder.

Other than that, it's a matter of being mindful of where data comes from and how to properly sanitize input. c.f. xkcd:

You're right though, it'd be nice to help people make things safer. Replacing mushcode entirely would be a better direction, I think.

Interestingly, several people found this odd tangent as interesting as I did and informed me of the usage "blank" carbon-copy; I'm still not sure which is most prevalent, but both blank and blind carbon-copy do appear to be used and used interchangeably.

Per Wikipedia, "Ralph Wedgwood obtained the first patent for carbon paper in 1806."

So. I guess we can celebrate 209 years of cc and bcc, at least as used for office political shenanigans.

@Thenomain said:

As I said, if expected behavior was to have each person's comments hidden, then the accepted nomenclature for this is 'bcc'. Accepted as in older than aJobs or even Mud.

Even the earliest mailspec I could find (okay, without looking very hard), RFC 733:

               STANDARD FOR THE FORMAT OF

              ARPA NETWORK TEXT MESSAGES(1)




                    21 November 1977

Has mention of bcc with the traditional semantics in section IV: Semantics, subsection B: Reference Specification Fields, heading 3: Receiver fields, item b. This was a codification of much earlier mail semantics from early arpanet days, likely dating back to research from circa 1965.

That said, cc stands for carbon-copy, and so bcc is blind carbon copy, and I believe both were in use within business and governmental offices in at least the US by the 1940s. I don't have a citation for that though-- and I suspect one of those hideous style manuals would be a better place to track the origins of the term.

@Groth It's written to be portable mushcode, and very old. Hence, numeric registers.

Though really, all mushcode is pretty awful.

@Rook I think tags would probably be the better approach. There is enough disagreement about genre territories and styling and whatnot that they prove more expressive. A lot of imageboard sites seem to have done the same-- with extensible tags.

As far as that other effort, yeah. Disappointing. I offered what R&D I already had toward that and everyone seemed to think, "Oh, ew. That's old stuff. We're going to use <insert superfluous new technology here> to do everything."

@Misadventure said:

I sense five dimensional transforming anti-deSitterspace Venn Diagrams on the horizon.

If you maintain tagsets as a popularity vote of whether different people agree that tag applies to a place or not, as well as containment/exclusion/etc relations between tags with a similar uncertainty/voting mechanic, then hyperbolic projections of the effective semantic cloud do make sense.

The Difference Engine was magnificent-- but then I'm a computer dork and the idea of viable mainframes made with gears and steampower and punch cards is AWESOME. It really could work, and thinking about how to do these things and how history might have been different is something I find fascinating.

Now, "steampunk" as a modern style can be an absolutely horrible thing. Tacky use of corsets that aren't worn right, stupid plastic gears spraypainted and glued to all surfaces? Ugh. It is bad and if you like this you should feel bad.

Reasonable approximations of Victorian-era clothing at each of the various social classes can be very nice. The whole ethic of Reason-- that we can observe natural phenomena and draw conclusions about the working of the universe and better ourselves by doing so and that any gods that might exist are irrelevant-- I love that.

@Jennkryst said:

Randomly, if MUSHes and MUXes are the same, then why doesn't combat on... any mush ever, work like on BTMux?

@Jeshin said:

Are you referring too http://battletechmux.com/index.php/Site_Frontier:Main_Page ???

That one is a fork of TinyMUX that changes some things; haven't looked in detail at what, but has something to do with how big robots do fighty things at each other. If you're talking about MU family trees, yes; it should be on their as a fifth mush type, but I don't think it's used outside of that game.

@SG said:

I wouldn't have expected it to, since when I looked for the help on @select, it didn't seem to exist on MUX.

Look in your compat.conf file, included by the default netmux.conf:

alias @select   @switch/first

Which explains what's going on here; it's a legacy command equivalent to using @switch with the /first switch. See help @switch. But I'd expect that compat alias isn't going away ever, so whichever you like.

@Rook said:

Side note: For the new to the genre? MUX is MUSH. It is just a branch of the codebase.

Right. They are the same thing; brought it up only because mudstats foolishly files them separately.

@Jeshin:

There are some differences among these four branches though;

• TinyMUSH, which I've really never used myself.
• Rhost has a more complicated security model, essentially with different levels of staffers that encourages codestaff to have separate privleged accounts that they don't normally use. Very nice stuff.
• Penn has better SQL support, better regex functions (hello regmatch), and a generally better build process. Lots of new functions and syntaxes for referencing DBrefs in ways that break safely if the number is reallocated to a new object.
• MUX has many of the more commonly used Rhost/Penn features (not the Rhost security model sadly), and generally better color support.

Some differences visible from the user:

• Rhost comchannels are by default disabled, and most rhost games (anecdotally) use instead a softcoded comsys that works reasonably well. Subtly different evaluation/quoting results. Rhost lacks telnet-negotiation (and thus NAWS) support.
• Penn comchannels use a different syntax, and inline color attribution requires code-escape and ansi() calls.
• MUX needs to be @restarted anytime it loses sql connectivity, and the ssl code is a bit dodgy.

@mail systems work completely different on every codebase. Paging syntax and capabilites have subtle differences in semantics and output. The same theoretical capabilities do work across the board, though.

Note: when we talk about using SQL, we mean as an auxiliary database for storing tabular data of whatever sort. The "in-game" mu-db remains a custom hierarchical attr-val database, just like all other MU games.

MOO and CoolMUD/ColdMUD are very different than mushes; different assumptions and the hardcode presents a very open-ended set of tools. Numerous people (including me, sigh) have used MOO to e.g. write a webserver and other oddities. This is wonderfully powerful, but also means that the MOO user interface is a lot less unified. The bare minimal.db setup doesn't differentiate between players/things/rooms/doors; all of these things are softcode. I think this is fantastic, but it also means the average non-technical user can't really tell much about the UI from knowing only that site Foo is "a MOO."

MUSHes (and MUXen, which really are the same for these purposes) instead present a very uniform UI with (relatively) rigid constraints on the data and implementation choices. On the code-side of things, ALL data is LBUFs, or large-buffers, which traditionally were 4000 bytes in size. More modern MUX environments generally default to 8000, Firan used 24000, and my fork (in use on the Reach, Darkspires, et al) tends to use 64000. MUX use utf-8-based, so that may or may not mean 64000 characters tho. Also, color-codes are stored in-text in a persistent fashion. All other datatypes-- integers, floating point values, lists, error indications, DBrefs, etc.-- are represented in these text LBUFs with the same hard limit on sizing.

MOO instead had an actual typed (albeit dynamically typed) language with internal stack-oriented bytecode virtual machine. MUSHes lack that data typing capability, which is why larger mush applications like Anomaly Jobs (a ticket tracking system, essentially) tend to have hilariously small limits on their dataset and prefer to drop data as soon as possible.

To get an idea of MUSH programming, read Amberyl's guide and likely browse Brazil's tinymux softcode wiki, if that is still up. The PennMUSH people also likely have some good docs. For most users, the "big four" mush families (TinyMUSH, RHOST, PennMUSH, and TinyMUX) are essentially the same, though they have different design goals and limitations, and somewhat different UIs for email and comchannels.

To get an idea of MOO progamming, I actually mirror some of the MOO hardcode and semi-standard default softcode starting point, aka a 'core,' which explains some of the basic MOO user assumptions, as far as they ever had any.

There is also MUCK. Where MUSH went with a naive string processor and MOO went with a modern yacc parser with bytecode stack vm, MUCK implemented a typed FORTH, accessible in-game as MUF and a more limited higher-level MPI language sometimes used on top of that. MUCK is a great deal more powerful than MUSH, but many people have trouble thinking in forth terms and MUCK has historically been associated with the Furry community. @nuku_v would be a good person to ask about that stuff, but he doesn't seem to have connected here in a few months.

MUSH/MUX examples this community is likely more familiar with, vaguely sorted by max-conn per last 30:

• Shangrila (adult)
• The Reach (hybrid NWoD1+NWoD2 set in Maine with Lovecraftian theming), many staffers/players here
• Naughty Muffin (adult)
• City of Hope (wod?)
• New Prospect (wod?)
• Kushiel's Debut (Kushiel books)
• M*U*S*H (Penn-based social)
• HeroMUX (superheros)
• CoMux (superheroes)
• Requiem for Kingsmouth (wod)
• Sheltering Sky (wod)
• Eldritch (wod; are you guys even open yet?), @thenomain's game
• Shadowrun Denver (shadowrun)
• Road to Amber (amber)
• PernWorld (pern)
• DarkSpires (Dresden Files, FATE-based, set in Oxford), @jinshei's game
• RenoMush (wod)
• Blood of Dragons (GoT)
• Game of Bones (GoT)
• City of Fog and Blood (nwod, sadly mostly defunct)
• Haunted Memories (nwod, set in Vienna, sadly defunct), many staffers/players here
• Wildcard (AnitaBlake, FATE-based, basically defunct), formerly mine, now run by @Cobaltasaurus, in theory
• Blood&Citrus (AnitaBlake, NWoD1 retheme, defunct)

MUCK examples:

• Tapestries (like a furry shangrila)
• Furry Muck (similar but less adult more social?)
• Flexible Survival (MUD-like but very adult, furry), @nuku_v's game
• Rusted Promises (Still a bit MUD like, but more RP-oriented, not really adult, somewhat furry), also @nuku_v's game

Be sure to look down the lists at mudstats, as there are many more than I have listed but I've been a bit out of touch and don't recognize a lot of the newcomers. Note that they separate MUSH/MUX and don't separate NWoD1/NWoD2/OWoD, so it's a bit awkward.

Also, be sure to check max/min/avg/current orderings; some games are in different timezones (e.g. because their staff are in Austrailia), and have varying numbers of continuously-connected or continuously active clients. Reach's internal +who at least gives a stat on currently-active unique IPs, which is a more meaningful number.

@Thenomain said:

On[c]e a conflict is resolved, it's resolved. It's done, over with, and if you want to engage it again that's cool and all but it's not the kind of game that RPGs (traditionally story-based) are meant to be about.

For a better model of a GOOD puzzle-based mmo-ish environment, see Puzzle Pirates. Not sure it's aged well, but then neither have MUs.

Also. Probably the best MUD/MMO-ish thing out there with Eclipse-Phase similar theming would be EVE Online. Food for thought. It has quite active RP communities as well.

Most scenes benefit a great deal from having multiple competent storytellers that can cooperate in an ad-hoc fashion to improve the detail and interest of a narrative.

But then again, I'm more the narrativist-type than the simulationist-type.

I find MMOs to be a FANTASTIC idea-- and I've played on many of them, dating back to UltimaOnline. CORP POR

...but I find them absolutely soulcrushingly boring for the most part. It wasn't until World of Warcraft-- which many argue sort of perfected the genre-- that I realized they had flawlessly perfected most all of the parts that I hated.

@Jeshin There was at least one, set on Luna, I think. It didn't go well.

An eclipse-phase MUD with strong promotion of RP would be... well. Pretty awesome. hmmmmm.

Usually, I'm not a mud player as anything remotely grindy is instantly a huge put-off. Usually. Sometimes, well implemented NPC combat/puzzle things might be of interest. I know they're of large interest to a lot of other people.

In terms of technology base though, MUSH is one of the most primitive, largely because it never needed to be more. The community at its best is more focused on MU RP as a literary form. Or so I keep telling myself.

What @Bobotron said. Is what I get for not testing.

Note that some communities like to see the values of each die rolled. Mathematically this is usually pointless, but it does make it feel more like a traditional tabletop would. Sometimes these little things mean a lot to people.

Also, fair warning that the human mind doesn't handle random bad luck very well. We have an astonishing amount of mental capacity geared for noticing patterns-- and that tends to trigger even where it probably shouldn't. Fudging the dice roller to optimize for perceptual randomness is a whole different thing and a somewhat open area of research. Likely it would involve re-weighting probabilities based on perceived frequency in some span of former rolls. (Don't worry about this for now; no games are this clever yet.)

Another weird thing that can be useful for GMs that warrants tracking each die is best-of/worst-of operators. Consider:

+roll best 3 of 4d6

These work great for gently leaning results in one direction or another.