03 Feb, 2012, Rarva.Riendf wrote in the 101st comment:
Votes: 0
Quote
It changes on the fly, based on where the player is and what they're interacting with. So, how are you (the awesome coder that you think you are) going to "order" the command list to ensure things are matched in the order you (the font of all knowledge and wisdom) have determined is the most desireable order for abbreviation?

Let me see…alphabetically, in order of file command appearnce (date) so a player always have the same result, I can think of dozen of differents order to do on the fly…Maybe if you were not so stuck in your codebase way of doing you would be awesome too ?
The way you deal with command parsing has asolutely no relation whatsoever to the codebase you use…again.
03 Feb, 2012, quixadhal wrote in the 102nd comment:
Votes: 0
Rarva.Riendf said:
Quote
It changes on the fly, based on where the player is and what they're interacting with. So, how are you (the awesome coder that you think you are) going to "order" the command list to ensure things are matched in the order you (the font of all knowledge and wisdom) have determined is the most desireable order for abbreviation?

Let me see…alphabetically, in order of file command appearnce (date) so a player always have the same result, I can think of dozen of differents order to do on the fly…Maybe if you were not so stuck in your codebase way of doing you would be awesome too ?
The way you deal with command parsing has asolutely no relation whatsoever to the codebase you use…again.


So much for your enforcing a set order to control which command an abbreviation invokes. If you sort via any automated means, you lose that control.
03 Feb, 2012, David Haley wrote in the 103rd comment:
Votes: 0
quixadhal said:
So much for your enforcing a set order to control which command an abbreviation invokes. If you sort via any automated means, you lose that control.

Um, what? If you sort by date a command was added, there is a set, unchanging order for which command is invoked. Adding a new command won't change the sort order for existing commands.

As long as the sort doesn't change the order of existing commands, you don't lose the control.
04 Feb, 2012, quixadhal wrote in the 104th comment:
Votes: 0
Ok, what would be the date of the command added via an object that's in your hand? The date you picked it up? the date the object was written? The date of the particular clone of it you're holding?

So, let's say you do sort by date. When you decided the sort order, 'get' was the oldest command and 'give' was newer. Since you wanted 'get' to come first, you chose oldest-command-first for your sort.

Now, you pick up the ancient club of grumpiness, which defines a 'gank' command. The date on the club is older than the 'get' command, because some bug was fixed in 'get' more recently than the club was made. So, now 'g' refers to 'gank' instead of the 'get' you had hoped it would.

Oh, but wait! I hear you say you meant the file creation date, not the last modified date!

Suppose you're playing from a backup that got restored improperly, so all files end up created at the same time… the time the archive was made. Sure, don't do that… but what if you did?

Suppose you're using a virtual object that doesn't HAVE a filesystem date. All you have is the date the object was instantiated, and maybe this object was one of the first ones built… made out of a generic "object" prototype before anyone bothered to write a custom 'club.c' file?

Yes, I'm stretching… but my point remains valid. Unless you are a MUD with only one developer, you can't always know with 100% certainty what commands are going to be available for parsing to a particular player at a particular time in a particular environment. Well, maybe you can if you have a Diku which doesn't allow commands to be added or modified on the fly, but in other systems… relying on sort order seems doomed to failure, and failure in strange ways that are hard to reproduce unless you happen to see it happen yourself.
04 Feb, 2012, David Haley wrote in the 105th comment:
Votes: 0
The point is to make sure that the commands stay in order for the player using them. It therefore suffices to ensure that the sort order is such that new commands always go at the end of that player's sort order. You may, therefore, sort by the order in which the player came across the command. Of course, this means that abbreviations won't work the same across players.

I can write code that will always guarantee without a shred of doubt when the particular command was created. It has nothing to do with being a single-developer MUD.

I'm not advocating the usefulness of this scheme; indeed I think there are far better ways to deal with ambiguity. I am simply disputing your statement that it is impossible to create a sort order that doesn't change for players.
04 Feb, 2012, Rarva.Riendf wrote in the 106th comment:
Votes: 0
quix: you just lack of imagination and only use what your codebase support…awesone, as you say.

