Jump to content

Appending STATE.IDS with new entries


aVENGER_(RR)

Recommended Posts

I've noticed that several mods add new entries to this file, mainly in order to improve script efficiency, so I wanted to do the same for Rogue Rebalancing. A few questions:

 

 

1) As I understand it, a new state must be a valid combination of some of the existing states. How exactly are these values combined?

 

2) What happens if two mods add the same entry but with different names? For example, the Big Picture mod adds a state called STATE_NOT_VISIBLE and Sword Coast Strategems adds STATE_NOT_TARGETTABLE which seem to to the same thing (0x400010).

 

3) What exactly is the difference between STATE_REALLY_DEAD (added by the BG2 Fixpack) and the regular Dead() trigger? Also, is there an in-depth explanation of the functions of all the new states?

 

4) Does a standardized list of new states exist somewhere? I'd really prefer not to clutter STATE.IDS with my custom state names. For now, I'm planning to include the entries mentioned in the IESDP entry for STATE.IDS but I was wondering if there were other commonly used states as well?

Link to comment
' date='Sep 11 2007, 02:31 AM' post='97518']

1) As I understand it, a new state must be a valid combination of some of the existing states. How exactly are these values combined?

You add the values; the new state returns true if any of those conditions are met. StateCheck(Myself,STATE_REALLY_DEAD) returns true if any of the values combined to create it are true--I think NI reflects this in it's scripts by displaying it as something like StateCheck(Myself,STATE_ACID_DEATH | STATE_FLAME_DEATH | etc)

 

' date='Sep 11 2007, 02:31 AM' post='97518']

2) What happens if two mods add the same entry but with different names? For example, the Big Picture mod adds a state called STATE_NOT_VISIBLE and Sword Coast Strategems adds STATE_NOT_TARGETTABLE which seem to to the same thing (0x400010).

Scripts or dialogues with either trigger will compile and work; when decompiled they'll probably preferentially use one or the other, i.e. I think WeiDU will use the last symbolic entry when decompiling.

 

' date='Sep 11 2007, 02:31 AM' post='97518']3) What exactly is the difference between STATE_REALLY_DEAD (added by the BG2 Fixpack) and the regular Dead() trigger? Also, is there an in-depth explanation of the functions of all the new states?

Dead() can only check death variables; Dead(Myself) is not valid. As Avenger mentions, Dead("foo") actually checks the global variable SPRITE_IS_DEADfoo. Fixpack added STATE_REALLY_DEAD so that we could swap all of the invalid Dead(Myself) checks easily to StateChecks without loss of functionality.

 

' date='Sep 11 2007, 02:31 AM' post='97518']4) Does a standardized list of new states exist somewhere? I'd really prefer not to clutter STATE.IDS with my custom state names. For now, I'm planning to include the entries mentioned in the IESDP entry for STATE.IDS but I was wondering if there were other commonly used states as well?

Outside of STATE_REALLY_DEAD, you'll probably also see a lot of CD_STATE_NOTVALID (0x80101FEF). Though it bears my prefix, it's better attributed to Max, who used the idea first (for DLTC, I think). The basic idea is to replace the broken IsValidForPartDialogue("foo") with a !StateCheck("foo",CD_STATE_NOTVALID) to check for dialogue availability.

 

You'll typically see code like

 

APPEND ~STATE.IDS~ ~0x80101FEF CD_STATE_NOTVALID~ UNLESS ~CD_STATE_NOTVALID~

 

to prevent multiple entries.

Link to comment
You add the values; the new state returns true if any of those conditions are met. StateCheck(Myself,STATE_REALLY_DEAD) returns true if any of the values combined to create it are true--I think NI reflects this in it's scripts by displaying it as something like StateCheck(Myself,STATE_ACID_DEATH | STATE_FLAME_DEATH | etc)

 

Ahh, it's simple hex addition then. So, the combination of STATE_MIRRORIMAGE + STATE_BLUR + STATE_IMPROVEDINVISIBILITY would be 0x60400000 right?

 

