11 replies to this topic

[Idobek]

I am adding a few new kits and would like to make them compatible with at least 3 other mods that modify weapprof.2da. Currently to do this I would have to prepare multiple ADD_KITs and, after determining which mods were installed, only install one.

For example, I add a thief kit so I have an ADD_KIT for a vanilla game. Ashes of Embers Universal Weapons component would not support my kit so I have a separate ADD_KIT for vanilla plus AoE. The IKTweak (soon to be G3Tweaks) component Weapon Styles for All also modifies this file so I have an ADD_KIT for vanilla plus WSfA and vanilla plus AoE plus WSfA. That is for separate ADD_KITs, only one of which would be installed. This is not hard to do but it is hard to maintain, if I want to change an aspect of one of the kits I have 4 ADD_KITs (maybe more) to update.

Now, if I knew the column in weapprof.2da that the kit was using I could simply use some SET_2DA_ENTRYs to update that file. I would like a

READ_KIT_PROFICIENCY ~KITNAME~ "value"

command. I would then be able to use the value to update weapprof.2da.

A more universal command would be:

READ_2DA_ENTRY ~COLUMNNAME~ ~ROWNAME~ "value"

This would be useful for changing 2DA entries relative to their current value, instead of having to set them arbitrarily.

[weimer]

I'm afraid that I don't understand this at all. Why do you need different ADD_KITs? How do those mods change weapprof.2da?

I can certainly add READ_2DA_ENTRY, but you'll have to know what to do with it, because I'm not firm on this issue.

[weimer]

READ_2DA_ENTRY added (works just like SET_2DA_ENTRY, same args, final arg is a variable name). Maybe you can write a tutorial explaining why you want it. :-)

[CamDawg]

I think it's for an inter-mod compatibility issue. Rogue rebalancing gives thieves 3 stars in DW; Ashes of Embers allows clerics stars in edged weapons, universal clubs allows extra stars in clubs, weapon styles for all (does what it says ), etc. Let's say you wanted to make a kit that would reflect the changes introduced by other mods.

Rather than a series of nested ACTION_IFs to determine the appropriate ADD_KIT (with a different weapprof line for each), it would be easier to use a single ADD_KIT and then use ACTION_IF and SET_2DA_ENTRY on weapprof.2da. Since kits move around based on mod install order, though, you an not reliably use S_2_E as the row/column (depending on the 2da) are not consistent on a player's installation.

READ_2DA_ENTRY is a very handy addition. Thanks Wes!

[Idobek]

What he said. In future I think I'll explain what I want to Cam and get him to post the request.

[Idobek]

Could READ_2DA_ENTRY set some variables a la COPY? So when I do this:

COPY_EXISTING ~xpcap.2da~ ~override/xpcap.2da~
READ_2DA_ENTRY 7 0 2 ~ikvariable~

I end up with 3 variables set:
1: ikvariable = RANGER
2: number_rows = 23
3: number_columns = 2

(This is probably not a good example, because the read variable is a string not a value, and I can't think of a reason for wanting to read anything in this file, but hopefully you get the idea )

The "number_rows" would be the total number of rows in the file, the "number_columns" variable would be the total number of columns in the file. As we now know the number of columns and rows in the file we can edit anything within it. Before we were limited to editing the vanilla data only because we simply wouldn't know where in the file the new data was.

It would also solve my issues with kit addition as I would know that my kit was in the last column of weapprof.2da and would now know how many columns there were.

*Idobek goes off to find Cam to make sure this post made sense.

[Scar]

A useful addition indeed, it ties right in with the recent improvement of S_2_E. I can see some uses already. Thanks, Wes!

@Cam: might I suggest you use that for modifying the spell progression tables in Cleric Remix. By using something like:

R_2_E "spells"
"spells" ++
S_2_E "spells"

encased in some while loops, you can react on previous modifications, like Bluchers high level tables.

[Scar]

I end up with 3 variables set:
1: ikvariable = RANGER
2: number_rows = 23
3: number_columns = 2

Well, maybe Scar can help...
I think I get it. You need an instruction that returns the maximum number of rows and columns, since you don't know the actual dimensions of the tables you're working with - additional rows or columns might have been added. Once you know the boundaries, you can reference anything within.

It would also solve my issues with kit addition as I would know that my kit was in the last column of weapprof.2da and would now know how many columns there were.

Can you be sure that the kit you're looking for is the last one? ... Well, I guess you can, since you added it yourself. Otherwise you'd need a while loop reading the captions (RANGER, CLERIC, etc.) one by one, until it finds the one you're looking for... then the "running variable" would point to the right column.

[CamDawg]

I was thinking of just running the R_2_E in a while loop as it cycles through the column/row headers until you could get a match. Have it start at row/column zero and move to the right/down. Once it found a match it would kill the WHILE loop. That way the max table size isn't needed.

@Scar
Thanks, I was planning on doing this for the next build.

[Idobek]

For the my kit adding issue I can write a WHILE loop, but there are other reasons for knowing the max table size. For example, my Weapon Styles for All, AoE's Universal Weapons & EoU's Multi-Class Grand Mastery could affect all kits in the table not just the vanilla kits.

[Littiz]

It is a great addition indeed, thanx Wes!
Yet:

Since kits move around based on mod install order, though, you an not reliably use S_2_E as the row/column (depending on the 2da) are not consistent on a player's installation.

...this seems the core problem for me to use it.

[Scar]

...this seems the core problem for me to use it. 

That's easy (tho not tested, due to the lack of WeiDU v155):

SET "col" = 0
SET "cap" = ~dummy~
WHILE NOT ("%cap%" = ~RANGER~) BEGIN
  SET "col" = ("%col%" + 1)
  READ_2DA_ENTRY 0 "%col%" 3 "cap"
END

As soon as it reads RANGER from the table's titles, the loop exits and "col" holds the coordinate you need. Well, some error handling would be neccessary in case RANGER is not in the table.

The real question is, what would happen if above loop would run out of the boundaries of the table and read an 'empty' value? If it'd be a defined value for end-of-line, you could check for that and use the loop to determine a table's dimensions as well as error handling.

EDIT: Damnit, I knew there had to be a catch... I thougth I did something like this

WHILE NOT ("%cap%" = ~RANGER~) BEGIN

before, but apperantly I didn't. I was just toying around, and it seems to me that WeiDU can't compare a variable (filled with READ_ASCII) with a string. It chokes with:

ERROR: [ar0907.are] -> [override] Patching Failed (COPY) (Failure("int_of_string"))

Here's the code I played with, if someone else wants to try:

COPY_EXISTING ~ar0907.are~ ~override~
    READ_LONG 0x5C "infooffset"     // Where to find info points?
    READ_SHORT 0x5A "infocount"     // How many info points are there?
    WHILE "%infocount%" BEGIN
        SET "infocount" = ("%infocount%" - 1)
        READ_ASCII ("%infooffset%" + "%infocount%" * 0xC4) "infoname"   // What's this point called?
        WHILE ("%infoname%" = ~Trigger Point 3~) BEGIN
            WRITE_SHORT ("%infooffset%" + "%infocount%" * 0xC4 + 0x20) 2
        END
    END