Dan_P Posted January 9 Share Posted January 9 (edited) This is an issue I noticed when testing this mod with my own kits, which use ADD_KIT_EX to install. Some components of ToF are replacing the clab files for base classes, which can break multiclass kits installed before ToF. Specifically, the QD_MULTI lines are added by the ADD_KIT_EX/qd_multiclass functions, which are what most multiclass kits mods use. These are a row of QD_MC effects and are given from the base class clabs. These give the kit effects for mc kits (using kit-targeted EFFs). So obvious suggestion is to not touch these lines at all. Or if you have to overwrite the clab, please make sure to add back in the QD_MULTI lines if they were in the table to begin with, or if the relevant files are detected in the override. This will prevent breaking mc kits installed before ToF. These should have no effect on anything other than the specific kits being targeted. -- I've copied the relevant lines that would need to be added to each table: Spoiler Fighter (CLABFI01) QD_MULTI AP_QD_MCF01 AP_QD_MCF02 AP_QD_MCF03 AP_QD_MCF04 AP_QD_MCF05 AP_QD_MCF06 AP_QD_MCF07 AP_QD_MCF08 AP_QD_MCF09 AP_QD_MCF10 AP_QD_MCF11 AP_QD_MCF12 AP_QD_MCF13 AP_QD_MCF14 AP_QD_MCF15 AP_QD_MCF16 AP_QD_MCF17 AP_QD_MCF18 AP_QD_MCF19 AP_QD_MCF20 AP_QD_MCF21 AP_QD_MCF22 AP_QD_MCF23 AP_QD_MCF24 AP_QD_MCF25 AP_QD_MCF26 AP_QD_MCF27 AP_QD_MCF28 AP_QD_MCF29 AP_QD_MCF30 AP_QD_MCF31 AP_QD_MCF32 AP_QD_MCF33 AP_QD_MCF34 AP_QD_MCF35 AP_QD_MCF36 AP_QD_MCF37 AP_QD_MCF38 AP_QD_MCF39 AP_QD_MCF40 AP_QD_MCF41 AP_QD_MCF42 AP_QD_MCF43 AP_QD_MCF44 AP_QD_MCF45 AP_QD_MCF46 AP_QD_MCF47 AP_QD_MCF48 AP_QD_MCF49 AP_QD_MCF50 Thief (CLABTH01) QD_MULTI AP_QD_MCT01 AP_QD_MCT02 AP_QD_MCT03 AP_QD_MCT04 AP_QD_MCT05 AP_QD_MCT06 AP_QD_MCT07 AP_QD_MCT08 AP_QD_MCT09 AP_QD_MCT10 AP_QD_MCT11 AP_QD_MCT12 AP_QD_MCT13 AP_QD_MCT14 AP_QD_MCT15 AP_QD_MCT16 AP_QD_MCT17 AP_QD_MCT18 AP_QD_MCT19 AP_QD_MCT20 AP_QD_MCT21 AP_QD_MCT22 AP_QD_MCT23 AP_QD_MCT24 AP_QD_MCT25 AP_QD_MCT26 AP_QD_MCT27 AP_QD_MCT28 AP_QD_MCT29 AP_QD_MCT30 AP_QD_MCT31 AP_QD_MCT32 AP_QD_MCT33 AP_QD_MCT34 AP_QD_MCT35 AP_QD_MCT36 AP_QD_MCT37 AP_QD_MCT38 AP_QD_MCT39 AP_QD_MCT40 AP_QD_MCT41 AP_QD_MCT42 AP_QD_MCT43 AP_QD_MCT44 AP_QD_MCT45 AP_QD_MCT46 AP_QD_MCT47 AP_QD_MCT48 AP_QD_MCT49 AP_QD_MCT50 Mage (CLABMA01) QD_MULTI AP_QD_MCM01 AP_QD_MCM02 AP_QD_MCM03 AP_QD_MCM04 AP_QD_MCM05 AP_QD_MCM06 AP_QD_MCM07 AP_QD_MCM08 AP_QD_MCM09 AP_QD_MCM10 AP_QD_MCM11 AP_QD_MCM12 AP_QD_MCM13 AP_QD_MCM14 AP_QD_MCM15 AP_QD_MCM16 AP_QD_MCM17 AP_QD_MCM18 AP_QD_MCM19 AP_QD_MCM20 AP_QD_MCM21 AP_QD_MCM22 AP_QD_MCM23 AP_QD_MCM24 AP_QD_MCM25 AP_QD_MCM26 AP_QD_MCM27 AP_QD_MCM28 AP_QD_MCM29 AP_QD_MCM30 AP_QD_MCM31 AP_QD_MCM32 AP_QD_MCM33 AP_QD_MCM34 AP_QD_MCM35 AP_QD_MCM36 AP_QD_MCM37 AP_QD_MCM38 AP_QD_MCM39 AP_QD_MCM40 AP_QD_MCM41 AP_QD_MCM42 AP_QD_MCM43 AP_QD_MCM44 AP_QD_MCM45 AP_QD_MCM46 AP_QD_MCM47 AP_QD_MCM48 AP_QD_MCM49 AP_QD_MCM50 Cleric (CLABPR01) QD_MULTI AP_QD_MCP01 AP_QD_MCP02 AP_QD_MCP03 AP_QD_MCP04 AP_QD_MCP05 AP_QD_MCP06 AP_QD_MCP07 AP_QD_MCP08 AP_QD_MCP09 AP_QD_MCP10 AP_QD_MCP11 AP_QD_MCP12 AP_QD_MCP13 AP_QD_MCP14 AP_QD_MCP15 AP_QD_MCP16 AP_QD_MCP17 AP_QD_MCP18 AP_QD_MCP19 AP_QD_MCP20 AP_QD_MCP21 AP_QD_MCP22 AP_QD_MCP23 AP_QD_MCP24 AP_QD_MCP25 AP_QD_MCP26 AP_QD_MCP27 AP_QD_MCP28 AP_QD_MCP29 AP_QD_MCP30 AP_QD_MCP31 AP_QD_MCP32 AP_QD_MCP33 AP_QD_MCP34 AP_QD_MCP35 AP_QD_MCP36 AP_QD_MCP37 AP_QD_MCP38 AP_QD_MCP39 AP_QD_MCP40 AP_QD_MCP41 AP_QD_MCP42 AP_QD_MCP43 AP_QD_MCP44 AP_QD_MCP45 AP_QD_MCP46 AP_QD_MCP47 AP_QD_MCP48 AP_QD_MCP49 AP_QD_MCP50 Ranger (CLABRN01) QD_MULTI AP_QD_MCR01 AP_QD_MCR02 AP_QD_MCR03 AP_QD_MCR04 AP_QD_MCR05 AP_QD_MCR06 AP_QD_MCR07 AP_QD_MCR08 AP_QD_MCR09 AP_QD_MCR10 AP_QD_MCR11 AP_QD_MCR12 AP_QD_MCR13 AP_QD_MCR14 AP_QD_MCR15 AP_QD_MCR16 AP_QD_MCR17 AP_QD_MCR18 AP_QD_MCR19 AP_QD_MCR20 AP_QD_MCR21 AP_QD_MCR22 AP_QD_MCR23 AP_QD_MCR24 AP_QD_MCR25 AP_QD_MCR26 AP_QD_MCR27 AP_QD_MCR28 AP_QD_MCR29 AP_QD_MCR30 AP_QD_MCR31 AP_QD_MCR32 AP_QD_MCR33 AP_QD_MCR34 AP_QD_MCR35 AP_QD_MCR36 AP_QD_MCR37 AP_QD_MCR38 AP_QD_MCR39 AP_QD_MCR40 AP_QD_MCR41 AP_QD_MCR42 AP_QD_MCR43 AP_QD_MCR44 AP_QD_MCR45 AP_QD_MCR46 AP_QD_MCR47 AP_QD_MCR48 AP_QD_MCR49 AP_QD_MCR50 Druid (CLABDR01) QD_MULTI AP_QD_MCD01 AP_QD_MCD02 AP_QD_MCD03 AP_QD_MCD04 AP_QD_MCD05 AP_QD_MCD06 AP_QD_MCD07 AP_QD_MCD08 AP_QD_MCD09 AP_QD_MCD10 AP_QD_MCD11 AP_QD_MCD12 AP_QD_MCD13 AP_QD_MCD14 AP_QD_MCD15 AP_QD_MCD16 AP_QD_MCD17 AP_QD_MCD18 AP_QD_MCD19 AP_QD_MCD20 AP_QD_MCD21 AP_QD_MCD22 AP_QD_MCD23 AP_QD_MCD24 AP_QD_MCD25 AP_QD_MCD26 AP_QD_MCD27 AP_QD_MCD28 AP_QD_MCD29 AP_QD_MCD30 AP_QD_MCD31 AP_QD_MCD32 AP_QD_MCD33 AP_QD_MCD34 AP_QD_MCD35 AP_QD_MCD36 AP_QD_MCD37 AP_QD_MCD38 AP_QD_MCD39 AP_QD_MCD40 AP_QD_MCD41 AP_QD_MCD42 AP_QD_MCD43 AP_QD_MCD44 AP_QD_MCD45 AP_QD_MCD46 AP_QD_MCD47 AP_QD_MCD48 AP_QD_MCD49 AP_QD_MCD50 -- Also, if anyone wants a hotfix for now, just make a blank .tp2 file. Paste this in and run it with weidu: Spoiler BACKUP ~d2-qdmultifix/backup~ AUTHOR ~~ VERSION ~0.1~ BEGIN ~QD_MULTI fix~ REQUIRE_PREDICATE (GAME_IS ~bgee bg2ee iwdee eet~) ~Game not supported~ REQUIRE_PREDICATE (FILE_EXISTS ~override/QD_MCF01.SPL~) ~~ NO_LOG_RECORD //QD_MULTI lines OUTER_TEXT_SPRINT d2qdmulti_f ~QD_MULTI AP_QD_MCF01 AP_QD_MCF02 AP_QD_MCF03 AP_QD_MCF04 AP_QD_MCF05 AP_QD_MCF06 AP_QD_MCF07 AP_QD_MCF08 AP_QD_MCF09 AP_QD_MCF10 AP_QD_MCF11 AP_QD_MCF12 AP_QD_MCF13 AP_QD_MCF14 AP_QD_MCF15 AP_QD_MCF16 AP_QD_MCF17 AP_QD_MCF18 AP_QD_MCF19 AP_QD_MCF20 AP_QD_MCF21 AP_QD_MCF22 AP_QD_MCF23 AP_QD_MCF24 AP_QD_MCF25 AP_QD_MCF26 AP_QD_MCF27 AP_QD_MCF28 AP_QD_MCF29 AP_QD_MCF30 AP_QD_MCF31 AP_QD_MCF32 AP_QD_MCF33 AP_QD_MCF34 AP_QD_MCF35 AP_QD_MCF36 AP_QD_MCF37 AP_QD_MCF38 AP_QD_MCF39 AP_QD_MCF40 AP_QD_MCF41 AP_QD_MCF42 AP_QD_MCF43 AP_QD_MCF44 AP_QD_MCF45 AP_QD_MCF46 AP_QD_MCF47 AP_QD_MCF48 AP_QD_MCF49 AP_QD_MCF50~ OUTER_TEXT_SPRINT d2qdmulti_t ~QD_MULTI AP_QD_MCT01 AP_QD_MCT02 AP_QD_MCT03 AP_QD_MCT04 AP_QD_MCT05 AP_QD_MCT06 AP_QD_MCT07 AP_QD_MCT08 AP_QD_MCT09 AP_QD_MCT10 AP_QD_MCT11 AP_QD_MCT12 AP_QD_MCT13 AP_QD_MCT14 AP_QD_MCT15 AP_QD_MCT16 AP_QD_MCT17 AP_QD_MCT18 AP_QD_MCT19 AP_QD_MCT20 AP_QD_MCT21 AP_QD_MCT22 AP_QD_MCT23 AP_QD_MCT24 AP_QD_MCT25 AP_QD_MCT26 AP_QD_MCT27 AP_QD_MCT28 AP_QD_MCT29 AP_QD_MCT30 AP_QD_MCT31 AP_QD_MCT32 AP_QD_MCT33 AP_QD_MCT34 AP_QD_MCT35 AP_QD_MCT36 AP_QD_MCT37 AP_QD_MCT38 AP_QD_MCT39 AP_QD_MCT40 AP_QD_MCT41 AP_QD_MCT42 AP_QD_MCT43 AP_QD_MCT44 AP_QD_MCT45 AP_QD_MCT46 AP_QD_MCT47 AP_QD_MCT48 AP_QD_MCT49 AP_QD_MCT50~ OUTER_TEXT_SPRINT d2qdmulti_m ~QD_MULTI AP_QD_MCM01 AP_QD_MCM02 AP_QD_MCM03 AP_QD_MCM04 AP_QD_MCM05 AP_QD_MCM06 AP_QD_MCM07 AP_QD_MCM08 AP_QD_MCM09 AP_QD_MCM10 AP_QD_MCM11 AP_QD_MCM12 AP_QD_MCM13 AP_QD_MCM14 AP_QD_MCM15 AP_QD_MCM16 AP_QD_MCM17 AP_QD_MCM18 AP_QD_MCM19 AP_QD_MCM20 AP_QD_MCM21 AP_QD_MCM22 AP_QD_MCM23 AP_QD_MCM24 AP_QD_MCM25 AP_QD_MCM26 AP_QD_MCM27 AP_QD_MCM28 AP_QD_MCM29 AP_QD_MCM30 AP_QD_MCM31 AP_QD_MCM32 AP_QD_MCM33 AP_QD_MCM34 AP_QD_MCM35 AP_QD_MCM36 AP_QD_MCM37 AP_QD_MCM38 AP_QD_MCM39 AP_QD_MCM40 AP_QD_MCM41 AP_QD_MCM42 AP_QD_MCM43 AP_QD_MCM44 AP_QD_MCM45 AP_QD_MCM46 AP_QD_MCM47 AP_QD_MCM48 AP_QD_MCM49 AP_QD_MCM50~ OUTER_TEXT_SPRINT d2qdmulti_p ~QD_MULTI AP_QD_MCP01 AP_QD_MCP02 AP_QD_MCP03 AP_QD_MCP04 AP_QD_MCP05 AP_QD_MCP06 AP_QD_MCP07 AP_QD_MCP08 AP_QD_MCP09 AP_QD_MCP10 AP_QD_MCP11 AP_QD_MCP12 AP_QD_MCP13 AP_QD_MCP14 AP_QD_MCP15 AP_QD_MCP16 AP_QD_MCP17 AP_QD_MCP18 AP_QD_MCP19 AP_QD_MCP20 AP_QD_MCP21 AP_QD_MCP22 AP_QD_MCP23 AP_QD_MCP24 AP_QD_MCP25 AP_QD_MCP26 AP_QD_MCP27 AP_QD_MCP28 AP_QD_MCP29 AP_QD_MCP30 AP_QD_MCP31 AP_QD_MCP32 AP_QD_MCP33 AP_QD_MCP34 AP_QD_MCP35 AP_QD_MCP36 AP_QD_MCP37 AP_QD_MCP38 AP_QD_MCP39 AP_QD_MCP40 AP_QD_MCP41 AP_QD_MCP42 AP_QD_MCP43 AP_QD_MCP44 AP_QD_MCP45 AP_QD_MCP46 AP_QD_MCP47 AP_QD_MCP48 AP_QD_MCP49 AP_QD_MCP50~ OUTER_TEXT_SPRINT d2qdmulti_r ~QD_MULTI AP_QD_MCR01 AP_QD_MCR02 AP_QD_MCR03 AP_QD_MCR04 AP_QD_MCR05 AP_QD_MCR06 AP_QD_MCR07 AP_QD_MCR08 AP_QD_MCR09 AP_QD_MCR10 AP_QD_MCR11 AP_QD_MCR12 AP_QD_MCR13 AP_QD_MCR14 AP_QD_MCR15 AP_QD_MCR16 AP_QD_MCR17 AP_QD_MCR18 AP_QD_MCR19 AP_QD_MCR20 AP_QD_MCR21 AP_QD_MCR22 AP_QD_MCR23 AP_QD_MCR24 AP_QD_MCR25 AP_QD_MCR26 AP_QD_MCR27 AP_QD_MCR28 AP_QD_MCR29 AP_QD_MCR30 AP_QD_MCR31 AP_QD_MCR32 AP_QD_MCR33 AP_QD_MCR34 AP_QD_MCR35 AP_QD_MCR36 AP_QD_MCR37 AP_QD_MCR38 AP_QD_MCR39 AP_QD_MCR40 AP_QD_MCR41 AP_QD_MCR42 AP_QD_MCR43 AP_QD_MCR44 AP_QD_MCR45 AP_QD_MCR46 AP_QD_MCR47 AP_QD_MCR48 AP_QD_MCR49 AP_QD_MCR50~ OUTER_TEXT_SPRINT d2qdmulti_d ~QD_MULTI AP_QD_MCD01 AP_QD_MCD02 AP_QD_MCD03 AP_QD_MCD04 AP_QD_MCD05 AP_QD_MCD06 AP_QD_MCD07 AP_QD_MCD08 AP_QD_MCD09 AP_QD_MCD10 AP_QD_MCD11 AP_QD_MCD12 AP_QD_MCD13 AP_QD_MCD14 AP_QD_MCD15 AP_QD_MCD16 AP_QD_MCD17 AP_QD_MCD18 AP_QD_MCD19 AP_QD_MCD20 AP_QD_MCD21 AP_QD_MCD22 AP_QD_MCD23 AP_QD_MCD24 AP_QD_MCD25 AP_QD_MCD26 AP_QD_MCD27 AP_QD_MCD28 AP_QD_MCD29 AP_QD_MCD30 AP_QD_MCD31 AP_QD_MCD32 AP_QD_MCD33 AP_QD_MCD34 AP_QD_MCD35 AP_QD_MCD36 AP_QD_MCD37 AP_QD_MCD38 AP_QD_MCD39 AP_QD_MCD40 AP_QD_MCD41 AP_QD_MCD42 AP_QD_MCD43 AP_QD_MCD44 AP_QD_MCD45 AP_QD_MCD46 AP_QD_MCD47 AP_QD_MCD48 AP_QD_MCD49 AP_QD_MCD50~ //check clabs and write in QD_MULTI lines if needed ACTION_DEFINE_ASSOCIATIVE_ARRAY d2qdmulti BEGIN CLABFI01 => ~%d2qdmulti_f%~ CLABTH01 => ~%d2qdmulti_t%~ CLABMA01 => ~%d2qdmulti_m%~ CLABPR01 => ~%d2qdmulti_p%~ CLABRN01 => ~%d2qdmulti_r%~ CLABDR01 => ~%d2qdmulti_d%~ END ACTION_PHP_EACH d2qdmulti AS clab => string BEGIN ACTION_IF (FILE_EXISTS_IN_GAME ~%clab%.2da~) BEGIN ACTION_IF !(RESOURCE_CONTAINS ~%clab%.2da~ ~AP_QD_MC~) BEGIN APPEND ~%clab%.2da~ ~%string%~ END END END /* */ If your class clabs were missing the QD_MULTI lines, they will be added back in. The installer will be skipped if you don't have QD_MCF01.SPL file in the override. Edited January 9 by Dan_P Quote Link to comment
DavidW Posted January 9 Share Posted January 9 Assume I'm not. (I can guess, though - probably an incompatibility between different ways of doing multiclass kits.) Quote Link to comment
Dan_P Posted January 9 Author Share Posted January 9 Updated the OP with more info. Quote Link to comment
DavidW Posted January 9 Share Posted January 9 I'm wondering how that could be happening. ToF doesn't intentionally reset CLAB files - I'm modifying existing content, not rewriting from scratch. I assume you don't know which actual component broke it? Do you have a copy of one of the clabs that gets wiped, from just before ToF gets installed? One possibility is that something is adding a clab line in in a way that's technically illegal given the clab format - ToF is finicky about such things. You might also do a --change-log on (e.g. clabfi01.2da). Quote Link to comment
Dan_P Posted January 9 Author Share Posted January 9 I haven't checked one-by-one for each component. I do know that all the QD_MC lines are removed if you install all the class components. Just checking one right now, one that does affect it is Thief Evasion. This was tested with just a kit mod and ToF on an otherwise clean install of BG2EE. -- CLABTH01 (before thief evasion): 2DA V1.0 **** 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 ABILITY1 GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** ABILITY2 **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ABILITY3 **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ABILITY4 **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ABILITY5 **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ABILITY6 **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** QD_MULTI AP_QD_MCT01 AP_QD_MCT02 AP_QD_MCT03 AP_QD_MCT04 AP_QD_MCT05 AP_QD_MCT06 AP_QD_MCT07 AP_QD_MCT08 AP_QD_MCT09 AP_QD_MCT10 AP_QD_MCT11 AP_QD_MCT12 AP_QD_MCT13 AP_QD_MCT14 AP_QD_MCT15 AP_QD_MCT16 AP_QD_MCT17 AP_QD_MCT18 AP_QD_MCT19 AP_QD_MCT20 AP_QD_MCT21 AP_QD_MCT22 AP_QD_MCT23 AP_QD_MCT24 AP_QD_MCT25 AP_QD_MCT26 AP_QD_MCT27 AP_QD_MCT28 AP_QD_MCT29 AP_QD_MCT30 AP_QD_MCT31 AP_QD_MCT32 AP_QD_MCT33 AP_QD_MCT34 AP_QD_MCT35 AP_QD_MCT36 AP_QD_MCT37 AP_QD_MCT38 AP_QD_MCT39 AP_QD_MCT40 AP_QD_MCT41 AP_QD_MCT42 AP_QD_MCT43 AP_QD_MCT44 AP_QD_MCT45 AP_QD_MCT46 AP_QD_MCT47 AP_QD_MCT48 AP_QD_MCT49 AP_QD_MCT50 CLABTH01 (after thief evasion): 2DA V1.0 **** 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ABILITY1 GA_SPCL412 **** **** **** **** GA_SPCL412 AP_#EVASION **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** GA_SPCL412 **** **** **** **** **** **** **** **** **** **** **** **** **** **** Quote Link to comment
DavidW Posted January 9 Share Posted January 9 OK, that's helpful, and roughly what I expected. SCS and ToF use a function, kit_edit_clab, that reads the clab file into a 2da, edits it, and writes it. That function is expecting all row headers to be of the form 'ABILITYx', since that's universal in the unmodded game, but that's a bad design choice on my part, since the engine doesn't have a problem with other naming conventions for CLAB rows and they don't violate the file format. In any event, in its current format the function will fail to read the QD_MULTI line. (When it writes the clab back out again, it only bothers with nonempty rows, which is why there's only ABILITY1 in the post-evasion file.) The fix is obviously to make kit_edit_clab a bit more permissive. (One thing it won't naturally do, even with that change, is preserve the QD_MULTI row name - the QD_xxxx entries will get put in a normal ABILITYx line. Is that going to cause any problems?) There's a second problem, which is that the pre-evasion CLABTH01 isn't a legal 2da file: there are 40 column headers but the last four rows have 50 entries. kit_edit_clab won't care (it will just ignore the rows after entry 40) but other functions I use would care. I should probably encourage them to be more tolerant; that said, it would also be a good idea if the ADD_KIT_EX function didn't break the 2da format. Thanks for the report and the help. Quote Link to comment
argent77 Posted January 9 Share Posted January 9 25 minutes ago, DavidW said: There's a second problem, which is that the pre-evasion CLABTH01 isn't a legal 2da file: there are 40 column headers but the last four rows have 50 entries. kit_edit_clab won't care (it will just ignore the rows after entry 40) but other functions I use would care. I should probably encourage them to be more tolerant; that said, it would also be a good idea if the ADD_KIT_EX function didn't break the 2da format. ADD_KIT_EX shouldn't break any 2da resources. Missing entries will be automatically (and semi-intelligently) filled by the function to leave a valid 2da file. @Dan_P Could you please provide a repro case if the file above was created by ADD_KIT_EX in that state? Quote Link to comment
Dan_P Posted January 9 Author Share Posted January 9 24 minutes ago, argent77 said: ADD_KIT_EX shouldn't break any 2da resources. Missing entries will be automatically (and semi-intelligently) filled by the function to leave a valid 2da file. @Dan_P Could you please provide a repro case if the file above was created by ADD_KIT_EX in that state? I had to google repro case (lol). I'm not a programmer. Do you just mean mods installed? If so, I tested with clean BG2EE v2.6.6 (Steam version) with The Workshop Kitpack and Thief Evasion from beta 3 of ToF. This is the weidu log: // Log of Currently Installed WeiDU Mods // The top of the file is the 'oldest' mod // ~TP2_File~ #language_number #component_number // [Subcomponent Name -> ] Component Name [ : Version] ~D2-WORKSHOPKITS/D2-WORKSHOPKITS.TP2~ #0 #9999 // The Workshop Kitpack -> Base kits + multiclass variants: 4.7 ~D2-WORKSHOPKITS/D2-WORKSHOPKITS.TP2~ #0 #10 // Misc item pack: 4.7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40450 // Thieves gain the Evasion ability (on a successful save for half damage against abilities that require you to dodge, take no damage): Beta 3 No files in override before install. Quote Link to comment
subtledoctor Posted January 9 Share Posted January 9 (edited) 1 hour ago, DavidW said: the pre-evasion CLABTH01 isn't a legal 2da file: there are 40 column headers but the last four rows have 50 entries. kit_edit_clab won't care (it will just ignore the rows after entry 40) but other functions I use would care. I should probably encourage them to be more tolerant; that said, it would also be a good idea if the ADD_KIT_EX function didn't break the 2da format. The engine doesn’t care about this any more than it cares about the content of the row headings in column 0. It would be nice if there was a standard, I guess, but the standard is 40 columns, while lots of players and mods assume 50 due to the popularity of extending the level limit. (Not to my taste, but what can you do.) The result is a bit of a mish-mash, which is unfortunate… but that mish-mash doesn’t cause any problems in the absence of your mods. If your mod has more exacting expectations about the files’ layout, why not quickly fix the layout before running your function? Pad out all the rows that have fewer columns than COUNT_2DA_COLS? Doesn’t Camdawg have a function floating around that does that? 1 hour ago, DavidW said: (One thing it won't naturally do, even with that change, is preserve the QD_MULTI row name - the QD_xxxx entries will get put in a normal ABILITYx line. Is that going to cause any problems?) No technical problems… though, once I realized that column is insignificant I started bring descriptive with it. It has (very occasionally) been useful for troubleshooting, telling a player e.g. “look for the row that begins with ‘D5_PSIONICS’ and make sure you see _____ in the 3rd column” or somesuch… so it definitely removes information that was intentionally added by other modders. Edited January 9 by subtledoctor Quote Link to comment
DavidW Posted January 9 Share Posted January 9 1 minute ago, subtledoctor said: The engine doesn’t care about this any more than it cares about the content of the row headings in column 0. It would be nice if there was a standard, I guess, but the standard is 40 columns, while lots of players and mods assume 50 due to the popularity of extending the level limit. (Not to my taste, but what can you do.) The engine cares about 2da files being legally formatted in a bunch of places. That - currently! as far as I know!- it allows certain illegal formats to fail gracefully in the particular context of CLAB files is not a great reason to format them illegally. (There are various ways in which you can illegally format a cre or sto or are file that the engine will overlook; it's still not a good idea to do it.) And there doesn't need to be a standard, because in 2024 there is no need to just throw an APPEND at a clab file when it can be more intelligently patched to make sure it remains legal. 5 minutes ago, subtledoctor said: If your mod has more exacting expectations about the files’ layout, why not quickly fix the layout before running your function? In this specific case I'll probably look at doing that, but I do want to defend the general principle: we have a very well documented set of file formats for IE games, people should keep to them, and if their not doing so breaks something, it's on them. (Not that the illegal format is what's actually causing the problem here: it's nonstandard row headers, which is legal, and is on me.) Quote Link to comment
subtledoctor Posted January 9 Share Posted January 9 (edited) 24 minutes ago, DavidW said: That - currently! as far as I know!- it allows certain illegal formats to fail gracefully in the particular context of CLAB files is not a great reason to format them illegally I’m not arguing in favor of that. I’m just pointing out that the extant group of mods made for these games over 20+ years has hundreds or thousands of instances of this being done, and most are not going to be fixed anytime soon. Imperfect though they may be, players often make a choice to install those imperfect mods. The only question is whether you would obliterate those mods from users’s games. 24 minutes ago, DavidW said: And there doesn't need to be a standard, because in 2024 there is no need to just throw an APPEND at a clab file when it can be more intelligently patched Fair enough… but… I’ll be honest I have many, many instances of APPEND in my mods (like very very many) often from a very long time ago. It is not ideal… in fact there are very many parts of my mods that are archaic or inefficient and otherwise less than ideal. But once they work, and the bugs get ironed out… I’m not about to take time away from my kids to go back in a optimize things. Nobody here gets paid for this, and most people don’t use it to showcase their work the way you do. I want to accomplish ____, and once I’ve accomplished that I don’t want to spend more time on it. So here in 2024, all those APPENDs I wrote in 2014 are still there, and I expect they will still be there in 2034. If a mod comes in later and threatens to destructively enforce the file format, I suppose I would throw a function in the ALWAYS block as a prophylactic measure. But I’m not about to rewrite 437 instances of kit table patches. Edited January 9 by subtledoctor Quote Link to comment
DavidW Posted January 9 Share Posted January 9 22 minutes ago, subtledoctor said: most people don’t use it to showcase their work the way you do I'm not sure what that means. Quote Link to comment
argent77 Posted January 10 Share Posted January 10 (edited) 13 hours ago, Dan_P said: I tested with clean BG2EE v2.6.6 (Steam version) with The Workshop Kitpack and Thief Evasion from beta 3 of ToF. This is the weidu log: // Log of Currently Installed WeiDU Mods // The top of the file is the 'oldest' mod // ~TP2_File~ #language_number #component_number // [Subcomponent Name -> ] Component Name [ : Version] ~D2-WORKSHOPKITS/D2-WORKSHOPKITS.TP2~ #0 #9999 // The Workshop Kitpack -> Base kits + multiclass variants: 4.7 ~D2-WORKSHOPKITS/D2-WORKSHOPKITS.TP2~ #0 #10 // Misc item pack: 4.7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40450 // Thieves gain the Evasion ability (on a successful save for half damage against abilities that require you to dodge, take no damage): Beta 3 No files in override before install. Thanks. I have identified an issue that can lead to non-padded table entries under certain conditions. It'll be fixed in the next release of ADD_KIT_EX. 14 hours ago, DavidW said: The fix is obviously to make kit_edit_clab a bit more permissive. (One thing it won't naturally do, even with that change, is preserve the QD_MULTI row name - the QD_xxxx entries will get put in a normal ABILITYx line. Is that going to cause any problems?) That will currently cause problems if multiclass kits are installed before and after ToF since ADD_KIT_EX explicitly checks for the "QD_MULTI" keyword to determine whether to initialize files related to the multiclass kit mechanism. Making the check more robust is a trivial matter, but that will require kit mods to update to the next ADD_KIT_EX version. The same is true for mods that use @subtledoctor's QDMULTI library directly. Edited January 10 by argent77 clarify Quote Link to comment
DavidW Posted January 10 Share Posted January 10 1 hour ago, argent77 said: That will currently cause problems if multiclass kits are installed before and after ToF since ADD_KIT_EX explicitly checks for the "QD_MULTI" keyword to determine whether to initialize files related to the multiclass kit mechanism. I'm persuaded I should avoid doing this, since people are using the metadata. Quote Link to comment
argent77 Posted January 10 Share Posted January 10 @Dan_P ADD_KIT_EX has been updated to v0.6.1 which fixes the issues mentioned in this topic. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.