Spelling casting into queue?
 

Is it possible to put a spell in queue from the UI?

I know it is possible through the UI to cast a spell upon clicking. And that it is also possible to stop a current spell cast, clear the queue, and cast a spell. However, I've had no luck in pressing a button to cast a spell, when something else is already being cast.


Is this purposely not doable from the UI, or just a bug? Any insight?

Figured it out, see post #18

Strange. I know for certain that e.g. my clicky cures used to queue, but you are right, it does not seem to work anymore. Bah, I guess I'll have to change my click to cure code now to always cancel spellcast.

I wonder if this was changed on purpose, maybe in response to Aditu's automation mods that would hook onto what was currently casting and were pulled from this site upon SOE's request?

I'm not sure. I never checked the functionality in the past to know that it worked then.

My click to cure on my group/player window have canceled casting to cure since the beginning, but i've had a few request to change it, since it was dangerous for a healer to cancel a heal :)

I guess we'll have to get some Dev insight on this one? I don't really see how queuing an ability can be bad, since you can only queue 1. /shrug

My click to cures have toggle buttons to change between "cancel spellcast" and "queueing" modes, that's why I'm certain that queueing worked. :)

I have already asked for some dev insight, would be nice if this was not intentional.

Yea henchman's qued spell did work. I havn't checked to see if it still does or not. Frankly I don't care either, things like this piss me off.. Hmm I must be in a mood today..:/ lol

Assuming you mean queuing a spell during a current spell cast and not queuing a spell during a recovery period... such a change would have only made my scripts work better, not worse. It'd be a poor scapegoat unless SoE did untested changes without at all understanding how the scripts worked.

I don't personally use /useabilityonplayer in a queued fashion that often in normal play. My little button mods are all set to cancel spells before casting another so I would have never noticed such a thing. I am actually curious about this now because one of my released mods would rely on that functionality still.

I had sent Rothgar a PM asking about this, haven't heard back yet though. If I do I'll let you know.

Aditu I agree it wouldn't have affected your mods, but it does affect lots of other mods, so I just thought that if the change was on purpose, it may have been done to remove every possiblity of scripting more than one spellcast in an attempt to further limit what you can do via interface scripting. I still hope it's just a bug however...

I guess I'm confused in general now. I tried using the queuing version of my raid mod for giggles and it works perfectly. It correctly queues one spell after a previous cast and correctly queues a non-available spell during a current cast.

So what's broken about it again? The only thing I have not tested is to not have any spells being cast and try to have a button press cast a spell and queue another spell immediately on its heels.

I think that is what he is talking about.

Actually both variants of doing it work fine now, seems to have been fixed. Cool, so I guess it was a bug.

Edit: Switched my click-to-cure back to queueing mode as the default (I always felt that works better for all but raid situations).

I'm still having no luck with my queueing of cures.

They will cast when nothing else is going on, but will not queue while casting another spell.

Just guessing here and really don't know why it would but it might have something to do with the command target_previous. gm9's and My C2C code does not incorporate that command as we have our cure buttons out side of the membersinfopage.

I dunno, it's weird... And I'm pretty sure I remember seeing target_previous in various coding where people use click to cures. Not sure. I think that's where I copied the code for the OnHoverIn/Out.

I'll have to mess with it more...
Just doesn't make sense to me that the code above can cast a spell but it won't go into queue.

Yes that's my old code, originally introduced with ProfitUI 3.x, and many others started using it for their mods then. That was before we had usabilityonplayer.

On the actual issue I'll have to retest I guess, I also don't see why target_previous would affect queueing.

I know that if I manually put in chat "/useabilityonplayer xSpell" while another spell is being cast, that it will work and become queued.

If anything, all I'm trying to do get the UI to execute one line of what you could also put in a macro. It's practically the same thing as a hotkey. 1 spell cast, simple! :) or is it?!

Not sure what ya mean here? Seems no matter where I put a button on the player page, it registers as a "click" to the window

Oh right, you posted player window code. Landiin was referring to the group window. You are correct that for the player window you can't seem to circumvent the hardcoding (on the player window I also still use the code you posted).

Opps my bad.. I thought u was talking about group for some reason.. /sigh

Ok with testing I've found.....

- both useability and useabilityonplayer will queue from the UI.
- target_previous used before or after a spell cast screws it up as guessed above
- clicking fast on the player window, and clicking and holding for more than a few 10ths of a second will result in different functions of the player window

If you "useability" and click quickly on the player window, you'll target yourself.
If you click and hold and then release after a short second or so, you'll not target yourself.

Interesting, yes?

So from what I've got here that I"m currently working on I can use "useabilityonplayer" and it won't changer my target, but only if I click and hold the buttons, rather
than click quickly.
I guess it really only poses a problem for the player window if you really don't want to change your target to cure yourself.

Edit: now for the solution
I have my overlying cure buttons in their own page, over top of the impairment icons...

This tells the parent "player window" itself to not absorb input when hovering over my curebuttons page. This disables the player window from targeting yourself all-together.

Seems to work wonderfully, and I can see it working on the group window if you want to work within the group members' pages.
Finally!

Just wanted to note it's been working well. If anyone else finds this useful, maybe we can get gm9 to sticky my previous post in the XML author forum.

hey I'm here, no need to scheme behind my back, lol. :p

So you figured it out, nice. I made your sticky. If you want you can go and clean the text up so it stands alone (so far I just copied your post above).

Thanks much.

