Quick Combat Questions

Ernam

@Arador nothing in the curing, alias, target, or queue system respects character status (retardation/stun/sleep/etc).  This was fixed shortly after release of server curing.

That is to say, it currently works as you are suggesting.

if you ever see evidence otherwise, be sure to bug it.

Arador

Tested it twice a week ago with Aegoth. Bugged it, no response yet.

Ernam

Arador said:

If you try and enqueue an alias set to stand/kick, it will still over ride the stand with the kick when it fires.

I think I simply misunderstood this part.  This is working exactly as intended and would work exactly the same way with a client side alias, which is how it is supposed to work.

if you don't want to stand/kick, then don't use an alias that uses stand/kick.  Use an alias that sends kick.  Pretty straight-forward.

Alaskar

@Ernam‌, I hate to say it, but some times I feel like you may form strong opinions without realizing you may be wrong. While stand/<action> is certainly useful, it will fall to shit in retardation.

https://ada-young.appspot.com/pastebin/8f999689

Like that.

Also, if I use the do queue in SVO, it checks to see if I am able to do something before doing it.

Server-Queueing https://ada-young.appspot.com/pastebin/948b54a2

SVO Queueing: https://ada-young.appspot.com/pastebin/321c04c0

In fairness, it did try it once, but then it clearly waited until writhed before attempting to do it again.

The situation could change before the command fires, certainly, but it wouldn't hurt for server queuing to simply check before wasting an action. It'd go a long ways in simplifying the use of server-queuing. Which I'm not saying is completely necessary, but that's essentially what's being discussed. And I wasn't referencing validating the command at time of entry; I was pondering the possibility of having the command validated at time of execution. 

1. <attack command>/off EQ
2. <queue attack command while waiting for EQ>
3. <second attack/combo queued through use of server alias>
4. <proned>
5. <here server-side will execute each action before standing.>
6. <stand>

It would be nice if at step 5 the game simply checks for hindrance before executing. So step 5 is then delayed until hindrance is removed.

Nexes

Alaskar said:

@Ernam‌, I hate to say it, but some times I feel like you may form strong opinions without realizing you may be wrong. While stand/<action> is certainly useful, it will fall to shit in retardation.

https://ada-young.appspot.com/pastebin/8f999689

Like that.

Also, if I use the do queue in SVO, it checks to see if I am able to do something before doing it.

Server-Queueing https://ada-young.appspot.com/pastebin/948b54a2

SVO Queueing: https://ada-young.appspot.com/pastebin/321c04c0

In fairness, it did try it once, but then it clearly waited until writhed before attempting to do it again.

The situation could change before the command fires, certainly, but it wouldn't hurt for server queuing to simply check before wasting an action. It'd go a long ways in simplifying the use of server-queuing. Which I'm not saying is completely necessary, but that's essentially what's being discussed. And I wasn't referencing validating the command at time of entry; I was pondering the possibility of having the command validated at time of execution. 

1. <attack command>/off EQ
2. <queue attack command while waiting for EQ>
3. <second attack/combo queued through use of server alias>
4. <proned>
5. <here server-side will execute each action before standing.>
6. <stand>

It would be nice if at step 5 the game simply checks for hindrance before executing. So step 5 is then delayed until hindrance is removed.

That's working correctly. Obviously in retardation you won't be using multi action aliases.

As for setting aliases, it's probably working that way so you can't change the meaning of an alias while you are waiting for the one second delay. You should do what you actually need to one at a time in retardation.

Arador

@Ernam‌, I know. I'm not saying it should work by firing one at a time. I agree with you and that part of it is functioning as I expect it to. It is only the fact that the queue add command and setalias command hits retardation that bothered me. If I want smart queues, SVO can do that.

Nexes

Arador said:

@Ernam‌, I know. I'm not saying it should work by firing one at a time. I agree with you and that part of it is functioning as I expect it to. It is only the fact that the queue add command and setalias command hits retardation that bothered me. If I want smart queues, SVO can do that.

First, I am not Ernam. Second, yes a client side system will "do" the right thing.

However, while I also would -like- the ability to change my aliases during retardation, I understand why that is not allowed. It would defeat some of the purpose of the 1 second delay. People who do not use server side systems are forced to re-send a new command if the situation changes, losing whatever time they've waited on their first command. If server side aliases didn't trigger this behavior, I would make it loop RETARDATION_COMMAND over and over, and simply set it to be what I need, never taking a loss for changing what I want to do. I am pretty sure that is not what is intended.

Alaskar

I don't think the actual setalias commands should be affected by retard. Obviously, it's probably not a big issue, but it should not be affected by retard. Changing the alias meaning during the one second wouldn't matter, as the command has been sent. To change it would, in my mind, start the one second delay again. 

Also, for queuing: 
https://ada-young.appspot.com/pastebin/1de6e83d

Affected by retardation. 

https://ada-young.appspot.com/pastebin/c7abdce7

Clearly, it can quickly become a problem in retard when multiple poorly timed commands are queued up and going crazy with each other. Also, CQ ALL seems to not be affected by retard.

