[BG2:ToB] - Some SPECIFIC.IDS notes

[aVENGER_(RR)]

It seems that there are still some uncertainties about the function of SPECIFIC.IDS and the specifics field located at 0x274 in CRE files. I thought it might be useful to pool some of the common knowledge about these things in one place. Here's what I've got so far.

 

Although the SPECIFIC.IDS file in BG2 originally contains only 3 values, many more entries are actually used in-game. Nearly all CRE files in BG2 have a specifics value assigned to them. This was apparently done by the developers in order to mark certain creatures as parts of a larger group (a team if you will). In practice, having the same specifics value enables creatures to utilize NearestMyGroupOfType() and its other iterations as script objects and thereby interact with their teammates. Here's an example from GPARCHER.BCS:

 

 

IF
See(NearestEnemyOf(Myself))
OR(2)
	Range(NearestMyGroupOfType,20)
	See(NearestMyGroupOfType([0.0.0.CLERIC_ALL]))
HPPercentLT(Myself,35)
!GlobalTimerNotExpired("CalledForHealing","LOCALS")
THEN
RESPONSE #100
	SetGlobalTimer("CalledForHealing","LOCALS",6)
	DisplayStringHead(Myself,72808) // I need healing!
	Shout(HEALME)
	Continue()
END

 

 

 

And here's the appropriate response from GPHEALER.BCS:

 

 

IF
Heard(NearestMyGroupOfType,HEALME)
!HPPercentLT(Myself,35)
!StateCheck(LastHeardBy(Myself),STATE_DEAD)
Global("OnWayToHeal","LOCALS",0)
HaveSpell(CLERIC_HEAL)
THEN
RESPONSE #100
	SetGlobal("OnWayToHeal","LOCALS",1)
	SetInterrupt(FALSE)
	Spell(LastHeardBy(Myself),CLERIC_HEAL)
	SetInterrupt(TRUE)
END

 

 

Interestingly, according to my testing, it isn't necessary for creatures to have the same EA value in order to be in the same group. Simply having the same specifics value is enough. Oddly, this means that GOODCUTOFF (green circle) and EVILCUTOFF (red circle) creatures can be in the same group as long as their specifics values are the same. Also, you can check a creature's specifics value using the Specifics() trigger and set it using the ChangeSpecifics() action.

 

 

 

P.S.

 

devSin, if you're around, feel free to jump in and add some stuff in case I missed anything.

[devSin]

I had a write-up that specifics is also group (see also InMyGroup(), but GroupOf is unrelated IIRC) somewhere around here. I believe you can do spec checks, but I believe the object disregards any EA you try to pass it (like NearestEnemyOfType, which also discards the EA you use and figures out itself if a matching object should be an enemy of the caller). Which is, of course, dumb because it doesn't actually do any EA checking, so you end up with the inability to ever specify the EA of the group member you want to find (but with IE, what else did you expect?).

 

It wasted like an afternoon or two for me to find and fix CRE groups and make sure that everyone who used scripts with the code had a nonzero group. I'm not eager to dredge up those memories, so no other new input from me.

[aVENGER_(RR)]

I had a write-up that specifics is also group (see also InMyGroup(), but GroupOf is unrelated IIRC) somewhere around here. I believe you can do spec checks, but I believe the object disregards any EA you try to pass it (like NearestEnemyOfType, which also discards the EA you use and figures out itself if a matching object should be an enemy of the caller). Which is, of course, dumb because it doesn't actually do any EA checking, so you end up with the inability to ever specify the EA of the group member you want to find (but with IE, what else did you expect?).

 

Yup, I've found this in my tests as well. So, for the record, the current IESDP entry for the InMyGroup() trigger and the NearestMyGroupOfType() object is incorrect. In essence, both simply use a specifics check while completely disregarding the target's EA value. I'm also thinking that the GroupAttack() action may instruct the script runner to attack members of the same group as the specified target but I'm not really sure about it.

 

Also, this should be public knowledge but I'll put it up here too, for completeness sake. A specific value doesn't have to be written in SPECIFIC.IDS in order to work properly in scripts and EFF targeting. This is similar to how shouts function with regards to SHOUTIDS.IDS (which BTW is the lamest filename ever).

 

It wasted like an afternoon or two for me to find and fix CRE groups and make sure that everyone who used scripts with the code had a nonzero group. I'm not eager to dredge up those memories, so no other new input from me

 

Yeah, I think group mismatches may have been causing some weird issues with Suldanesselar elves back in the old days, but I believe the fixpack took care of that one way or the other.

[aVENGER_(RR)]

I'm also thinking that the GroupAttack() action may instruct the script runner to attack members of the same group as the specified target but I'm not really sure about it.

 

Confirmed via in-game testing. Deactivate the party AI and then assign this script to a party member:

 

IF
Global("RR#GRATK","LOCALS",0)
THEN
RESPONSE #100
	SetGlobal("RR#GRATK","LOCALS",1)
	GroupAttack(NearestEnemyOf(Myself))
END

 

After that, spawn several creatures with the same specifics value near the PC and one with a different specific value a bit further away. For my test, I spawned three copies of SLGUARD1.CRE (specifics = 201) and one copy of RETHUG01.CRE (specifics = 66). Now activate the party AI. With the aforementioned script in place, the PC will attack the nearest SLGUARD1.CRE and then proceed to engage its other two copies. After that, he will ignore RETHUG01.CRE even though he is the only enemy remaining.

 

For comparison, if you substitute GroupAttack(NearestEnemyOf(Myself)) with just Attack(NearestEnemyOf(Myself)) and re-create the same situation, the PC will only kill one copy of SLGUARD1.CRE and then stop attacking.

[igi]

Local copy updated, thanks.