Rift wrote:you say that.. but i'm playing right now in my house, but only if i try and go outside do i get a problem.
i guess it could have something to do with... lighting... ie.. going outside and getting lit.
<the_trav> the way it works right
<the_trav> those .res files
<the_trav> kept in haven-jar.res
<the_trav> there's like a hierarchy of resource loaders
<the_trav> it'll try to load them locally first
<the_trav> then from somewhere else
<the_trav> then from the server
<the_trav> when it finds one
<the_trav> it compares the version number (encoded in the file) with the one the server sends
<the_trav> the server message is something like "res file name gfx/hud/equip/male/kaka version 0"
<the_trav> so it loads kaka
<Gaskin> Wouldnt it say "Client too old" ?
<the_trav> then it looks at the front and says "ok, I've got version 1"
<the_trav> compares it with the version the server asked for
<the_trav> flips out
<the_trav> Gaskin, nah the client is different to the resources
<the_trav> it's supposed to be so loftar and jorb can replace individual files without making you re-download the whole jar
<the_trav> if the server said load version 5
<the_trav> and you had version 1
<the_trav> it'd go to the next level in the hierarchy
<the_trav> but because you've got what claims to be a newer version than what the server wants
<the_trav> the client assumes someone is haxxoring your boxxors
<Jackard> last time we had this problem it was with gold terrain art not loading because server was having issues
<the_trav> when I was mucking around with the resource extractor, I just disabled that check
<Jackard> and it went away next day once server recovered
<the_trav> could be that when it fails to load anything at all it gives version 0
<the_trav> it's not a number I expected
<the_trav> javas way of handling nulls is pretty lame
theTrav wrote:explanation copied from irc
- Code: Select all
<the_trav> the way it works right
<the_trav> those .res files
<the_trav> kept in haven-jar.res
<the_trav> there's like a hierarchy of resource loaders
<the_trav> it'll try to load them locally first
<the_trav> then from somewhere else
<the_trav> then from the server
<the_trav> when it finds one
<the_trav> it compares the version number (encoded in the file) with the one the server sends
<the_trav> the server message is something like "res file name gfx/hud/equip/male/kaka version 0"
<the_trav> so it loads kaka
<Gaskin> Wouldnt it say "Client too old" ?
<the_trav> then it looks at the front and says "ok, I've got version 1"
<the_trav> compares it with the version the server asked for
<the_trav> flips out
<the_trav> Gaskin, nah the client is different to the resources
<the_trav> it's supposed to be so loftar and jorb can replace individual files without making you re-download the whole jar
<the_trav> if the server said load version 5
<the_trav> and you had version 1
<the_trav> it'd go to the next level in the hierarchy
<the_trav> but because you've got what claims to be a newer version than what the server wants
<the_trav> the client assumes someone is haxxoring your boxxors
<Jackard> last time we had this problem it was with gold terrain art not loading because server was having issues
<the_trav> when I was mucking around with the resource extractor, I just disabled that check
<Jackard> and it went away next day once server recovered
<the_trav> could be that when it fails to load anything at all it gives version 0
<the_trav> it's not a number I expected
<the_trav> javas way of handling nulls is pretty lame
java.lang.RuntimeException: Weird version number on gfx/hud/equip/male/kaka (1 > 0), loaded from local res source
at haven.Resource.load(Resource.java:129)
at haven.Session$RWorker.handlerel(Session.java:350)
at haven.Session$RWorker.getrel(Session.java:383)
at haven.Session$RWorker.run(Session.java:451)
Users browsing this forum: Ahrefs [Bot], Claude [Bot] and 0 guests