Stop paralysis and stun from eating queues

Lenn

I posted this in-game via IDEA #39:

"Add some way for queueing to honour afflictions, perhaps a configurable list of afflictions to wait on, or maybe just an option to wait on common afflictions like paralysis/stun."

I imagine from a user perspective, assuming it's not just a basic CONFIG option, it could just be like the tree strategy thing, which I have not actually played with but seems to be pretty intelligent.

If you see any glaring issues with this, please let me know. If you think it's a good idea, please support it to help end my despair.

Antonius

This has been asked for, and rejected, multiple times (I'd say at least five, if not more) in classleads. As far as I understand it's just not possible to implement it without impacting the performance of the queueing system, and given how heavily that gets used that means impacting the performance of the entire game.

Lenn

I have a hard time believing it wouldn't improve performance given a common alternative is spamming the server with hundreds of commands each performing similar condition checks.

Atalkez

I think most of us don't spam the server with as many commands as you think. A lot of people will use an affcheck for Paralysis to determine if they need to send anything at all.

Cyr

Lenn said:

I have a hard time believing it wouldn't improve performance given a common alternative is spamming the server with hundreds of commands each performing similar condition checks.

Computing often isn't that simple. Given the system in place I wouldn't be shocked at all that it would create a huge drag on the queuing system, and that's without even seeing the code.  

Sena

Lenn said:

I have a hard time believing it wouldn't improve performance given a common alternative is spamming the server with hundreds of commands each performing similar condition checks.

Consider that very few people will actually be spamming those commands at any given time (most of the time nobody will), while having the game handle it means there's a slight impact every single time the queue runs for anyone. It wouldn't be surprising for that to add up pretty quickly.

Lenn

Most commands that get queued also have similar affliction checks already.

Edit: I'm not saying such a system for sure wouldn't cause performance issues, especially if naively coded. I'm just saying I have a hard time believing it's not possible and the reason is performance.

Cyr

Edit: nevermind, too many assumptions to make a clean discussion on the complexity 

Lenn

My personal assumptions for the above are that affliction, balance, queue, and config look-ups can be done in memory (no database look ups) and are significantly less of a bottleneck than sending a message to the client.

I'd indeed be surprised if these assumptions were incorrect.

Armali

You'd be surprised how archaic and ancient the Achaean engine is. Remember, it was created in the 90s and it HAS NOT BEEN UPDATED TO MODERN STANDARDS since.

Lenn

The idea was voted for review. Thanks to everyone who supported it.

I'll keep this thread updated with any details, even if it ends up only being a repeat of what's already been said above.

Astarod

Honestly, I fight in lag all the time. Queue solving my lag issues w/para(stun) would be immaculate. Thanks for posting the idea, Lenn. 


Yeah yeah, I know. I'll 'get gud'. :middlefinger: @Caelan

Lenn

Several months later, I got the unfortunately expected response:

Message #15933      Sent by Achaea

2019/11/07/20:49 Your idea (Add some way for queueing to honour afflictions, perhaps a configurable list of afflictions to wait on, or maybe just an option to wait on common afflictions like paralysis/stun.) has been deleted with comment: Due to the way that queueing is implemented, this is not possible at current.

Cooper

You're still missing the point that paralysis and stun are intended to disrupt offense. As has been suggested to you several times, you can write a short script that will require your actions for you if you really want that.

Minifie

Stun and paralysis also negatively impact you moreso the higher your latency is, to a degree that windows of opportunity that someone with a 50ms latency can take advantage off are stopped for 500ms. I have checks if para or stun are true I don't send my attack command, and while serverside will catch they are gone, my end won't, so for me, para and stun aren't 1.6s or so of hinderance, it can be up to ~2s. Fair cop if they want it to work like this, but it's basically extra punishment for those not close to the server.

Namino

As a monk who uses mind command liberally, paralysis is actually miserable when latency is even marginally present.

>sends combo
>gets paralyzed during latency
>combo including the undeafening jab eaten by paralysis
>mind command not stopped by paralysis, pointlessly goes through, stripping my equilibrium for 4 seconds
>cue endless loop
>die in abject misery

That being said if you wrap every single attack you do in a paralysis check this isn't a problem, and you can hammer the attack until it goes through, which is what the phenomenon finally motivated me to do.

Lenn

Cooper said:

You're still missing the point that paralysis and stun are intended to disrupt offense. As has been suggested to you several times, you can write a short script that will require your actions for you if you really want that.

No thanks.

Cooper

Minifie said:

Stun and paralysis also negatively impact you moreso the higher your latency is, to a degree that windows of opportunity that someone with a 50ms latency can take advantage off are stopped for 500ms. I have checks if para or stun are true I don't send my attack command, and while serverside will catch they are gone, my end won't, so for me, para and stun aren't 1.6s or so of hinderance, it can be up to ~2s. Fair cop if they want it to work like this, but it's basically extra punishment for those not close to the server.

Why would you code something that directly delays your attacks like that? Gag the failed going through/you are paralyzed message instead. 

Minifie

Cooper said:

Minifie said:

Stun and paralysis also negatively impact you moreso the higher your latency is, to a degree that windows of opportunity that someone with a 50ms latency can take advantage off are stopped for 500ms. I have checks if para or stun are true I don't send my attack command, and while serverside will catch they are gone, my end won't, so for me, para and stun aren't 1.6s or so of hinderance, it can be up to ~2s. Fair cop if they want it to work like this, but it's basically extra punishment for those not close to the server.

Why would you code something that directly delays your attacks like that? Gag the failed going through/you are paralyzed message instead. 

What do you mean? If I am not paralysed, and send a command to queue, the queue arrives and I am paralysed, it stores it until I eat magnesium or cure paralysis. However, this still requires my client to receive that information, so it can then deploy that command. I lose out on time because I still have to receive that information, then have the client respond and send the command. My return latency is usually around 500ms, which means that if paralysis eats my queue, I need the cure to happen, the message to show up on my mudlet, for it to send and for the server to receive it. If I THEN get paralysis again before this entire routine happens, I lose the attack completely, even though I was not paralysed at the time. There is no way around this, unless I can have a toggle to pause queueing until SS cures paralysis then it turns queuing back on and deploys from server end. If there is something I'm not doing that can get around this, I am all ears, but I've not figured it out without requiring my side receiving the information that paralysis is cured and my side sending the command back to the server.

Accipiter

I think he is saying spam your attack constantly so it goes through, but doesn't realise that how Achaea accepts commands makes it not reasonable to do with a high ping.

Khel

Maybe something worth looking into is a way to bundle an entire attack to where if one piece fails, the whole thing does? If I rend as dragon and it gets blocked by paralysis, my illusion can still go through, just like @Namino and mind command. I'd rather they both fail. So like...

setalias attk stand/light pipes/bundle(dragoncurse 1 sensitivity/rend target head/conjure illusion target please stop curing)/sq n

No idea about the viability of that, either, but it would let me spam my attack without worrying about needing to trigger a successful rend to illusion and the associated latency thereof.

Minifie

Accipiter said:

I think he is saying spam your attack constantly so it goes through, but doesn't realise that how Achaea accepts commands makes it not reasonable to do with a high ping.

Except I react to eats etc. . . spamming definitely leaves me in a bad position!

Archaeon

Gag the para etc lines that spam 

Cooper

Accipiter said:

I think he is saying spam your attack constantly so it goes through, but doesn't realise that how Achaea accepts commands makes it not reasonable to do with a high ping.

Every top fighter spams attacks to attack as quickly as possible. To only input attack commands when you aren't paralysed is purposely handicapping yourself.

Archaeon

The .1ms delay on using your own queues for that kind of shit. I highly suggest spamming.

Astarod

Just treat Lag like OOC blackout. 

Predict the eats! Predict the predictions!

If you don't have your killpath memorized who even are you. 

Antonius

Cooper said:

You're still missing the point that paralysis and stun are intended to disrupt offense.

Having the queueing system wait until hindering afflictions aren't present to execute (some) commands wouldn't stop hindering afflictions from hindering you, so it doesn't seem like that point has been missed?

Minifie said:

Accipiter said:

I think he is saying spam your attack constantly so it goes through, but doesn't realise that how Achaea accepts commands makes it not reasonable to do with a high ping.

Except I react to eats etc. . . spamming definitely leaves me in a bad position!

I manually select afflictions, and spam attacks through paralysis/stun (without gagging the resulting output, even!), so I'm not sure why it would. What do you think the problem(s) would be? (Or what problems did you experience, if you've already tried it?)

