DavidW

No.

I don't know, I'm afraid. But SCS v32 was quite drastically rewritten under-the-hood, so I'd expect lots of bits of Jimfix to need updating in order to work correctly.

That's not live code - it gets used by the code I run to get the IWD resources and strings, but doesn't get run when the player installs. ALIEN: maybe get the installer to stop looking for tp2 files in subfolders once it's found one further up? (Not that it's a big deal.)

Elemental arrows don't penetrate PNM. But Arrows of Dispelling do.

SCS got there first: it's been doing this for about fifteen years, long before the Enhanced Editions. I'd say that over those 15 years the strong majority of players prefer the current default - and SCS AI is optimized around it - so I won't be changing it. It is easy enough to disable if you don't want it. I'm not very moved by strict fidelity to D&D rules. BG2's system is obviously based on AD&D second edition but it's a different system, and makes lots of changes to better fit a CRPG setting (as well as many changes inspired by D&D 3e).

This is documented, actually: removing clone quickslots is one of the spell-system changes, and all of them can be disabled in stratagems.ini. Sorry about that! I tend to find SCS's 'SFO' language fairly self-commenting - but of course, that's only true if you're familiar with its function library, and that's not documented at all.

SCS doesn't actually do this - I think it would be cheating to peek at a weapon's enchantment status. I mark up weapons to help creatures work out when their own attacks are ineffective (mostly this is unnecessary in EE, of course). SCS wizards cast their protection spells without reference to what weapon the enemy is actually using. (Though higher-level wizards tend to skew more towards carrying PMW and less towards carrying Mantle et al).

Right. It's BG/BG2 only, at least for now.

You need to edit the code in lib/hla.tph, specifically the grant_hlas and number_of_hlas functions. There's an argument that I ought to parse lunumab, but right now I don't.

Bartimaeus is right: that's how it is supposed to work. I'll have a look to see if it's broken somehow.

If you want to use v31 you're on your own, sorry.

Each one is tied to a BG2 scroll; anywhere the BG2 scroll turns up, the IWD one does too. The list of ties can be found in stratagems/iwdspells/data/iwd_arcane.2da

It's hardcoded. Look at the hla_level_minimum function, in lib/hla.tph, and also at the hard_minimum variable in the grant_hlas function (same location) if you want to try your own tweaks.

Locking this, now that 2.0.11 is out.

I've just released version 2.0.11, which fixes a few bugs and compatibility issues (notably, the nasty bug where you got granted the slayer power, lots of times, upon going to Watcher's Keep in Shadows of Amn). Bugfixes: - Slayer power is no longer granted (and re-granted, and regranted...) if you go to Watcher's Keep in SoA - slightly tightened the script that grants Bhaalspawn powers - Blocked a (rare) scenario where Balthazar or another NPC ally could get resurrected, mid-battle, as a neutral - 'Slightly improved cutscenes' was erroneously requiring Enhanced Edition - Imoen and Sarevok's banters should now be less interruptable (thanks to Jastey for advice on this one) Compatibility fixes: - Imoen's NPC dialogs no longer lead to a stutter-bug clash with Imoen Romance - Removed compatibility code with Iylos and Edwin, since those mods have updated to work without it - Enforced the requirement that Iylos and Spell Revisions are installed after Ascension - Melissan's spear ('spermel') is now patched correctly (and no longer throws a WARNING) if the beta fixes from BG2 fixpack are installed Links: Download the mod Download at GitHub Project page Readme EDIT: updated to 2.0.12 - the only changes are to translations. (Notably, the Russian translation has been fully updated.) EDIT: updated to 2.0.13. Changelog: Further Russian translation updates Updated Detectable Spells Guarded against Timestop detection variable not properly being deactivated EDIT: updated to 2.0.14. Changelog: Fixed a bug that was preventing some non-English translation lines being used properly Replaced outdated use of LONG_BOW as a synonym for MAGE_ALL in scripts (in rare cases this was causing compatibility issues with other mods)

There are two separate bugs here. - The missing splstate.ids is probably because you are using an older version of BG2EE. Ascension 2.0 uses features of the more recent versions; update to 2.5 and try again. - cdheld.eff is added by the Fixpack, which you have installed, and it is quite hard to see how another mod could have removed it. Is it possible you're using an out-of-date version of Fixpack? (If some mod is removing that file, it's likely to break quite a lot of things, not just Ascension installation.)

That's very bizarre. My best guess (if you're still around) is that the ascension.tra file has just got corrupted. Delete the mod folder; delete the contents of 'weidu_external/lang/ascension', re-download it, and try again.

I'm glad it does; otherwise the modder doesn't notice bugs. In this case, it was a clash between the beta fix component of BG2 Fixpack and Ascension - not game-breaking, but Melissan's spear ends up more powerful than it's supposed to be. Now fixed, but I'd probably never have known about it without that warning.

@vanatos: is this something you're likely to release in the next few days? If so I'll disable my current Ascension-side workaround for this issue.

Local variables are stored for non-joinables. (The engine represents them as an opcode-187 effect attached to the CRE file.)

I think I have it fixed on my side; no need to do anything on yours. The problem with removing the checks entirely is that (since banters are called randomly from time to time) you might by chance get the banter implausibly early. I assume that's why Imoen Romance's original writer added them, and it's why I put them into Ascension. They just need to be coordinated - but I've done that (locally) in Ascension now, so I think you can leave Imoen alone for this one.

I sort of feel this is the kind of thing that works okay on first implementation and then breaks a year later when some apparently-innocuous change gets made somewhere else. I think my suggestions of rewiring the Imoen dialog structure or, failing that, just enforcing that Imoen is installed first, are safer.

(Not tested.)

You can do it using the technology I discuss in the early part of this thread. It's a bit cumbersome, though, and it requires me to add some hooks for you (which isn't that easy for ICT). Have a look at my suggestion in the other thread. If that works for you (and no-one spots a problem), we're good. If not, we can talk about alternatives. (To be honest, it might at that point just be easier for Imoen to enforce an install order using FORBID_COMPONENT).

On Imoen romance compatibility: The problem is that as currently coded, Imoen romance needs to redirect Imoen redirections to new blocks: block 15 gets redirected to 'FD', blocks 18 and 19 get redirected to 'finalbreak'. I would be inclined to repurpose those hardcoded numbers for the new blocks instead: that is, in FinalConversation.d, I'd do Then, in the APPEND bit, you also include (These are just renamed copies of imoen25j's blocks 15, 18, 19.) That lets you avoid any modifications to the solar's script and any problems with Ascension or extra NPCs, without needing to allow explicitly for Ascension and without having to restructure Imoen's dialog. The downside is that if some other mod wants to interject into Imoen's comment to the solar, it'll interject at slightly the wrong place. But that strikes me as an edge case, and less serious than the alternative (which risks Imoen's dramatically critical final lines being skipped entirely). Comments welcome from people who spend more time with NPCs than me. (@Jastey ?)