Spelling casting into queue?

[gm9]

Originally Posted by Drumstix42

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.

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.

[Drumstix42]

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?!

Originally Posted by Landiin

gm9's and My C2C code does not incorporate that command as we have our cure buttons out side of the membersinfopage.

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

[gm9]

Originally Posted by Drumstix42

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

[Landiin]

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

[Drumstix42]

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...

OnHoverIn="Parent.absorbsinput=false"
OnHoverOut="Parent.absorbsinput=true"

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!

[Drumstix42]

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.

[gm9]

Originally Posted by Drumstix42

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.

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

[EQAditu]

Originally Posted by gm9

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

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.

[Drumstix42]

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.