igi Posted June 10, 2006 Share Posted June 10, 2006 I agree with devsin. This has been on my list of things to check for quite some time. I'm not sure how the value stored relates to the time the item is removed (it doesn't seem to be a time in second, or a game-time, or a delay), but fiddling it definately produces different times. Link to comment
devSin Posted June 10, 2006 Author Share Posted June 10, 2006 CHUI v1 controls, button - 0x16 is the cycle number, and 0x17 are the flags (IESDP currently has them swapped). The known bits: no bits - center text (horizontal & vertical) (0) bit 0 - justify text left (1) bit 1 - justify text right (2) bit 2 - justify text top (4) bit 3 - justify text bottom (8) bit 4 - anchor text (16) bit 5 - reduce text size (32) bits 6 and 7 didn't appear to do anything. bit 4 (anchor) anchors the button text at 0,0 (top-left), and all other bits then operate relative to the anchor position (so, left justify + anchor would have the text left aligned starting at 0,0). Just anchor will center the text at 0,0 (most or all of it will not be visible). bit 5 (shrink) just makes the button text smaller than normal. I won't be looking at CHUs again, ever. Link to comment
Avenger Posted June 11, 2006 Share Posted June 11, 2006 Woo, this reduce text size thing is interesting. I'll have to test it some. Maybe this is the cause why GemRB looks slightly different in some cases I just wonder how reducing happens, as these fonts are not true type fonts but fixed bitmaps. Maybe the engine uses alternate bitmap? Or omits some rows/columns? Or does some bitmap shrinking? Or it just turns all letters lowercase??? Link to comment
devSin Posted June 12, 2006 Author Share Posted June 12, 2006 It looks like rudimentary scaling. I think it's used for the kit/racial enemy buttons; probably others during character creation. The results aren't very appealing. As for create item (days), items with values at 0x8 disappear, even if given to another character, and across multiple sessions (save, relaunch, reload). The items aren't actually removed, but are replaced with the "drained" item (referenced in the ITM header). Link to comment
Avenger Posted June 12, 2006 Share Posted June 12, 2006 Uh, i've never noticed this feature I'll test and implement it then. Link to comment
devSin Posted July 15, 2006 Author Share Posted July 15, 2006 GAME v2.0 - After the game time (real seconds, which should be a DWORD), there are two DWORD values for some unknown purpose. The first is an offset (this will always be the file length) to some unknown structure type (strangely, this is stored big endian in Mac ToB?). The second is a count of the unknown structures (or something; non-zero values will fail assert(cnt == (DWORD)nGame)). In short, it should be: 0x74 , 4 (DWORD) , Game time (real seconds) 0x78 , 4 (DWORD) , Unknown 0x7c , 4 (DWORD) , Unknown 0x80 , 52 , Unknown/unused <{POST_SNAPBACK}> It looks like these may be the offset and length to another stored locations structure, this one used by the ExitPocketPlane() action (obviously, ToB only). I guess it's automatically set by the pocket plane opcode, but I won't do anything useful like actually test. The locations seem to be 8 (resref) +2 (xpos) +2 (ypos) bytes long, with one for each member of the party when the pocket plane opcode was executed. Link to comment
Avenger Posted July 16, 2006 Share Posted July 16, 2006 Heh, i already knew this, and i swear i wrote about them The following actions use these: 236 StorePartyLocations() 237 RestorePartyLocations() Here is the old topic: http://forums.gibberlings3.net/index.php?showtopic=3765 [edit] Oh, you mean, ANOTHER stored locations. DUH. ok. Link to comment
devSin Posted July 16, 2006 Author Share Posted July 16, 2006 Yeah, this is an entirely separate structure. They just used 8 reserved bytes at the end of the GAM header for the offset+count. The value at 0x7c is actually a count (not length); the Mac version stores these big endian (!!), so it took me a second to calculate 0x6000000 (100663296, what NI shows it as). (GAME V2.0 & GAME V2.1)... 0x74 , 4 (DWORD) , Game time (real seconds) 0x78 , 4 (DWORD) , offset to PP stored locations (set by PP opcode) 0x7c , 4 (DWORD) , count of PP stored locations (set by PP opcode) 0x80 , 52 , Unknown/unused Unlike normal stored locations, I doubt these are cleared when the ExitPocketPlane() action is used, but I guess they could be. The locations structure appears identical: 0x0 (resref) stored area 0x8 (word) stored xpos 0xa (word) stored ypos Link to comment
devSin Posted July 20, 2006 Author Share Posted July 20, 2006 Thanks for moving this back to discussion. BioWare usurped 16 bytes from the reserved section at the end of the ARE header in ToB. AREA V1.0 0xd4, 8 (ResRef) , Rest movie (day) 0xdc, 8 (ResRef) , Rest movie (night) 0xe4, 38 (byte) , Unused/reserved No mysteries. If the party can rest in an area, the normal rest movie (as determined by the area type flags) is overridden with the specified movie. If the party rests during daytime, the day movie plays, else the night movie plays. This happens if any or all of the following type flags are set (the ones that allow resting, obviously): outdoor, city, forest, dungeon, and can rest (actually, I made up city and forest; I don't know these actually allow resting without outdoor or dungeon). I was hoping it was controlled by the rest flag, but it isn't (I would say to imagine using SetAreaRestFlag() to change rest movies based on events, but I don't think anybody can make a movie that would be worth it). I think I've seen this before (or I've previously discovered it and forgot about it). It isn't in the IESDP, so here it is. @Avenger, GemRB Unlike normal stored locations, I doubt these are cleared when the ExitPocketPlane() action is used, but I guess they could be.The locations are cleared when the ExitPocketPlane() command is executed. Link to comment
Avenger Posted July 20, 2006 Share Posted July 20, 2006 The movie fields are new to me Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.