ID:2355405
 
Resolved
An obscure feature in the parser, allowing a potential argument to be validated by passing it to a proc, was broken way back in version 306.
BYOND Version:511
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 65.0.3325.162
Applies to:Dream Daemon
Status: Resolved (512.1417)

This issue has been resolved.
Descriptive Problem Summary:

Yet another obscure parser facet I've discovered in the documentation but can't get to work. Per the "argument expanding" section of the documentation, it's supposed to be possible to pass along a verb's argument to a proc used for validation of that same argument, and it will send the current value of the text being typed in. It appears that nothing is sent along.

That I'm aware of, I might be literally the first person to try to make use of this, but it could potentially let me do a lot of server-side error handling.

Numbered Steps to Reproduce Problem:

1. Create a verb with an argument "argument as anything in myproc(argument)"
2. Create myproc(argument) that outputs world << "Command: ([argument])" and returns list(argument)
3. When myproc is run, it should be outputting "Command: (whatever you typed)" and then accepting that as input, since it's in the list being returned.
4. Instead, the world output shows that argument is empty and nothing is in the list being returned.

Code Snippet (if applicable) to Reproduce Problem:
mob/verb/action(argument as anything in myproc(argument))
world << "Your totally valid input is [argument]."

mob/proc/myporc(argument)
world << "Command: ([argument])"
return list(argument)


Expected Results:

You should be able to type anything in for the verb argument, as whatever you pass along will be returned as a valid result.

(Note: this isn't how I would use the feature, as you can just use text. But it illustrates the principle.)


Actual Results:

"Arg" is empty until it's been accepted/validated.

Does the problem occur:
Every time? Or how often? Every time.
In other games? The feature is consistently missing/inoperative.
In other user accounts? N/A
On other computers? Yep.

When does the problem NOT occur?

It's been consistent since I first discovered it in the documentation. I thought it might be a side effect of the "expanding" bug (another obscure feature documented in the same place) I mentioned before, so I waited for the fix, but no joy.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Haven't found a version it worked for. Doesn't work in the stable release, the latest beta, or the earlier versions I tested the previous bug on.

Workarounds:

None as of yet.
Wow, this was a weird one. The routine that checks for the last argument looks at the arg structure of the proc it will be calling to find out the number of its arguments. However, the logic for that was broken in a past version, because it was dividing an ID array's length by 2, but for a long time now procs have stored additional data in that array and so the divisor has changed. This routine was hard-coded, and was never changed to use the new #define macro.

Here's the fun part: the value of ARG_DATA_LENGTH changed in version 306, and again in 309. Version 306 was the first BYOND build I ever used. So this bug predates my time on BYOND.

Another fun fact: You can combine this (now that it's fixed) with the expanding var like so:

mob/verb/action(argument as anything in myproc(expanding,argument))
world << "Your totally valid input is [argument]."

mob/proc/myproc(expanding, argument)
world << "Command: ([argument]) ([expanding])"
return list(argument)
Lummox JR resolved issue with message:
An obscure feature in the parser, allowing a potential argument to be validated by passing it to a proc, was broken way back in version 306.
Whew. Talk about a golden oldie. Thanks for the fix!

And yessssssssss. Combining it with expanding was exactly what I was hoping to do.
I wonder how many other features are around that haven't been used in ten years :P
In response to Flick
Flick wrote:
I wonder how many other features are around that haven't been used in ten years :P

The mysql database framework has a system to import the column as a number instead of a string or import into the rsc and give you a file reference to it, but this is so unknown and underused that nadrew actually commented it out from the dantom.db connector library saying it didn't seem to do anything even thou it worked in my testing of it.

In response to MrStonedOne
MrStonedOne wrote:
Flick wrote:
I wonder how many other features are around that haven't been used in ten years :P

The mysql database framework has a system to import the column as a number instead of a string or import into the rsc and give you a file reference to it, but this is so unknown and underused that nadrew actually commented it out from the dantom.db connector library saying it didn't seem to do anything even thou it worked in my testing of it.


Had no implementation in the version I was working with (the conversions list wasn't doing anything at the time), if that changed in the meantime (probably when they moved to a better library for it), nice.