A (Theoretically) Simple Exp Bar Fix....
 

I've been playing with this idea a bit recently, but haven't had any luck actually implementing it successfully. But I think that's more because I'm groping around in the dark, than because it's not actually possible. :D

So, I'm hoping someone who's got more practice with XML scripting can figure out how to make it work....

The problem we're seeing with exp bars right now, of course, is that the game has started rounding the "GameData.Self.ExperienceCurrent" (henceforth just "Current") dynamic data value. That means that the mods which show experience to tenths of a percent by displaying "Current" + decimal point + last digit of "GameData.Self.ExperienceBubble" (henceforth just "Bubble") show incorrect values whenever "Bubble" is greater than 49%.

That rounding needs to be undone.

It *should* be fairly simple to do so.

(a) Set "Variable1" to "Current."
(b) Set "Variable2" to "Bubble."
(c) If "Variable2" > 49, subtract one from "Variable1" (undoing the rounding).
(d) Display "Variable1" + decimal point + last digit of "Variable2."

As I said, though, I haven't managed to actually implement such a scheme successfully, but I'm reasonably certain it *can* be done. I can get bits of the idea to partially work, but I'm really not sure what I'm doing, and before I spend much more time on it, I figured I'd check to see if anyone else can get it to work more quickly. ;)

-- Darryl (Milquetowst)

EDIT: There is one potential problem with this idea, even if it can be implemented successfully. When the dynamic data is displayed directly, of course, it updates regularly. Would the info still update regularly if the dynamic data was copied to variables, which were then displayed, or would the data in that case only update whenever the window was forcibly updated, as by closing and reopening it?

I can't believe this is still broke. Is there some sort of advantage to why its doing this now? does it ease burden on the servers or something? I guess its not a crucial problem but it makes any UI I use seem "broken." I would imagine the fix would be relatively simple on their end unless they have some odd plan to change exp display or something in some way later on.

Thing is even the exp percent it shows for tooltip, including default, shows the wrong exp, rounding that incorrectly too. I'll have something like 44% exp according to the bars and the tooltip exp shows 45%

OK, technically, it's NOT broken. If you really want to get picky, taking the whole-number experience percentage display by itself, it has at long last been FIXED. It was BROKEN when the number WASN'T being correctly rounded. (If you've got 48.9% experience, for example, it is actually CORRECT to round up to 49%, and WRONG to round down to 48%.)

That having been said, of course, the fact that the devs finally fixed the experience percentage display to round correctly has broken the various experience bar UI mods that took advantage of the incorrectly rounded display to show experience gain to tenths of a percent. :)

No matter what else they do, the tooltip should stay as it is, and show the correctly rounded whole percentage number.

My preference for the actual displays would be that they provide *two* dynamic data fields, though, one showing the exp percentage in the old way and one showing it in the new way. (Both would have tooltips showing the correctly rounded whole number.) That way, exp bar modders could provide either whole number displays or tenth-of-a-percent displays correctly.

In any event, in the meantime, I've adjusted my own exp bar mod to accommodate the way the data's being handed down now, but still allow me to see how many tenths of a percent gain I'm getting from particular kills or particular tradeskill combines. It may not be the most elegant display imaginable, but it works.

-- Darryl (Milq)

Well I guess if they wanted it to be rounded, yeah its fixed. For people who want to see it the old way, the correct percentage of exp they have to be shown, its broken. And like I said, I can sit there and look at the bars and clearly see its not the percent number its showing me, making any percent I can show useless as far as I'm concerned. Unless they want to pump up the exp gain so much I'm getting whole number percentages for average kills.

And I'd debate them rounding it like this anyway, they are lying about how much exp you have, embellishing it at some point. 48.9% is more than 48%, so its safe to say you have at least 48%, but its not quite 49% yet.

Doesn't make sense to me why they would do this. I don't ever see people saying "hey could how much exp I have be more vague?" unless they are being sarcastic. If anything they want the actual numbers down to points, like 100000 points of exp for a level.

But if you have a way to get it to show the correct percent that would be great. In the mean time my old mod still shows me how much I'm getting for a kill if its at a point where it doesn't round it off.

Ok, going back to the original idea...nm, figured this out
Im confused at what variable 1 and 2 are.

Though an easy way to solve the problem would be to over write the dynamic data with the correct data so that when the xp bars pull it they pull the right data. The biggest problem your going to have here is getting the calculations to run whenever the dynamic data changes, you could attach it to the OnHide of the target and implyed target window, so when ever you kill something in the spilt second your target window dissapears and you select a new target the calculations run and the xp bar is correctly updated.

Though im a bit new to UI modding and havent gotten math commands to work correctly for me yet. Hope this helps.

I have an idea, ill play with it and see if i can get it to work. Though no promises..

I've noticed something very interesting about the point numeric value. Maybe i'm wrong, but there are 9 lines on an exp bar/bubble. Lets say you have 38.7% showing in your numeric value. That .7 is actually the value of 1 bubble. And it starts over for each bubble. Look for yourself. Each time the bubble gets close to one of those lines it is either 8, 9 or 0 and at the start it is 1, 2, 3 etc...

