FredSRichardson Posted August 14, 2007 Share Posted August 14, 2007 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
FredSRichardson Posted August 14, 2007 Author Share Posted August 14, 2007 Actually, it looks like "ignore_can_see = 1" is the only parameter that I need to add for the IWD1 INI files to work in IWD2. Link to comment
Avenger Posted August 14, 2007 Share Posted August 14, 2007 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
Avenger Posted August 14, 2007 Share Posted August 14, 2007 ok, ignore_no_see is not existant, it is ignore_can_see as you wrote. Link to comment
FredSRichardson Posted August 14, 2007 Author Share Posted August 14, 2007 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
FredSRichardson Posted August 14, 2007 Author Share Posted August 14, 2007 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
Avenger Posted August 15, 2007 Share Posted August 15, 2007 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
FredSRichardson Posted August 15, 2007 Author Share Posted August 15, 2007 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
devSin Posted August 15, 2007 Share Posted August 15, 2007 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
Avenger Posted August 15, 2007 Share Posted August 15, 2007 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
FredSRichardson Posted August 16, 2007 Author Share Posted August 16, 2007 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! ). 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
Avenger Posted August 16, 2007 Share Posted August 16, 2007 script_name is of course not a script slot name, but the scripting name field (death variable for weidu ninjas) What i need the most is an iwd1-->iwd2 script slot mapping. Link to comment
FredSRichardson Posted August 16, 2007 Author Share Posted August 16, 2007 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
Avenger Posted August 16, 2007 Share Posted August 16, 2007 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
Avenger Posted August 16, 2007 Share Posted August 16, 2007 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
Recommended Posts
Archived
This topic is now archived and is closed to further replies.