I'm not sure if im to put this in the bug reports or in feature suggestion, but /scon can bring along recursion, which is not something you want (in mIRC) i suppose

example of recursion, and following error when used:
* Error allocating stack memory
alias away { scon -at1 away $iif($1,$1-,) }

With mIRC i feel that when using scon/scid there probably should be a simple check to see if there is recursion happening though i have no idea if this is an easy fix.


sidenote: If anyone is interested, fixed it doing this: alias away { scon -at1 .raw away $iif($1,$1-,) }

A slightly more elegant solution is to use a ! prefix with the command, like so:



If you aren't already familiar with this, /!away will execute the default built-in /away command, thus ignoring any custom /away alias you have created. You can use this prefix to bypass any custom alias.

Unfortunately, it's difficult for mIRC to consider every possible scenario where recursion could occur, and in some cases it may even be desired. There probably is not an easy fix for this.

Good morning :>

I wasnt aware that using the ! prefix would also make mIRC use the built-in command as well, thanks =)

Anyhow, just thought i'd make a post since it does give that error, also i really wish the helpfile would be updated to have things like this included in it

It's in the helpfile under the Aliases topic, in the Command prefixes section. I learned it the hard way too

Ah, very easy to miss to be a apart of the "/.alias" part of it. It needs to be separated more, and its not clearly written imo, i didn't read that as "uses the built-in alias instead", probably because using the ! prefix on $identifiers yields a different result :P

Ah well, thanks anyhow =)

It's not part of "/.alias" it's part of "Aliases" - meaning custom aliases.. which is exactly where recursion usually applies!

It can also apply to signals:



Although for some reason, mIRC doesn't catch that and just runs that signal indefinitely and you have to ctrl+break to get out of it.

Anyhow, recursion is a very useful tool when used correctly and doesn't need to be "fixed" - the scripter just needs to be aware that it exists and how to get around it (by using !builtincommand)

That code will only cause recursion if you use /signal -n.

If a signal is calling itself in its own event, regardless of whether there's a delay or not, it's recursion.

If you meant that you get the error allocating stack memory error by using /signal -n, then yes you're right.

But without -n it's not. It is scheduling a signal for later, and the later invocation will not be from the context of the original event.

Fair enough. I don't know much about the underlying code, thanks!

alias away { if (%t.away) break | set -eu0 %t.away 1 | scon -at1 $iif($show,away,.away) $iif($1,$1-,) }

That'll fix your recursion problem.