SPL/ITM: Extended header target type

[igi]

A value of 3 (currently laughably labelled 'dead character') in the target type field in the extended header for spells seems to have nothing to do with dead characters; instead it seems to override the range field. With a value of 1, the character will walk to be within the spell range before casting the spell, with a value of 3 the character just casts the spell from their current location - even if it's halfway across the map.

 

EDIT: This was tested with BG2:ToB btw - utterly untested on other engines.

EDIT: Also, to clarify a value of 0 ('invalid') means the no target can be selected and the spell will not be cast. A value of 2 ('Inventory/Crash') seems to crash in every circumstance I can think of, and is likely to be ranamed in the next IESDP update to just 'Crash'.

EDIT: Seems to have no effect on items (at least for melee abilities).

[Kung Fu Man]

In Torment, 2 definitely causes a crash, but I can't find any difference in behavior for 3 sadly.

 

Makes some sense. Spells and items meant to raise dead targets for this game are named in the EXE, rather than dependent on a variable (no I really don't get why the hell they did that >_<)

[plainab]

I think we might be talking the same thing here...

 

Dead Character (or perhaps 'Dead Party Member') for value 3 makes sense to me.

BG2 Raise Dead scroll has this value set for the scroll to properly cast the spell. In BG vanilla the scroll Raise dead does not work because in the ability header it is set to target 1-Creature (according to DLTCEP) if that is changed to 3-Dead Character it works just fine in the game.

 

I don't know of any other uses for value 3 beyond getting the Raise Dead Scroll to work properly....

 

There must be something there that tells the engine that a dead party member is a valid target. Change the target value to 1 and neither the spell or scroll will work.

[Kung Fu Man]

Well in PST items and spells that can be used to raise the dead are named in the EXE: without that, trying to target a corpse with it results in it working on corpses. However they use Targetting value 1, not 3.

[Taimon]

A value of 3 (currently laughably labelled 'dead character') in the target type field in the extended header for spells seems to have nothing to do with dead characters; instead it seems to override the range field.

 

I can confirm (from the code point of view) that 3 ignores the range calculation as well as the projectile field (uses projectile 1 as default).

 

2 and 6 are assert(false) [crash] in nearly all target type checks. (I think there is one case were only one of both is a crash, but it's probably irrelevant.)

There is a different codepath for 7 in most checks. I guess this could use some investigation.

[Avenger]

No range/projectile is required for targeting dead characters.

I agree that no range/projectile is a bit closer to the technical description of the targeting type, but 'dead character' is closer to the practical description.

PST seems to have re-hardcoded this, just like they re-hardcoded treasure tables, etc.

I don't know why they chose to do that, it sucks...

[Kung Fu Man]

PST seems to have re-hardcoded this, just like they re-hardcoded treasure tables, etc.

I don't know why they chose to do that, it sucks...

 

Well we "have the technology", why don't we make an EXE patch to override those limits?

[Displacer]

I found the random treasure lists, of course they're hardcoded, but they are accessed the same way other 2da files are. As soon as I find the 2da functions it would probably be a simple task to strip the original 2da's from the exe, put them into a external 2da file and access them that way. But first I need to find the 2da functions. I need a break from area processing anyway so I'll see what I can find.

[Displacer]

Well there may be hope. With one exception every single 2da file is referenced in the code. It looks like there is a huge function that loads them all at once. PST just ignores the hardcoded ones and uses its internal lists, but the code to at least load all the 2da's in the game are there so it may be possible to activate that code. The single exception is reverb.2da, I saw that string referenced once, but it looked like an INI setting. Even the ones that are not used, or leftover from BG1 are accessed.

[Kung Fu Man]

If we can sort out a list of unused 2DA files, might make some headway on figuring out everything hardcoded in the EXE.

 

And wow did we hijack igi's thread o_O

[igi]

Added to local copy.