• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver

Tribute Bug

Jmo

Ex-Admin Dust Bunny
Creator
Joined
Mar 16, 2006
RedCents
794¢
The last poster was right, there is a bug with the tribute. A few guildies and I all had it tonight. I don't know how to cause it exactly, but I'm GUESSING that if you have Tribute on, camp out, and log back in and you'll have a 13000+ minute timer for Tribute. I don't know if that's exactly how to do it, but everyone in my guild who had the bug had Tribute on when they logged out last. Hope this helps to figure it out exactly.
 
The increase occurred while zoning as well. I zoned and got the wierd 13000+ value, zoned again and it went to 26000+...but bad news: zoned again and it was back to normal...zoned back the way I came and it went wacky again.

Couldn't tell if it was zone specific or truly random. North Ro to East Free, went to 13K. East Free to West Free, went to 26K. West Free to Commonlands, back to normal. Back to West Free, went back up. Go figure.
 
32786 would be the upper limit on tribute then. Which is expected due to the datatype it's stored as in memory (16 bits)

Some odd calculation is adding 13000 to it everytime a zone event occurs, anyone mind testing if it goes from 13000 to 26000 to normal to 13000 to 26000?

When it reaches anything over 32786 it "overflows" and returns to normal.
 
Ccomp5950 said:
32786 would be the upper limit on tribute then. Which is expected due to the datatype it's stored as in memory (16 bits)

Some odd calculation is adding 13000 to it everytime a zone event occurs, anyone mind testing if it goes from 13000 to 26000 to normal to 13000 to 26000?

When it reaches anything over 32786 it "overflows" and returns to normal.
it randomly steals tribute from you if you zone while bugged, btw.
 
Then serverside the tribute is correct but client side it's not displaying correctly most likely.

Someone with 0 tribute go add 100 (or some ammount) and then bug it see if it still allows you to use tribute after it should have stopped you if it didn't bug out.
 
Ccomp5950 said:
Then serverside the tribute is correct but client side it's not displaying correctly most likely.

Someone with 0 tribute go add 100 (or some ammount) and then bug it see if it still allows you to use tribute after it should have stopped you if it didn't bug out.
it's not a clientside bug. I ended up losing ~2400 tribute in 5 minutes of having 500 tribute from zoning a lot - and relogging left the bug (and the tribute loss) intact.
 
Ccomp5950 said:
32786 would be the upper limit on tribute then. Which is expected due to the datatype it's stored as in memory (16 bits)

Some odd calculation is adding 13000 to it everytime a zone event occurs, anyone mind testing if it goes from 13000 to 26000 to normal to 13000 to 26000?

When it reaches anything over 32786 it "overflows" and returns to normal.

If this was simply overflow then bits of adjacent data are being screwed with as well.


ADJACENT INFO <----- TRIBUTE INFO <------ ZONING INFO ????

I imagine that when they bumped up the amount of tribute we could accumulate, the binary digits tacked on for it's use were still being used by some zoning information?

Long Story short, if this is the case and the cause can be isolated, we may be able to repeatedly /call the overflow to change the adjacent information at will. If we're lucky, that info would enable some uber hacks.

Warning, if this is true all this would be serverside but at this time the 'bug' is not an active hack per say, we'd be more like victims.
 
Tribute Bug

Users who are viewing this thread

Back
Top
Cart