Argument filter procs making use of the "expanding" var didn't receive the correct value for the expanding flag when first called.
BYOND Version:511
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 59.0.3071.115
Applies to:Dream Daemon
Status: Resolved (512.1416)

This issue has been resolved.
Descriptive Problem Summary:

The argument "expanding" for procs used to filter arguments for verbs can be used to require an option to typed in full. However, if no text has been entered for the argument and the player hits space, the list of valid arguments is generated as if !expanding. Sometimes even if text had been entered,

I'm assuming this is a bug because while I can imagine many uses for hidden list items that must be typed out to access, I can't imagine a use for arguments that are hidden when typing but can be freely selected from a list.

Further, if you start to type text for the argument then backspace, it the spacebar-expansion behaves as expected (hidden options remain hidden). After a few repetitions, the command expansion behaves erratically in terms of displaying the hidden option or not.

Numbered Steps to Reproduce Problem:

1. Make a verb called for example "talk" that takes an argument that's "anything in arguments(expanding))".
2. Define arguments(expanding) to return a list("one","two") if expanding and list("one","two","three") if !expanding.
3. Run the game and type "talk" then hit spacebar twice. All three options will display.
4. Type "t" and hit space; it will autofill to "two" because that is the only valid option being returned by arguments() when expanding is true.

The more I play around with this, the weirder it gets. Sometimes it will auto-expand the secret option, even though expanding should definitely be true.

Code Snippet (if applicable) to Reproduce Problem:

Here's a complete "mini project" that reproduces the weirdness I'm encountering in my larger one.


name = "Old Wise Person"
var/list/topics = list("hello"="Hi!","name"="I am error.","secret"="It's a secret to everybody.")
verb/talk(topic in topics(expanding))
set src in view()
usr << topics[topic]

if (expanding)
return list("hello","name")
return topics

Expected Results:

Only two options will autoexpand/autocomplete, with the third one being accessible only if typed in full.

Actual Results:

All three options can be autoexpanded, sometimes inconsistently after manipulating the command line text.

Does the problem occur:
Every time? Or how often? Every single time, though as mentioned above, the accuracy of the "expanding" variable seems to go up and down.
In other games? In both my test project and my main project.
In other user accounts? This seems to have no effect.
On other computers? On two so far.

When does the problem NOT occur? Sometimes after text has been entered and then deleted.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? I've never done anything with the "expanding" variable, so just for fun I went back to version 460. It didn't work then.

Workarounds: None that I can find. The help section on argument expanding suggests you can pass the value of the text being typed as an argument to the proc, like so:
verb/something(typing as anything in someproc(typing))

...and suggests that "typing" will be equal to the text you've typed so far, which could be used to validate secret argument options. But my test of this suggests that null or an empty string is passed to someproc() as the value of typing.
Bumping this as it's becoming a serious sticking point in my work.
Huh. I don't know how I missed this the first time around, but I'll jump on it.

The funny thing is, this is a feature I either never knew about or only ran into once and promptly forgot.
I didn't know about it, either, until last August when I tripped over it in the documentation. It neatly solved some tricky design problems in my MUD games... or it would, if it worked as described.

I wondered if it was some obscure thing that nobody ever used and so nobody had maintained its functionality or noticed it breaking during one of the client overhauls.
Lummox JR resolved issue with message:
Argument filter procs making use of the "expanding" var didn't receive the correct value for the expanding flag when first called.