Version 8 released

[aVENGER_(RR)]

I found a major bug that causes installation failure (at least when I have SpellPack installed). Many of SCSII's components add/remove/shift around effects. A lot of reading and writing oftsets. This sounds pretty harsh, and this also happens with detectable spells as well, is the macros tend to bring out of bounds parse errors/mess up .spl and .itm files (don't know about .cre files).

 

Hmm, since Rogue Rebalancing uses the same Detectable Spells version as SCSII, this means that the RR components which use DS may be incompatible with SpellPack as well. I'll try running some tests when I get back from work.

[DavidW]

I found a major bug that causes installation failure (at least when I have SpellPack installed). Many of SCSII's components add/remove/shift around effects. A lot of reading and writing oftsets.

 

This sounds pretty harsh, and this also happens with detectable spells as well, is the macros tend to bring out of bounds parse errors/mess up .spl and .itm files (don't know about .cre files). The reason behind this is that effects in abilities and effect offsets sometimes (see IESDP) use SHORT instead of LONG, and you READ_LONG rather than READ_SHORT in many of them.

 

I'm unclear where the burden of responsibility rests here. SCSII installed fine on a vanilla (or BG2-fixpacked) install, last time I checked, so presumably each file I read is LONG in the vanilla case, and if it's breaking, it's because some other mod has changed LONG to SHORT. So what makes the SCSII choices wrong?

[Taimon]

The effects offset (0x6a) should always be a long and the index into the effects in the extended headers (0x90 here for the first ext. header, but this is not guaranteed) is a short. It most likely is a typo in scsII.tph:1198.

[Galactygon]

Hmm, since Rogue Rebalancing uses the same Detectable Spells version as SCSII, this means that the RR components which use DS may be incompatible with SpellPack as well. I'll try running some tests when I get back from work.

 

Detectable Spells works just fine with SpellPack, I have made some concessions due to that bug (DS originally mispatched my SPWI921.spl). Therefore RR should have no incompatibilities with SpellPack.

 

I'm unclear where the burden of responsibility rests here. SCSII installed fine on a vanilla (or BG2-fixpacked) install, last time I checked, so presumably each file I read is LONG in the vanilla case, and if it's breaking, it's because some other mod has changed LONG to SHORT. So what makes the SCSII choices wrong?

 

Yes, SCSII installs wonderfully over vanilla, and all of the AI enhancements work nicely with SpellPack. What I am talking mostly about are the Spell-changing components. I haven't tested them all, so I have no further bug reports.

 

What I know for certain is DS goes out of bounds as well, even though I haven't looked at it for long.

 

-Galactygon

[Galactygon]

Now that I had the time to take it apart, install it component by component, look through the macros, I will give you my results:

 

1.) I, on accident, had an older version of DS installed. I haven't looked into the older version of DS yet, but one thing is certain: the newer version of DS does not behave the way I described it a few posts earlier. Although it complains that 2 items I patched are corrupted. I made it sound scarier than it really was.

 

However, that still means some of the mods ought to update DS to something more recent.

 

2.) There is only one, not many typos in SCSII v8. Previous versions of SCSII caused more problems at installation, so I thought there were many more typos, but that doesn't matter now.

 

The typo I am talking about is under the action macro ~transfer_item_abilities_to_spell~. It is one line of code, not two.

 

This:

READ_LONG ~0x90~ ~item_eff_num~ // we only ever look at the first ability, so this can be hardcoded

should be replaced by this

READ_SHORT ~0x90~ ~item_eff_num~ // we only ever look at the first ability, so this can be hardcoded

and that fixes everything.

 

Now the drama is over, we can all go and enjoy SCSII. So far, I am by and large impressed with the AI. I will keep you posted, DavidW.

 

-Galactygon

[DavidW]

The typo I am talking about is under the action macro ~transfer_item_abilities_to_spell~. It is one line of code, not two.

 

This:

READ_LONG ~0x90~ ~item_eff_num~ // we only ever look at the first ability, so this can be hardcoded

should be replaced by this

READ_SHORT ~0x90~ ~item_eff_num~ // we only ever look at the first ability, so this can be hardcoded

and that fixes everything.

Yep, that looks like a bug. Thanks, I'll chase it.

[aVENGER_(RR)]

Now that I had the time to take it apart, install it component by component, look through the macros, I will give you my results:

 

1.) I, on accident, had an older version of DS installed. I haven't looked into the older version of DS yet, but one thing is certain: the newer version of DS does not behave the way I described it a few posts earlier. Although it complains that 2 items I patched are corrupted.

 

My testing confirms this as well. It seems that DS installs fine over SpellPack, except for two warnings which say that it was unable to patch SCRL07.ITM (Protection from Magic) and POTN33.ITM (Potion of Magic Blocking).

 

BTW, I've done a few preliminary tests with SpellPack + RR's tactical encounters and so far the only issue I've noticed was that Abi-Dalzim's Horrid Wilting is no longer party friendly so enemy casters will damage themselves and their allies when they use it. I guess this will affect SCSII as well as its Mages also make frequent use of that spell.

[DavidW]

BTW, I've done a few preliminary tests with SpellPack + RR's tactical encounters and so far the only issue I've noticed was that Abi-Dalzim's Horrid Wilting is no longer party friendly so enemy casters will damage themselves and their allies when they use it. I guess this will affect SCSII as well as its Mages also make frequent use of that spell.

 

Oooh yes.

