Sword Coast Stratagems v34 (edit: 34.3) now available

[Graion Dilach]

On 9/20/2021 at 5:01 PM, DavidW said:

I should add that if any fan of SR and the IWD spells wants to do me a set of SR+IWD spell choices, I'd be happy to use them. I'm not sufficiently invested in SR to do it myself. The relevant files are in stratagems/[mage|priest]/spellchoices/[iwd|demivrgvs], in a hopefully-self-explanatory format - it's basically a matter of looking at the SR allocations and the IWD allocations and combining them.

(In principle you could also do it for the defensive spell choices in stratagems/[mage|priest]/spellchoices_defensive/[iwd|demivrgvs], although those are quite a lot more complex.)

I have a question for this one, actually.

Would it be possible to have a setting where these files are partially externalized out to somewhere to allow other mods expanding them? Similarly like how BP-BGT Worldmap uses the Worldmap folder to expand the default map with whatever data content mods throw there. This would allow other mod(der)s adding spells to the game allowing SCS to also pick it up and utilize (some of) these spells. Since these would be externalized, you could also offload the responsibility of compatibility maintenance to the projects utilizing them.

[DavidW]

1 hour ago, Graion Dilach said:

I have a question for this one, actually.

Would it be possible to have a setting where these files are partially externalized out to somewhere to allow other mods expanding them? Similarly like how BP-BGT Worldmap uses the Worldmap folder to expand the default map with whatever data content mods throw there. This would allow other mod(der)s adding spells to the game allowing SCS to also pick it up and utilize (some of) these spells. Since these would be externalized, you could also offload the responsibility of compatibility maintenance to the projects utilizing them.

Not really, for two reasons - one technical, one philosophical.

The technical reason is that putting a spell into SCS's spell-allocation list is only enough to get a mage to memorize it, not to cast it. Casting the spell requires a block in their script, and those blocks have to be written manually, one spell at a time. They can't be automated, because every spell has different requirements as to who would be a better or worse target and as to where it should be in the casting order.

The philosophical reason is that it wouldn't obvious to an end user that some problem with enemy AI is caused by a bad choice by a prior modder, rather than in SCS itself. I want to make sure (as far as I can) that SCS players have a good experience of the mod - I don't want to outsource responsibility of that to other mods.

[Graion Dilach]

