25 Mar, 2009, Cratylus wrote in the 2nd comment:
I am confused. How can they be extended if the core set is still under discussion?
-Crat
http://lpmuds.net
-Crat
http://lpmuds.net
25 Mar, 2009, David Haley wrote in the 3rd comment:
Crat's very good question aside, questing should also allow any combination of the options. Also, the distinction between "automated" and "integrated" is not at all clear to me.
Equipment system should say "no restrictions", not "none", which makes it sound like there is no equipment…
If DBSIZE is merely a sum of other fields, it's unclear why it exists. The reason for its existence should be made clear.
Why no "ROOMS" field?
Equipment system should say "no restrictions", not "none", which makes it sound like there is no equipment…
If DBSIZE is merely a sum of other fields, it's unclear why it exists. The reason for its existence should be made clear.
Why no "ROOMS" field?
25 Mar, 2009, Scandum wrote in the 4th comment:
Updated it with Haley's suggestions. Already answered Crat's question elsewhere.
25 Mar, 2009, Cratylus wrote in the 5th comment:
Scandum said:
Already answered Crat's question elsewhere.
I'm sorry, I missed the answer. What is it?
-Crat
http://lpmuds.net
25 Mar, 2009, Scandum wrote in the 6th comment:
That this would be an inclusive rather than exclusive set of variables.
25 Mar, 2009, David Haley wrote in the 7th comment:
I don't understand your answer. Why do you want two separate sets? Who will use one set or the other, are people supposed to use both, … ?
25 Mar, 2009, Scandum wrote in the 8th comment:
Muds are supposed to support the official variables if possible, Mud lists can support variables from both lists or make up their own, in turn Muds can decide to support extended variables for auto updating their listing.
What I want to avoid is forcing 70+ variables on Muds.
What I want to avoid is forcing 70+ variables on Muds.
25 Mar, 2009, Cratylus wrote in the 9th comment:
Scandum said:
Muds are supposed to support the official variables if possible, Mud lists can support variables from both lists or make up their own, in turn Muds can decide to support extended variables for auto updating their listing.
What I want to avoid is forcing 70+ variables on Muds.
What I want to avoid is forcing 70+ variables on Muds.
Most of the stuff in this "extended" set is almost certainly going to be used by
most muds, making it de-facto core. It is pointless to separate it. It will be
"forced" by the very nature of it being actually useful and used.
-Crat
http://lpmuds.net
25 Mar, 2009, Tyche wrote in the 10th comment:
"DBSIZE" Current number of rooms, exits, objects, mobiles, and players. (TinyMUD term).
Why use Diku terminology in a description of a Tiny term?
It's rooms, exits and things. Or better just "current number of objects" since not all Tinys are Mushen.
There are no mobiles. Everything is an object.
Why use Diku terminology in a description of a Tiny term?
It's rooms, exits and things. Or better just "current number of objects" since not all Tinys are Mushen.
There are no mobiles. Everything is an object.
25 Mar, 2009, David Haley wrote in the 11th comment:
Surely even though internally it's "just an object", just as surely there is a distinction between things that are supposed to be NPCs and things that are supposed to be inert objects. Yeah, sure, this distinction might be invisible to the code, in which case the point is moot, but we're talking about information useful to players, not artifacts of implementation decisions.
I mean, I could implement everything, including rooms and exits, as "just objects"; would it make any sense for me to say that the concept of room or NPC is completely foreign to my game?
I mean, I could implement everything, including rooms and exits, as "just objects"; would it make any sense for me to say that the concept of room or NPC is completely foreign to my game?
25 Mar, 2009, Tyche wrote in the 12th comment:
David Haley said:
Surely even though internally it's "just an object", just as surely there is a distinction between things that are supposed to be NPCs and things that are supposed to be inert objects.
No there really really isn't.
David Haley said:
Yeah, sure, this distinction might be invisible to the code, in which case the point is moot, but we're talking about information useful to players, not artifacts of implementation decisions.
Users create rooms, exits and things, and often program them.
And half the terms listed above should have (DikuMud term) appended as they are meaningless to other muds.
25 Mar, 2009, David Haley wrote in the 13th comment:
Are you truly saying that people have zero conception of NPC vs. sword? I perfectly agree that the code might not, but that's a separate question.
25 Mar, 2009, Scandum wrote in the 14th comment:
MSSP world variables are pretty much what the engine perceives, not the people. Alphabetized, removed belligerent tagging, and added unique players.
25 Mar, 2009, David Haley wrote in the 15th comment:
Scandum said:
MSSP world variables are pretty much what the engine perceives, not the people.
Umm. Are we writing a protocol for engines to talk to each other and compare implementation details, or for people to use on listing sites to figure out what games to take a look at?
25 Mar, 2009, Tyche wrote in the 16th comment:
David Haley said:
Are you truly saying that people have zero conception of NPC vs. sword?
No
25 Mar, 2009, Scandum wrote in the 17th comment:
David Haley said:
Umm. Are we writing a protocol for engines to talk to each other and compare implementation details, or for people to use on listing sites to figure out what games to take a look at?
Scandum said:
MSSP world variables are pretty much what the engine perceives, not the people.
Umm. Are we writing a protocol for engines to talk to each other and compare implementation details, or for people to use on listing sites to figure out what games to take a look at?
All of the above, this list is inclusive, remember?
25 Mar, 2009, David Haley wrote in the 18th comment:
My point was more along the lines of "why do we care about engine implementation parameters that people don't care about", when the point is to provide data for human consumption?
25 Mar, 2009, Scandum wrote in the 19th comment:
David Haley said:
My point was more along the lines of "why do we care about engine implementation parameters that people don't care about", when the point is to provide data for human consumption?
Interesting.
25 Mar, 2009, Hades_Kane wrote in the 20th comment:
If I have several individual players that share a network or two, and thus have the same IP, does that mean that I'm basically penalized in the total number of players based on how they choose to connect to the game?
Random Picks
Feel free to contribute and I'll update it with whatever the consensus is.