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 :)