ENs - Subs - Buff/Debuff Bar Subs. (oEUO & EUO)

[Scrripty]

k now that you're through questioning my skill level   I'll give you a couple impressions after going thru the code and playing with the functionality.  Why on earth do you reopen the buff bar if it loses focus?  That's extremely annoying and makes it nearly unusable in most of the ways I'd love to use it..  I'm 99 percent positive without going thru it and trying to write one myself that you can just leave the bar where it is after the first initialization and do a scan of the bar to see if it's moved instead of reopening it.  Then just scan the set distances to see if there's an icon, and scan for the icon based on that...  There's got to be a way to do that.  I understand the logistics of it, you scan the bars contsize, but it just seems the easy way out.  The usefullness of this goes through the roof for EUO if you just find a way to overcome reopening the bar every time it loses focus.  I see the reason, but question the need to do it that way.  I can see how it would be easier than finding an alternate solution tho.  Even damage numbers over spawn make the gump lose focus, which is very annoying.   On a less than close inspection, it looks like you do a short scan of the pixels and make some sort of code to determine a hit, which is perfect, You scan each set point, if that point is not in the "known" scans, it's not a buff bar icon, return.  No need to reopen the buff bar as long as it stays in the same location.  Unless I'm missing another reason for opening the buff bar every time it loses focus?  I think I remember reading something about reinitializing it cause icons get stuck or something?  I hope the oEUO uses the new gump indexing to overcome this limitation.  If it does maybe I'll switch to that as I'm working on a script that the buffbarscanner is AMAZING for and would love to add the functionality either in euo, or oeuo as I'm developing them both side by side for ease.

[Endless Night]

k now that you're through questioning my skill level     Just messing with ya Twinkle McNugget  

Why on earth do you reopen the buff bar if it loses focus?  Agreed its very annoying. The main reason is that the buffbar icons postion and bar overall size changes according to how many icons are on the bar...  I could probably map all the diff combination of bar size- relative to icon position in all the 4 directions and then use that to aviod reopening the bar and scanning and at one time i considered it but I think its faster time wise to reopen the bar vers all the pixel scanning that would be needed. (Pixel scanning in EUO is not exactly bionic if i rember right) But as you guessed it i got lazy thier and didnt bother to test the time diff.  It was quiet a feat at the orginal time of writing to get it to where its at. And considering i hardly use the script myself ive never pushed it further... Also of consideration is that new icons get added and sometimes i take my time adding the icon information in (note Bard icons still missing) ... so using a technique of determining bar lenght by pixel scanning may stop when it hits an unknown icon when in fact thier could be 10 more icons on the bar..

That said i pushed the OpenEUO version further... its far superior and insanely fast, and yes its probably the first published script to use gumpindex... infact the version on EasyUo is still my original conversion and the format for gumpindex has changed since that release (so dont download it from thier). The openEUO version is so fast that OpenEUO itself cannot time it. (OpenEUO smallest time segment is 15ms) The recorded time it takes to read the average buffbar is either 0ms or after 10+ continuous 0ms reads 15ms

[Scrripty]

Well I might just have to dig into the buffbarscanner and redo it for my use.   Otherwise I'm gonna have to make my own that doesn't reopen the bar.  I see what you're saying about reading the bar but the initial part of the gump doesn't change right?  Like the blue ball you click to change direction, and the underlying graphic there.  That stays the same, so you scan that to ensure the bar is open, and in the right direction, then scan the bar one by one in order to get the correct ones.  I also rearranged your pixel scanning in my version to be more pvp/pvm specific, so scanning the icons should take a SIGNIFICANTLY lower amount of time.  When you get a hit you move on to the next one I'm assuming, so it makes sense to scan for the most likely icons that would appear on the bar first.  Aka: Specials, Magery, then Necro/Myst, maybe Spellweaving after... should see a significant speed gain just by doing that.  I notice I probly get hit most by magery spells like Curse/Clumsy and such.  Then in pvp probly curse and necro/myst spells and Specials.  So it makes sense to put those at the forefront of any scans...  Also, it's only the length of the gump that changes, but the overall gump stays in the same location right?  So the actual icons show up in the same spots every time... I just dont see why it wouldn't be possible to easily remove the opening of the gump completely from the script...  Seems like a no brainer.  I bet it would even be faster...  Detecting the facing of the gump with pixel scanning is trivial, and if you lose focus on the gump THEN you reopen it.  It would make opening the gump happen once, MAYBE twice the WHOLE time you run the buffbarscanner, and not interfere with things like manually clicking a spell icon.  Or opening your backpack.  The way it sits now it's near unuseable for me.  I'm not putting it down, on the contrary, it's an amazing piece of work.  Just that one limitation puts it at the bottom of my useage pool.  I'll have to play with it more cause I don't just want it's functionality, I NEED it, but I need that gump opening eliminated.   If you'd like to do it, I'd love that.  Either way, I have to do it.