Okay, makes sense (I was unaware that the casting blocks are specifically tailored to each spell, thought that's also procedurally generated). Thanks for the explanation!

[subtledoctor]

Why I try to focus on replacing existing spells instead of adding new ones, and making sure replacements have the same targeting and general tactical criteria as the one being replaced (e.g. Sunfire->Missile Storm).  Making new spells is fun, but generally only as shiny baubles for players to have fun with, or as special kit abilities or something.

[Guest Yeehaw]

It's okay to start a new playthrough as of now or should I wait a bit more?

[DavidW]

1 hour ago, Guest Yeehaw said:

It's okay to start a new playthrough as of now or should I wait a bit more?

I don't really know how to answer that. I mean: I don't intentionally release updates with serious bugs, so every time I release something, at the time of release it solves every serious issue I know of. Sometimes I learn of a new serious issue after release and then warn people there's a fix coming, but that's not the case now.

On the other hand, empirical evidence says that SCS releases often go through 3-4 releases to get stable, because while I do test things before release, inevitably my own testing is way less reliable than having lots of other people test it for me. So maybe there's a serious bug I've missed? There were on 34.0 (Aec'letec), 34.1 (SR compatibility) and 34.2 (issues with projectiles). Possibly there's one with 34.3 that no-one's noticed yet. 

My guess is that 34.3 is probably pretty stable, but it's only a guess. 

[Salk]

Hello, DavidW!

I don't know if it might have escaped your attention but I asked you a question here about SCS and I would be grateful for an answer, if possible.

I might add another question: is there a way to manually exclude some specific CRE scripts from being changed by SCS prior to installation?

Thanks!

EDIT: One last curiosity. It seems the size of SCS increased with 30-35% since v33. What's the cause?

Edited September 22, 2021 by Salk

[maus]

5 hours ago, Guest Yeehaw said:

It's okay to start a new playthrough as of now or should I wait a bit more?

In addiotion to DavidW's answer: Always start a new playthrough. If there is a serious bug in the way you install or play game, DavidW would be happy to know about it. And this is the only way to detect it

 

[DavidW]

3 hours ago, maus said:

In addiotion to DavidW's answer: Always start a new playthrough. If there is a serious bug in the way you install or play game, DavidW would be happy to know about it. And this is the only way to detect it

 

It's true that from my selfish point of view it's better to start a new playthrough, yes. But I don't begrudge someone wanting to wait a bit for the release to stabilize.

[DavidW]

On 9/19/2021 at 2:26 AM, Salk said:

A question, DavidW.

If I modify some creature's original script(s) and/or swap the original script(s) with a new one(s) before installing SCS, what does SCS do when it comes to it?

I'm asking because I customized a few combat scripts for some BG1 NPCs and was wondering if they'd be affected.

Thanks.

SCS looks in CRE files for scripts from a certain list (e.g., MAGE8). If it finds one, it deletes it and replaces it with a new SCS script, and also processes the CRE file for weapon proficiencies, spell allocations, etc. (There is some more complex functionality to handle the small number of scripts that have both combat and non-combat contents.

So: If you modify MAGE8, your modifications will be lost. If you replace MAGE8 with SALK01, SCS will skip the creature and your script will be unchanged.

[Salk]

Thanks, DavidW!

It is useful information. Is there a place inside SCS I can look for that list you mentioned?

[DavidW]

4 hours ago, Salk said:

I might add another question: is there a way to manually exclude some specific CRE scripts from being changed by SCS prior to installation?

Not without editing the code. Replacing the script with a new-named copy on the creatures you want protected is the simplest workaround.

(Though to some extent, if you want to prevent a generic combat script from being SCS-ified, you might want to ask if you want SCS at all.)

4 hours ago, Salk said:

One last curiosity. It seems the size of SCS increased with 30-35% since v33. What's the cause?

The new version of IWD Spells has a larger footprint - partly because of the resources for vanilla-BG2 conversion, partly because it's common code with IWDification and so contains the resources for IWD bard spells even though SCS doesn't implement them.

[Salk]

3 minutes ago, DavidW said:

(Though to some extent, if you want to prevent a generic combat script from being SCS-ified, you might want to ask if you want SCS at all.)

No, I do want SCS to handle all combat scripts except for 3-4 cases for which I created custom scripts for a few NPCs. Since they are not generic combat scripts then there should not be any compatibility problems after what you told me. 

Cheers! 

Edited September 22, 2021 by Salk

[DavidW]

1 minute ago, Salk said:

It is useful information. Is there a place inside SCS I can look for that list you mentioned?

It's not externalized, so you need to look in the code.

• for mages: the read_in_mage_scripts macro at the bottom of mage/mage.tpa.
• for priests: the read_in_priest_scripts macro at the bottom of priest/priest.tpa.
• for general AI: the read_in_combat_scripts macro at the bottom of genai/genai_shared.tph.

There are also some special cases contained deeper in the code, but that's most of them.

[DavidW]

1 minute ago, Salk said:

No, I do want SCS to handle all combat script except for 3-4 cases for which I created custom scripts for a few NPCs. Since they are not generic combat scripts then there should not be any compatibility problems after what you told me. 

OK, cool. Yes, that's a common situation, and you have the right solution: if you don't want SCS to handle your NPC's AI, you just need to write your own AI for them (which can just be a renamed copy of a vanilla script - all that matters is the name). Provided your script uses your modder prefix, SCS will definitely ignore it. (But make sure you don't leave a WTASIGHT or something lying around in the script list along with your custom script.)