Dead() can only check death variables; Dead(Myself) is not valid. As Avenger mentions, Dead("foo") actually checks the global variable SPRITE_IS_DEADfoo. Fixpack added STATE_REALLY_DEAD so that we could swap all of the invalid Dead(Myself) checks easily to StateChecks without loss of functionality.

 

Ok, but they basically work the same for creatures with designated death variables, right? For example, are Dead("aran") and StateCheck("aran",STATE_REALLY_DEAD) the same thing?

 

Outside of STATE_REALLY_DEAD, you'll probably also see a lot of CD_STATE_NOTVALID (0x80101FEF). Though it bears my prefix, it's better attributed to Max, who used the idea first (for DLTC, I think). The basic idea is to replace the broken IsValidForPartDialogue("foo") with a !StateCheck("foo",CD_STATE_NOTVALID) to check for dialogue availability.

 

Thanks for the clarification. I remember reading about the IsValidForPartDialogue() wackiness somewhere. Something about the trigger failing due to a partially blocked line of sight and such. I guess I'll use CD_STATE_NOTVALID then.

Link to comment
Ahh, it's simple hex addition then. So, the combination of STATE_MIRRORIMAGE + STATE_BLUR + STATE_IMPROVEDINVISIBILITY would be 0x60400000 right?
Ok, but they basically work the same for creatures with designated death variables, right? For example, are Dead("aran") and StateCheck("aran",STATE_REALLY_DEAD) the same thing?

Yes on both counts.

 

Thanks for the clarification. I remember reading about the IsValidForPartDialogue() wackiness somewhere. Something about the trigger failing due to a partially blocked line of sight and such. I guess I'll use CD_STATE_NOTVALID then.

It fails on LOS issues and also, IIRC, it returns false for the character (gabber) involved in dialogue. I recall having Yoshimo initiate dialogue with Irenicus at Spellhold, and having Irenicus comment that Yoshimo wasn't present.

Link to comment
Ok, but they basically work the same for creatures with designated death variables, right? For example, are Dead("aran") and StateCheck("aran",STATE_REALLY_DEAD) the same thing?
Yes, except that you can only StateCheck() an active object. Aran would have to always be in the area where you expected STATE_REALLY_DEAD to be true. (In most cases, it's used where you'd want to do Dead(Myself) or something to keep from running ApplySpell() or DisplayString() or whatever on dead actors.)

 

Thanks for the clarification. I remember reading about the IsValidForPartDialogue() wackiness somewhere. Something about the trigger failing due to a partially blocked line of sight and such. I guess I'll use CD_STATE_NOTVALID then.
Like Cam says, it also returns false if IsGabber(), but there shouldn't be any range or sight issues (if it's not true, then See() !IsGabber() !Dead() !StateCheck() wouldn't be true either).

 

Note that the engine doesn't need the symbol for anything. You can use 0x60400000 (1614807040) in your script and dialogue code and not have to mess with the IDS files at all. Also, be sure not to add duplicate entries for the single-bit values if you use NI.

Link to comment
Also, be sure not to add duplicate entries for the single-bit values if you use NI.

 

You mean entries like 0x4 STATE_PANIC and such? I don't think I'll duplicate any of those. Basically, I just want to make a few scripting shortcuts similar to STATE_OUT_OF_ACTION but without the charmed bit since I treat charmed opponents differently in RR.

Link to comment
' date='Sep 11 2007, 11:42 PM' post='97632']You mean entries like 0x4 STATE_PANIC and such? I don't think I'll duplicate any of those. Basically, I just want to make a few scripting shortcuts similar to STATE_OUT_OF_ACTION but without the charmed bit since I treat charmed opponents differently in RR.
Yeah, any of the default ones (all individual bits are already labeled in a default STATES.IDS). Near Infinity builds its checkbox pane using the IDS, but it can't handle multiple symbols for a single bit, so in the case of STATES, you'd break CRE loading (viewing and editing).
Link to comment

Archived

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

×
×
  • Create New...