[Scrripty]

I just loaded up kals magnifier and looked at the bar, you can use 3 pixels to scan for gump direction...  Maybe 4 to make it near perfect.  You could probly get away with 2 pixels tho.  One on the blue area, and one on the end of the long part of the bar... but there's a lot of colors near that color so a few extra pixels would be adviseable.   This looks pretty easy to change.  #contposx + 20 #contposy + 7 and every icon has 3 pixels in between them...  Do you scan a whole line for each pixel?  My way would probly be to scan a whole line in the middle of each icon, set a cipher for the line, and check it against known types, and if it matches add it to the variable, if it doesn't match any, save it's "cipher" and move on to the next one, if the NEXT one doesn't match any known icons, you're done with that scan.  Easy peasy.  Should be REALLY fast and a ton less annoying.   

[Endless Night]

I see what you're saying about reading the bar but the initial part of the gump doesn't change right?  Like the blue ball you click to change direction, and the underlying graphic there.  That stays the same,

Not nessacarrily .. depends on the direction the bar is facing if i rember correctly... both x and y changes as more icons are added and taken away.  So depending on the direction and the number of icons... icons are not nessarrilly in the same place every time..   All this is from memory thow and i would have to recheck my memory to be 100% acuarate.

If you have something that is so speed dependant.. as to make a difference in the order the icons are checked... I would strongly recommend you use the OPEN EUO version... this uses the new gumpindex commands and thus never reopens the buffbar unless it has been closed. And works at 5,000-10,000x faster than the EUO version.

If i get the time tommorrow i will play with it a bit .. but considering EUO is broken and given that Cheffe might not patch EUO at all this turn round it might be a mute point.

[Scrripty]

EUO isn't broken.   You patched. It's not that what I'm doing is that speed dependant, it's that I'm designing it ground up to be all about keeping speeds down.  And I want to continually scan buff bars every loop of the script for as many characters as I have in the group I'm using.  I've got the initial loop average using your very of the scanner down to 28 ms per loop with 2 characters and that's blazing fast and plenty fast enough.  But I believe I can lower that time and remove the blinking pretty easily.  I'll just use a right facing bar only and not release my work and step on your toes.   Back to the discussion:  I checked with the bar facing right, and the icons are 27x27 pixels and 3 pixels apart, that was just using 2 buff bar icons tho to test.  Could be different.  Also, the actual buff bar graphic never changed it's location on the uo grid at all when adding buffs.  It stayed in the exact same location, just the length of the bar changed to accomodate more icons.  If you have the bar in the black area, it would be pretty trivial to know when you're out of buff icons on the bar cause the scan would come up all black wouldn't it?   I'd love to use your icon info to do it, but I haven't even looked at what you did to come to your scan info.  I think I read you scan in an X but I didn't look very deep and see how you came up with your numbers.  I'll give the script to you if you wanna let me use your info, and you can do what you like with it after I'm done.  It will be your property.   I just want it for one personal script.  Probly be 1000 others without the gump opening tho. heh

[Endless Night]

go ahead and use my info for your personal unreleased script... send me a copy when your done and ill implement it into the offical version after expanding for all directions.

Couple of notes.
- i believe the bar expands both x and y after the 3rd icon (this might have no real bearing on right/up facing bars but  probably would on left and down.)
- the contsize even with 0-3 icons is the same size as 3 icons
- i use pixel pairs to id an icon... scanning an entire line of an icon would slow down the script enourmously. Originally i did scan 28pixels and the script was to slow to be useful.  After much analysis i dicovered i could get unique identifiers useing just 2 pixel points per icon... the exact pair is subject to change every time thiers new icons but so far i have never had to change it.
- I would use a end of bar condition after 2 failed icons... in order to compensate for 1 unknown icon... very unlikely 2 get 2 unknowns in a row.