I wasn't quick enough to see why this problem was happening, but it makes sense.

I'm guessing that the cure button does the following...

1. Target a player
2. Begin casting a spell
3. Target Previous

Shouldn't be anything wrong with that part. As originally stated, the problem is with pressing one of those buttons twice... the 2nd before the 1st completes a cast.

1. Target a player
2. Begin casting a spell
3. Target previous
4. Target a player
5. Begin casting a spell(queued)
6. Target Previous

The problem is the interaction between step 5 and 6. In the actual game, forget about scripts, if you change targets while having a spell queued, the queue will clear. This is to protect from the queued spell casting on the new target instead of the target that was selected when the spell was queued. IE, the spells don't keep in memory what the target was at the time of queueing.

I dunno about the target switching clearing memory for useabilityonplayer. That's a specific targeted spellcast, but I haven't tested enough to know...
However, it doesn't seem to matter much now with what I figured out -- as you can press the buttons twice now with no problem, as there's no target switching required.

Also, the /target_previous had trouble with normal user spell cast followed by a button spell cast, as I had explained above.

Again though, taking out the need of /target_previous was key and removing the absorbed input of the player/groupwindow while pressing the button fixes any problems.

Hard to tell how on-topic this is still, but personally I still prefer useability over useabilityonplayer for the Player window. On the Byzola encounter, class adds cast a debuff on the player that will clear target and prevent target switching. When the character cannot switch targets, useabilityonplayer becomes 100% inoperable. Even when the target is oneself.

The only way to cure the effect is to cast Cure without a target, thus curing yourself. The useability UI mods will attempt to switch targets, fail, but cast regardless and cure the player. useabilityonplayer UI mods fail completely.

That is interesting and useful information. I just don't like the window's functionality of clicking the window and getting a target. Different click lengths get different results.

I guess you could disable the functionality of the input, and then manually get the target and cast using useability? I dunno the difference in the game system and if it will not target quick enough. Or since it's just the player window, you could clear target.

My main concern was just getting abilities to queue, and not change target.
For things like a specific encounter, and needing to cure yourself because game-functionality is altered, can really be solved with a hotkey casted spell.
And when it's dealing with yourself, keyboard is usually faster than mouse anyhow. But otherwise, it's all just opinion based stuff :)

Well, I forgot to mention that my group window still uses that functionality as well. For various reasons(AA spec), I am often the only player in my group not incapacitated. For that reason, I must cure the rest of my group of a specific effect or they will be unable to cast anything. Because of my AA spec, I can ignore one of the effects on myself and cure the others. If I have the no-target effect on myself, attempting to cure another group member will by mistake cure me. IE, it tries to switch to the group member before casting cure but ends up curing me.

I only mention this because I do indeed normally rely on a keyboard cure key which will in effect cure myself. But with the group window doing it also, I don't have to sit there and wonder why my mouse clicking is casting absolutely nothing(with useabilityonplayer). I just have to click twice(with useability).

Given what I describe, I suppose it's surprising that I never ran into your queuing problem... except I have a habit of not casting another spell until the recovery period because my cure hotkeys will cancel casting normally and not queue at all.

Ah ok. Gotcha.

Thanks for the info on that encounter aditu, I guess I'll keep my useability code as well then (on the player window). Also I never knew that changing targets now clears the queue, unless I'm completely mistaken that used to be different.

PS: Off topic, but useabilityonplayer also has the problem of not working with character names containing non-ASCII (just like all UI scripting). The default UI's voice chat icons in group/raid window have the same issue btw.

Hmm, I swear that changing targets while a spell was queued was like that since I started playing. The easiest way to see this is not by using two spells, but trying to cast the same spell twice. If it has a long recast, like ten seconds, it's super easy to see that changing targets after the first cast will cancel the queue. Even if it's a group spell that doesn't require a target to begin with.

About the non-basic characters thing... that might explain why one of my "international" users is having trouble getting my raid mod to work. I tried giving him the XML escape code for the character the spell had, but it didn't work for him. It's accepted that there's no workaround? Even though simple things like ' work?

Tested out useabilityonplayer, and it too un-queue's a spell when changing targets.

I think that's kinda lame, TBH, but not game breaking...

You could technically cause a loop between two objects to keep trying to cast a spell until it shows up as currently casting, but I dunno if that would cause lag or not, lol. Plus it would be dangerous if you decide to not want to cast that spell after pressing the button. Unless you have ESC set to cancel spell casting, or you move... lol, still a bad idea. I dunno how smart you'd be able to get with it either.

Do a smart queue? Set a variable to currently casting spell, wait for that variable to be different (as in not casting) and then issue the spell cast. That's like true queue'd casting with no clearing.

You can check to see if a spell was canceled by the user by checking the progress bar of the casting window to see if it was close to 1.000 or not when it was hidden... but how would you check through the UI to see if something was queued? To be a smart queue, you'd have to keep the spell queued even when the queue gets cleared. Since you cannot see if something is queued, that part sort of fails because queuing the same spell while one is queued will also clear the queue. Or do you mean to not queue it in the normal sense but have an auto cast once the previous spell has completed casting(when the casting bar is hidden)?

I meant the latter. To let the UI auto cast once the previous spell has completed casting. And to not get spiffy. Just do the normal spell cast when the previous spell casting is done.

again, it could lead to unwanted results I think if you really change your mind that you don't want to cast a cure next. but that seems like it would only be in extreme situations.