ScriptUO
Official ScriptUO EasyUO Scripts => Script Debug => Topic started by: Grandewd on February 02, 2014, 08:18:26 PM
-
Ok, here's a very simple piece of code that I've been experimenting with:
event macro 50 3 ;
wait 1s
contpos 160 120
wait 1s
halt
Event macro 50 3 will open my pet's healthbar just fine. If his healthbar is NOT up prior to running this, then it does exactly what I mean it to do. It opens his healthbar, and then positions it at the proper x,y.
However, if his healthbar is ALREADY OPEN - the contpos moves my backpack to the contpos x,y coords.
I'd appreciate it if you would tell me why this happens.
:-[
-
Because the focused cont is your backpack and not the pet's healthbar. It's refreshed when a new container is opened, if something is already open, then it doesn't refresh. You have to close your pet's health bar first then open it again for it to become to focus. #another-problem-stealth-doesnt-have.
-
...#another-problem-stealth-doesnt-have.
lol
-
Ok, but shouldn't Event macro 50 3 (which opens the pet's healthbar) force the last container to be that healthbar if nothing else has received any clicks prior to contpos?
-
- aren't allowed in the new hipster's invented #'s (hashtags) era.
#sorrymanhadtocallyououtonthat
-
#doh
-
Your better bet would be to just drag out the healthbar and have the script wait until you click on the healthbar. Then Position it. Mind you if you move the health bar or move your cursor over the Health it will not give a proper reading. For doing things like that OEUO and Stealth are much better than EUO.
-
shouldn't Event macro 50 3 (which opens the pet's healthbar) force the last container to be that healthbar if nothing else has received any clicks prior to contpos?
It would be nice if it did, however the gump opened by the 'new targeting system' macros behaves differently than status gumps opened manually. Pretty sure it has a different #contname as well. I'm not sure though; had a spectacular raid failure a while back that hosed a bunch of VM's, and haven't felt like piecing it all back together so you might want to test that assertion before depending upon it. As others have pointed out, most of the other scripting environment handle gumps/gump-info better, even in oeuo they're something of a pain (but at least you can enumerate them all...)
-
Try turning off the Targetting System and turning it back on when it does that.
-
shouldn't Event macro 50 3 (which opens the pet's healthbar) force the last container to be that healthbar if nothing else has received any clicks prior to contpos?
It would be nice if it did, however the gump opened by the 'new targeting system' macros behaves differently than status gumps opened manually. Pretty sure it has a different #contname as well...
Yea, I noticed that tonight. If I pull my Cu's bar myself, it disappears when I mount it. However, if I use 50 3 to pull it, and then mount the pet, the damn health bar stays there. Wow...
I'll have to remember to look at the #contname when I get on again, but all healthbars are NOT created equally....
-
Try turning off the Targetting System and turning it back on when it does that.
Good thought, manwinc, but the result is the same.
-
#nextcontposx or whatever the command was
-
#nextcontposx or whatever the command was
Have you ever looked at what the current container is while things are changing on the screen ingame? I mean, even the numbers that float up when damage is being taken are shown as containers. (Damage is even in the name of the container :) )
So, nextCPos has never been worth much considering how often the client sees stuff as a container, since at any given moment the next container can (and more often than not, does) change...
What continues to confuse me is how event macro 50 3 can be responsible for opening a healthbar (container), and yet - when you use #contpos the moment after you invoke event macro 50 3 - it will virtually always ignore that container {healthbar} if it was already open and moves on to whatever last container had the focus. But if it's not open prior to invoking 50 3, it always treats it as the last open container...
And I just don't see how that works...
*** Edit *** I'm now wondering if event macro 50 3 (in addition to popping open the healthbar) also sets it as the last container open - but it doesn't do this if it is already open??? Could this be the case?
-
How about just working with the quirks.. ie dont try and move it if it doesnt reopen, presume you moved it the first time you opened it.
event macro 50 3 ;
wait 1s
if #contid = <put the appropriate id here>
{
contpos 160 120
wait 1s
}
halt
-
Thanks for helping me understand why this happens, and for giving me direction. I appreciate it...