temnix Posted June 14, 2021 Posted June 14, 2021 The Level() trigger only considers the first class of a creature, and PartyLevel must be like that too. It probably also shortchanges dual- and multi-class characters. I went to look at script actions hoping that there would be something more encompassing, but if this is all there is, then the Minimum Hit Dice/Maximum Hit Dice on effect limits will work just as badly. Maybe I could use stats? First run a LEVEL2 check and set a variable, then LEVEL3 and set another, then AddGlobals, and only then the check for LEVEL1 or Level()... But how many blocks would that take? For every possible combination of levels in the first, second and third class, that's crazy. Quote
subtledoctor Posted June 14, 2021 Posted June 14, 2021 (edited) Not exactly the same thing, but when I set up a single-class to multiclass conversion in-game, sometimes the original class would become CLASS2, so I would need to record the level - say, 9 - and then change the characters multiclass level from, say, level 9/level 1 to level 1/level 9. The only way I came up with was an annoyingly long script to set a variable to one of 50 values depending on the original level. I think basically similar to what you are describing, a crap-ton of script blocks for what is ultimately a simple operation. In my case, 50 blocks to set the variable correctly and then 50 more to apply the change. https://github.com/UnearthedArcana/Will_to_Power/blob/master/Will_to_Power/data/kit/d5pzirc.baf But then again I'm trash at writing BAF scripts, maybe it could be done more efficiently. Edited June 14, 2021 by subtledoctor Quote
temnix Posted June 15, 2021 Author Posted June 15, 2021 Maybe that works, although in my case using just the first class level may be acceptable. It's for something that happens every level and involves a slice of the experience total. I thought about it and realized that multi-classers will just see this event more rarely, but they will get a proportionally bigger share of XP, so that evens out in the end. Another thing that could be done would be to edit all CLAB files and add a self-casting spell for every class for every level, incrementing the same local variable by 1. That way there would be a ready variable to read for any character always. May be a good idea for a technical patch, in principle. Quote
subtledoctor Posted June 15, 2021 Posted June 15, 2021 49 minutes ago, temnix said: Another thing that could be done would be to edit all CLAB files and add a self-casting spell for every class for every level, incrementing the same local variable by 1. That way there would be a ready variable to read for any character always. May be a good idea for a technical patch, in principle. Yeah that would be very easy I do that a lot. It would only bring install order into play, since you would want it to be applied after any mods that add new CLAB tables. But that's easy: just slap a bolded disclaimer in the readme/mod page that says "INSTALL AFTER ALL MODS THAT ADD KITS." Only things to be aware of there are: 1) Multiclasses apply everything in both of there underlying trueclass CLAB tables, i.e. a fighter/cleric applies everything in CLABFI01.2da and CLABPR01.2da. If it is a kitted multiclass it does not apply anything directly from its own CLAB table. So if the spell increments a variable, it will increment it each time a multiclass advances in each class. 2) NPCs run their CLAB table effects every time they join the party. So if Minsc joins in Irenicus' dungeon as a level 8 ranger, his variable will increment to a value of 8; if you leave him in the Copper Coronet to go kill all the animals in the druid grove, and then pick him up again to go to Spellhold, his variable will increment another 8 times to 16. (The CLAB table effects are removed when someone leaves the party, but some spell effects are not prone to being removed... I think that when a variable is incremented with opcode 309, then removing the spell with the 309 effect does not reduce the variable. You'll want to confirm this behavior, though.) Assuming my supposition about opcode 309 being applied indelibly is correct, then 1) and 2) can be addressed in the same fashion: instead of having one spell that is applied in every level of every CLAB table, make 50 different spells with identical effects (increment variable by 1) but different names. Apply each one once. In your script, whatever else it does at each class level, have it apply opcode 206 protection against the CLAB spell of the appropriate level. This way, the variable will incremented exactly once per level up, to a maximum of 50 times, and never incremented erroneously. Quote
temnix Posted June 15, 2021 Author Posted June 15, 2021 (edited) So if the spell increments a variable, it will increment it each time a multiclass advances in each class. Of course. That's the point. A fighter/cleric with one level in each needs two upgrades, one from each class, at the start. I'm more uncertain about how this would work with dual-classing, but it probably would. The example with Minsc also seems to describe just what should happen. Quote I think that when a variable is incremented with opcode 309, then removing the spell with the 309 effect does not reduce the variable. You'll want to confirm this behavior, though.) Nothing can remove a set variable, global or local. It can only be set to zero. Anyway, I don't need to think about this any more. If anyone wants to make this kind of mod and give everyone a reliable way to detect total levels, they are welcome to it. Edited June 15, 2021 by temnix Quote
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.