I know that /timer has a special routine to look for variable assignments, so that the /timer command itself won't evaluate a variable in typical cases.
mIRC seems a bit greedy though, I was trying to pass parameter to an alias called via timer:

/main a inc c

Here if %b is 'inc', %c disappear:

with/without the leading forward slash, same thing happens with

/main a dec b
/main a set b

but not
/main a var b

Thanks for your bug report. This is a known issue. The /set, /inc, /dec commands require that the %var parameter is not evaluated when forming the command line. Previously, when /timer was used and included a reference to these commands, the %var was evaluated. Scripters requested that an exclusion be added for /timer in this case. However, as the parser works by evaluating all parameters first, then forming the command line, and then executing the command which parses its parameters, there is no way for the variable parser to know where the command starts in a variable parameter /timer command, especially if $+ and [ ] are used. This means that if you decide to use /set, /inc, or /dec in a /timer command, you will need to enclose your variable names with [ ] to prevent them from being parsed. This behaviour has been in place ever since this feature was added, so changes to this behaviour now would break all scripts that already do this.

The /var command cannot be supported in /timer as it is far too complex.

After testing this out, I decided to fix how %vars are parsed with /timer in the latest beta. This should be backwards compatible and work as before, except in cases where it was broken, as described above.

The code that parses %vars is very old. It has been tweaked over a long time to work the way it does. Unfortunately, it is also unecessarily complex because of all of the incremental changes over the years. So I decided to rewrite it completely. This is not something I normally do, especially with old code. But I think in this case it makes sense. However, this does mean it will need heavy testing as it affects how %vars are parsed. In my tests, the behaviour seems identical to previous versions, apart from the /timer fix. Please let me know if you spot any issues.

I notice that there is a malfunctioning script of mine that works in conjunction with sockwrite. Sometimes it does not read variables due to changes. In the previous beta this was not true.

Please provide a short, example script that reproduces your issue?

Also, please test your script again with the previous beta. Preferrably, run both the new beta and the old beta at the same time with the same script with debugging /echos to see how the results vary.

The previous beta no longer works, is limited to 30 days. However from what I notice, the variables when calling through the sock are not always timely answered when multiple calls are made from the sock. I have a fairly long script from an RSS feed reader and it reads several urls and with current version it sometimes does not reproduce the sock call.

The previous beta, v7.58.808, should still be working.

Either way, I really would need a method to reproduce the issue because, so far, I have not been able to reproduce any issues in any of my test scripts.

I would suggest that you add debugging information to your scripts and analyze the results.

I understand, but I also no longer have access to the previous version 7.58.808. However the script code is very long and as I said, what I notice is that whenever I execute the command that traces the urls where the feeds are downloaded, it calls the sock multiple times because there are several urls, and only the The second attempt is that it checks as if it were a lock that existed.

If you add debugging to your script, can you verify that this is due to incorrect %var parsing? That is the issue we need to track down.

I have added a link to the previous beta here.

Something goes with sockread or sockopen due to a change made in the latest beta. I apologize for not being able to identify where the error is, but I believe it will be due to the timer that was created in this change. Because when sockread or sockopen is called multiple times, it does not work for the first time. Even the $sockerr handle does not return the error.

Okay, thanks for testing it out. I will be reverting this change in the next beta.

Thank you Khaled
I apologize for not being able to help in the best way.

Thanks, I found an issue with how the variable parser handles /sockread parameters in the beta. I have released a new beta that reverts this change for now but will be fixing the /sockread issue and performing some more tests before including it again in the next beta.

It's ok
The beta released today normalized the /sockread command, when you release the new beta, I'll give you feedback