When I think about a functionality, I dont think:what tool do I have, but instead 'what is the goal', then if I can use the provided tool, cool, less code..otherwise, just code, no codebase limit you, sice you can modify whatever you want.
04 Feb, 2012, quixadhal wrote in the 107th comment:
Votes: 0
DH, I think you're ignoring the context of this pointless argument. :)

The point isn't being made about whether or not a command list can be sorted, obviously it can be. The point was that if you're relying on the order of commands to make player abbreviations work properly, anything which would disturb that order would make it impossible to do so.

In my example, I gave a contrived (but valid) case where the "date" of the commands available varies. You could specify that any commands added by objects are always put at the beginning or the end of the list, in which case your abbreviations will either always hit them first, or never hit them at all. Is that desireable?

30 pages back, before this particular layer of pointless nitpicking began, someone was complaining about abbreviations and I was suggesting that it's both easier and makes more sense to simply have a default set of aliai for commonly used abbreviations, and otherwise only allow abbreviations if they are non-ambiguous. IE: "kill", "kiss", and "kick" would self-abbreviate to three characters, but an alias of 'k' => 'kill' would solve the problem in a clean and clear way, which the players themselves could alter if it didn't fit their play-style.

That was ignored, perhaps as making too much sense, and we wandered down the "You don't need useful-thing-X because obscure-method-Y does the same thing!"

True. Have fun with it. God help anyone who ever has to try to maintain your code.
04 Feb, 2012, Cratylus wrote in the 108th comment:
Votes: 0
Discworld has a reasonable approach to this (as far as I understand it). Commands have filenames like ki_ll.c and kic_k.c (I made those up, just examples) and the parser knows which abbreviated command you want by virtue of it being standardized per the filename. I presume these can be superseded by aliases, making it 1) a handy standard, 2) modifiable by the player.

I don't think it matters very much that DW happens to be LP, I figure this sort of an approach would work wherever. I am glad we're finally off the Red Vs Blue thing, that was well past its freshness date.

But, guys…didn't you notice this thread already achieved its purpose of providing me a 100 get?

-Crat
http://lpmuds.net
04 Feb, 2012, Rarva.Riendf wrote in the 109th comment:
Votes: 0
Quote
The point isn't being made about whether or not a command list can be sorted, obviously it can be. The point was that if you're relying on the order of commands to make player abbreviations work properly, anything which would disturb that order would make it impossible to do so.

There is nothing impossible at all, just a choice to make how to order the command that would disturb it.

Quote
E: "kill", "kiss", and "kick" would self-abbreviate to three characters, but an alias of 'k' => 'kill' would solve the problem in a clean and clear way, which the players themselves could alter if it didn't fit their play-style. '

Stuff that diku/merc/rom can do with a simple alias system so again, we are not discussing that.
You are proposing a default set of alias, I say it is uneeded to provide abreviation. I said you just have to make a choice.
Choice you are unable to think of in your way of thinking. You just dont want to make any BUT provide a default set of alias (so in the end you made some choice anyway).
04 Feb, 2012, quixadhal wrote in the 110th comment:
Votes: 0
Rarva.Riendf said:
Stuff that diku/merc/rom can do with a simple alias system so again, we are not discussing that.

*We* aren't? I was, maybe you refuse to because it doesn't advance your agenda.
Quote
You are proposing a default set of alias, I say it is uneeded to provide abreviation. I said you just have to make a choice.
Choice you are unable to think of in your way of thinking. You just dont want to make any BUT provide a default set of alias (so in the end you made some choice anyway).

You also seem to confuse "unable to think of" with "think you're wrong" and "think the way you are suggesting is unreliable and overly complicated" or perhaps "easy to implement and forget that you even did so, thus making it a royal pain for the next maintainer to adjust".

You've accused me of lacking imagination, yet you seem totally unable to even think of any other way to do things than the way you've chosen.. a way that fits nicely into the rigid hard-coded mechanics of your Dikurivative's command parser.
04 Feb, 2012, Rarva.Riendf wrote in the 111th comment:
Votes: 0
Ya know what, you are right, it is impossible to force a consistant order in a 'dynamic' environement…happy now ?…(jsut ignoring the fact that your player could order them themselves, not aliases, but just having a list of command they designed to be launched before any other when using abreviation…and I am the one lacking imagination…oh hell…I give up, hope all LPMud coder are not that closed minded…)
100.0/111