DavidW

No ETA, sorry. Not imminent, though.

According to your debug, you're still using 33.6. (Did you update from the github rather than from the official release? The former wasn't updated until more recently.)

v33.7 of SCS should fix the Cure Moderate Wounds issue.

These issues should hopefully be fixed in v33.7, now available to download.

Updated to version 33.7, mostly to fix a non-English-language problem that 33.5 created.

Got it. A glitch in the SCS adaptations for WEIDU 247 means that english-language strings aren't available for non-english installs, which leads to crashes if a string is missing in the non-english version. Fix coming soon (probably later tonight.)

OK, I can reproduce this. Let me investigate...

I agree with @subtledoctor that this is clearly an SCS problem. No, SR shouldn't be using a hardcoded non-prefix-guarded name for a resource, and yes, changing that might help to some extent, but ultimately, if my code is mangling a spell's name string then it's not working correctly, and needs fixing on my side. (I just haven't had a chance to sort it out.) FWIW I don't (quite) agree with this. I think of the IWD/BG/BG2 namespace as basically shared - mod files should avoid overlapping any of it (prefixes basically achieve this) but it's okay to move resources between them (unless there's actually namespace conflict). Otherwise you end up with a huge amount of unnecessary (and bug-inducing) work in doing resource transfer between games. I also think it's fine to follow BG2 naming conventions for child resources (SPWI315c.bam for SPWI315.spl's bam, SPWI315b.spl for SPWI315.spl's secondary spell, etc), provided you do it dynamically. The point of these naming rules is to avoid namespace conflict: if all resources either use modder prefixes, or dynamically conform to the rules, there's no problem*. (I think the SR problem is being caused because it's using a static name for a resource without a modder prefix.) *Well, provided you don't get namespace conflict within a single modder's files, something I'm getting increasingly worried about for my own mods...

And there can't be, really. Prefixes are invisible in-game, there's no good reason not to avoid duplication. But if two people want to put an area at the same point in the worldmap, they might both have valid artistic reasons to do so. Of course it's courteous to avoid clashes if you can do so without meaningfully harming your mod, but it can't be an absolute rule.

I am skeptical that this is the underlying problem. Normally, missing language strings should be replaced by the English-language ones, not cause install failures. Something may have been broken by the most recent function update; alternatively it may be a problem with whatever autoinstaller you are using. Can someone playing in German/Polish see if the problem repeats when installing manually (i.e. not with an autoinstaller)?

No. It's an extremely clever tool but it's clearly still a bit work-in-progress. But more importantly, there is plenty of room in the standard SPWI/SPPR space for the IWD spells, as demonstrated by the fact that IWDEE itself has them all present there. I can see that if you want to use a huge number of spell mods it would be helpful for some of them to use a tool like this, but IWDification just isn't a good choice for it. Among the reasons: you will break any extant mod that looks for the IWD spells via spell.ids (SCS, for one.) The amount of work required to fix mods to allow for that, and the number of bugs that would inevitably arise along the way, dwarf the advantages for what is a relatively edge-case scenario, especially as OlvynChuru's own mod is using this tool. (IWDification is more @CamDawg's baby than mine these days, but I strongly suspect I speak for him too.)

Second edition AD&D fairly consistently assumes that monsters have d8 hit dice and fighter THAC0s, and BG is pretty faithful to that. SCS follows their lead. I read the THAC0 table for anything with a PC character class. If it's a monster, it gets a hand-calculated THAC0. (Even if the player is using their own THAC0 chart, I've no way to tell if they want it to apply to monsters.) What makes you think I don't? Yes. That's intentional, though I agree that the readme doesn't make that obvious.

I don't *think* it applies to PCs but I'm not sure. (But PCs really should be conforming to the rules here in any case.) No. It's a fairly respectable number. (The reason for doing it is that vanilla BG/BG2 uses ad hoc THAC0 modifiers to make various creatures more powerful, in lieu of actually giving them their bonuses from weapon specialisation etc. Since SCS enforces the latter, there's a danger of overdoing it unless the ad hoc modifiers are reined back.) 'current' is the actually-possessed value. 'possible' is the value calculated from the creature's level according to AD&D rules. So if it always reverts to 'current' that means it never changes.

Great, happy to hear it.

It will be a compatibility clash with some other mod you have installed (probably one that rearranges proficiencies or similar); your mod list is very long so it's not easy for me to guess which, sorry.

You'll need to say what the problem actually is.

I already have some DEFINE_DIMORPHIC_FUNCTIONS (it's in Weidu v247 because I asked for it) and I update double-defined functions when I see them but I don't see a lot of advantages in systematically doing it - more accurately, the advantages are outweighed by the likelihood of accidentally breaking something.

Hang on. If those are PC-summoned fiends, they should just be going on an uncontrolled rampage. Attacking each other is permissible in that circumstance. So I’m not clear why this is a bug. (It’s also extremely difficult to see how anything in 33.5 could have changed this.)

Can you give me an exact reproduction scenario? And when you say 'again', do you mean you verified it as not happening on some previous build? - if so, which one? Thanks.

Unintentional, yes. I'll add it to the list to fix; in the meantime, you can CTRL-Y the dogs with a clear conscience.

There is a typo in '2da/dualfc.2da' - a missing space between two iterations of 'AP_D5_DUAFC', so that the file has 'AP_D5_DUAFCAP_D5_DUAFC' instead of 'AP_D5_DUAFC AP_D5_DUAFC'. I doubt it has much visible effect in-game in of itself (it only applies at 25th level) but it means the CLAB files are malformed, and that confuses SCS.

There is a typo in the file 'dualfc.2da' in Tweaks Anthology that's causing this (it's used in component 2450, 'give PnP class restrictions'). If you uninstall that component you should be fine. (Or you can fix it yourself if you like - edit 'cdtweaks/2da/dualfc.2da' in Notepad or similar, find 'AP_D5_DUAFCAP_D5_DUAFC' and replace it with 'AP_D5_DUAFC AP_D5_DUAFC', and then reinstall that component.)

You're welcome. The bug was actually quite general, albeit only showing up on some install choices - I'm pleased to have had the chance to catch it early.

v33.6 is now out, fixing the problem with grodrigues's install.

Can you try unzipping the attached file, putting it into stratagems/sfo/general, and seeing if it fixes the problem? lib_evaluate.zip