Aliases may not queue commands.

Aelios

So, after searching the Forums for a discussion on this - I feel this is somewhat relevant.

Any idea why this change was put in? It seems counter-intuitive. As a bard, my offense relies heavily on dealing with two different balances - and making one alias to do the following is the easiest way to manage this:

"setalias AeliosAttack tunesmith rapier pesante / queue add eqbal jab @Tecton"
"send AeliosAttack" 

Sure, it's a relatively easy swap to Client-side, but it means I've got to go edit 30 or so aliases to do the same exact thing, so I'm not really sure what this accomplishes as a change?

Or maybe I'm alone in this frustration. Who knows.

Aesi

I suspect it might have caused problems if aliases were recursively calling themselves.

Otherwise, perhaps it's an attempt to level the playing field a bit, instead of queueing 14 things at once in the same packet you need to send a few requests, bringing latency into play.

Aelios

This is very easily countered by how Achaea handles commands. It's why many fighters enter a "delay" command first, by prefacing their offense with "stand".

Achaea processes commands in batches, after the first has been sent.


So, a series of : SEND/SMILE/DANCE would process SEND first, then a slight delay, and SMILE/DANCE would be sent at the same time in the following packet.

Aesi

Yeah, you're right. Just conjecture at this point.

Antonius

Recursion is the likely answer, yes. Allowing people to queue commands from aliases, and still allow them to queue aliases, would potentially allow one idiot doing something dumb to bring down the entire server.

Krypton

Aelios said:

Or maybe I'm alone in this frustration. Who knows.

Definitely not alone

Dochitha

@aelios you could do this:

send("setalias AeliosAttack tunesmith rapier pesante/jab @Tecton curare")
send("setalias AeliosSing sing limerick at @Tecton")
send("queue add eqbal AeliosAttack/queue add class AeliosSing") 

I have the impression that they accomplish the same thing, just more lines.

Aelios

I've tried the recursion thing though, the old alias wouldn't call any other aliases.

Like : 

setalias test1 smile at antonious
setalias test2 hop antonious/test1

test2

It wouldn't fire "test1", it'd view that as a command itself - which its not.

Tharvis

i have a feeling this mostly hits mobile users

-but apparently rumor is it was removed after someone managed to create an infinite loop?

Aesi

Setalias lolcrash queue add eqbal lolcrash

that would be bad.

Aelios

A better solution would be just to remove the ability of server-side aliases to call other server-side aliases.

It's like burning down a house instead of killing a spider.

Tesha

Burning your house down in reaction to a spider is a perfectly reasonable reaction, though.

Antonius

Aelios said:

A better solution would be just to remove the ability of server-side aliases to call other server-side aliases.

Haven't we (you) already proven that that doesn't work already?

If you mean remove the ability of server-side aliases to queue other server-side aliases, that's not really feasible. You'd have to check at the point that the queued command fires, which is a pretty substantial increase in overhead to the queueing system.

Krypton

In-game aliases (i.e., SETALIAS) cannot call other in-game aliases, and they cannot call Nexus window aliases either.

But... Nexus window aliases CAN call each other AND call in-game aliases.

Aelios

Krypton said:

In-game aliases (i.e., SETALIAS) cannot call other in-game aliases, and they cannot call Nexus window aliases either.

But... Nexus window aliases CAN call each other AND call in-game aliases.

In game aliases, however, are now unable to call queue'd actions. It isn't even calling other aliases.

Any weighing in on this, @Tecton @Sarapis @Makarios ?