subtledoctor

I don’t believe SCS changes spell tables. It shouldn’t make any difference. Note however the rest if TnB very much should be installed before SCS. FYI this exact same component exists in Scales of Balance. So if it is easier for you to wrap your head around it, you can skip it in TnB and install it from SoB. (SoB is installed right around the same time as SCS.)

Okay, found it. I'll explain in long-winded fashion, for the sake of posterity. If you look at your savegame in NI or EEKeeper, you should see effect #4 and effect #5: these apply -1 spell per level for spell levels 1 through 7. Way down in the effects' "Parent Resource" field you will see they are from a spell called "D5__SLT." The two effects together give you an overall -2 penalty. These are here because you installed "Stat-Based Bonus Spells" from TnB or SoB. That component increases the spells per level by two, and then selectively applies penalties based on your INT score. MnG bards are not subject to that mod; therefore they do not get any penalties applied; therefore they must get a -2 penalty to offset the general table bonus. The result is to bring them in line with what the spell table would look like without the "Stat-Based Bonus Spells" mod. Effect #41 is an identical -1 penalty for spell levels 1 through 7; the parent resource for this one is "D500SLT." This is applied because any kitted mages, such as all of the MnG bards, get an automatic +1 bonus, like specialists. We want bards to have the same number of spell slots as a non-specialist. So the game and that other mod are applying a +3 bonus, and we are applying a -3 penalty. So far so good. At effects #504 through 525, you will see a bunch more spell slot penalties, with the parent resource names "D517SLT" and "D589SLT." These are normal, they are only applied while you are casting spontaneously. They are canceled when you use the Spell Preparation ability. So you can ignore these. Now, in your post-Planar Prison save, you will see "D5__SLT" applied again in effect #530 and #531, and you will see "D500SLT" applied again in effect #565. This is because the effects were not removed when HD left your party - I think because they were triggered by the QD_Multi system instead of directly by his CLAB file. However, these effects were re-applied with his other kit abilities when he re-joined the party. I thought the QD_Multi system prevented this from happening... but I guess it is not reliable. (@argent77 and @Aquadrizzt, we might want to look into this.) With those penalties being applied twice, HD is now subject to an overall -6 penalty...! So to fix this for yourself: delete effects #530, #531, and #565 from Haer'Dalis in your savegame. Do not remove effect #4, #5, or #41 - we need these three penalties applied once, just not twice. For me going forward: I will probably shift these penalties into the "initialize bardic spellcasting" ability. That should entirely fix this issue. And for those who wonder why the mod needs kit abilities to be initialized manually, this is the answer.

I have a Mac and iPad, both platforms which have not been able to run 32-bit apps for several years. I don’t have the best understanding of how this affects other platforms. But if the 2.5 game runs on your system, then it runs on your system. (Most 64-bit systems still run 32-but apps... Apple is ahead of the curve - in excluding 32-bit conpatibility.) I don’t think the move to 64-bit will not be noticeable to you. (Unless your system cannot run 2.5 and can run 2.6, which is of course a noticeable difference.)

Ah. Great, I made that hotfix for nothing. Can you attach the saves for each case? I have a sense of what the problem is, but directly examining his .CRE file would help me nail it down. Once it’s nailed down the fix should be pretty quick and easy. And I’m working on an update to the mod now so it’s good timing.

I glanced at the 2.6 patch notes and... all of the things that have been fixed are not things that I noticed or cared about. All of the things that I really want fixed are not being fixed in 2.6 and will have to wait for 2.7 (presumably in ~2027) or 2.8 (in ~2039). Except pathfinding. The pathfinding in 2.5 is bad, and is fixed in 2.6. Of course, it’s not that bad - I’ve been playing 2.5 and it’s been fine. Further, the bad pathfinding is a bug introduced by Beamdog themselves, in the 2.0 patch. It was fine in v1.3. It’s taken Beamdog five years to fix a bug of their own making. (Side rant: I love reading pissy comments like this bragging about how many years the games have received support. Like, yeah when you only release a patch once every 4-5 years it gets really easy to say stuff like “our games are still being patched 4-8 years after release!!2!” Consider IWDEE: the 2.5 iOS patch broke the ability to mod the game. Not because of any bugs in the game itself, but only because Beamdog messed up the way the iOS app uses OS hooks to handle files with the “.iwddata” extension. Fixing this is extraordinarily easy, and involves zero changes to the game itself. So it needs NO testing...! And yet we’ve had to wait several years, and counting, for the 2.6 patch. And given the number of bugs that are not being addressed in 2.6, and the number of new bugs introduced by Beamdog with prior patches, I have zero confidence even this simple issue will be fixed.) Anyway, tl;dr: forget the 2.6 patch. 2.5 is fine, and many mods have been extensively used with it. It is a known quantity, and it works tolerably well. Who knows how 2.6 will work? Playing is more fun than waiting, so play!

