subtledoctor Posted March 9, 2023 Share Posted March 9, 2023 (edited) I collected together a small group of functions that I have found to be useful in different ways across different mods. They don't quite fit in the semi-useful Weidu macros thread - those are low-level functions intended to help with Weidu coding, whereas one design goal of these is to create particular finished in-game results with minimum effort. Another design goal here is inter-mod compatibility. Modders can all reinvent the wheel and each use their own method to implement something like arcane casting in armor, but that is a recipe for compatibility conflicts. If mods adopt a uniform method, then they can get out of each others' way and each one will work as it is individually intended. The full Readme is here. This package has five functions so far: Arcane spellcasting in armor Modifying HLA tables Granting extra weapon proficiencies by dialogue Generalized IWD-style 'effect evasion' Innate ability pools The package contains a little mod with five example components, which together amount to a mod to improve the Skald kit. Together, they do this: Allow Skalds to cast spells in chain mail Give Skalds two HLAs from the fighter HLA table Give Skalds two extra weapon proficiencies Give Skalds an extra saving throw to evade fear/horror effects Give Skalds a point pool to innately cast Armor of Faith, Remove Fear, and Draw Upon Holy Might Those links go to the example code that powers this mod. You can see how easy it is to use these - in many cases it only requires 5-15 lines of code in the Weidu installer, in order to achieve things like armored casting, extra proficiencies, and special ability pools. I can imagine other modders might have fun ideas beyond what I've already done with these; using these drop-in functions can possibly save time and effort, improve compatibility, and enable ideas that might not otherwise have been attempted. If these help anyone, great. What's the point? You may ask. Which is reasonable. For some cases it is obvious, like with ability pools where 15 lines in Weidu can result in a spell mechanic normally not available in the game engine. But what about something simple, like HLAs. Why bother using a macro like this just to edit a little .2da table? Well, let's say you are making a druid kit - say a Rain Druid, and you want it to have mostly normal druid HLAs but also some bonus weather-related HLAs you created. The easy thing to do is grab the normal druid HLA table, LUDR0.2da, add your new ones to the list, and then ship the new file with your mod. But, what if the player installs other mods that change the base druid HLA table, like Refinements or something? Now your kit will have a copy of the old basic table, while all the other druid kits in the game have the fancy new table! Not good. What you can do instead, is ship your kit and assign it to LUDR0.2da. Then, after the kit is installed, use the 'action_add_hla' function to add your new HLAs. Now the kit will have your custom HLAs in addition to whatever was already in the table. Further, since Refinements itself uses this function to modify HLA tables, this way install order will no longer matter - the player will get the expected benefit of both mods regardless of installation order. (And the more we can make things independent of install order, the better.) Anyway, if anyone has comments, criticism, suggestions, improvements, or wants to completely rewrite these, by all means post about it. Or if you have your own high-level macros like these and want to share them here, by all means do so. The more the merrier. Edited March 9, 2023 by subtledoctor Quote Link to comment
subtledoctor Posted March 9, 2023 Author Share Posted March 9, 2023 (edited) A note about the proficiency-by-dialogue function: (And I'll tag @CamDawg and @morpheus562 since this is potentially relevant to their stuff) I hesitated putting up the "DialProf" macro and encouraging people to use it, because a proficiency dialogue installed with a kit or something in the middle of the stack will be broken by mods that change the proficiency system later. The DialProf macro adheres to the content of WEAPPROF.2da, PROFS.2da and PROSFMAX.2da when it is installed, but those values will change when something like the Tweaks BG1 proficiency system is installed, or the Skills & Abilities proficiencies are installed. However, I think I have a solution. A later mod like Tweaks Anthology can cure the problem by simply re-running each instance of the DialProf macro that was installed earlier. So this version of the DialProf macro now creates a .2da table, "dialprof.2da," and logs the variables from that particular instance of the macro. If three kit mods add extra proficiency abilities this way, there will be three rows appended to that table. Tweaks Anthology can then: Grab the dialprof folder and dialprof.tpa file from this package, and drop them into CDTweaks/lib/ At the end of the BG1 proficiency system component, after all changes have been made, run this: INCLUDE ~%MOD_FOLDER%/lib/dialprof.tpa~ ACTION_IF (FILE_EXISTS_IN_GAME ~dialprof.2da~) BEGIN COPY_EXISTING ~dialprof.2da~ ~override~ COUNT_2DA_ROWS 4 dialprof_rows PATCH_IF (dialprof_rows > 1) BEGIN FOR (row = 1; row < dialprof_rows; ++row) BEGIN READ_2DA_ENTRY row 0 4 name READ_2DA_ENTRY row 1 4 dlgs READ_2DA_ENTRY row 2 4 lev1 READ_2DA_ENTRY row 3 4 levs INNER_ACTION BEGIN OUTER_SPRINT prof_script_name ~%name%~ OUTER_SPRINT class_dlgs ~%dlgs%~ OUTER_SET script_level_one = %lev1% OUTER_SET script_higher_levels = %levs% LAM PROF_DIALOGUE END END END BUT_ONLY END Voila, all existing proficiency dialogues will now work with the BG1 proficiency system. And ditto for Skills & Abilities. Throwing that out there to see if people think that's a reasonable proposition. Edited March 9, 2023 by subtledoctor Quote Link to comment
morpheus562 Posted March 9, 2023 Share Posted March 9, 2023 I am all for helping with compatibility. Do I need this to run at the end of my proficiency overhaul? Quote Link to comment
subtledoctor Posted March 9, 2023 Author Share Posted March 9, 2023 1 hour ago, morpheus562 said: Do I need this to run at the end of my proficiency overhaul? Precisely. There are no mods using this yet so it won’t actually do anything in your mod. But if mods come along and start using this (I’m about to update one of mine with it) then they will automatically work with your new proficiency setup. Quote Link to comment
Dan_P Posted April 4 Share Posted April 4 I'm pretty sure this is a bug. Noticed this when implementing an ability pool for a kit. With the ability pool function, you can't currently have a kit gain abilities at varying levels (without a workaround). Specifically, the SPLs that block gaining abilities until the required level ("b" suffix) aren't given to the character when the points pool is initialized. This can be tested quickly with the skald kit example, included with the functions. You can work around it by applying the "b" files from the kit clab in front of the "000" file, but it's probably best to have the function add them to the "000" files directly, or applied from a subspell. 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.