25 Mar, 2009, David Haley wrote in the 41st comment:
Votes: 0
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…
Next, I think that a good number of the fields seem "hack-and-slash centric" – by hack-and-slash I mean game servers like Diku, Smaug, etc. Is this the intent of MSSP, or is it intended to be adopted by game servers outside of this realm?
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?
Are these object instances or prototypes? For example, if a mud loads 10 angry kobolds, should that count as 10 or 1 ?
Assuming it is prototypes, would a definition of DBSIZE as: The sum of all unique rooms, mobiles, and objects work? I'm not so sure if this would work all that well for non tiny muds.
Might be an idea to just get rid of "MUDPROGS", "MUDTRIGS", "RESETS" and "SSL" as official variables. Would it be very hard for Tinies to separately count items and mobiles?
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.
25 Mar, 2009, David Haley wrote in the 44th comment:
Votes: 0
Scandum said:
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?
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.
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 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.
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.
Shouldn't be too hard for Dikus to report DBSIZE as total rooms, exits, mobiles, objects, and players. Not entirely sure what garbage is.
25 Mar, 2009, David Haley wrote in the 48th comment:
Votes: 0
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.
Shouldn't be too hard for Dikus to report DBSIZE as total rooms, exits, mobiles, objects, and players. Not entirely sure what garbage is.
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. :-)
Scandum said:
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.
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.
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.
25 Mar, 2009, David Haley wrote in the 54th comment:
Votes: 0
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.
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.
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.
26 Mar, 2009, David Haley wrote in the 60th comment:
Votes: 0
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.