[Galactygon]

BTW, I've done a few preliminary tests with SpellPack + RR's tactical encounters and so far the only issue I've noticed was that Abi-Dalzim's Horrid Wilting is no longer party friendly so enemy casters will damage themselves and their allies when they use it. I guess this will affect SCSII as well as its Mages also make frequent use of that spell.

 

Glad to hear that. I have addressed this in B5 by preventing the caster (the AI caster not the player caster) from taking damage, but that still leaves non-undead allies vulnerable.

 

In the end, I will probably end up reverting it to being party-friendly for the sake of the AI.

 

-Galactygpn

[Galactygon]

I've found what caused the install failure bug, that had to do with SPWI921.spl I was talking about earlier. Hence my omission of SPWI921.spl from SpellPack B5.

 

It was not DS, but rather an action macro ~mage_alacrity~ under SCSII/mage/mage.tph

 

The macro was reading incorrect offsets; it was looking at the casting feature block rather than every single ability at a time. I've rewritten that macro, so it fixes that bug and doesn't patch if there is no opcode 188 in the ability. Just copy and paste it (you might have to reformat the lines if the forums split them in two).

 

-Galactygon

 

DEFINE_ACTION_MACRO ~mage_alacrity~ BEGIN

COPY_EXISTING
~spwi921.spl~ ~override/dw#qalac.spl~
	READ_LONG 0x64 ~abil_off~
	READ_SHORT 0x68 ~num_abil~
	READ_LONG 0x6a ~fb_off~
	SET ~efftotalsofar~=0
	FOR (~abilsofar~=0;~abilsofar~<~num_abil~;~abilsofar~=~%abilsofar%~+1) BEGIN
		SET ~this_is_alacrity~=0
		READ_SHORT ~%abil_off%~+0x28*~%abilsofar%~+0x1e ~num_eff~
		READ_SHORT ~%abil_off%~+0x28*~%abilsofar%~+0x20 ~eff_off~ // <--
		FOR (~effsofar~=0;~effsofar~<~num_eff~;~effsofar~=~%effsofar%~+1) BEGIN
			READ_SHORT ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30 ~type~
			PATCH_IF ~%type%~=188 THEN BEGIN
				READ_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x3 ~power~
				READ_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0xd ~disp~
				READ_LONG ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0xe ~time~
				READ_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x12 ~prob1~
				READ_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x13 ~prob2~
				SET ~this_is_alacrity~=1 // If this is really improved alacrity, and not some subspell
			END
			~efftotalsofar~=~%efftotalsofar%~+1
		END
		PATCH_IF ~this_is_alacrity~=1 THEN BEGIN
			WRITE_SHORT ~%abil_off%~+0x28*~%abilsofar%~+0x1e ~num_eff~+1
			FOR (~indexabils~=0;~indexabils~<~num_abil~;~indexabils~=~%indexabils%~+1) BEGIN
				READ_SHORT ~%abil_off%~+0x28*~%abilsofar%~+0x20 ~index_eff_off~
				PATCH_IF ~index_eff_off~ > ~eff_off~ THEN BEGIN
					WRITE_SHORT ~%abil_off%~+0x28*~indexabils~+0x20 ~index_eff_off~+1
				END
			END
			INSERT_BYTES ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30 0x30
			WRITE_SHORT ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30 189
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x2 1
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x3 ~%power%~
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0xc 0
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0xd ~%disp%~
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0xe ~%time%~
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x12 ~%prob1%~
			WRITE_BYTE ~%fb_off%~+(~%eff_off%~+~%efftotalsofar%~)*0x30+0x13 ~%prob2%~
			~efftotalsofar~=~%efftotalsofar%~+1
		END
	END

END

[DavidW]

Sorry, can you clarify: is this a bug in SCSII - i.e., does the macro not do what it's supposed to do - or is it a case of being compatibility-unfriendly? I'm assuming the latter, as that spell seems to work the way it's supposed to on testing.

[Galactygon]

I'm assuming the latter, as that spell seems to work the way it's supposed to on testing.

 

It's both - sometimes you can get away with incorrect offsets or a switch between SHORT/LONG in a vanilla installation (I do not know why this mysteriously happens), but other mods that add/manipulate the file will cause errors unless all the offsets and whatnot are in order.

 

These "silent bugs" are wierd, and has caused me more than one headache in my tp2.

 

What I have done with the macro is:

1.) Corrected the effect offset from feature block offset. Originally, it was reading "0x6a Feature Block Table offset" (IESDP) and thought that would be the effect offset. It should have read the effect offset in each extension header (...+0x20) instead.

2.) Made sure the effect offset is read each time the macro is in a new extension header rather than only once in the case some mod (not mine) adds extra abilities.

3.) Only patch if there is an opcode 188 (Aura Cleansing), because if there isn't, the variables will not be defined by the time you add a new effect and the installer will return parse errors.

 

-Galactygon

[Taimon]

Another macro issue:

The nochunk macro can produce incorrect offsets in the CRE file.

[DavidW]

Another macro issue:

The nochunk macro can produce incorrect offsets in the CRE file.

 

I tentatively think this isn't correct; I've replied at SHS.

[Graoumf]

Hello David,

 

Nothing important but our translator noticed something strange in the .tra file:

 

@92=~All ToB priests who can cast 9th-level spells get HLAs~

 

@98=~All SoA priests who can cast 9th-level spells get HLAs~

 

Isn't it 7th-level spells instead?