Jarno Mikkola Posted April 29, 2016 Share Posted April 29, 2016 Show us how one would use that at adding the Use All Items HLA to Kensai. Yes, a cheesy example, just cause it's all I came up with. Ouh, and you might wish to make the macro a .tpa file for ease of inclusion. And make that print out the function version info... if you like the idea. Link to comment
subtledoctor Posted April 29, 2016 Author Share Posted April 29, 2016 Sure. Btw the code *is* in a .tpa file, in the example mod at the github link I posted a few posts up. Current version is 0.3. Looking at an unmodded LUABBR.2da, I see that the kensai normally uses lufi0, the same as other fighters. We don't want everyone to get UAI, so we'll have to make a new table for the kensai. But, I don't know if another mod has already done this. So I'll use the get_hla_table function ane make an allowance for either cirsumstance: INCLUDE ~mymod/lib/hla_actions.tpa~ LAF get_hla_table STR_VAR kit_name = ~KENSAI~ RET hla_table END // find the HLA table associated with the kensai ACTION_IF %hla_table% STRING_EQUAL_CASE ~fi0~ BEGIN // if kensai table is unmodded COPY_EXISTING ~lufi0.2da~ ~override/lud5ken.2da~ LPF add_hla STR_VAR ability = ~AP_SPCL915~ num_allowed = ~1~ END // make new table and add UAI to new table COPY_EXISTING ~LUABBR.2DA~ ~override~ SET_2DA_ENTRY 29 1 2 ~d5ken~ // associate new table with kensai END ELSE BEGIN // if kensai table has changed COPY_EXISTING ~lu%hla_table%.2da~ ~override~ LPF add_hla STR_VAR ability = ~AP_SPCL915~ num_allowed = ~1~ END // add UAI to whatever table is now associated with kensai END Link to comment
Jarno Mikkola Posted April 29, 2016 Share Posted April 29, 2016 Btw the code *is* ...Yeah, well, not to mislead, I nearly always just read the very last one of posts from the same poster, in a multi page threads, assuming that it hasn't changed, unless the very first post is indicated to be the primary post over all, as a thread management... and thanks for the example. Link to comment
subtledoctor Posted April 29, 2016 Author Share Posted April 29, 2016 Hmmm... thinking more about this: my original idea was focused on APPEND... but with INSERT_2DA_ROW it's not necessary to remove the blank rows at the bottom of the document. And because you can just set the insertion point wherever you want... I guess the whole idea of the add_hla function is really unnecessary. Oh well, even just the illusion that this makes HLA editing easier might spur more people to make HLA mods, and that will be a good thing. Link to comment
subtledoctor Posted May 4, 2016 Author Share Posted May 4, 2016 It just occurred to me that the current Replace_HLA function is not ideal: if the HLA to be replaced is not present in the table being patched, the function will default to mimicking Add_HLA. But the preferred behavior would be to simply do nothing. So I need to add a check to determine that the HLA being replaced actually exists in the table, before performing any patches. Link to comment
Jarno Mikkola Posted May 4, 2016 Share Posted May 4, 2016 It just occurred to me that the current Replace_HLA function is not ideal: if the HLA to be replaced is not present in the table being patched, the function will default to mimicking Add_HLA. But the preferred behavior would be to simply do nothing. So I need to add a check to determine that the HLA being replaced actually exists in the table, before performing any patches. Or you could make it optional. Aka make a variable that is set to 1 or zero by default... and if it's zero, do no add, and if it's set as one add it anyways. Link to comment
subtledoctor Posted May 4, 2016 Author Share Posted May 4, 2016 I'm not convinced. I think I'll probably change the Replace_HLA function to just use REPLACE_TEXTUALLY. The you will be able to do two different things: 1) Replace HLA 1, but if it's not present then do nothing. COPY_EXISTING ~luxxx.2da~ ~override~ LPF replace_hla STR_VAR remove_ability = ~GA_HLA_1~ ability = ~GA_HLA_2~ num_allowed = ~99~ END2) Replace HLA 1, if it's not present then add HLA 2 anyway. COPY_EXISTING ~luxxx.2da~ ~override~ LPF remove_hla STR_VAR remove_ability = ~GA_HLA_1~ END LPF add_hla STR_VAR ability = ~GA_HLA_2~ num_allowed = ~99~ END Link to comment
lynx Posted May 4, 2016 Share Posted May 4, 2016 emplace_hla as a shorthand for the second? Link to comment
subtledoctor Posted May 5, 2016 Author Share Posted May 5, 2016 Okay, that seriously simplified replace_hla. Like, it's literally 2 lines of code now, instead of ~40. https://github.com/subtledoctor/Modify_HLAs/releases/tag/0.4 Link to comment
subtledoctor Posted May 10, 2016 Author Share Posted May 10, 2016 I'm trying to extend these a bit to be easier, so you could simply say LAF add_hla STR_VAR kit_name = ~RANGER~ ability = ~SPCL923~ num_allowed = ~20~ END...and have it automatically incorporate the table-checking code I wrote above in my example for Jarno. But, it's not working. Do action functions not tolerate any patching code within them? Link to comment
Magus Posted May 11, 2016 Share Posted May 11, 2016 But, it's not working. Do action functions not tolerate any patching code within them? Of course. Action is action, patch is patch. The only way to mix them is INNER_*, OUTER_* Link to comment
subtledoctor Posted May 11, 2016 Author Share Posted May 11, 2016 Of course. Action is action, patch is patch. The only way to mix them is INNER_*, OUTER_* Well, that's not normally the case. I can do: ACTION_PHP_EACH something COPY something PATCH_IF something WRITE_BYTE something END BUT_ONLY ENDIn other words you can normally do patches within actions, but not vice versa (without INNER_ACTION). It's non-obvious (to me, anyway) that the same rule wouldn't apply to functions. Link to comment
Mike1072 Posted May 11, 2016 Share Posted May 11, 2016 Functions don't behave any differently. If your code isn't working (error message? installs successfully but doesn't do what it's supposed to?), post it for someone to take a look at. Link to comment
subtledoctor Posted May 11, 2016 Author Share Posted May 11, 2016 Yeah, I realized after posting that the get_hla_table action function does this. So my problem is nothign to do with the nature of functions, but rather it's a problem in my code. Here's what I have so far: ACTION_DEFINE_ASSOCIATIVE_ARRAY d5_orig_hlas BEGIN MAGE , Ma0 => Ma0 FIGHTER , Fi0 => Fi0 CLERIC , Cl0 => Cl0 THIEF , Th0 => Th0 BARD , Ba0 => Ba0 PALADIN , Pa0 => Pa0 DRUID , Dr0 => Dr0 RANGER , Ra0 => Ra0 FIGHTER_MAGE , FM0 => FM0 FIGHTER_CLERIC , FC0 => FC0 FIGHTER_THIEF , FT0 => FT0 FIGHTER_MAGE_THIEF , FMT => FMT MAGE_THIEF , MT0 => MT0 CLERIC_MAGE , CM0 => CM0 CLERIC_THIEF , CT0 => CT0 FIGHTER_DRUID , FD0 => FD0 FIGHTER_MAGE_CLERIC , FMC => FMC CLERIC_RANGER , CR0 => CR0 ABJURER , Ma2 => Ma0 CONJURER , Ma6 => Ma0 DIVINER , Ma5 => Ma0 ENCHANTER , Ma9 => Ma0 ILLUSIONIST , Ma8 => Ma0 INVOKER , Ma7 => Ma0 NECROMANCER , Ma3 => Ma0 TRANSMUTER , Ma4 => Ma0 BERSERKER , Fi1 => Fi0 WIZARD_SLAYER , Fi2 => Fi0 KENSAI , Fi3 => Fi0 CAVALIER , Pa1 => Pa0 INQUISITOR , Pa2 => Pa0 UNDEAD_HUNTER , Pa3 => Pa0 FERALAN , Ra1 => Ra0 STALKER , Ra2 => Ra0 BEASTMASTER , Ra3 => Ra0 ASSASIN , Th2 => Th0 BOUNTY_HUNTER , Th3 => Th0 SWASHBUCKLER , Th1 => Th1 BLADE , Ba1 => Ba0 JESTER , Ba2 => Ba0 SKALD , Ba3 => Ba0 TOTEMIC_DRUID , Dr1 => Dr0 SHAPESHIFTER , Dr2 => Dr0 BEAST_FRIEND , Dr3 => Dr0 TALOS , Cl1 => Cl0 HELM , Cl2 => Cl0 LATHANDER , Cl3 => Cl0 MONK , Mo0 => Mo0 BARBARIAN , BRB => Fi0 WILDMAGE , WMG => Ma0 SORCERER , So0 => So0 Blackguard , Pa4 => Pa4 SHADOWDANCER , Th4 => Th4 DWARVEN_DEFENDER , Fi4 => Fi4 DRAGON_DISCIPLE , So1 => So1 DARK_MOON , Mo1 => Mo1 SUN_SOUL , Mo2 => Mo2 GRIZZLY_BEAR , bea => bea SHAMAN , Sh0 => Sh0 OHTYR , Cl4 => Cl0 OHTEMPUS , Cl5 => Cl0 END DEFINE_ACTION_FUNCTION add_hla STR_VAR kit_name = ~~ 2da_row = ~1~ ability = ~*~ icon = ~*~ strref = ~*~ min_lev = ~1~ max_level = ~99~ num_allowed = ~*~ prerequisite = ~*~ excluded_by = ~*~ alignment_restrict = ~*~ BEGIN COPY_EXISTING ~luabbr.2da~ ~override~ COUNT_2DA_COLS cols // amount of columns READ_2DA_ENTRIES_NOW rows cols // read all file into memory FOR (row = 1; row < rows; ++row) BEGIN // iterate over rows READ_2DA_ENTRY_FORMER rows row 0 ~l_kit~ // read column value PATCH_IF ~%l_kit%~ STRING_EQUAL_CASE ~%kit_name%~ BEGIN SET patch_row = %row% END READ_2DA_ENTRY_FORMER rows row 1 ~l_table~ // read column value END BUT_ONLY ACTION_PHP_EACH d5_orig_hlas AS kit => tab BEGIN ACTION_IF ~%kit%~ STRING_EQUAL_CASE ~%kit_name%~ BEGIN OUTER_TEXT_SPRINT orig_table ~%tab%~ OUTER_TEXT_SPRINT new_table ~%kit_1%~ END END ACTION_IF VARIABLE_IS_SET ~new_table~ BEGIN ACTION_IF (~%orig_table%~ STRING_EQUAL_CASE ~%l_table%~) AND (FILE_EXISTS_IN_GAME ~lu%l_table%.2da~) BEGIN COPY_EXISTING ~lu%l_table%.2da~ ~override/lud5%new_table%.2da~ COUNT_2DA_COLS cols // amount of columns COUNT_2DA_ROWS cols rows // amount of rows READ_2DA_ENTRIES_NOW file cols // read all file into memory first_empty_row = rows // default value to amount of rows in order to skip removal if the table is full FOR (i = 0; i < file; ++i) BEGIN // iterate over rows SET empty_col_count = 0 // amount of empty columns in the row FOR (j = 0; j < cols; ++j) BEGIN // iterate over columns in the row READ_2DA_ENTRY_FORMER file i j col_value // read column value PATCH_IF "%col_value%" STRING_EQUAL "*" BEGIN // asterisk symbolizes empty column empty_col_count += 1 END END PATCH_IF "%empty_col_count%" = ("%cols%" - 1) BEGIN // first column in every row is its number, that's why (cols - 1) first_empty_row = i // remember the first empty row i = file // skip iterating over the rest of the rows END END INSERT_2DA_ROW ("%first_empty_row%") %cols% ~%2da_row% %ability% %icon% %strref% %min_lev% %max_level% %num_allowed% %prerequisite% %excluded_by% %alignment_restrict%~ PRETTY_PRINT_2DA END // ELSE BEGIN // COPY_EXISTING ~lu%l_table%.2da~ ~override/lud5%l_table%.2da~ // END END // ELSE BEGIN END That would more or less get repeated after the ELSE BEGIN, to account for situations where the %new_table% variable is not set (basically, for mod-added kits). But I didn't get to that part yet because the above code failed when it was meant to succeed. My test .tp2 code was LAF add_hla STR_VAR kit_name = ~RANGER~ ability = ~GA_SPCL923~ num_allowed = ~20~ END That is meant to add the paladin's innate Summon Deva to the trueclass ranger - and give the trueclass ranger a new table with the 'd5' prefix, in the meantime. But the 'lud5ra0.2da' table was never created, so something there is resulting in a false negative. Link to comment
Jarno Mikkola Posted May 11, 2016 Share Posted May 11, 2016 My test .tp2 code was LAF add_hla STR_VAR kit_name = ~RANGER~ ability = ~GA_SPCL923~ num_allowed = ~20~ ENDThat is meant to add the paladin's innate Summon Deva to the trueclass ranger - and give the trueclass ranger a new table with the 'd5' prefix, in the meantime. But the 'lud5ra0.2da' table was never created, so something there is resulting in a false negative. Did you forget that there's no such kit as RANGER ? It's the class name. The kit name is TRUECLASS ... Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.