And I'm not saying multi-command aliases should work in retard. I have created aliases which always work by making in-game aliases, and those don't work in retard, so I had to have a separate set of aliases for retardation. Not a big deal, but it took me by surprise when it first happened. Not sure why I use single command aliases to create single command aliases, but I was just making aliases (I switched computers)

And I also wasn't saying that server-queuing in regards to hindrance isn't working as intended, I merely indicated that it would be nice if it worked around hindrance. It'd make queuing commands far simpler.

Nexes

Alaskar said:

I don't think the actual setalias commands should be affected by retard. Obviously, it's probably not a big issue, but it should not be affected by retard. Changing the alias meaning during the one second wouldn't matter, as the command has been sent. To change it would, in my mind, start the one second delay again. 

Also, for queuing: 
https://ada-young.appspot.com/pastebin/1de6e83d

Affected by retardation. 

https://ada-young.appspot.com/pastebin/c7abdce7

Clearly, it can quickly become a problem in retard when multiple poorly timed commands are queued up and going crazy with each other. Also, CQ ALL seems to not be affected by retard.

And I'm not saying multi-command aliases should work in retard. I have created aliases which always work by making in-game aliases, and those don't work in retard, so I had to have a separate set of aliases for retardation. Not a big deal, but it took me by surprise when it first happened. Not sure why I use single command aliases to create single command aliases, but I was just making aliases (I switched computers)

And I also wasn't saying that server-queuing in regards to hindrance isn't working as intended, I merely indicated that it would be nice if it worked around hindrance. It'd make queuing commands far simpler.

I could see queue management being allowed for free, since they slap that 1 second delay when the queue fires anyways.

I merely indicated that it would be nice if it worked around hindrance. It'd make queuing commands far simpler.

I agree that it would make things simpler. I am trying to say that it might be OP.

Eld

Nexes said:

As for setting aliases, it's probably working that way so you can't change the meaning of an alias while you are waiting for the one second delay. You should do what you actually need to one at a time in retardation.

This is a potential reason for it, if server queueing evaluates aliases at execution time, rather than when they're queued. Is that how it works?

Seems to me it would be preferable (though possibly requiring more work to implement on the back end, depending on how things are set up) to evaluate aliases at queueing time, and then queue the resulting commands. For example,

  SETTARGET tar eld
  SETALIAS kk kick &tar
  QUEUE ADD BAL kk
  SETTARGET tar rat

resulting in kicking Eld on balance, rather than kicking a rat. IF it's the case that server queueing waits until execution to evaluate commands (so that it would send "kick rat" in that example), and IF that's the reason for SETALIAS and related commands respecting retardation, then changing that behaviour (if feasible) and allowing alias commands to ignore character status would seem to be a cleaner solution. It also seems more intuitive to me for the queue to execute the command I gave it as interpreted in the context in which it was given, rather than being affected by commands that come between the queueing and the execution, but that may just be me.

As for the statement about doing what you need to do one action at a time, there are a couple reasons it would be more convenient to be able to use aliases in retardation. One is, as @Arador mentioned, that being able to send commands in as consistent a way as possible tends to simplify coding. If I have an alias/hotkey/whatever that sets an alias to stand and do a slash/strike combo, possibly with an infusion or other extra commands, then queues that alias, I'm certainly going to want to change it to a single command in retardation, but it may well be easier to just modify the list of commands going into the alias (so that stand/slash tar/strike tar becomes just stand or whatever) and leave the rest the same, rather than having a whole separate chunk of code to queue the single command directly. I may also still want to do something like SETALIAS st touch amnesia/stand;QUEUE ADD BAL st. You certainly can just do those things by directly queueing commands rather than using aliases in retardation, but it's still potentially convenient to be able to use aliases for them, and I don't see a particular reason for the option not to be available.

Sena

setalias testalias1 tumble w/w
testalias1
queue add eqbal testalias1
setalias testalias1 touch idea

Alias "testalias1" will now execute: "tumble w/w"
3902h, 3850m, 18800e, 16400w ex-[15:33:10]
You begin to tumble agilely to the west.
You cease your tumbling.
You must regain balance first.
3902h, 3850m, 18800e, 16400w e-[15:33:30]
[System]: Added TESTALIAS1 to your eqbal queue.
3902h, 3850m, 18800e, 16400w e-[15:33:30]
Alias "testalias1" will now execute: "touch idea"
3902h, 3850m, 18800e, 16400w e-[15:33:30]
You have recovered balance on all limbs.
[System]: Running queued eqbal command: TESTALIAS1
You have no idea.

