Hello! I'd like to request a variable to use alongside "expanding" in passing along to verb argument procs called "final" that is set to 1 when the arguments are being checked the final time because the command has been sent/submitted, rather than when they're merely being entered/expanded.
This would be useful for server-side error catching. Example: in a MUD, you're getting ye flask at the same time thy dungeonman is. You both type"get ye-flask" and the command line takes this because ye-flask is showing up in your gettable() proc. But thy dungeonman is quicker on the draw, so by the time you hit enter, the valid entry of "get ye-flask" is invalid and you get an ugly and off-brand error message.
But if we could do get(item as anything in gettable(final)), the gettable proc could choose to accept that unacceptable entry, with the get verb then giving a graceful, in-game feedback explaining the how and why of you can't get ye flask as it doesn't show up in gettable(), only gettable(final=1).
If this can be done and the other bugs/omissions I've reported fixed, it officially replaces my request for a server-side error handling proc, as it would let me handle those things at the specific object/verb level, where BYOND does things best.
ID:2355445
 Mar 22 2018, 5:57 am (Edited on Mar 22 2018, 8:23 am)
|
|||||||
Redundant
| |||||||
Ahhhh, yeah, I think that would probably work, and maybe less awkwardly than you're imagining because of some other awkward things I'm already doing in the code to make the user experience slicker and the parser more powerful.
If I'm understanding how the thing you just fix for me works, there's no reason I can't have currentarg (as in, whatever's sitting in that space in the input line) added to the list of acceptable choices returned when !expanding, and then all it has to do is respond gracefully to the presence of unexpected text where it's looking for an object or whatever. So I think I'm probably good here. | |
Please feel free to resolve this one as redundant. The fully functioning argument-foo in 1417 does the trick.
| |
Lummox JR resolved issue (Redundant)
| |
The approach I'm thinking is like so: You pass the expanding flag and the argument to your arg proc. If not expanding, this is final, so you basically just have to check if the argument you got is consistent with any of the values in your list. If it isn't, you can return something like a special object that has the same name (with hyphens turned back into spaces, etc.). Then the verb executes, and you just check to see if the object you got as an argument is the special non-match arg or if it's normal.
Not a great way to handle that, I know.
IMO adding another argument to the arg procs is going to be a very difficult way to go about this too, though. I'd have to add a special var index like "expanding" uses, and it'd just be a mess. Plus that puts the feature off till 513.
I think what might work better is something in the client skin, which I can add right away, like "onerror" that will send parsing errors to a verb on the server in place of the regular output. (If for any reason it failed to parse the verb however, it should show the original output.) I think that proc might be interested in several things, such as:
1) What the full command entered was
2) Which argument failed to complete, or 0 if it was the verb itself
3) The text of just that argument
4) The text of DS's internal error message