Forums Bug Reports /set in editbox, /var .secs

I came across these issues while replying to the /saveini thread.

(1) When a local %var is created, it clones the .secs value from an existing global var of the same name. Luckily it appears the .secs value is ignored, even when the local scope contains a while() that lasts longer, as the local's .secs isn't getting decremented.



(2) In editbox, when /set is used with a single slash, and there is more than 1 space preceding the switch parameter and/or the %var_name, it generates an error and does not set the variable.





I'm not aware of another /command that behaves as if it even notices whether you've used consecutive spaces or not. Though this way does allow setting global variables containing consecutive spaces, it shouldn't need to forbid them preceding the variable name.


EDIT: **

sorry for the typo. I meant for my examples to show using the /SET command not /VAR, which instead is treated as if an invalid command that gets sent to the server, even with the -g switch.

Thanks I am aware of both of these. The first is a side-effect of how the unset feature was originally implemented. The implementation has changed over the years, so it might be possible to change this but either way, as you noticed, it has no effect. The second issue is intentional and cannot be changed.

ok.
And related to the 2nd issue, i didn't mention a similar issue with single-slashed var in the editbox being treated as an invalid command that's sent to the server, since it formerly had no effect without the 2nd slash to evaluate things. However now with the -g switch, /var can have a reason to be used in the editbox without 2 slashes, though in that context it's just something that should be done with /set instead.

Edit:
Correction. when using "/var -g %x 123", it's not the /var that gets sent as the invalid server command, but the -g.

When I test this in an editbox, the entire /var line gets sent to the server.

This is due to the way /var was originally implemented, as a way of setting local variables in a script. /var is not actually a command in the same way as other commands. It is parsed inline, inbetween other script parser processes, and converted to /set internally. This means that if I did change it to be a normal command, its code would be moved outside of its current parsing sequence, which would likely lead to backwards-compatibility issues.

To prevent /var being sent to the server, I will add a second check for /var as a normal command which will report an error.

Same as in no-beta, in newest beta I'm seeing /var in editbox sending info to the server, just neither sending the 'var' string itself.



Causes @debug window to show:

I am afraid I am unable to reproduce this issue here. When I type /var in any editbox, I now see the message "* /var: cannot use here". Are you perhaps using a script that is circumventing the normal processing of commands?

Not sure that we need an error message - we quite often use /var in an editbox to provide you with examples of bugs.

It seems to me that an editbox line should be treated as an alias (subroutine) and variables treated as local variable until the editbox script terminates when they are deleted.

Please see above posts. /var unevaluated shows error message because it will be sent to server. //var evaulated is not.

Ah - yes - I forgot about / vs. //.

Sorry, I had a stray comment in aliases file missing a semi-colon that was behaving like an alias, that formerly was never triggered by //var. I see the cannot-use message now.