So queueing does evaluate aliases (and targets, since I've used that a lot while bashing) at execution, not when queued.

Eld

Actually, now that I think of it, that still shouldn't be a problem for retardation, since it should evaluate the alias when you get balance, try to execute all commands, giving the sluggish line for each one, and then execute the last one a second later if you haven't done anything to interrupt it, so sending a multi-command alias then changing the alias during the retardation delay wouldn't affect anything, anyway. I think I'd still prefer to have them evaluated at queueing time, but again, that's just personal preference. No reason for alias commands to respect retardation either way.

Ernam

They evaluate properly if you use addqueue.

however, I've bugged a lot of commands that evaluate on entry instead of when queued (like doublestab), which have all been fixed.

i recommend either bugging the things that do this, using addqueue, or both.

Antonius

@Eld Evaluating at queueing time would make the queue system far more difficult to use than it currently is.

Right now I can modify what an alias does and be confident that if it is queued it will execute the right commands. What I don't have to do currently, and what your suggestion would absolutely require me to do, is worry about whether or not that alias is currently queued and write a system to track queued commands.

Eld

Antonius said:

@Eld Evaluating at queueing time would make the queue system far more difficult to use than it currently is.

Right now I can modify what an alias does and be confident that if it is queued it will execute the right commands. What I don't have to do currently, and what your suggestion would absolutely require me to do, is worry about whether or not that alias is currently queued and write a system to track queued commands.

I was thinking of it in sort of the opposite direction. If I queue a command, I'd like to know what's going to be executed when the queue fires, and not have to worry about changes that I make subsequently changing the commands I've already queued. In any case, since the potential problem I was thinking of isn't actually a problem, I have no argument that it should be one way or the other; I'd find the other more intuitive, but if I start using the system more, I'll adjust to the way it is.

Ernam

I think the answer to your question here is to just not use the same aliases in retardation that you would use out of retardation (which is pretty much the point of retardation).

Obviously a chain of commands sent all together isn't going to work as you want it, forcing you to send one at a time.  I know this is obviously the point of retardation, but it seems to be exactly what you're having issues with - trying to use "normal" aliases while in retardation.

Not to be repetitive, but if you want to stand and then kick in retardation, you should use an alias to stand, then use an alias to kick, not an alias to stand/kick.  You certainly shouldn't expect anything to "figure out" the delays/logic necessary to do this and execute it for you, because that's quite literally automation (not the illegal kind).

I am going to go out on a limb and just say that people are just spoiled by SVO's clever retardation queueing system.  It's key to understand that you can do exactly the same thing using server queueing, but you still need to manage it client-side, because that kind of functionality simply can't be supported in-game.

Arador

@Nexes I know you are not Ernam. I was replying to Ernam, not you. @Ernam like I said, I don't expect setalias so stand/kick to be fired separately in retardation. I'm sending 2 commands to be fired, the second is going to eat the first. I know that, I understand that, I agree with that. My only issue is that the creation of an alias or the act of adding it to the queue hits retardation which is an obvious bug as I stated in my OP on this matter. 

Ernam

Arador said:

@Nexes I know you are not Ernam. I was replying to Ernam, not you. @Ernam like I said, I don't expect setalias so stand/kick to be fired separately in retardation. I'm sending 2 commands to be fired, the second is going to eat the first. I know that, I understand that, I agree with that. My only issue is that the creation of an alias or the act of adding it to the queue hits retardation which is an obvious bug as I stated in my OP on this matter. 

If SETALIAS is not ignoring retardation, then a bug report should have been the end of this, tbh.  If setalias is being delayed by retardation as you say, I am 100% sure it will be fixed, as soon as Makarios gets to it.

Adet

Related to the queueing discussion:

Sent By: Achaea on 1/20/18:05

Your bug report (detail: Server-side queueing: adding something to the queue can be affected by stupidity. If performing the action itself also has a chance to be affected, this means that stupidity can hit twice for the same action, overly penalising queue users. If performing that action does -not- have a chance to hit stupidity, this means that the player can simply send the command again before equilibrium/balance is regained, giving them an advantage over queue non-users.) - has been fixed.

Ernam

Dat @Makarios.   Dude does not sleep.

Kuy

There are times when certain people do lot react to Pranks Badjoke the way they are supposed to. I can't seem to replicate the problem. However, my badjokes never once broke Ellodin's shield in a skirmish yesterday, and I have no idea why. Anyone have a suggestion?

Jovolo

May have been true deaf or otherwise not heard the bad joke

Hasar

Wind @Kuy? 

Arador

Kuy taps his microphone. 

Kuy says, "Is this thing on?" 

Tough crowd. 

Cooper

Not -entirely- familiar with how badjoke works, but does it work if the person is off balance? If so, could have been spamming writhe.

Kuy

Truedeaf.

Tael

Do Formulation masks (specifically SECUREd Formulation masks) do anything yet? My understanding is that the ability to retain the defence after removing the mask was fixed, but I'm pretty sure the defence didn't actually do anything when I tested it initially.

Also, has anyone asked about whether it's possible to customise the alchemy masks?

Also also, I can't test right now, but what does "TEMPER has had its balance cost increased, providing more synergy with WRACK." mean? How does increasing the balance cost make it more synergistic and does this interfere with anything like the usual suggestion to take nimble as an alchemist?

Jovolo

Still nimble. At bus stop. Cold hands. Cant ecplain

Naverre

Is Shin Burst damage modified by int and/or by your level in Shindo?

Arador

What raises Deathaura damage? Int? Sash?