Jump to content

IWD1/2 INI Files


Recommended Posts

These are a bit mysterious to me. It looks like a lot of features were added in IWD2. What I've found is that the IWD1 INI files aren't "forward compatible" in IWD2 and some default fields need to be added. I think (but I'm not sure) that the ones I need to add are "spec_var_value" and "spec_var_operation", but "ignore_can_see" may also need to be there.

 

Here's a typical IWD1 entry:

[Shadow12]
spec					= [255.0.0.0.161]
spec_qty				= 1
spec_var				= VALE_OF_SHADOWS_SPAWN
cre_file				= vsShadow
create_qty			  = 1
script_Default		  = gnMMgSG
ai_specifics		  = 161
spawn_point			 = [1706.0372:0]

 

and here's the converted IWD2 entry that seems to work:

[Shadow12]
spec					= [255.0.0.0.161]
spec_qty				= 1
spec_var				= vale_of_shadows_spawn
spec_var_value		  = 1
spec_var_operation	  = equal_to
cre_file				= _SSHADOW
create_qty			  = 1
ignore_can_see		  = 1
script_Default		  = _GNMMGSG
ai_specifics		  = 161
spawn_point			 = [1706.0372:0]

 

I think the "spec_var_value" and "spec_var_operation" are really just explicit parameters for the spawn trigger, something like:

 

if (spec_var spec_var_operation spec_var_value) then {
spawn cre_file
}

 

IWD2 has a bunch of other fancy features like "spec_var_inc" which causes the "spec_var" to be modified by the specified amount when the spawn is triggered. That's used for the fancy shaman drummer spawns.

Link to comment

So, if there is no spec_var_operation, then it will simply use the spec_var as a true/false value.

 

In GemRB i've implemented these tags so far (mainly from pst).

 

spec

spec_var

spec_qty

create_qty

cre_file

point_select

spawn_point

spawn_point_global

facing

ai_* - IDS values

script_* - AI script slots

dialog

death_scriptname

ignore_no_see

 

What else you found?

 

[edit]

All details are interesting, for example, the exact resource (DLTCEP can't really search spawn .ini files, yet).

I welcome any clarification how the tags work.

This includes the tags you or I already mentioned.

Link to comment

Here's what I have for IWD1, things a little different in IWD2 (I'll post that later).

 

There are some odd anomalies, like the wailing virgins don't use a spec_var which probably means they're spawned right away, and the thieves that attack in Dorn's Deep are unusual in general. The list here is somewhat by order of occurrence. These are only the fields used together with the "cre_file" field.

 

cre_file			ResRef for CRE to spawn
ai_specifics		### 3-digit number, unique within area
spec				[255.0.0.0.<ai_specifics>]
spawn_point		 [XXXX.YYYY:FACE] or [XXXX.YYYY] Position (and facing) of spawns (IESDP)
spec_var			Variable which triggers spawns
spec_qty			 Always 1 when present
create_qty		   Always 1 when present
ignore_can_see	  . Always 1 when present

script_area		 BCS script to use in ? slot.
script_default	  BCS script to use in "default" slot.
script_specifics	BCS script to use in ? slot.
script_override	 BCS script to use in override slot.
script_general	  BCS script to use in general slot.
script_class		BCS script to use in class slot.
script_race		 BCS script to use in race slot.

check_view_port	 .  Always 0 when present

script_name		 .  A string. Only used in AR8001.INI
				This appears to be the same as the name field
				for the Actor.  "spec" uses the same string value
				when script_name is specified.  Very odd.
				"ai_specifics" are dropped when this is present.

point_select		. Always R when present.  Only used in AR6006.INI

Link to comment

Hmm, now I'm not so sure that the IWD1 INI's weren't working without changing them. It looks like the CRE's are moving around whereas in IWD1 they'd just stay put. I'll have to run a few more tests. I'm pretty sure their scripts are the same.

 

EDIT: Okay, I guess I don't know what's going on. The INI files seem to work as they are. It might be that the CRE's are moving around.

Link to comment

Great list!

 

I'll try to make one for PST, as it is the first engine this stuff appeared, and even IWD2 contains strings like 'lady_mod', which came straight from PST.

In the .exe you will see about twice as many keywords as they really use.

Though I doubt many modders will mod spawn ini files, i'll try to implement as many as possible. This .ini file seems a cheap (in computing time) replacement for spawn scripts, yet, it is functionally better than the faulty area spawn headers.

Link to comment

Yes, I was thinking that the INI would be a great modding resource. Very easy to add new encounters and trigger them from the ARE script.

 

What I summarized above was only for the INI records that contain the "cre_file" field. I haven't looked to see if the other types of headers are any different.

 

SOUNDS.INI is a real mystery to me. Any idea how this works? I noticed that there are sound files associated with each record. For example, the Carrion Crawler is stored in the record "[MCAR]" and there are a bunch of fields which I think specify sounds for different actions. In the CHITIN.KEY there are files like MCARA1.ave (I can't remember the file name and extension, I'll have to edit this later). What I can't figure out is what glues the entry in SOUNDS.INI to the CRE file.

 

Fortunately for me, the SOUNDS.INI file in IWD2 is almost exactly a superset of the same file in IWD1 (it's missing something like an Elite Goblin Archer). The IWD2 version of the file looks like it adds a bunch of stuff.

Link to comment
SOUNDS.INI is a real mystery to me. Any idea how this works? I noticed that there are sound files associated with each record. For example, the Carrion Crawler is stored in the record "[MCAR]" and there are a bunch of fields which I think specify sounds for different actions. In the CHITIN.KEY there are files like MCARA1.ave (I can't remember the file name and extension, I'll have to edit this later). What I can't figure out is what glues the entry in SOUNDS.INI to the CRE file.
Sequence sounds. The file lists an animation tag, the available sequences (not all sequences are always used, and some are probably never used), the sound resource to play for the sequence, and the frame where the sound should be started. Multiple resources forces the engine to choose randomly from the available sounds; an empty resource is just as likely to be chosen, keeping a sound from playing every single time the ATTACK_SLASH (or whatever) animation fires (which would be supra-annoying).

 

BioWare copied the feature for BG2 (in BG, the sounds had to be specified in the CRE file for each and every CRE), but rather than an ugly hack, they utilized the 2DA handling that already existed. In BG2, the sequence sounds get random pitch changes (the same as accomplished by its WFX files), but I don't know if this is true in ID2.

Link to comment

Animations are identified with the 4 character prefix, like MCAR.

Except in PST, where the 4 characters are not continuous, but in the form of X..XXX.

 

The various animation sequences belonging to the different stances may be contained in different .bam files (that was the extension you looked for), the different animation schemes contain different distribution of stances among these animation resources.

 

You can find these (usually) 4 character prefixes listed in animate.src (iwd2), or in anisnd.2da ( i think in bg2).

 

GemRB also adopted this thing, in avatars.2da

A sample line (in our .2da) is:

ANI_ID	  AT_1	   AT_2		  AT_3		 AT_4	   TYPE	   SPACE	  PALETTE
0x1001	 MWYV	   MWYV	   MWYV	   MWYV	   11		 5			 1

The type field tells gemrb which animation scheme is this, so it will know how to create the bam resref from the prefix. (This is how gemrb supports new animations)

Link to comment

It's been a while since I've checked out GemRB, I'll have to check it out some time soon (I've been using IESDP quite a bit lately to examine area layouts, very nice indeed! :D).

 

Here's my info for IWD2 INI fields that use the "cre_file" field:

 

These always occur together.  This looks like it might be a template:

cre_file				CRE file
spec_var				trigger variable 
spec_var_value		  trigger variable value
spec_var_operation	  trigger variable operator
spawn_point			 [XXXX.YYYY] spawn location, but can be a list!
spec_qty				Always 1
create_qty			  Always 1
ignore_can_see		  Always 1

These fields also occur when the cre_file field is specified:

spec					
ai_specifics			

spec_var_inc			Always -1 when present (probably resets trigger)
area_diff_1			 ? Always 0 when present
area_diff_2			 ? Always 0 when present
point_select			? Always R when present

script_name			 These are the CRE script slots
script_combat		   .
script_movement		 .
script_special_1		.
script_special_2		.
script_special_3		.
script_team			 .
script_override		 .

Link to comment

I've always found the script slots baffling. Do they just specify order of execution?

 

In that case, it would just be a matter of determining the order for the IWD1 and IWD2 slots and the mapping would be pretty straight forward. The odd part is that certain script slots come from the ARE Actor fields and some don't.

Link to comment

Yes, they get priority.

Override is the highest, and exists in all engines.

But the rest of the slots is not so clear.

IWD2 creature and area structures seem to contain more script slot fields too, despite there are 7 entries in both scrlev.2da (script level) files.

 

scrlev.2da is like this:

level	 iwd2			others
0		 override		override
1		 special_1	   area
2		 team			specifics  
3		 special_2	   -
4		 -			   class
5		 combat		  race
6		 special_3	   general
7		 movement		default

 

[edit]

 

Ok, luckily the mapping is quite sane, i made some testing, and it turns out the above table is useful, with one trivial change: special_2 == class.

So there are 7 script levels in both engines, with one empty slot which is either 3 or 4, but this doesn't really cause any difference.

Link to comment

AR5012.ini contains area_diff_3, so your statistics are not complete.

 

I believe area_diff_x = 0 means that the spawn doesn't occur at the given difficulty.

 

point_select = r means random selection from the listed spawn points.

point_select = s probably means single point (this is the default i think)

point_select = e means it will use spawn_point_global (save_spawn_point/facing can save another group's spawn location)

Link to comment

Archived

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

×
×
  • Create New...