[FIXED] NPCs become allys without reason
-
Grimson
- Developer
- Posts: 802
- Joined: Sat Jun 04, 2005 1:52 am
- Location: Germany
- Has thanked: 0
- Been thanked: 0
NPCs become allys without reason
Found a new bug in 3.6, if you manually add an NPC (it has to be saved into the worldfile). Then quit and restart the server the NPC is shown as an ally (the name is green) to the players. This is reproduceable.
-
Grimson
- Developer
- Posts: 802
- Joined: Sat Jun 04, 2005 1:52 am
- Location: Germany
- Has thanked: 0
- Been thanked: 0
There seems to be a problem with saving the GuildNumber of a char. The default for no guild is "-1", but it get's saved as "ffff" into the worldfile. Upon the next world load the "ffff" is then converted to "0". So all chars end up in the guild with the number "0".
I have checked where the number get's saved and couldn't find any obvious errors, so I'm a bit puzzled now.
I have checked where the number get's saved and couldn't find any obvious errors, so I'm a bit puzzled now.
-
giwo
- Developer
- Posts: 1780
- Joined: Fri Jun 18, 2004 4:17 pm
- Location: California
- Has thanked: 0
- Been thanked: 0
As for numbers changing, I'll have to look into that.
I can say that GuildFealty should be unsigned, it defaults to 0xFFFFFFFF (or our INVALIDSERIAL typedef). However on loading it in we use string.toLong(), which would cause that number to roll over to a -1 (generally) and then automatically converted back to an unsigned (which would hopefully be 0xFFFFFFFF) when setting the actual value. Needless to say that's not good, as it's all on hopes the compiler is converting those properly, which isn't a guarantee.
Anyhow, compiling now to test and track this one down.
[EDIT]
That, aparrantly, was a different bug. Just realized we were talking about GuildNumber, not GuildFealty here.
That problem, however, is that we don't use a 0x but save it as hex, which would certainly cause it to spit out.... interesting... values.
[EDIT #2]
This seems to be the case in several sections of CChar. I am implementing a system to save us from this problem in the future, but my guess is someone added or removed a worldfile tag which also was setting the stream back to decimal from hexadecimal. Needless to say this is a reasonably large error with quite a scope of influence, so UOX3 v0.98-3.6 is going to need to be re-released with this fix, lest peoples worldfiles get corrupted.
I can say that GuildFealty should be unsigned, it defaults to 0xFFFFFFFF (or our INVALIDSERIAL typedef). However on loading it in we use string.toLong(), which would cause that number to roll over to a -1 (generally) and then automatically converted back to an unsigned (which would hopefully be 0xFFFFFFFF) when setting the actual value. Needless to say that's not good, as it's all on hopes the compiler is converting those properly, which isn't a guarantee.
Anyhow, compiling now to test and track this one down.
[EDIT]
That, aparrantly, was a different bug. Just realized we were talking about GuildNumber, not GuildFealty here.
That problem, however, is that we don't use a 0x but save it as hex, which would certainly cause it to spit out.... interesting... values.
[EDIT #2]
This seems to be the case in several sections of CChar. I am implementing a system to save us from this problem in the future, but my guess is someone added or removed a worldfile tag which also was setting the stream back to decimal from hexadecimal. Needless to say this is a reasonably large error with quite a scope of influence, so UOX3 v0.98-3.6 is going to need to be re-released with this fix, lest peoples worldfiles get corrupted.
Scott