% ticks question

[suprphrk]

Anyone know:


1% exp equals 3.3 ticks ( note that since fractional ticks do not exist that the % is rounded ) This rounding can equate to a significant error reported by the % value in the client.


Is this rounded or truncated? I'll notice that on some mobs that con the same, one of them will give me 2 ticks, one will give me 3. Do they actually give different exp? or was the first estimate truncated when sent to my bar, and after added on the second one (still truncated) but the addition equals the extra tick?

For instance, let's say a mob gives you 2.5 ticks. Rounding it should show 3 ticks, but it only shows 2. The next kill of the same mob, same con, shows 3 ticks. Is this because 2.5 + 2.5 = 5? or is it that one mob is 2 and the other is 3? Is it accumulative (i.e. 24,934,205 and next mob is 25, 104, 100) and takes a percentage overall? I'm confused about that part.

Thanks,

Jalanon

[S_B_R]

From what I've observed it's rounded. Your examples are a little on the extreme side so it looks like it truncates. Usually when you kill a mob that gives you more than 1.0 tick it's only slightly more than 1.0 (i.e. 1.1 or 1.2) . for example if you get 1.2 per mob it would go something like this:

MOB# SrvrXP ClientXP Remainder
1. 1.2 1.0 0.2
2. 1.4 1.0 0.4
3. 1.6 2.0 -0.4
4. 0.8 1.0 -0.2
5. 1.0 1.0 0.0After the fifth mob the cycle repeats. The server keeps track of the actual values, and applies the remainders to the next XP you get. Make sense? ;)

-edit-
In the example above each mob gives 1.2 ticks.

[Ratt]

As far as I know, the experience bar doesn't notch up until you actually reach that notch.

So you could be at .99 ticks and not see a tick until you get that extra .01.

I could be wrong about that though.

[S_B_R]

Hmmmm, that could be...

[S_B_R]

So I guess is would look like this then:
Each mob is 1.2 ticks.

MOB# SrvrXP ClientXP Remainder
1. 1.2 1.0 0.2
2. 1.4 1.0 0.4
3. 1.6 1.0 0.6
4. 1.8 1.0 0.8
5. 2.0 2.0 0.0The total XP is the same. The server is keeping track of all the remainders and adding them to the next +XP. I guess it truncates... ;)

[Junu Peeth]

Originally posted by S_B_R


MOB# SrvrXP ClientXP Remainder
1. 1.2 1.0 0.2
2. 1.4 1.0 0.4
3. 1.6 1.0 0.6
4. 1.8 1.0 0.8
5. 2.0 2.0 0.0

I was just considering, wouldn't the table look like this:

MOB# SrvrXP ClientXP Remainder
1. 1.2 1.0 0.2
2. 2.4 2.0 0.4
3. 3.6 3.0 0.6
4. 4.8 4.0 0.8
5. 6.0 6.0 0.0
Or am I not reading your description correctly.

As another way of coding it that seems a little easier also. All XP Data is stored server-side and when an XP gain is registered it is converted into number_of_ticks (= 330 * XP_in_current_level / total_XP_for_level) then trunc[number_of_ticks] is sent to the client. The client then compares this incoming integer (which would be in the range of 0 to 329) with the integer it currently has displayed as visual XP. If the integers do not match then it changes the visual XP Bar and also performs the operation XP% = number_of_ticks*100*330 and displays XP% if your UI has a place for it.

Whether EQ uses this way to send updates for XP (not zoning updates) I do not know. But it does seem a little easier than having to record server-side what the client side data is and a remainder also. When this information can be obtained by a trunc command and a subtraction.

[S_B_R]

Yes, I think you misunderstood. May chart was showing XP on a per mob basis, not cumulative XP. Meaning mine adds up to 6.0 and your last value is 6.0, basically we're saying the same thing, I wasn't trying to guess at how the server actually handles the math behind the scenes.

The reason I didn't show cumulative values is the client does know how much XP "it" has, and there for the server would only need to send updates. +/- however many ticks per mob kill, The server would have to keep track of how many mob you have killed since zoning in your scenario. The client would also have to disregard all XP since "it" zoned every time the server sends it a new tick(s). For example.

You login and the server tells your client you have 127/330 XP ticks. now you kill a mob and the server checks and that mob is worth 1 tick of XP. The server then send the client "+1" tick. The client now knows it has 128/330 tick. You kill the next mob and the server checks and that mob is exactly the same as the last mob you killed so you get another tick. the server send the client "+1" tick. The client now knows you have 129/330 ticks. rinse and repeat.

How the server handles the math is really unimportant. In your scenario the server needs to remember how many mobs you have killed, in mine it needs to remember the "remainder". All that matters is that any fractional excess (or deficit) is retained, so that XP is conserved.

