| View previous topic :: View next topic |
| Author |
Message |
Zebranky
Joined: 04 Jun 2006
Posts: 415
|
 Posted: Fri Oct 17, 2008 21:17 Post subject: |
 |
|
I can write a fixer; I have the framework already written for a different fix we needed to apply for 1.69 compatibility. I don't really want to deal with Java, though, so... 
BTW, in case anyone is curious about what's going on internally, I believe the spell effects, current location, reputations with NPCs, automap data (parts revealed), and local vars on the PC are all stored on logout in a structure called a TURD (BioWare is cute like that). On login, these are restored from the TURD list, but the list is indexed by, among other things, FirstName. Apparently whatever handles comparing two CExoLocStrings in this case does not enjoy having a bunch of extra languages hanging out up in 4000-land. This could probably be NWNx-d, but that is left as an exercise to the clinically insane reader.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/
<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.
<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for? |
|
| Back to top |
|
 |
PlasmaJohn
Joined: 04 Mar 2005
Posts: 70
Location: The Garage
|
| Posted: Fri Oct 17, 2008 22:28 Post subject: |
|
|
Whatever is in FirstName is giving GFFEditor.exe fits: several of the language ids are duplicated. This suggests to me that there may be a more fundamental structural error.
I deal with Java everyday, I'll poke at it to see what I can see. |
|
| Back to top |
|
|
PlasmaJohn
Joined: 04 Mar 2005
Posts: 70
Location: The Garage
|
| Posted: Fri Oct 17, 2008 23:02 Post subject: |
|
|
| FirstName is the 0 field or the first field in the field list. It also happens to be the first CExoLocString read or written back out. I smell something uninitialized. |
|
| Back to top |
|
|
Zebranky
Joined: 04 Jun 2006
Posts: 415
|
| Posted: Sat Oct 18, 2008 1:18 Post subject: |
|
|
I did also notice the GFFEditor issue. I assumed it was just poor handling of language IDs over a certain value, and I didn't see anything wrong from a quick look at the bic. The actual language IDs are in the 4000 area, whereas GFFEditor shows them around 2000. I believe the game still has the same issue when lower IDs are used.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/
<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.
<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for? |
|
| Back to top |
|
|
Jambo
Joined: 24 Sep 2008
Posts: 22
|
| Posted: Sat Oct 18, 2008 1:50 Post subject: |
|
|
Slight update on this, I edited the Autobic sources to have it write the information it needs to a new field (suitably named "Autobic") but unfortunately after then logging in a character, this field is not saved. I assume NWN has an internal list of field names it saves and ignores any custom ones.
I've updated relevant Autobic sources to use the description field as an alternative, and this works fine. SetDescription will also not destroy the content of this field.
On an unrelated note, the Advanced Editor of Leto does better with these unusual field values. |
|
| Back to top |
|
|
PlasmaJohn
Joined: 04 Mar 2005
Posts: 70
Location: The Garage
|
| Posted: Sat Oct 18, 2008 15:39 Post subject: |
|
|
There's also an error in CExoLocString around line 146: he's appending an unnecessary null terminator. Taking that out got the login screen to report sane values.
I'm still trying to wrap my head around why he felt it necessary to embed the metadata into the bic in the first place... Shouldn't that information be a simple lookup? |
|
| Back to top |
|
|
Gryphyn
Joined: 20 Jan 2005
Posts: 431
|
| Posted: Sun Oct 19, 2008 0:45 Post subject: |
|
|
| PlasmaJohn wrote: | | There's also an error in CExoLocString around line 146: he's appending an unnecessary null terminator. Taking that out got the login screen to report sane values. |
The 'extra' null terminator is not an error - it's a safeguard.
Strings are not always required to have a null terminator, adding any extras only results in the file getting a little padded.
Strings should always be retrieved using the offset-size pair, and not relying on a null terminator. An extra byte won't hurt, where as a missing byte WILL cause issues. |
|
| Back to top |
|
|
Zebranky
Joined: 04 Jun 2006
Posts: 415
|
| Posted: Sun Oct 19, 2008 2:12 Post subject: |
|
|
PJ: You're forgetting that he wrote this for CoPaP, where nobody can really be guaranteed to have the same data. It was the best way to make sure the necessary data got preserved for later validation.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/
<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.
<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for? |
|
| Back to top |
|
|
PlasmaJohn
Joined: 04 Mar 2005
Posts: 70
Location: The Garage
|
| Posted: Sun Oct 19, 2008 15:42 Post subject: |
|
|
| Gryphyn wrote: | | The 'extra' null terminator is not an error - it's a safeguard. |
The GFF spec is clear that these strings are not null terminated. If the code is not correctly calculating the length then that is a bug that must be corrected not kludged. AFAICT, keeping the null breaks an assumption that the NWN engine is making on the login screen. If it breaks one part of the code, it is likely that something else has the same problem.
| Zebranky wrote: | | PJ: You're forgetting that he wrote this for CoPaP, where nobody can really be guaranteed to have the same data. It was the best way to make sure the necessary data got preserved for later validation. |
As we've discovered over the years, that simply doesn't work without at least a minimal amount of coordination. Of course that's 20/20 hindsight. Hmm... ok, guess I'll moderate my rant to "Nice try but... ur doing it wrong"  |
|
| Back to top |
|
|
Jambo
Joined: 24 Sep 2008
Posts: 22
|
| Posted: Wed Oct 22, 2008 20:18 Post subject: |
|
|
GffData.java -- I noted a few other potential issues as well....
| Code: | public static byte[] longToBytes(long value)
{
byte longBytes[] =
{
(byte) (0xff & value), // low byte first
(byte) (0xff & (value >> 8)),
(byte) (0xff & (value >> 16)),
(byte) (0xff & (value >> 24)),
(byte) (0xff & value >> 32),
(byte) (0xff & (value >> 40)),
(byte) (0xff & (value >> 48)),
(byte) (0xff & (value >> 56)) // high byte last
};
return longBytes;
} |
Pretty sure that should be (0xff & (value >> 32)), at leats to be on the safe side.
| Code: | public static byte[] shortTo4Bytes(short value)
{
byte intBytes[] =
{
(byte) (0xff & value),
(byte) (0xff & (value >> 8)),
(byte) 0xff, // empty
(byte) 0xff // empty
};
return intBytes;
} |
Bioware actually writes the last two bytes as nulls, not 0xff.
writeStructArrayEntry works fine for the most part. It will write out a structure length or offset, so for the first/base structure it writes the length. Bioware on the other hand simply write the offset (which is 0 for the first structure).
GffLabel.java + GffResref.java also seem to use unneeded null characters to terminate the strings.
It's fair to say, after you log in/back out again, Bioware will write a file back out however it likes though. There's other editors out there (ie: Leto) which managed to write a file 300k bigger but the moment I log in/back out with that character, the bic shrinks back by 300k again.
So to Bioware's credit, they at least allowed for some pretty bad inaccuracies in writing the GFF structure. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
