Incoming Macro Changes

[Kunaak]

as long as "Cancel Spellcast" and "Clear all queued abilities" work fine in the same macro, I'll live.

oh, and target macro too

as a raider, I know first hand, just how badly lag is getting. theres been a few times in the last few months, where we just had to completly leave a zone mid way through, cause of 3-4 second delays on hitting a button, pulling, and having the entire raid basically "freeze in place" then insta death, as soon as the game caught up. lag has been getting really really bad in the last year, but mainly in the last 6 months. I even hear in SF right now, no one will even try to pull the new contesteds, cause as soon as half a raid forms - the game becomes a slide show.

just leave the basic macros alone - like dont get smart and deciede we dont need a target macro, or cancel spellcast.

theres few things that suck as bad as having a foot and a half tall add wandering around that you have to find, or it wipes the raid, and you have 12 void beasts the size of trees, and a entire raid blocking any hope of seeing anything that small.

or getting a curse that has to be cured in 4 seconds or your groups dead, and you curse cure takes 3 seconds to cast, and your already in the middle of a cast.

[Elebu]

I mean why not right?  The first cut of this was [Removed for Content] and right before an xpack launch. Now that the xpack is out, time to bring down the hammer (again).

You guys never cease to amaze me.

[Jonaroth]

These changes sound great. I was really worried when you guys changed macros last time as it kinda broke my ability to two box in this game, but this new change should be a good change.

[BubbaCajunOG]

What do these changes mean to macros that, have either A) Equip offhand-->Usespell. B) Equip armor, equip armor, equip armor,--->Use spell--->2nd Macro Equip armor, Equip armor, Equip armor. (There used to be several buff armor peices that would increase the duration and proc % of cob, without being stuck with these peices for the duration of the whole fight, one macro to equip instantly before cob and one to equip your wanted armor during the fight with another macro as cob was casting.) C) Use spell----> Equip offhand/Shield. (Ive noticed that if i switch out any of my offhands or ranged while in combat my casting spell will stop casting...Why?)

[Captain Apple Darkberry]

Quisical wrote:

