V13 issues

[DavidW]

@Yangus: could you find the k#anna.cre file, turn it into a zip file, and upload it to this thread, please?

 

Here's a link to the zip file you need:

 

 

Download k#anna.zip from FileFactory.com

 

Sorry, I don't do these free file-download sites, they're too hassly. Email it to david dot wallace at magd dot ox dot ac dot uk if you aren't able to upload it to the thread (I lose track of who does and doesn't have upload rights)

[ScuD]

One more issue, just merely a typo. In scsii\help\help.tph there is dw#ghjmuy to dw#ghjmu.

[Yangus1]

Sorry, I don't do these free file-download sites, they're too hassly. Email it to david dot wallace at magd dot ox dot ac dot uk if you aren't able to upload it to the thread (I lose track of who does and doesn't have upload rights)

 

That's fine, I have just emailed you the file.

[ScuD]

Somehow "Improved Dragons" and "Improved Golems" when adding CRE immunity set the CRE effect property PARENT RESOURCE to %EFFSOUR.SPL. This looks like the usage of ADD_CRE_EFFECT issue. The issue was fixed by changing golem.tph lines 35-36 to

LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=55 duration=1 STR_VAR effsource="" END
LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=13 duration=1 STR_VAR effsource="" END

dragon tph line 78

LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=211 duration=1 STR_VAR effsource="" END

line 81

LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=13 duration=1 STR_VAR effsource="" END

line 86-87

LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=55 duration=1 STR_VAR effsource="" END
LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=13 duration=1 STR_VAR effsource="" END

line 484-486

LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=55 duration=1 STR_VAR effsource="" END
LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=211 duration=1 STR_VAR effsource="" END
LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=13 duration=1 STR_VAR effsource="" END

And probably line 2594 in scsii.tph to

LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=206 timing=1 parameter1=~-1~ STR_VAR resource=EVALUATE_BUFFER ~%resource%~ effsource="" END

Maybe this issue is harmless, but I think it still worth the attention.

[Guest temujin.]

Somehow "Improved Dragons" and "Improved Golems" when adding CRE immunity set the CRE effect property PARENT RESOURCE to %EFFSOUR.SPL. This looks like the usage of ADD_CRE_EFFECT issue.

 

this is a WeiDU bug regarding functions not setting variables properly to their default values if they are not set in the caller's environment. I already mentioned this to David, but I dunno if he was planning to fix it though)

 

