[35.6] NPC customization trimming of kits

[Connelly]

NPC customization trims the CLAB files of kits. As examples, I have the unmodded vanilla CLABPR01, and QDMAGUS from Tome & Blood's Magus, both after and before NPC custom gets installed. I couldn't get change-log to show them to me so I had to take the weidu backups and overrides copies manually. And in the weidu log you can see I've only installed Tome & Blood's Magus kit and SCS's Improved NPC customization.

CLABPR01_01_default: This is the unmodded 2da exported directly from the game with NearInfinity before any mod, with six ABILITYN rows and a single AP_CDHLYSYM entry in the first row 25th column.

CLABPR01_02_SCS: With NPC Customization, the six ABILITYN rows have been trimmed to two, although AP_CDHLYSYM remains in place. No particular damage seems apparent.

QDMAGUS_01_base: The basic file that exists in the T&B folder. Instead of ABILITYN rows, it has one MAGUS row, and two ANIMS_N rows.

QDMAGUS_02_installed: I assume the same base file but changed at the time of installation for whatever reason. It adds four ARMCAST rows.

QDMAGUS_03_SCS: With NPC Customization, the entire table goes away.

WeiDU.log SCS NPC custom trim examples.zip

Edited January 10 by Connelly

[jmerry]

With CLABPR01, it looks like the logic here trims any ABILITYN rows that don't have any ability entries. Which is harmless. Or at least, it's harmless as long as there's at least one ability row left (Have you checked CLABFI01 or CLABMA01? Those don't have any abilities at all). But at the same time ... is there any positive reason to do so? The only way trimming rows might matter is if you needed to make room, and I don't think there's a maximum number of rows in the format.

With QDMAGUS, it's the already known issue with the table parser not recognizing rows that don't have the ABILITYN label. That will be fixed.

[DavidW]

OK, good: that's all as expected. (i.e. it contains the compatibility issues I'm aware of but no new ones.)

12 hours ago, jmerry said:

With CLABPR01, it looks like the logic here trims any ABILITYN rows that don't have any ability entries. Which is harmless. Or at least, it's harmless as long as there's at least one ability row left (Have you checked CLABFI01 or CLABMA01? Those don't have any abilities at all). But at the same time ... is there any positive reason to do so?

The way SCS / ToF tends to work is that a 2da gets read into a data structure, the data structure is modified, and then the data structure gets written back out. The data structure I define pays attention to how many abilities you have at each level and what order they appear in, but not to exactly where they are in the file, so that information isn't preserved when it gets written back out. (This is related to things like: I want to be able to say 'add these powers at these levels' without having to stipulate which actual row they should appear in.)

However, this seems to be causing enough confusion that I'm minded to make the structure a bit more deferential to actual ability placement.