I`m not for consolidating spells, I like the activety and choice of what I cast and when. I have never used a macro since I started playing at launch and I am a raid/myth main healer - I enjoy PLAYING my character. Yes I have a lot of hotbars, every spell in my book is available with a single click.

^ This.

Yeah...I know that clicking buttons can be hard.  ...and switching targets to click buttons before you switch targets to click more buttons again is even harder.  ...and OMG! not to mention remembering who you last clicked buttons on!  ...but seriously?

While I enjoy the utility of the macro system, and put it to good use, I would be in favor of change if said change actually helps with lag/server performance.

[Calain80]

I actually like the change. While I would also prefer a special "queue command", I don't have a problem if the last ability is queued. Most of my macros are the CA and Spell Version of an ability (CA -> Spell -> CA). As long as the client does know, when to send the CA and when to send the spell (not in range for CA), nothing will change for me.

ArivenGemini wrote:

Rothgar wrote:

The only issue I see at the moment that needs to be worked out are macros that spam the same ability with different targets.

What about extending the system to allow more than one recipient on the command, such that the list is passed to the server and it checks for the first one that it can cast on and handles it that way?   not ideal because it still requires the server to process those checks.

I also like this idea. If you could send a usabilityonplayer ability ... command. where ... means all the possible targets divided by a blank. (e.g. useabilityonplayer "Jester's Cap" Rothgar ArivenGemini Calberak).

While this would need some code changes on the server side it will probably have the least impact on performance (as you would only need to check once, if the ability is actually ready) at the cost of a small memory overhead. (as you need to add a pointer to the list of possible targets and store the list instead of just a pointer to a single target.

You might even check if it is a possible target on the client side (checking if it is a group or raid member) before sending out the command so you only send the names of "confirmed" targets to further reduce the number of checks that need to be done by the server. Or you could limit it to a certain number (possibly 5) of max targets, that will be checked.

[Azzad]

I only use 2 command macros. I don't feel that is exploiting in any way.

I wouldn't even mind hitting the button twice, i mainly do it to save room on the hot bar, but this system means you can't put toggle effects in a macro at all because hitting it the second time to do the second ability wil toggle off the first ability.

[Eriol]

Thanks for responding to my earlier post Rothgar.  It didn't help my understanding much, but over the course of the thread and most of your responses, I have a clearer idea what the "current" idea is.  That being said, I have a question/clarification about what is now being said:

Rothgar wrote:

Macros will now be pre-processed on the client before sending anything to the server.  This extra "intelligence" will let us reduce the amount of spam and hopefully make them work better for you in the long run.

When you press a macro key, the first available ability will be sent to the server.  The last ability in the list will then be queued.  If the first first available spell has a zero casting time, the next available spell will also be sent. 

If you are currently casting or no spells in the macro are available for casting, the last ability will still be queued.  This mimics the existing behavior and still allows queuing to work.

So if I read this right, if you have a macro with 3 hostile spells in it, call them A, B, C, and ability B has ZERO casting time, and group messages between each cast, a, b, c, the macro would have the following arrangement (top to bottom) of: a, A, b, B, c, C.  Now consider the following scenarios.  Expected Results are what I expect based upon what you've said above:

Scenario 1:  The player is not casting anything, and has an appropriate target and hits the macro.

Expected Results 1: Message a gets sent, Abilitiy A starts to cast, message b is sent, and message c is sent, and ability C is queued.

Scenario 2: Ability A is on cooldown, and a spell is being cast (possibly A, but doesn't matter, but player is in the middle of casting), and the macro is hit.

Expected Results 2: Message a gets sent, Message b gets sent, Message c gets sent, and ability C is queued.  This is according to the last paragraph I quoted.

Scenario 3. Ability C is on cooldown, and a spell is being cast that is not from the macro.

Expected Results 3: Message a gets sent, Ability A gets queued, message b gets sent, message c gets sent.

Is all of the above right?  I'm not somebody who uses multi-spell macros (though I can see the value of using an insta-cast then ability one), but I wanted to be clear in my understanding.  At most for myself currently, I use a "message then ability cast" one, so as long as those queue correctly (and by what you've said, it seems like they will no problem) then I'M happy, but I want to be clear for everybody.

[Redchief]

Rothgar wrote:

Several weeks ago we made a round of changes to improve server performance.  One of these changes was to throttle the amount of unnecessary command spam coming from the client as a result of the macro system.  This had a few side-effects that were noticable to the average player enough that we decided to revert those changes until a better solution could be implemented.

We think we have a better solution and will be making it available to the Test Server soon.  I just wanted to give you a heads-up with a quick explanation of these changes.

Macros will now be pre-processed on the client before sending anything to the server.  This extra "intelligence" will let us reduce the amount of spam and hopefully make them work better for you in the long run.

When you press a macro key, the first available ability will be sent to the server.  The last ability in the list will then be queued.  If the first first available spell has a zero casting time, the next available spell will also be sent. 

If you are currently casting or no spells in the macro are available for casting, the last ability will still be queued.  This mimics the existing behavior and still allows queuing to work.

These changes should achieve our goal without significantly impacting the way you currently use macros.

As always, your feedback is welcome!

PLEASE READ THE ENTIRE THREAD BEFORE RESPONDING. 

This thread is an ongoing discussion.  Before you ask something that has been answered, please make sure you read the entire thread.

So after reading the entire thread, and your first post twice, the simple explanation is that macros will work as they do now on the surface, but the actual checks for reuse/availabity will be done client side rather than on the server.  Thus reducing processor request on the server, thus knocking out some of the lag.  Is this correct?

[Fendaria]

Do we only get one insta cast spell per macro? I believe the Sorcerers now will have two insta cast spells that they will want to use, Cataclysm and Freehand Sorcery, and will often want to use these on the same spell. Fendaria

[Leucippus]

Rothgar wrote:

SkyBee wrote:

From what I am reading, if I cast a spell directly followed by a macroed spell, then I am going to have to repeatedly tap the macro, since macro will not allow use of the queue ability, until it casts so I do not lose time in the casting routine. Ugh, the aggravation ....   This change will force players watch watch their casting progress bar like a hawk.

As I have it currently, if you are casting and click a macro icon, the last ability in the list will queue.  This is exactly how it would occur today except that instead of it sending 20 useability commands, each one overwriting the other, the macro will now just send the last one.

I like this change, but I have a question on wording related to this phrase in the starter post:

"When you press a macro key, the first available ability will be sent to the server. The last ability in the list will then be queued. If the first first available spell has a zero casting time, the next available spell will also be sent. "

Does "last ability in the list" have the same meaning as "first available ability"? If not, then the above statement "This is exactly how it would occur today..." is not quite right.

Ignoring the zero cast time abilities for the moment, as these huge macros work today, the "first ability", scanning from top to bottom of the entries in the macro, is cast, and the "first ability", scanning from the bottom to the top of the entries in the macro is queued. The queued ability changes quite often between casts, as different abilities become available as their refresh timers expire. These huge macros are typically clicked as fast as one can click; lag prevents one from simply clicking when an ability appears to be ready (doing so would defeat the purpose of spell queueing almost entirely, actually).

To reuse an earlier example

Master StrikeIce CometBall of Fire

Assuming Master Strike is cast would:

(1) Master Strike cast and Ball of Fire queue

or

(2) Master Strike cast and Ice Comet queue

or

(3)  Master Strike cast and nothing queue

It sounds like after this change (1) would occur; however, currently, (2) would occur if Ball of Fire was currently unavailable. If all were available, then (1) would occur both currently and and after this change. The statement "This is exactly how it would occur today.." conflicts with this thought, so I am a bit confused. (Yes, this earlier example is a bit poor to demonstrate this situation because Ball of Fire has a much faster reuse time than Ice Comet; if the order of Ice Comet and Ball of Fire were reversed in the example, then this queuing order situation would occur more frequently.) As things currently are, (3) would only occur if both Ice Comet and Ball of Fire were unavailable.

Various other related thoughts:

Only some zero cast time abilities work in macros. Only the ones that cast while another ability is currently casting work in macros. It would be nice if they all worked this way, but they do not. (The effective cast time of those that do not is instant plus lag time (or perhaps double lag time, they defeat spell queueing) instead of instant, sigh.)

These huge macros often have the first entry and the last entry being exactly the same. Doing so allows that ability to be cast first, whenever it is available.

With this change, there will still be quite a few extra messages sent to the server, duplicate queue messages. Perhaps the client could keep track which spell is (expected) to be currently queued, and not attempt to requeue that same spell more than, say, four times a second or so (0.25 seconds is the minimum, non-instant, recovery time, which is why I picked four times a second, it could be less frequent conceivably); it has to be resent every so often unless the server sends a confirmation of which spell currently is queued.

It would be nice if this huge macro only needed to be clicked once to start it, then the client (rapidly) would process the casting and queueing of abilities, as mentioned above, without need for another click. If done this way, extra queue requests might not sent to the server, and the macro would behave similar to the way auto-attack works now. Manually casting another ability, macro, etc. should stop this behavior, requiring another click of this macro to restart the behavior. (What happens is, in the presence of lag, these macros need to be clicked very quickly to have spell queueing work properly; the time between clicks effectively adds to the cast time of the cast ability, if queuing fails, or to the reuse time of the cast/queued ability, if queueing succeeds.)

End of my too long post.

-Leucippus

[Leucippus]

After a little more thought, and ignoring the current mechanics for a moment, and ignoring the instant cast situation, what I would like these huge macros to do (all on the client side of course) is:

Scanning the huge macro from top to bottom, cast or queue the first available ability. Keep the queued ability current with respect to this huge macro at all times.

Perhaps many of the constructs one finds in these huge macros are just a way of trying to implement that statement with the current game mechanics. The number of available abilities can be overwhelming, as others have also stated. The second sentence in that desire leads to the clicking of the macro button (or key) as fast as possible; (it would be so nice if one of these "spare" processor cores could handle that boring task). Notice: no scanning from bottom to top for the ability to queue.

Remember, "first available ability", as mentioned just now above, takes into account everything (from the client's point of view of course), not just spell reuse timers. (range, target type, available power(mana), etc.)

-Leucippus

[Gungo]

BubbaCajunOG wrote:

What do these changes mean to macros that, have either A) Equip offhand-->Usespell. B) Equip armor, equip armor, equip armor,--->Use spell--->2nd Macro Equip armor, Equip armor, Equip armor. (There used to be several buff armor peices that would increase the duration and proc % of cob, without being stuck with these peices for the duration of the whole fight, one macro to equip instantly before cob and one to equip your wanted armor during the fight with another macro as cob was casting.) C) Use spell----> Equip offhand/Shield. (Ive noticed that if i switch out any of my offhands or ranged while in combat my casting spell will stop casting...Why?)

gear exploit. People were casting spells w items that buffed the spell and unequiping the item before cast finished and keeping the buffed effect.

[redhill]

Not in the 9 or 10 years of playing eq1 and eq2 have I ever posted on the forum but this change brings me here.  Please do not change they way this game is played.  I for one will cancle 4 accounts and almost did when the last attempt at fixing the macro system went in.  I do hope you can help lag but not at the cost of playablity. 

[Leucippus]

SkyBee wrote:

Dirges (with Gravitas), Troubs (with Jcap), and Illies (with Timewarp) all use this implementation of up to 5 targets (for bards with t8 sig drum) and 4 targets for Illies. I do not know what other abilities require this. I think these are the only abilities that require this.

I hope a compromise will be found to allow this to work.

My troubador, without the T8 signature drum, needs six targets. Jester's Cap immunity can be on all six group members simultaneously, the macro still fails to find a valid target sometimes. Perhaps a couple more, like eight, would be a better limit, to allow for some more gear growth.

With more than one troub in a raid, you might need more than six, but that case could be ignored with no one noticing most likely.

-Leucippus

[DuneWarrior]

I dont mind the changes to badly, as long as it mimics the behaviour we have today as close as possible.

I, as many others, also think that if you ARE giveing it a quick rework, add a /Wait AS well as doing the rework you lined out in the original post.

While i know the logic behind NOT having the /wait back from launch, i think the time is there for you guys to reconsider this small addition to macros which in ADDITION to your changes would lower server macro processesing substantially, simply because many of the current mass macro users would modify their macros to use /wait, thereby having the processing happen client side for larger buff macros, HQ's, Stealths etc.

[Rothgar]

Fendaria wrote:

Do we only get one insta cast spell per macro? I believe the Sorcerers now will have two insta cast spells that they will want to use, Cataclysm and Freehand Sorcery, and will often want to use these on the same spell. Fendaria

All instant-cast spells will be sent as long as they are the first available spells.  When the macro hits an available spell that is NOT instant-cast, it will stop sending useability commands except for queuing the last ability.

I've seen lots of questions about very specific macro scenarios.  I think so far all of them that you've asked will work fine.  These changes will not affect any other commands except for "useability" commands.  So using items, equipping gear, canceling spellcast, etc., will all work fine.

The point of this post is really to get feedback on the new system before it goes to Test, but I'd really like you guys to try it on test and give feedback then as well.  This will answer all your questions about what works and what doesn't work.

[ranga]

OK here's my feedback.

If the new system breaks existing macros it's not fit for purpose so find another solution please. Don't even put it on test. Explore it some more. Find one that works.

Then bring it back for comment please.

That's how it works in my job TYVM

[Talazar]

ranga wrote:

OK here's my feedback.

If the new system breaks existing macros it's not fit for purpose so find another solution please. Don't even put it on test. Explore it some more. Find one that works.

Then bring it back for comment please.

That's how it works in my job TYVM

It won't.

[Silzin]

Rothgar wrote:

When you press a macro key, the first available ability will be sent to the server.  The last ability in the list will then be queued.  If the first first available spell has a zero casting time, the next available spell will also be sent.

I think i understand the rest, but 1 thing.  for a long macro string will only the last spell/CA be queued or will it queu the last availabl?

[Armawk]

ranga wrote:

OK here's my feedback.

If the new system breaks existing macros it's not fit for purpose so find another solution please. Don't even put it on test. Explore it some more. Find one that works.

Then bring it back for comment please.

That's how it works in my job TYVM

I cant agree. If existing macros are either-

1: huge and bloated and cost a lot of server time

2: huge and complex and come close to autoplay

Then stopping them working is a good idea.

You are supposed to actually play the game yourself, macros should be for minor items of convenience not to mean you dont have to bother with boring things like selecting targets or casting chains of spells.

[Valdaglerion]

A few thoughts and questions...

1. Harvest abilities being combined into a single ability . . . how will this work with various harvesting tools and gear. IE. Overclocked Mining Pick that decreases MINING time by 2.5 seconds or items that add +skill to a single type such as fishing? If they all become "harvest" will those tools all need to be revamped?
2. Macros other than spells . . . obviously the spell queing is crucial to a lot of macros but what about equippping and unequipping gear. These range from complete gear swaps including every slot on a toon to appearance macros to hot swaps for 2-5 pieces of gear at a time. Will these still work as they do currently?

[Jaxl]

Rothgar wrote:

snowline wrote:

How would /cancel_spellcast macro's be affected? Cures, Cure curses, death saves, instant heals, stringing multiple instant abilities together how are they going to be impacted?

Can we still change what is queued for next ability (several times) during a long cast as the situation changes during the duration of that cast?

Can people make Jcap macro's to run down the priority of JCAP recipients until a person isn't immune?

My understanding of your initial post is you're trying to reduce the dataflow without changing gameplay, that's a great goal, but only if it's fully realised and it's the code changing not people's playstyle having to change.a

Nothing other than useability commands would be affected, so you can still cancel spellcasts.  Things will queue the same way they always do, the only difference is that we won't be sending all of the queue commands, just the last one. 

If you're not casting, we won't be sending commands for abilities that are not ready yet (unless its the last one).

The only issue I see at the moment that needs to be worked out are macros that spam the same ability with different targets.

How about changing the syntax of the command so that multiple targets could be listed comma delimited..

/ target1,target2,target3

The ability would then apply to the first legal target.

[circusgirl]

As a raider on Antonia Bayle, I am very, very glad this change is going in.  That one night we had with mega-macros disabled was like playing a completely different game.  Seeing a 30% increase in your parse as a result of a minor coding change is pretty amazing, and I am absolutely THRILLED that you're doing something about the spam-macro-lag.

<3<3<3<3<3<3<3<3<3<3<3

[Xill]

shaunfletcher wrote:

ranga wrote:

OK here's my feedback.

If the new system breaks existing macros it's not fit for purpose so find another solution please. Don't even put it on test. Explore it some more. Find one that works.

Then bring it back for comment please.

That's how it works in my job TYVM

I cant agree. If existing macros are either-

1: huge and bloated and cost a lot of server time

2: huge and complex and come close to autoplay

Then stopping them working is a good idea.

You are supposed to actually play the game yourself, macros should be for minor items of convenience not to mean you dont have to bother with boring things like selecting targets or casting chains of spells.

This      ^^.

Raids complain about unrelenting lag in raid zones while half of them are spamming huge macro's and overloading the server. Then tell you not to fix it like that, but find a different way and have no constructive feedback. Just fix it but don't screw me up in the process.... even though I am part of the problem.

[knightofround]

If I understand this correctly, the only significant change is that if you have a macro with, say, 20 abilities on it, only the first and last abilities that are up are sent to server. Plus any additional instant-cast abilities, as long as you place them at the front of the macro. And also, the process of selecting which two+instant cast abilities are sent is processed on the client's side instead of the server side.

If that is the case, then I love this change. It moves the burden of processing lag from the servers to the clients who use those 20 ability macros instead. I think it will also improve ping lag on the side of people who use such macros because only 2-4 abilities will be sent to the server instead of the full 20 abilities in those ubermacros. This is an elegant fix, and I'm curious as to why the macro system wasn't built this way in the first place.

I think a lot of people who are upset in this thread are under the impression that it is removing the ability to queue whatsover via clicking on the hotbar. That is not the case, it sounds like this only affecting macros that have more than 2 non-instant cast abilities in them.

[Boyar]

When one of my guildies told me about this I was worried, but reading the thread and Rothgar's updated post, I'm much less worried and am actually looking forward to reducing the lag I've been contributing to.

One immediate question is whether dragged icons will now be treated the same way as the equivalent /usability command since they're being parsed on the client. If so, this would be extremely beneficial for macros that mix /commands with dragged icons.

As it stands, dragged icons in macros frequently execute before / commands, even if they are last in the list;

• /cl
• /cancel_spellcast

will frequently cancel its own casting, especially at laggy times; if you use "/usability " at the end instead, you get the right effect, but no reuse shading for the icon; if you use both, you reliably cast but then sometimes queue another cast as well.

If a side effect of client side parsing is that non-usability commands are properly ordered among ability casting and queueing, this will be fantastic for those of us who need to be able to respond instantly to events while keeping informed of our abilities' status.

By the way, Aditu made a great anti-spam macro thingy in eq2interface that each time you click it, it sequentially casts one ability from a designated hotbar. If macros could have a toggle/checkbox between standard queueing and sequential single cast, that would be awesome (though obviously more work on your part ).

[ykaerflila]

This does not have much affect on me most of my macros are gear swaps (non-combat ) or text / target macros, but reading through this got my gears turning.

for multi target / single spell marco:

Since you are workign on pre processing on the client can you not either add a special macro command  or the ability to add extra target blanks like we have on spells now(possibly let the target field of a spell take multiple names seperated by commas). ie

/target_1 "person"

/target_2 "another person"

/target_3 "someone else"

/useability spellname;

and with preprocessing batch this up and send it all to the server in one request to find the correct target there, or would this not aliveate any stress on the current system in place?

[Ventisly]

Hey Rothgar,

I read the whole thread and it sounds like it will always queue the last spell in your macro.  What I do currently is double up a spell at the end of the macro to disable any queued spells.  Having spells go off when you don't expect them is a bad thing for when you go to hit your emergency spells when things go bad.  Some might suggest placing /cancel_spellcast at the beginning of your emergencies but when you are then trying to queue stuff up as quickly as possible when things are falling apart, you will mostly likely end up having your emergencies cancel each other if you try to cast too quickly.

Will there be an option to have the last spell in a macro queued or not?  A checkbox like the "Primary" option is now would work or an option on the macro itself to control queueing would be ideal.

[EQ2Magroo]

Artemiz@The Bazaar wrote:

A few thoughts and questions...

1. Harvest abilities being combined into a single ability . . . how will this work with various harvesting tools and gear. IE. Overclocked Mining Pick that decreases MINING time by 2.5 seconds or items that add +skill to a single type such as fishing? If they all become "harvest" will those tools all need to be revamped?

I don't think Rothgar is proposing changing the ability / skils requiredl, just that there will be a single command which will activate the "harvest" process. It will still check the appropriate skill for the type of node.

Basically it will work the same as currently where you can just double click a node, or hover over it with mouse and press 'F' (you don't even have to target the node currently using this method)