Just my 2 cents...

ok ive have come up with..

i put it into eq2ui_mainhud_target.xml

like this

and im not totally positive that it works but, it dosent crash the target window or anything elce :D
*wispers*anymore...

soo.. i think its fixed :nana:

Ok it dident work... i was testing it on one of my chars and xp went from 19.8 to 19.0 so...

Not shure what i did wrong.. is it possible to modify the dynamic data like i tryed to?

I didn't know it was possible to read from dynamic data like that. But, even if it is, I think that dynamic is only readable, not writable.

Honestly, I think that to make this idea work, you'd have to...

Hmmm...

Have invisible objects to read the currentxp and bubblexp out of the text fields for.

Do your calculations.

Then send that data directly to the text field you want it to display in in the experience window. (Remove the dynamic data from that text element first).

So now you've got a modified target window and a modified xp window. Although maybe you could put an invisible target element in the xp window and do the calculations there instead.

But it's all theoretical on my end, having done no testing myself.

I actually was screwing with this last night, I found that the dynamic data experiencebubble still stays accurate, and it really has 2 numbers. I actually have 20.7 exp without rounding in this.

So it was like:
21.7

If I showed all of the experiencebubble dynamic data
21.07

So the number was accurate and not being rounded, so for a kick I put the decimal right on the second number, between the 2 digits making
20.7

So the decimal would show correctly almost all the time except when it would round the exp every tens of exp. So like earlier it would show something like:
29.7
When what I had was really 19.7 Its really just a cosmetic adjustment, but it was pretty close, showing the exp exactly for a good amount of time.

Actually, I played with something like what you're doing, but found quite a few instances in which it gave screwy results.

(a) The "bubble" value never has a zero as a first digit, so if, for example, the exp amount is 50.3%, it displayed as "5 .3%" (with a space where the zero should have been).

(b) If the exp value is greater than 99.4%, so that the 99 has already been rounded, you end up seeing (for example) "109.8%" instead of "99.8%."

(c) If the exp value is about to hit *any* even tens amount, the display looks like it's 10% high; for example, 79.9% (where the main exp value of 79 has already been rounded to 80) displays as "89.9%."

In short, the inaccuracies were rather frequent, and in many cases far worse than just using an old XP bar mod and having to remember, for example, that "89.8%" is really just 88.8%. :D

-- Darryl

Well I guess I just saw it differently, it has more kinds of problems but their not as frequent since they only happen every 10% rather than possibly every percent. Still I'm going to stay with the old way.

I hope they allow some system to let us show it more precisely again, because otherwise I'll just let both numbers of the experiencebubble data show so people can still tell how much exp their getting per kill without doing a little deciphering. Just going to make it so you can tell its not a exact display of the exp like it was before.

After observing this further it appears to me that the numbers after the point are nolong in tenths, but rather in 100ths and changing back to 0 every 10 onehundreths. as seen on the exp ui I am using.

For example in pic 11 it shows that my exp is 46.61/100% and my tradeskill exp is
43.28/100ths%. In Pic 12 my exp is 48.74/100th %. Then need is to stop thinking in 10ths to solve it and think in 100ths...

As you can see by the blue and yellow bars on the pic's I've uploaded.

Now the problem is how to get it to take that 10/100ths and turn it into .1 then .2, .3 etc......

Not quite sure what you're saying Turzen, but what the data gives you is 2 fields. Lets say my XP is at exactly 17.52% (I know you could never know that but lets just play along).

The first field you get is the whole numbers, which now are rounded (before it was just truncated): In this case you would get 18, because the 5 rounds up.

The second field you get is the second number and the 10ths: here you would get 75.

In the old days it was easy, you just put the first field, a decimal point, and the second field with the first number cut off, but now with rounding you would get 18.5 as your display.

While this 'bug' is annoying, I don't think its too hard to mentally see if the decimal is >= .5 and then just subtract one from the ones. Do it enough and it starts becoming second nature.

But no 1/100ths data is passed along. The numbers you're giving show what I've just said:

46.61 should be 46.1 (you've repeated the 6), the 6 doesn't round up because the 10ths is only 1.

43.28 on the other hand gives you the illusion of having 100ths because all 4 digits are different... but we can see that this is a result of the "3" being a rounded "2" because the 10ths are 8, which rounds up, but the first digit in the second field isn't rounded, so it shows as a 2.

Just a note: SOE actually rounds up at .4, i.e. you'll get 17.4, then when you earn XP it will jump to 18.4 (it stays at .4 after rounding, meaning that SOE internally uses more exact numbers, e.g. .45).

Its not a matter of being crippled in knowing what my exp is with this, adjustment, but I do find it bothersome. To me, it makes the use of exp in numbers near useless, besides seeing how much a individual kill gives you. Since I would use it for a more exact display of my experience. I can estimate my exp just by looking at the bar, but now I can even read it more accurately by looking at the bar rather than the number.

I really wish they would either turn it back or give us an option to show it like it used to.

OnHoverIn="LocalText=(<GoldEXPBar>.Progress)*100"

That used to work, anyway. :p

Not sure how to implement that, think the code has changed a good amount since then.