argent77

Yes, no entries at all. All you can do is go back and select another kit that works. As I said, in theory your idea should work since it only permutes existing rows. But you don't know if mods installed afterwards might get confused because of the mismatching row number / kitids values. There could also be other side effects that we haven't yet noticed.

After more testing it looks like KITIDS values don't have to correspond to the kitlist row number as long as a valid kit entry with the row number equal to the lowest order byte value of KITIDS exists. Otherwise character creation fails to list available alignment entries for the selected kit. So in theory sorting the kitlist table works without unwanted side effects, but it would be a rather fragile solution.

I think the KITIDS column in kitlist.2da must correspond to the row number, but I have to do some more tests to be certain. A quick test showed that character creation can't be completed if row number and the lowest order byte of the KITIDS value are different. Exceptions are specialist mages and the barbarian kit. If KITIDS is indeed linked to the kitlist row number then you'd have to update a lot of game resources.

If you rearrange kit entries in kitlist.2da you might also have to update kit references in game scripts and effect opcodes, maybe even references in saved games (if you're thorough).

You can fake it by using the non-breaking space (U+00A0). It doesn't count as column separator in 2da files. Typing a non-breaking space can be tricky. On Windows the keyboard shortcut Alt+255 (digits entered on the numeric keypad) might work.

This definition doesn't work as intended: ACTION_DEFINE_ASSOCIATIVE_ARRAY response_strrefs BEGIN %63960% => 1 %65051% => 1 %70436% => 1 END The percent sign is, along with tilde (~) and quotation mark ("), one of several options to enclose strings. The percent sign is special as it has a double meaning depending on context. It can be used to enclose strings as well as evaluate variables inside strings. So in this example you're just using the literal number 63960 as the array index since the percent signs aren't placed inside a string. This code should work as i

There is no need to call ADD_TRANS_TRIGGER multiple times for the same state. All responses that should be updated are listed in the variable following the DO keyword. For example, this code ADD_TRANS_TRIGGER ARAN 39 ~Global("C#IM_ImoenStays","GLOBAL",0)~ DO %responses_39% will be resolved as ADD_TRANS_TRIGGER ARAN 39 ~Global("C#IM_ImoenStays","GLOBAL",0)~ DO 1 3 if the code structure from your earlier comment found matching strrefs in response entries 1 and 3. This .d command will then add the trigger "Global("C#IM_ImoenStays","GLOBAL",0)" to both response entries in one go

That example code (together with the function GET_RESPONSE_STRREFS I posted in an earlier comment) should work fine with multiple responses in individual states. Have you encountered any problems?

What exactly fails? Should only one of the two responses be patched? I think that could be solved with an UNLESS or IF condition.

Near Infinity (or short: NI) is an open source cross-platform browser and editor, based on Java, for resources of Infinity Engine games. This version provides a couple of nifty features such as filtered list items, launching games directly from NI or improved loading times. You can grab the latest release from the download link below. Links: Discussion: SHS, Beamdog Download Documentation

It should be supported by all EE games since patch 2.0. There are several instances in Beamdog NPC-specific maps in BG2:EE as well.

Add PRETTY_PRINT_2DA after you're done modifying the 2DA file.

Congratulations from me too! Looks like GemRB is even (slightly) older than Near Infinity.

In case there are no matching response indices found the variable will be empty and the whole expression evaluates to ADD_TRANS_TRIGGER ARAN 39 ~Global("C#IM_ImoenStays","GLOBAL",0)~ DO This is a valid expression, but results in the script trigger added to all available responses found in state 39 (according to WeiDU docs). One way to solve it is by adding an IF condition to the ADD_TRANS_TRIGGER that never evaluates to "true". For example: ADD_TRANS_TRIGGER ARAN 39 ~Global("C#IM_ImoenStays","GLOBAL",0)~ DO IF ~a_nonexisting_trigger()~ That can be realized by adding this cod

This is an example how the whole dialog could be processed in one go. Current implementation requires that all variables contain at least one index or WeiDU will update all available responses of a state. That could be solved by adding a dActionWhen condition that is guaranteed to fail.