(in case you're curious, that %EFFSOURCE% is actually an internal variable in the ADD_CRE_EFFECT macro defined within Weidu itself; see weidu/src/tph/include/g_macros.tpa {477})

[ScuD]

Yep, I've already found that in WeiDU source Unfortunately haven't managed to find a way to fix. I hope my fix is the correct way to do that (at least the CRE files are correct, I've made a comparison after an installation with and without it).

[Guest temujin.]

I think it's the correct way to fix, but there's something else I forgot to say.

 

It's not just the effsource variable which needs to be manually set, there are other variables as well which may be used in earlier function calls that need to be reset to default.

 

 

for example, consider this code fragment (in dragon.tph):

 

COPY_EXISTING
			~bazdra02.cre~ ~override~
			 	LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~ INT_VAR opcode=101 parameter2=211 duration=1 END
	 BUT_ONLY

 

 

after installing, notice the 'Unknown' field at offset 0x91C (i.e. the result of the added effect in bazdra02.cre)

 

 

It contains these HEX characters: 53 50 50 52 35 30 35 44

 

In ASCII, this translates to: SPPR505D

 

 

this SPPR505D is the value set to the 'resource' variable used earlier in a previous, unrelated function call in a different file (spell.tph)

 

		SPRINT ~resource~ $breach_array(~%i%~)			// sppr505d is the last element in this array
	LAUNCH_PATCH_FUNCTION ~ADD_ITEM_EQEFFECT~ INT_VAR opcode=206 target=1 timing=2 parameter1=~-1~ STR_VAR resource=EVALUATE_BUFFER ~%resource%~ END

 

you see, there are other variables whose values are getting carried over from elsewhere, that need to be manually set to default.

 

 

 

Sigh.

 

If you've read the thread in the WeiDU forum, this was apparently a "feature".

 

 

 

[Demivrgvs]

@ScuD: Okay, got it. It is a compatibility problem between SRv3 and SCSII. For some reason, SR just replaces SPWI319 with a spell that does nothing except cast SPWI524. I don't know why Demi does this rather than just copy SPWI524 into SPWI319's slot, but in any case, the make_spells_silent macro is nothing like clever enough to track through to a secondary spell and modify that instead. So it fails to make any changes. Because it fails to make any changes, it doesn't create the spell at all.

 

Your commenting out of "BUT_ONLY_IF_IT_CHANGES" helps to some extent, because it at least makes sure the spell exists, which in turn prevents the mod crashing when it can't find it. But there's still a substantial compatibility problem, because the mod is unable to make the changes it needs to make to the spell.

 

I can think of ways to fix this at my end, but they're a bit awkward, and until I understand more from Demi as to why SR works this way, I'm reluctant to go to the effort.

I suppose it's better if I fix this compatibility issue myself, will do asap in the next hotfix (where I'll also include a compatible simulacr.spl as discussed here).

[Guest deducter]

Regarding the following three components:

 

Move Vhailor's Helm into Throne of Bhaal

 

Vhailor's Helm is not absurdly powerful relative to some of the items that can be found later in the game, but it's a bit much for something that can be bought for cash at the start of chapter 2. This component moves it into the early part of the Throne of Bhaal expansion (see the spoilers for details).

 

Move the Cloak of Mirroring into Throne of Bhaal

 

You can't get the Cloak until later in the game; still, it's hugely powerful and could be argued to be unbalancing at the time it's introduced. This component moves it into Throne of Bhaal (see the spoilers for details).

 

Move the Robe of Vecna into Throne of Bhaal

 

Similarly, the Robe of Vecna - one of the most powerful items in the game for a spellcaster - is overpowered for something that can be bought in chapter 2, and so this component moves it into Throne of Bhaal (see the spoilers for details).

 

I have IR v2 installed, and that mod changes the stats on these items, but does not move them as per your mod. You added a compatibility check that automatically skips these three options. I recommend you re-enable the option to move these items even with Item Revisions installed.

[Demivrgvs]

Regarding the following three components:

 

Move Vhailor's Helm into Throne of Bhaal

 

Vhailor's Helm is not absurdly powerful relative to some of the items that can be found later in the game, but it's a bit much for something that can be bought for cash at the start of chapter 2. This component moves it into the early part of the Throne of Bhaal expansion (see the spoilers for details).

 

Move the Cloak of Mirroring into Throne of Bhaal

 

You can't get the Cloak until later in the game; still, it's hugely powerful and could be argued to be unbalancing at the time it's introduced. This component moves it into Throne of Bhaal (see the spoilers for details).

 

Move the Robe of Vecna into Throne of Bhaal

 

Similarly, the Robe of Vecna - one of the most powerful items in the game for a spellcaster - is overpowered for something that can be bought in chapter 2, and so this component moves it into Throne of Bhaal (see the spoilers for details).

 

I have IR v2 installed, and that mod changes the stats on these items, but does not move them as per your mod. You added a compatibility check that automatically skips these three options. I recommend you re-enable the option to move these items even with Item Revisions installed.

This is "my fault" not David's one. As soon as IR v3 is out (hopefully very soon) this problem won't exist anymore and David solution is the best one to avoid issues.

[ScuD]

A question about Detectable Spells. Shouldn't versions for SCS ans SCSII be the same? What about scsii.tph?

Related question about other mods - D0 Questpack and Revised Battles also use Detectable Spells. Do these mods use just a different versions of the same or DS are different (but compatible) for each mod?

[DavidW]

A question about Detectable Spells. Shouldn't versions for SCS ans SCSII be the same?

No.

What about scsii.tph?

No.

Related question about other mods - D0 Questpack and Revised Battles also use Detectable Spells. Do these mods use just a different versions of the same or DS are different (but compatible) for each mod?

 

Questpack's is compatible (more accurately: SCS fixes compatibility issues with questpack at install time). I don't know about Revised Battles; probably not, since it's quite old.

[Guest Michayel]

Forgive my ignorance please!

The first post on this thread points out three bugs/errors in v13.

I am eager to have another run-through of BG2, this time with SCSII, but I'm concerned that the download in its present state will not install/work properly, due to these bugs.

 

To quote the mod-author... this '...needs fixing'.

 

What would people recommend I do: should I use v12, should I wait, or should I go ahead and use v13 in its current downloadable state?

 

Thanks for any help - I am really looking forward to experiencing this first-class mod.

[DavidW]

Forgive my ignorance please!

The first post on this thread points out three bugs/errors in v13.

I am eager to have another run-through of BG2, this time with SCSII, but I'm concerned that the download in its present state will not install/work properly, due to these bugs.

 

To quote the mod-author... this '...needs fixing'.

 

What would people recommend I do: should I use v12, should I wait, or should I go ahead and use v13 in its current downloadable state?

 

Thanks for any help - I am really looking forward to experiencing this first-class mod.

 

Use v13.

 

The first bug will have little or no noticeable effect. The second "bug" is a compatibility problem with Spell Revisions, not a bug in its own right (I understand that a hotfix for Spell Revisions will shortly be released). The third bug is either harmless or very nearly so.

 

@ScuD: would you mind copying this comment of mine onto your original thread, to avoid scaring people off?

[Demivrgvs]

The second "bug" is a compatibility problem with Spell Revisions, not a bug in its own right (I understand that a hotfix for Spell Revisions will shortly be released).

David, may I ask what dw#sprfi and dw#sprco are for? I restored spwi319 and spwi320 to work as "normal spells" instead of casting the respective 5th lvl version, but the issue seems to be still there.