[Junu Peeth]

I was confused by you showing serverXP on a per mob basis when it is more likely that it is stored server side as a cumulative total and the increase per mob is sent to the client as +n ticks. I understand your intention now though.

What still confuses me is your statement "Each mob is 1.2 ticks" but then the values shown in your SrvrXP column are shown as "1.2 1.4 1.6 1.8 2.0". Then in your reply you stated: "Meaning mine adds up to 6.0" But these numbers in fact add up to 8.0 a difference of 2, your math is incorrect in this case.

I believe this table might be what you're trying to express but misrepresented yourself:

MOB# MobXP SrvrXP ClientXP+ Remainder
1. 1.2 1.2 1.0 0.2
2. 1.2 2.4 1.0 0.4
3. 1.2 3.6 1.0 0.6
4. 1.2 4.8 1.0 0.8
5. 1.2 6.0 2.0 0.0
Where:
MobXP is the XP gained on a per mob basis;
SrvrXP is the cumulative XP gained since the last time you zone;
ClientXP is +n ticks command sent to the client to update the Bar display
Remainder is the amount left unreported by the server to the client. Whether this is actually stored server side is unknown.

This is one possible method that the server might use to report XP gain to the client. A simple way to see if this is true is whether or not the packets sent to the client upon the kill of a mob include a +n ticks integer or whether it sends an integer in the range 0 to 329. Either method is possible but it seems to me that the second option would be the less server intensive method and thereby hopefully theone that is coded.

Ah, I just did some digging and came across this by Fee:
This update does not contain the updated cumlative value but a value between 1 and 330.So it seems that your method is incorrect in that a +n ticks number is not sent to the client, this does not mean that a remainder is not stored server side. But as you said "How the server handles the math is really unimportant". As long as it sends the correct data then there is no problem. Although in my eyes storing a remaninder server side(which could mean storing the numer_of_ticks_in_level variable also) is inefficient usage of storage space when a divison and then, as I stated before, a trunc command and a subtraction will give the same result.

Just thinking of the coding, it doesn't affect packet info. Nothing to see here please move on.

The real question is are ticks truncated or rounded. Ratt says as far as he knows they are truncated although really this doesn't matter too much because whether truncated or rounded the data is still too inaccurate to be used as a baseline in any calculation of XP per mob.

[Cryonic]

As has been stated many times, it is still relatively easy to find the exp gained from a mob.

Every time you zone the server sends the EXACT amount of TOTAL exp your character has earned. Record that number, kill a mob, then zone. Record the new amount and subtract the first amount recorded. You now know EXACTLY how much exp you got from the mob (even if it was less than 1 tick in size).

[Junu Peeth]

Yep, I was referring to the usefulness(or lack of) the tick amount sent to the client as an intermediate update when a mob is killed. It is relatively useless.

As you stated actual XP for a kill is better calculated from before kill and after kill zoning packets.

[S_B_R]

Originally posted by Junu Peeth
What still confuses me is your statement "Each mob is 1.2 ticks" but then the values shown in your SrvrXP column are shown as "1.2 1.4 1.6 1.8 2.0". Then in your reply you stated: "Meaning mine adds up to 6.0" But these numbers in fact add up to 8.0 a difference of 2, your math is incorrect in this case.


Those number are per mob value with the remainder from the previous mob added.
MOB# MobXP SrvrXP ClientXP+ Remainder
1. 1.2 1.2 1.0 0.2
2. 1.2 1.4 1.0 0.4
3. 1.2 1.6 1.0 0.6
4. 1.2 1.8 1.0 0.8
5. 1.2 2.0 2.0 0.0in this chart the "SrvrXP" colum is the sum of "MobXP" and the remainder from the previous kill. the difference between "SrvrXP" and ClientXP is the decimal fraction is truncated, but that decimal fraction is not lost when it's truncated it's stored as a remainder on the server, and will be added to the next "MobXP".

The numbers I was refering to adding up to 6.0 is the Total ClientXP 1.0 + 1.0 + 1.0 + 1.0 + 2.0 = 6.0 which is the same 6.0 you come up with.

Anyway these are all just different guesses that both fit the known outcome.

As far as whether or not the ticks are relivant or not, they are just as relivant, when taken on whole, as the "real" XP numbers. On a per mob basis the "tick" system is less accurate but in the end it all works out. I've never heard of anyone Finishing a level only to have the level taken away from them the next time they zone. Nore have I ever heard of anyone being VERY close to finishing a level, and mysteriously Ding'ing the next time they zone.

[Junu Peeth]

I understand your explanation now.

[Critical1]

"I'll notice that on some mobs that con the same,"


same con or same lvl? there are several lvls of blue and yellow con mobs in the game.


of course the other explanations are alot prettier