If I made a bunch of unique "protoplasms", and then attached the same scripts to them, and added the same equipment, would they all really be a bunch of unique mobs in the end of the day? Not really…

I was having another look at mudstats today and the list of server types cracked me up: http://www.mudstats.com/ConnectedGraph.a...

Back on topic:

Not trying to rush things, but to get things moving forward, shall I create a new thread for MSSP Extended Variables to create an inclusive rather than exclusive list of variables?

DBSIZE is the number of objects. No such thing as prototypes. And I seriously doubt anyone running a Tiny is going to be able to differentiate much beyond rooms, exits and things. And it's marginally important to those looking to see how "developed" or active a game is. Square pegs and all that.

Edit: That is to say, I'd suggest adding the DBSIZE field and if they want/can fill in the others, they can. And if Dikus can't figure out what to put in DBSIZE then too bad.

I think part of the point is that these variables shouldn't be considered "extended" – I don't see why you're trying to keep your original set as the "final official" variables, and anything else that people bring up has to go into an unofficial or extended set.

Looks like all you want to do is argue, not do anything constructive.

I do not think that is what David Haley looks like at all.

I agree that the core set should include the stuff commonly found on listing sites.
Assuming listing is part of the point of this protocol.

1 + 1 and all that.

-Crat
http://lpmuds.net

Shouldn't be too hard for Dikus to report DBSIZE as total rooms, exits, mobiles, objects, and players. Not entirely sure what garbage is.

He said what garbage is; stuff that's allocated in a memory pool but that isn't actually used. Many dikurivatives don't have such a concept, and arguably nobody should report it in the first place since it's representative of implementation details, not something useful to players.

I suppose you might describe DBSIZE as "the total number of valid objects". And yes, players wouldn't be interested in the number of invalid/garbage objects.

Are exits actual objects on Tinymuds? We could define it as "total number of valid objects" but that'd be so open to interpretation people might count extra descriptions, helpfiles, mobprogs, areas, shops, resets, etc.

Yes, you can even pick them up and put them in your pocket. Perhaps even juggle them. :-)



Consider that exits and things are also sometimes "helpfiles" on Tinys. Sometimes helpfiles are actual external files. On ColdCore about half of the objects are helpfiles. Why does it matter that it's open to interpretation? Maybe it ought to be.

Ok, how to word it in such a manner that people don't confuse objects with items? Maybe:

"Current number of valid universal objects. (TinyMUD term)

?

Is there any reason why there can't be certain variables specific to certain codebase families? Then you can just ignore variables which don't apply to your mud.

Otherwise I fear the option will become so generic that they'll lose their value.

As I said pretty much when this thing started, yes, trying to "ontologize" the entire MUD family is just not going to happen. I think it would be more sensible to have several fields and just allow the N/A response when a question isn't relevant, something that Scandum seems to really dislike for some reason or another.

Ok I've never played with the articles here, but I figured
this was a good time to try. Please see:

http://mudbytes.net/index.php?a=articles...

Do I need to do anything to make it editable by members? Can someone
try to edit and see? The idea is to have something we're working on
to discuss, rather than debate Scandum's attitude.

Thx.

-Crat
http://lpmuds.net

Looks like I can edit it. Presumably that means anybody can… heh. :wink:

That's the idea. Let's get together on a real consensus.

-Crat

Yes, any registered member can contribute to articles. That's the entire point behind the module. It's meant to be wiki-esque.

The Playerkilling field options jumped out at me when I glanced over the article. Restricted by level and restricted by motive (ie, harassment) are two entirely different things, but would both fall under the same option because I'd consider a "full" PK MUD to be completely unrestricted. There's also clan-based, race-based and kingdom-based, and I'm sure many others. Would it be beneficial to move to something like: None, Level-restricted, Race-restricted, Motive-restricted (better term?), …, Unrestricted? I guess that approach would have to allow for multiple values.

Or maybe it should be more descriptive, such as Race-based, Level-based, etc.

Agreed. There's also RP-restricted, where you need a valid in-character reason to kill another player. Many MUDs use this in place of "harassment-restricted" rules, although you can always get around that by making up sociopathic characters.

I think that "team-restricted" covers the cases of clan, race, kingdom, etc. fairly generally without getting too much into specifics. I don't think it really matters if PK is restricted by clan or by kingdom, because the two are for many purposes the same thing.