Minifie

Antonius said:

Cooper said:

You're still missing the point that paralysis and stun are intended to disrupt offense.

Having the queueing system wait until hindering afflictions aren't present to execute (some) commands wouldn't stop hindering afflictions from hindering you, so it doesn't seem like that point has been missed?

Minifie said:

Accipiter said:

I think he is saying spam your attack constantly so it goes through, but doesn't realise that how Achaea accepts commands makes it not reasonable to do with a high ping.

Except I react to eats etc. . . spamming definitely leaves me in a bad position!

I manually select afflictions, and spam attacks through paralysis/stun (without gagging the resulting output, even!), so I'm not sure why it would. What do you think the problem(s) would be? (Or what problems did you experience, if you've already tried it?)

the problems aren't technical, but more hyperfocus. I can spam, but when I spam I tend to drift off, I find more methodical play keeps my focus in tact and response time better. I can swap to spamming, and adapt, but the latency part still isn't something that I KNOW I can fix on my end with regards to queue chomping of para/stun. If there is, I am absolutely prepared to change and adapt, but I just don't know how .

Namino

And again, reiterating that none of the proposed solutions are effective against attacks of which only a component of which is blocked by paralysis.

Spamming those will get you super murdered real fast as you continuously throw yourself off balance/equilibrium while your attacks do not have their intended effect, and if your latency is not great, trying to thread them in between paralysis cures becomes an exercise in hilarity. You get paralyzed after sending the command whilst unparalyzed (and thereby de-toothing the argument you can do a paralysis check client side). When your client checks, you're not paralyzed, it goes 'okie dokie boss' and sends the command, but by the time the server has received the command, you are now paralyzed, and throw yourself off equilibrium.

Edit: The obvious solution is to reflex the paralysis-insensitive part of the attack to fire when the paralysis-sensitive part completes successfully, but again the issue of latency rears its head, as if your latency is sufficient, your opponent will cure/react to whatever the paralysis-sensitive portion of the attack did prior to the insensitive command that was relying on it to be effective. The entire point of the queue per the help file is to help standardize people who have differing latencies, so this seems to be directly down that alley.

Khel

Namino said:

And again, reiterating that none of the proposed solutions are effective against attacks of which only a component of which is blocked by paralysis.

Khel said:

Maybe something worth looking into is a way to bundle an entire attack to where if one piece fails, the whole thing does? If I rend as dragon and it gets blocked by paralysis, my illusion can still go through, just like @Namino and mind command. I'd rather they both fail. So like...

setalias attk stand/light pipes/bundle(dragoncurse 1 sensitivity/rend target head/conjure illusion target please stop curing)/sq n

No idea about the viability of that, either, but it would let me spam my attack without worrying about needing to trigger a successful rend to illusion and the associated latency thereof.

Namino

Correction: One proposed solution is effective.