DavidW

On 10/24/2020 at 3:27 AM, Guest ront said:

I think that the best question to ask if there is any ETA for the new version, given that the current version is not advised to be played by DavidW himself.

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.)

19 hours ago, subtledoctor said:

But really, SR - and every mod - should be using a unique modder prefix for every file it adds to the game... even, probably, for icons to be used in SPPR___ files.  Even, probably, for files that are native to a different game like IWD. 

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...

2 hours ago, jastey said:

There is no central registration for EET Worldmap locations.

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.)

On 10/23/2020 at 2:13 AM, Jarno Mikkola said:

So if we take a book from it's natural cover, if a monster is not a warrior, they should then get the Thac0 progression of a cleric in respect to their level rather than a fighters... so, is this so ? No. Same thing with most monster hit points being a d8 rather than d10.

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.

On 10/23/2020 at 2:13 AM, Jarno Mikkola said:

And why you do not ? You don't read the Thac0 table, you just assume the value, buy calculating it from the creatures level(upto 21 from what I can tell).

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?

On 10/23/2020 at 4:56 AM, Valdygar said:

But isn't the tolerance check made on the difference between 'possible' and 'current' regardless of whether or not that difference is positive (ruleset thac0 is higher) or negative (current thac0 is higher)? In that case, wouldn't that mean that this thac0 adjustment could not just worsen thac0 that are a bit too good, but also improve thac0 that are a bit too bad?

Yes. That's intentional, though I agree that the readme doesn't make that obvious.

8 hours ago, Valdygar said:

Is it supposed to only affect NPCs and not player characters, not matter its value?

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.)

8 hours ago, Valdygar said:

Do we have a rough idea of how many creatures are affected with the base value (6)?

No.

8 hours ago, Valdygar said:

Is it a couple of edge cases, or does it actually correct a large number of creatures?

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.)

8 hours ago, Valdygar said:

Does this mean that whenever this part of the code is evaluated, "current" is always a better thac0 than "possible"

'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.

8 hours ago, Ym22 said:

Greetings, it is the first problem I have after having used this mod for a year, it really gives the game a unique touch.
I already tried to download the file again, but nothing keeps getting the error: illegal 22-byte write (AP_D5_DUAFCAP_D5_DUAFC) offset 0 of 11-byte file INNER_PATCH_SAVE
Here the log:

SETUP-STRATAGEMS.DEBUG 181.8 kB · 1 download

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.)

5 hours ago, grodrigues said:

It works. Only installed the components I wanted from the gameplay tweaks, but no errors or warnings. I do not have time now, so I will leave installing the rest for tomorrow and if some new problem arises I will holler.

Thanks for the trouble you took and the speedy response.

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.

3 hours ago, grodrigues said:

Sure. Below is a zip with the weidu.log and the SCS debug file. The error appears first in the Improved Shapeshift component, but is not fatal, and then explodes in the NPC customization.

I should add that this is a regression as with SCS v33.4 and weidu 246 everything installed fine.

 

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

lib_evaluate.zip