[Scrripty]

That code you posted returns: 1 0 BAR: RIGHT - Icons: 0 - _ so it's having an issue reading from the bar on my system.  I can scan pixels perfectly tho on my machine.  I'll look into it some.

[Scrripty]

Ok I can't tell if you were trying to obfuscate the procedure or you just overdid it.  Wow. heh  The bar does not change position after the initial scan, but having it change is a little issue.  Scanning the blue button for direction/location is the easy way to fix that.  Also, having the bar in the black area allows you to scan the two pixels for 0(black).  Not sure if any pixels come back double black on any of the icons?  Do you know off the top of your head?  I guess I can look eh.  I'm gonna make an assumption here and say that the first icon always stays at 20/7, and the blue button always stays at it's location no matter how large the bar gets with icons.  Scanning for direction and icons is extremely simple without opening the bar.  You could do a button search like every 5 iterations or 10 iterations of the scanner and see if the button scan matches, if not, the bar has moved and needs to be reopened and focused on, adjusting your variables to it's new location.  The first scan should always be 20/7 and so there's really no real reason to even open the bar except when it moves positions or if it's covered.  You could always scan for a blue pixel in the button and if not found reopen and refocus.  Which is probly what I'll do.  Interesting to read through your code as always.  I can definately tell it's older work of yours. heh  Also, my issue is the same your other one person was having.  My pixcol isn't matching yours.  Would be easily fixed tho.  Matter of fact, I might just fix it and not rewrite the wheel.

[Scrripty]

One more little note here then I'm done playing for the night.   I checked a few icons and noticed that the scans are exactly 512 off on the #pixcols.  And it's random wether it's on the x side or the y side of the scan.  So it's either a patch issue, my monitor just differs by that amount, or OSI changed something on purpose.   I'm going to change your setup to use a if #pixcol < #yourNum - 512 || #pixcol > #yourNum + 512 so all your info still works with a slight change here and there.  I wonder if the scans are ever off by more than that amount on peoples computers that differ?  512 is far from random tho.  If it scans and finds the info you have there after this change I'll just assume it's all near correct and move on and let you know how progress goes.

[Endless Night]

; If thier is icons that are not found, Make a newfile of code below and run
  set %BuffBarRecordAllIcons YES
  Call ScanBuffBar  ; Presumes file is in same location as euo
  Display ok %BuffBarCalls - BAR: %BuffbarDirection - Icons: %BuffBarIconsFound - %BuffBarIconNames
  For !x 1  %BuffBarIconMaxCount
       Display ok %BuffbarIcon . !x
 Halt

The above code running my unchanged script should list all icons found known and unknown... if its not finding icons its an easy way to determine why. Its also how i get the codes for unknown icons.

Umm totally forgot about that pixcol issue i better fix that .. as i didnt implement it in the OpenEUo version either and the openeuo version needs to be perfect.

[Endless Night]

Ok i completed a version that does as requested only for Left and down at present.  If the bar is facing up or right it uses the old method.  The scans time are simular via both methods.  The first scan is still performed via opening the bar/contsize as this initializes icon placement etc.

I will post if up shortly.. in process of adjusting the script to allow for custom pixel varience.
 

[Scrripty]

Yea I've been looking at more icons, seems like they are randomly off by 512/256.  I haven't found any yet off by more than 512 tho.  Might be a good idea to go as high as 1024 on the variance tho just to be safe?   Did you up the new version?

[Endless Night]

EUOX VERSION 18

- For bars facing LEFT and DOWN .. the script no longer reopens or refocuses the BuffBar instead uses pixel scanning to determine if bar is still in correct location (UP and RIGHT next version).  This elimates all bar flashing and interruptions to user actions... purly passive scanning.

- A Pixel color range variable has been added.. defaulty +/- 1024 from my default color values. To increase or reduce the range set this varialbe in your script (Adding this functionality slowed scanning speeds by approx 40%)
    set %BuffBarColorRange 0


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ive been toying with the idea of adding a function

gosub OnBuffBar Clumsy 

This would scan the buffbar only for the passed type... and no others .. if you have many icons on the bar this should be significantly faster.. what say yea...

[Scrripty]

I like that idea a ton.  You could still use all the same info and just scan for the one thing.  I rarely am scanning for more than 4 or 5 things at a time... how about you make it able to take any number of names?    Like scanbuffbar clumsy weaken curse