No, I think it's because the spells that grant spellcasting slots are engineered so that they cannot be applied twice, but when a character leaves the party all such effects are removed. When they can't be reapplied, you end up with no slots. This will probably work: Grab this hotfix mod repository (click "code" and then "download zip") and move the contents of the MnG 4.9 Bard Slot Fix folder into your game folder. Install the slot fix mod. Load up a save when Haer Dalis is not in the party, then have him join. (Alternatively, load a save when he is in the party, and have him level up. With this in place, levelling up and joining/re-joining the party should make a bard's casting slots snap to the number they should be. (Note, I might have modified the casting slot table, so this might be slightly different from what they had before... but this will be consistent, and this is what the table will be in MnG 4.9.5 and beyond. In short, they get spells of each spell level one level later than a wizard normally does - so, 1st-level slots at level 2, 2nd-level slots at level 4, etc. up to 6th-level slots at level 13 and 7th-level slots at level 15.) Probably should remove any spell-slot-adding equipment, save, then install this, then load the save. It might help. Note also, this does not affect memorization slots (the slots available on the spellbook page after you use the Prepare Spells ability). If you have a problem with memorization slots, then I have mis-read your post. If this doesn't work and it totally FUBARs your bards' spell slots, just uninstall the hotfix and load a save from before it was installed. But I think it should work.

Confirmed that the failure to memorize Command does not affect any other spells. Basically Command was listed as index #0 in the array of special bard spells, and then when processing them for the semi-spontaneous system the code begins with index #1. So I only needed to change a single digit - probably the easiest fix I've ever done.

All summons are overpowered in Heart if Fury mode. That’s my point: HoF makes the game harder in some ways, easier in other ways, and more boring in other ways. It creates more “correct” strategies that make the game easy (summons) and renders some strategies artificially ineffective (other magic). And you end up “winning” by using strategies that would not be effective in normal gameplay. As for rest-spamming: it just removes an important aspect of resource management. Resource management is a tactically interesting and engaging part of the game. Not bothering with it does not sound very “hardcore” to me. tl;dr: HoF is one crude way to add challenge to the game. I had fun playing it... once. But after that you can devise all sorts of different ways to add challenge, often more fun and interesting. That’s the beauty of this game. (That, and the music.)

There’s something to be said for learning what’s going on under the hood... (I don't know what that link is, the result is a blank page in my (mobile) browser...) EDIT - OK I see it now in my computer, and... meh. I don't know that it's that much easier to remember "DAMAGE_TYPE_lightning" versus "(4 << 16)." And what if you want a %-change in damage, instead of a set number? That variable does not address that. Whoops, I mean "DAMAGETYPE_lightning." Whoops, I mean "DAMAGETYPE_electric." Whoops, I mean "DAMAGETYPE_static_cling." Et cetera. If I'm working with NI open anyway, I don't need an extra layer of jargon to memorize. I won't even get into the fact that, as a VSCode extension, I assume this is OS-dependent and thus useless to people with a Mac or Linux. Last EDIT - don't mean to come down too hard on the project. It is nicely done and if it helps people then that's great. But it does not help me, and so "for the love of god" seems a bit hyperbolic.

Rest-spam s no different from turning the difficulty down to easy. Or, might as welljust cheat in a Ring of Regeneration for every party member and let the clock run for five minutes before moving another 30’ into the map. Of course, Right, HoF increases “challenge” but forces you to do things to make it easier, which reduces the challenge, so you've twisted the game rules into something barely recognizable for the sake of... what? Better to increase the challenge in ways that hew to normal gameplay (higher difficulty but no silly freebie bonus XP). I don’t play IWDEE because stupid Beamdog prevented 2.5 from being modded on iOS. But my preferred method was: 1) higher difficulty level; 2) no bonus XP; 3) further, a mod to reduce XP by half; 4) have to get through each map without any resting. And for extra fun, 5) use themed parties instead of a well-rounded group. But, as always, to each his/her own!

I know people disagree about this, but I highly recommend against using HoF mode on a first playthrough. It turns enemies into damage sponges, which of course makes them harder; but it also gives you tons of extra XP, which makes everything easier. If you want a fun challenge I would play on hard/insane difficulty, and turn difficulty-based XP bonuses off. So you advance at a normal rate, but you have to face lots more enemies, who hit harder.

Go figure.

Well, right now they expire after 20 rounds anyway. The thing is, a straight one-time point drain made a lot of sense when the mod only used hit points to power your abilities. You could walk around with Dermal Carapace, but your max HP would be 10 points lower. Add Danger Sense, and they would be 20 points lower. Etc. Maintaining powers came at a real cost and real risk. But now that we have PSPs, that risk is gone. A fighter/psion can layer on Carapace + Camouflage + Danger Sense + Inertial Barrier for something like an 11-point AC bonus plus damage reduction plus 1x/round Stoneskin plus crit protection plus AoE evasion... at that point why bother using any more psionics? Just walk around like that and tear things up. There needs to be some kind of cost to prevent them being permabuffs. Currently they expire after 20 rounds, meaning you have to spend those 36 points once per fight, or so. The proposal would hew closer to the actual D&D source material, making you spend points over time to maintain an effect. I could probably rig it such that the powers would auto-renew themselves while you are in combat, and would just expire when you are not in combat. That way you could initiate some abilities at the beginning of a fight, but you would not have to micromanage by turning them off.

Ha ha, no worries!

I think opcode 12 combines both damage type and modifier type in parameter2, so it’s difficult to work with. Try: LPF ALTER_EFFECT INT_VAR match_opcode = 12 parameter2 = (0 + (4 << 16)) END The ‘0’ is for modifier type (increment) and the ‘4’ is damage type (electric) but you are applying the ‘4’ two bytes over within the field, so to speak (i.e. 16 bits over, thus ‘<< 16’). Adding the two values together gives you the whole value for parameter2. If you expressed it as an integer it would indeed be 262144. But that seems even more inscrutable than (0 + (4 << 16))... to me at least.

Actually ADD_KIT_EX is good for that as well, probably better than ADD_KIT, and no need for the extra fl#_ function. If I was starting making kits now I would be using the new function, rather than the old one.

You put the .tpa file somewhere in your mod... like /my_mod/lib/ or something. Then in your .tp2 file you make sure the function is available to the mod by including it: INCLUDE ~my_mod/lib/a7#add_kit_ex.tpa~ (That can be in your AKWAYS block, if you have one.) Then, after the function is INCLUDE’d, you can use it according to the documentation.

In that case they should be able to learn from scrolls/spellbooks. And they should be able to know more than 5 spells per level. But they cannot, instead they learn upon level-up, and they can only know 5 spells. The class has never made sense to me - except from a pure powergaming standpoint. That's not to say it couldn't make sense... I'd love for someone to tell me a story about sorcerers in which the mechanics make sense. And then that story could inform any changes I might want to make to improve the class.

Honestly what makes most sense to me would be to simply make an alternative version of Item Upgrade, which has different item abilities that match the IR versions. I know that would be stepping on the toes of the original Item Upgrade mod, and care should be taken to obtain permission from someone who has some kind of responsibility over it. (If such a person exists, anyway.) But OTOH this would still honor the original design, and would not be antagonistic or competitive to the original in any way, so I see no reason such a person would not be willing to grant permission. IRR is a whole separate question... TBH I wouldn't be willing to put much effort into compatibility until it decides what it wants to be when it grows up, i.e. a mod all its own. More importantrly, it seems like IRR is making pretty drastic changes to items on a fairly frequent basis, so this might be a moving target.

I really want to know how you managed to get Project Image to use the caster's memorized spells...

I think I've hit upon a way to make the maintainable powers drain your PSPs (and HPs) over time, without having to more or less create a whole new mod. It would work like this: Currently, when you use a maintainable power like Inertial Barrier, there is a one-time cost of 6 points. The power lasts for 20 rounds, after which it cancels itself. The new way would be: you spend 6 points to initiate Inertial Barrier. Five rounds later, it renews itself - at a cost of 6 more points. Five rounds later, it renews itself again, costing you 6 more points. This continues until either 1) you cancel the power, or 2) you run out of points, whereupon it will auto-cancel. If you don't have enough PSPs left, the same thing will happen with your hit points: they will be drained every five rounds, until you run out of health and you fall down unconscious. I could, maybe, possibly, set it up so that initiating the power costs 6 points (or 10 for sciences) and the subsequent renewals each five rounds cost 3 points (or 5 for sciences). I could, of course, shorten or lengthen the period of time between renewals. I could also, of course, change the cost of powers, and/or change the amount of PSPs that psions gets. Thoughts? ---------------------------------- Separately, I think I want to change 'Life Detection' (a.k.a. See Invisible) into a devotion, instead of a science. But that would mean we need another science in the Clairsentience discipline. Any ideas?

I believe there is a COPY_KIT macro that is part of Weidu, works similar to ADD_KIT. But I vaguely recall Camdawg saying it is imperfect... maybe because it does not handle EE kit attributes, and fl#add_kit_ee doesn't work with it? In any event, @argent77's ADD_KIT_EX function is perfect for this sort of thing. As an extreme example, my mod uses it to systematically clone every single cleric and druid kit into several multiclass versions. Adds ~150 or more kits to the game in one fell swoop. That particular application is quite complicated, but for something like copying the DD kit into a variant version, ADD_KIT_EX could serve your purpose well.

Off topic, but what is "TNT?"

Need to change that 2nd line to PATCH_IF (~%kit_name%~ STRING_EQUAL_CASE ~SHAPESHIFTER~) BEGIN You turned the first entry (entry 0) of each row into a variable; next you need to check whether that variable matches the text string "shapeshifter." The way you had it, you were checking whether the text string "shapeshifter" matches the text string "shapeshifter," which will always return true. Also, the string after RESOLVE_STR_REF might need parens around the tildes. Maybe not... but I always put it inside parens, and it always works when I do.

I’m not on those forums, but sure, you can go ahead. (I had a bunch of bug reports filed before, but then Beamdog seems to have closed down the old system - including all of its open tickets - and asked players to register with a whole new bug-reporting system and re-file the same bugs. Like, sorry, I have better things to do with my time.)