Jump to content

Random notes


Taimon

Recommended Posts

Also, this flag is set in some of the animations in Irenicus' dungeon, and I swear it doesn't behave this way (unlike in the ToB areas where they finally use the flag, the animation doesn't disappear, regardless of settings).

I don't think this is related to the area itself. Can take a closer look, but I doubt it's worth the effort. The handling is very similar to the sound flag/"Low Mem Sound" setting.

Directly after the flag is checked (and it's clear) they check for "Low End Machine 2"/"Low Mem Sound 2".

 

Somebody needs to shoot you a TotSC .exe already.
Tell me when where and how and you've got access to one BG vanilla exe and one BG Totsc exe

I have one, but I don't think I will start reversing that one right now. It took too long to get familiar with the ToB executable. :party:

Besides, is there any interest in these things if they don't work in ToB?

 

Just by checking for bit 3 alone, you can weed out most if not all of the items that are creature specific and not available to party members... So... perhaps it is 'Displayable in Shop'

Can you confirm this ingame? I usually don't test things -- only looking through the code, so I haven't checked if this bit does anything for shops.

 

So, the rest spawn header and the spawn structs share a lot in common?

Definitely, will take a look at the spawn struct later.

Link to comment
I don't think this is related to the area itself. Can take a closer look, but I doubt it's worth the effort. The handling is very similar to the sound flag/"Low Mem Sound" setting.

Directly after the flag is checked (and it's clear) they check for "Low End Machine 2"/"Low Mem Sound 2".

Nah, you're probably right (Low 2 turns everything off IIRC, even though should only "large"). You think there'd be more consistency in where it's set, though.

I'm not sure that's all Bit 4 for ambients does, though... looking at old BG areas I have, they use it too, and I don't think there was Low Mem anything back then?

 

Edit: Meh, "Static animation" and "High memory ambient," it is, unless somebody gives me better labels.

 

Besides, is there any interest in these things if they don't work in ToB?
ToB is such a near-perfect superset of BG/TotSC (even if the underlying crap is handled differently) that everything is already known. (The toughness is in the differences of script execution and mechanics and behavior, and you're right nobody cares about those.)

 

I'm hard-pressed to think of any but these four values (which are completely unknown everywhere?) that can't be deduced from ToB counterpart (it's probably a boring worthless flag, of course; I don't think there's a single case where these assignments are set and the subsequent DWORD isn't '3').

 

Can you confirm this ingame? I usually don't test things -- only looking through the code, so I haven't checked if this bit does anything for shops.
I've done no-flag items in stores before, so it certainly has no effect in BG2 stores (these flags started with the engine, though, so maybe BG/TotSC does different).

 

Door flags (+0x28) Bits 5 & 6 are unknown

Either unreferenced or copied but not used.

I hoped 5 really did have some purpose (they had to set it on purpose in the rare places it's used, at least), but 6 is 99% always set (the WED linkage nonsense from IESDP never made sense to me?), so I guess I'll just call that one Not copyable. ;-)

 

Trigger flags (+0x60) Bit 0 does what?

Either unreferenced or copied but not used.

That makes me sad... something to do with travel triggers? but IESDP description was always nonsense. Maybe they come at these differently depending on trigger type?

 

Definitely, will take a look at the spawn struct later.
If you could find +0x78 and +0x7a and verify +0x84, I think that would finally knock this structure out?

 

If you ever get bored, I know nothing about WED files (WED stands for Wall Of Numbers, really!), and I trust the IESDP very little here beyond the basics (most known except door +0x8 WORD, polygon "hole" flags WORD, and overlay "# drawn" DWORD). There's also the "tiled objects" structure that is accounted for but has never, ever been seen and completely unknown what it's for (at least, I don't remember anything about it). I didn't list WED in mine because I truly don't care if it all remains unknown forever, but Avenger would, I bet, and he has more use for knowledge than I do. :)

Link to comment
Can you confirm this ingame? I usually don't test things -- only looking through the code, so I haven't checked if this bit does anything for shops.
I've done no-flag items in stores before, so it certainly has no effect in BG2 stores (these flags started with the engine, though, so maybe BG/TotSC does different).
I took the ax1h01 and removed the movable and displayable flags and was able to purchase the item and move it around within the inventory in both BG Vanilla and BG ToTSC.

 

I'm not really sure what those flags are meant to accomplish. Perhaps, Bioware simply set them for internal purposes when designing the items. Maybe they were used by whatever program they had for creating the items to begin with. If items that had them set work when not set, makes you wonder what they were for to begin with...

 

Those flags could always interact with something else or when something somewhere else is set to a certain value....

 

Still with the bioware files, it is a good indicator of what items are intended to be utilized by the player. Perhaps not so much with mod added items as those may not be flagged in the same way...

 

Although, I had used Shadow Keeper to put a bunch of weapons on my pc (for testing a offhand for ranged swapping mod - BG2) and found out that one of them couldn't be moved - deva.itm - in the game. The item file doesn't have bit 2 Movable set. However, as DevSin has said no-flag items seem to work as normal and my little BG test seems to confirm that. So I don't know what's going on with that...

 

I have one, but I don't think I will start reversing that one right now. It took too long to get familiar with the ToB executable.

Besides, is there any interest in these things if they don't work in ToB?

It would be nice to know what can and can't be done even with BG Vanilla. At the very least, you could find the needed offsets that the Bigg could use to get the widescreen mod working on BG Vanilla...

 

 

I was curious about the Rest section of the ARE file. I had noticed some things when I was working in IWD, but hadn't ever gotten around to doing much tinkering with it. There isn't anything listed as affecting how long it takes to heal 1 hp when resting. However, simple tests showed that resting in nice safe indoor areas without access to healing spells took X amount of time while resting in safe outdoor areas took Y amount of time and resting in dangerous outdoor areas took Z amount of time. Wondered if the same was true with BG2 and if so, what controls that and is it adjustable?

Link to comment
I'vI took the ax1h01 and removed the movable and displayable flags and was able to purchase the item and move it around within the inventory in both BG Vanilla and BG ToTSC.
IIRC, undroppable in BG/TotSC influences only the item list created for corpses (i.e., "undroppable" flagged item is not created when the owner is slain).

 

In BG2, it should be stuck in a slot and unable to move (although otherwise usable), and it won't drop or get copied to clones.

 

That's what I thought. But I'm not really sure.

There was like one case where they actually used the value (CString::setAt(0, char)), but I failed to trigger this in my testings.

Actually, it turns out BG/TotSC doesn't use this (and the GAM field is probably "Currently in party?" DWORD), so they purposely added it for some dumb reason. Who are these people? I hate having to special-case all this junk.
Link to comment
Somebody needs to shoot you a TotSC .exe already.
Tell me when where and how and you've got access to one BG vanilla exe and one BG Totsc exe

I have one, but I don't think I will start reversing that one right now. It took too long to get familiar with the ToB executable. :party:

Besides, is there any interest in these things if they don't work in ToB?

Definitely. Maybe not for NI or DLTCEP, they could run good enough with the ToB standards (Maybe even Echon or other BG1 modders use BG2 engine nowadays).

But GemRB tries to implement BG1 (and IWD and PST) as well, it is good to know if there are any BG1 specific quirks.

On the other hand, if you would rather spend your time with ToB, that's good. I could check BG1, just give some detailed map for ToB. It is always easier to do a second visit to a country, even with a somewhat different map. I discovered only the effect opcodes, avatars and the projectiles, but once i understood the appropriate code in one engine, it was cakewalk to do the same with the rest.

 

So, a detailed ToB map is a treasure map for me.

Link to comment

I'm pretty sure i found out what's bit 6 (value 0x40) is.

Hmm, Door flag 6 is the region link stuff. It enables the region field. I call it 'Linked' in DLTCEP.

 

If the door opens, it enables the linked region.

If the door closed, it blocks the region.

 

(The region also has a 'door blocks' flag)

 

Dunno where you read about WED linkage, this is region linkage :party:

Link to comment

Yeah, except that the flag doesn't actually do anything.

 

If you're saying that it indicates a corresponding trigger, just specify the trigger. It will behave exactly the same whether Bit 6 is on or off, yes? (The engine will, however, take note and make sure to enable the named trigger's Connected to door bit when the state changes.)

 

I'm not sure where the WED thing came from. Probably an older version of IESDP, where most my wrong ideas come from. :p

Link to comment
Do you think "Left-handed" is a fair label for ITM Bit 10, or am I reading your description wrong?

Sorry, missed that.

Leave it unknown for now.

It certainly has something to do with dual wielding or at least the dual wield animations (A7-9). Maybe there are some animation sets where A7-9 aren't actual dual wielding animations, but something else.

 

About WED and other research areas:

The more specific the research request is, the more likely it is, that I'm looking into it. I have to know what to look for.

And compiling a list is always good for me, so I don't need to extract this info from various posts. (lazyness :party:)

 

I already came across some of the WED processing. Together with the tilesets this forms a structure called "Infinity" in every area. I think the IESDP is pretty accurate here. But I stopped reversing it when it got too "arithmetic". (This is just plain ugly in assembler.)

Link to comment

Yeah, only the part of WED that isn't a big array of pain. The structure is pretty well known.

WED Doors +0x8 (word)
 usually 1? open/close bool (WEDs don't get saved, so doubtful)? flag?
WED Tilemap +0x6 (4 bytes)
 I think the IESDP is wrong here; this is usually something like 00 06 00 00 -- the 06 is a count, probably, but why byte-sized (or byte word byte)?
WED Polygon +0x8 (word)
 flags (usually 0xnnff; pretty sure both bytes are the flags)

Lowest priority as far as I'm concerned, though.

Link to comment
WED Doors +0x8 (word)

usually 1? open/close bool (WEDs don't get saved, so doubtful)? flag?

Well, it's "default door open state", with the meanings flipped in PS:T as usual. Don't know if it's possible to set the other bits, but this is definitely used by some of the games.

I think the IESDP is wrong here; this is usually something like 00 06 00 00 -- the 06 is a count, probably, but why byte-sized (or byte word byte)?

Well, that first byte definitely contains those overlay bits, so I don't see another obvious explanation than madness..

Link to comment
Well, it's "default door open state", with the meanings flipped in PS:T as usual. Don't know if it's possible to set the other bits, but this is definitely used by some of the games.
Now that I think about it, it does make sense since I believe the default behavior was to clear the open bits in the ARE during the periodic reset? I don't remember if BG2 still does that, though...

 

EDIT: actually, it just seems to always be 1, regardless of whether they want an open or close door...

 

Well, that first byte definitely contains those overlay bits, so I don't see another obvious explanation than madness..
For the first overlay, it will have some bit value (2 4 8 10). Additional overlays are where it gets dumb (is only the first byte used, I wonder?), and it may have a small value in the second byte (I don't believe it's simply additional bits) but will never have one in the first (could just be toolset junk if the above is true). So I can't treat it as a DWORD, and it's definitely not 1+3, so it's either crap or some other byte/word configuration.

 

I'm not sure why IESDP has 8 bits for the first, though (does any game have more than 5 of these? would more even work? does Bit0 really do nothing, or would it try to overlay the tileset with itself?).

Link to comment
Definitely, will take a look at the spawn struct later.
If you could find +0x78 and +0x7a and verify +0x84, I think that would finally knock this structure out?

0x76: difficulty (same as with rest spawns)

0x78: This is treated like a value in seconds, but it's difficult to make out, what they wanted to achieve with it. I think it's used to slow down the spawning process.

Before the probabilities are checked there is a test involving this value:

if ((world_timer % ([0x78]*15)) != (spawn_obj_id % ([0x78]*15)) -> abort

(spawn_obj_id is the engine internal identifier for the spawn point.)

And directly before calling the method that spawns the CREs, the value is modified:

[0x78] = [0x78] * 15/10 + 1.

So you can set some initial value here, but it will be modified ingame.

 

0x7a: bitfield

Bit 0: if Bit 2 is set, don't spawn

Bit 1: one-time-spawnpoint (checked for after the spawning, and disables the spawn point if set)

Bit 2: used internally, to disable the spawn point temporarily

It is set after a spawning, but the engine clears it in two situations:

(1) after the compressTime() method for the spawn point is called with a time amount of at least 16 hours (?)

(2) if Bit 0 is not set and there are no living spawns in the area

 

0x84: confirmed (max num of CREs to spawn)

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...