Jump to content

Patching State.IDS?


jastey

Recommended Posts

Patching ids files is something I'm never sure I do it right. I have BGII-ToB from GOG and if I install my mod the installer says

 

[stateCheck] argument [sTATE_REALLY_DEAD] not found in [state.IDS]

 

I am sure it's an easy patch, but how exactly do I do that in a compatible way? Is there a mod that does all this that I can use as reference? Because, taking the Fixpack code might use to incompatibilities if used by a later-to-install mod.

Link to comment

0x00000FC0 STATE_REALLY_DEAD

 

And it exists in both my EET as well as my old BGT install. But maybe it was added to the classic game already by a mod.

 

I would use in tp2

APPEND ~state.ids~ ~0x00000FC0 STATE_REALLY_DEAD~ UNLESS ~STATE_REALLY_DEAD~

Edited by Roxanne
Link to comment

STATE_REALLY_DEAD was originally introduced to Fixpack (I think it was from the Ding0) to fix the exact issue that jastey mentioned in the previous thread. The game had a ton of places where it was trying to use Dead() checks with objects which we had to change to the aforementioned StateChecks instead. It has since migrated its way into a lot of places (like EE), the same way that CD_STATE_NOTVALID has. :)

Link to comment

And righfully so! :)

Very cool statechecks.

I just recently found an older mod (I think it was Amber NPC I was updating and expanding for EE) that still had the six or seven state checks which were summarised later as CD_STATE_NOTVALID. Just an anecdote off topic...

Edited by Roxanne
Link to comment

And righfully so! :)

Very cool statechecks.

I just recently found an older mod (I think it was Amber NPC I was updating and expanding for EE) that still had the six or seven state checks which were summarised later as CD_STATE_NOTVALID. Just an anecdote off topic...

Yeah, and the difference is nothing, as you are still checking for the exact same stuff. In case you didn't notice.

 

Aka, this:

!StateCheck(Player2,0xf00)

Is the same exact thing as:

OR(4)
!StateCheck(Player2,0x100)
!StateCheck(Player2,0x200)
!StateCheck(Player2,0x400)
!StateCheck(Player2,0x800)

The only benefit is that it might be a little more clear to the eye of the beholder... the computer does the exact same checks in BOTH cases.

Edited by Jarno Mikkola
Link to comment

Aka, this:

!StateCheck(Player2,0xf00)
Is the same exact thing as:

OR(4)
!StateCheck(Player2,0x100)
!StateCheck(Player2,0x200)
!StateCheck(Player2,0x400)
!StateCheck(Player2,0x800)
The only benefit is that it might be a little more clear to the eye of the beholder... the computer does the exact same checks in BOTH cases.

 

There actually is one advantage: the former will work with older versions of IE that do not implement OR(), like the original BG1 and PST. (IWD1 does have it.)

Link to comment

Less number of triggers also mean less CPU cycle requirements. Your laptop or tablet will spare more battery, and you can't fry eggs on your PC ...

Are you sure that's the case, withing the game's processes ?

Cause the f = 8 + 4 + 2 + 1, aka the exact same thing.

Edited by Jarno Mikkola
Link to comment

 

Less number of triggers also mean less CPU cycle requirements. Your laptop or tablet will spare more battery, and you can't fry eggs on your PC ...

Are you sure that's the case, withing the game's processes ?

Cause the f = 8 + 4 + 2 + 1, aka the exact same thing.

 

 

Yeah, as Ardanis said above. Processing a trigger takes a lot of operations. The engine is quite complex inside. And, these triggers are evaluated frequently.

Jarno: evaluating those triggers takes about 5x the time than evaluating the combined trigger.

Link to comment
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...