Random notes

[devSin]

It looks like pieces of BG and BG2 are in there. I'm pretty sure BG/TotSC doesn't use 0x7a (the values here are just too random and never change on disk), and unlike BG2, the game supports (I think) spawn re-fires before the area is reloaded (but 99% of BG2 spawns just turn off; BG never does).

 

0x78 probably makes more sense, then, for BG/TotSC spawn points, to spread out subsequent firings?

[Taimon]

It looks like pieces of BG and BG2 are in there.

Since there is only one ARE version, that's very possible.

By the way, I did have a sneak peek at the dwords after the area link resrefs in TotSC. Sad news: Bit 0 of those dwords is shifted into the upper word of int1 of an Leave Area (#91) action, but this is never used by the action. (At least I didn't see anything.)

 

0x78 probably makes more sense, then, for BG/TotSC spawn points, to spread out subsequent firings?

Yep, but to me it looks like a very unusual way to do this. Would you implement it like that?

 

I haven't tested any of these, so it should be taken with a grain of salt until someone can confirm these things.

[Taimon]

and unlike BG2, the game supports (I think) spawn re-fires before the area is reloaded

Looking at what I've posted, I think it's possible in BG2 as well. (If Bit 0 of 0x7a is not set and all previous spawns have been killed.)

[devSin]

Yeah, but like I said, the majority turn off (or have the first bit set). In BG/TotSC, I'm unaware that they *ever* turn off (and don't have code to temporarily disable, since the junk values of 0x7a don't change on disk).

 

In the BG2 saves I still have on disk (I have enough to browse most the files, but I can't run the game to test anything currently), it seems accurate (spawns turn off, Bit 2 gets set, etc.).

 

In the Mac version of ToB (based on 26499b), the value copied to the actor expiry is messed up (constant 0x10111111) BTW, and if the Is spawned bool is true, the game actually purges the creature when the area reloads (from save, etc.; some fat bug caused by the guy who tried to fix the summoned monster bug in 26498).

 

I really don't know what the calculation there is. I'm not sure what's gained by breaking it to frames to get the remainder from the internal timer (there had to be some friendly way they could instruct the designers for filling this value, though)? My lazy self would just store the constant reactivation time in some of those reserved bytes left at the end and stick the desired delay between invocations in 0x78. Fancy calculations are for the smart people. :-)

 

If we're not starting to treat you too much like a dictionary and you happen to be around the ARE animation structure, can you also look into the final fields? I've never been satisfied with the descriptions so far:

+0x3c - Starting frame
uh, no? There's already a start frame field
maybe a frame offset or -/+ n frames
for random playback (actually, pretty much
looks unused everywhere?)

I'm pretty sure the original (BG/TotSC) ended with Height/Zloc DWORD +0x38; all these additions seem mostly useless and mostly unused...

 

For the automap structure, can you see/guess why the note number (+0xc) is always +10? Looking at my NI source, I think that's one of the last ?s I have in the ARE format.

[Taimon]

Right now, I need a little break.

Still have some patches, that I want to do. (Fix Blindness, externalize strrefs for undroppable npc items [Alora, Edwin, Minsc, ...])

 

What about ARE+0x52? And ARE+0x90?

Automap notes should be relatively easy to find out.

 

The problem with animations is, that I have to understand the whole animation process to make out what these bits do. And I'm far from having a good picture about how this goes.

[Avenger]

boolean variables map to dword, so when the bio dev said: oh i'm humble, i just need two flags, i don't waste a dword for a bitfield, he actually grabbed two dwords.

 

Why transparency is on a word?

Probably the graphic library which uses transparency defines it as a word. So the bio dev used a word.

Why the graphic lib uses a word?

Because using bytes are not speed optimised. (Well, words are not optimised either, but i guess some of these libs go back to 16 bit age?)

 

If you look at newer structs, they increasingly use dword bitfields. (Compare effv1 to effv2).

Ahh, well, sometimes they realize that they need to store 2 values in one, but don't want to convert all the structs again. Then they split a dword/word again

[Avenger]

about loop probability.

 

Well, the animation works like this (in gemrb at least):

 

When i need to render a frame, i ask the animation object for a frame: ani->GetNextFrame()

 

if the animation is looping, the Animation object will simply rewind (set a counter to 0).

if the animation is looping by chance, the Animation object will rewind based on a rand()%100<chance formula.

 

Not much of a speed difference.

[Avenger]

That count thing is used internally, it won't hurt if you set all to 0.

It is not entirely linear, if you delete a map note, it isn't recalculated.

Anyway, it is not usable for any modding purpose, it seems like some internal variable.

 

Have you looked at an entrance struct? The last 4-5 dwords are fully garbage - look like memory pointers

But there are some interesting fields.

[Taimon]

For the automap structure, can you see/guess why the note number (+0xc) is always +10?

Because it's the gui control identifier. Window 2 of GUIMAP has 3 controls and I guess they wanted to have some room for additional controls, just in case.

 

The internal counter in the areamap structure is initialized with 10 and the function that creates the gui controls also looks for ids >= 10 for the map notes. (The size of a map note control is 0x666. )

 

Have you looked at an entrance struct? The last 4-5 dwords are fully garbage - look like memory pointers

But there are some interesting fields.

Only garbage from the toolkit.

It's copied but nothing after the orientation is ever being accessed.

[devSin]

boolean variables map to dword, so when the bio dev said: oh i'm humble, i just need two flags, i don't waste a dword for a bitfield, he actually grabbed two dwords.

Where the talk of bool comes from?

 

Probably the graphic library which uses transparency defines it as a word. So the bio dev used a word.

But why would you define it this way (instead of a constant effect toggled by flag, of which you have plenty reserved, like everywhere else it's used) and then never use it (not even your fancy vidcel control structure get such a thing).

 

What about ARE+0x52? And ARE+0x90?

I believe +0x52 should be an extra weather.

 

+0x90 I've never seen hold any value on disk.

[Avenger]

boolean variables map to dword, so when the bio dev said: oh i'm humble, i just need two flags, i don't waste a dword for a bitfield, he actually grabbed two dwords.

Where the talk of bool comes from?

Why waste a dword when it is on/off

Worse than wasting a word for a byte.

Look at the spawn structure, there is a nice bitfield, but the enabled flag sprawls on a dword.

[devSin]

about loop probability.

OK, I've looked through BG2 areas and a bunch of saves, and I'm pretty sure I know what's going on here. These two bytes are probs1,2 (same as effects). If probs 1 is 0, the engine sets it to 100 (the probs 2 value never changes). I have to reinstall BG2 to check in-game, but this seems the most likely.

 

This leads to questions, though. Is this a per-frame probability (pretty impossible); if this is probs to play completely one single time, does it even make any difference to fail the probs check if you're just going to roll again every single frame (i.e., 15 times a second)? Unless you have a tiny probs, what point is there?

 

I also think this would probably end up being on the play and not the restart (e.g., you have to roll true to even get it to run in the first, not 100% first playback and then probs to restart).

 

I still have no idea what the value after "translucent" WORD is. It can't actually do anything (the only value here is -1 or 0, and it's just as common to -1 and other crap in BG/TotSC files, and the -1s in BG2 seem more likely copy/paste from BG areas that they did).

 

IWD has a ton of data in the later fields of the animation structure. Since BIS toolset looks to have initialized everything (no memory junk anywhere), are there any known IWD-specific values here, Avenger?

They also have an extra set of coords for all travel triggers (Type 2 only) in the two WORDs after BG2's activation override point; the points are always set correctly near the launch point; known what these are here for?

 

I was looking at CHUI, from my last work couple years ago, and some of the unknowns seem obvious now (subject testing):

text field +0x2e -> this is caret animation cycle (WORD) (I mean, is there even any doubt)

text field +0x30 -> this is caret animation frame (WORD)

text field +0x66 -> this is flags or boolean: value 1 = ALL CAPS (export filename)

[Avenger]

OMG, i didn't know about the cursor coordinates (obviously didn't suspect the frame/cycle fields either).

 

[edit]

Heh, i'm even more senile, DLTCEP actually had those fields declared as x/y pos.

 

Though i couldn't figure out how to use them.

In PST they are 6/8 in guisave.chu (save game name).

It won't help, if i apply them to the cursor position in any way.

 

On a related note, after font, there seems to be an unused word, and then 32 bytes text.

(In pst it contains 'Test')

 

[edit]

(Ok, the answer is: those positions are NOT the cursor positions, but the whole client area, that includes the entered text).

[devSin]

Yeah, the coordinates are the actual field location (I still label it "Caret position" simply because that's the first visual indication of the field location). There's not enough room in the structure for colors, and I can't see any obvious use for the DWORD prior or WORD following the font resource.

 

Like you note, that word is followed by a standard 32-byte string that isn't used for anything (commonly, "Test" or "test" or \x00). It's followed by the field length, and then that flags DWORD. The only use I can guess for that right now is 1, which forces the entered text to be all capitals, like when choosing a filename to export a character (at least, that's the only place it's not zero).

 

Beyond those, the only real CHU unknowns (outside all those flags) I see are the sometimes-nonzero values after the window control index and after the control-type byte, and those four words (that have to do something?) at the end of the slider control.

[Avenger]

Like you note, that word is followed by a standard 32-byte string that isn't used for anything (commonly, "Test" or "test" or \x00). It's followed by the field length, and then that flags DWORD. The only use I can guess for that right now is 1, which forces the entered text to be all capitals, like when choosing a filename to export a character (at least, that's the only place it's not zero).

For the 'case' field (my proposed name)

 

0 - normal

1 - upper case

2 - lower case

others - upper case

 

(So, it is possible to force lower case or upper case).

I hoped for pure numeric entries, but apparently that will be a gemrb specific extension