kjeron

 

...but the AREATYPE check doesn't work. It always returns true.

No, you're wrong. It perfectly works on EE v2.5+.

 

Simply add the following row

NOTAREA   0x106   -1        9

to SPLPROT.2da and you're done (courtesy of @Argent77)

 

Good to see it's been fixed.

You would have to add your own entry to SPLPROT.2da, but the AREATYPE check doesn't work. It always returns true.

 

If a spell 'Level' is not specified, then the spell will be cast at level 1 and the damage opcodes will inherit the dice values of this effect, otherwise the spell will be cast at the given level.

This seems to diverge from most instances in the engine, where if you set the "cast at level" field to 0 it uses your caster level. The IESDP seems to suggest that this opcode could not be used with effects that involve caster level. Is that correct?

 

If the subspell is to scale, you have to specify every level:

Give the spell with opcode 333 50 ability headers, minlev 1-50, with opcode 333 in every header, casting at minlev.

 

It needs to store the casting level this way because the "Caster" of the subspell can end up being the target of opcode 333, rather than the caster of opcode 333.

This mostly occurs if you save/reload while the effect is active.

I *suspect* you could probably

 

- change the UI so that shamans auto-select some fixed spell(s) on levelling without the player noticing;

- take those spells away again via CLAB.

CHARGEN applies the CLAB after spell selection, level-up applies the CLAB before spell selection.

It's the same issue other divine casters face with removing spells at level-up.

The CLAB would have to remove them both instantly and on a delay, to remove the spells for both situations.

 

Each kit utilizing it would need a combination of 5 spells per level that they either cannot or must have, so the UI has enough to select at every level.

These spells would have to be available for selection to all shamans, but adding dummy spells for this would likely cause conflict with mods that add Priest spells, since there are only 50 slots per level.

 

The mod would now have to worry about compatibility issues with UI mods - would probably be best if a separate mod implements the UI changes, and others just tie-in when it's been installed.

 

This method would otherwise work.

 

The same section of UI.menu is used by Shamans and Sorcerers for spell selection, so Sorcerers could use this as well.

Any shaman/sorcerer using it would then provide a way to select spells each level (likely though dialog menus).

Which casting mode are each of the opcode 146/148 effects using?
Is "Spell1" being cast manually or by another spell/opcode?

This should work:
Spell1 has:
- header target = any location
- projectile "None - 1"
- effect 1 = opcode 146, cast spell, target = self, param2=1, resource = SubspellA
- effect 2 = opcode 318, target = self, condition = not enough hp, resource = Spell1
- effect 3 = opcode 148, cast spell at point, target = self, param2=(0 or 1), resource = SubspellB

SubspellA has
- projectile "None - 1"
- target = self, 6 points damage, reduce max hp by 6

SubspellB has:
- header target = irrelevant
- projectile = Produce Fire projectile (affects anyone in ~15' diameter)
- effect 1 = fire damage, target = preset target

 

1. I think there was consensus that splprot.2da "Evasion check" didn't work outside IWD:EE engine mode.

It's worked in the engine ever since (v2.0 for BGEE, v1.3 for BG2EE), the relevant file (splprot.2da) just wasn't included by default (just had to import it from IWDEE).

More importantly, the Spellstate assigned to Thieves in IWDEE serves no function (in any game) - the "Evasion check" has hardcoded conditions (Class/Level = Thief/7+, if your "Helpless").

 

The only limitation that I'm aware of is that following item types are not detectable: Bows, Slings, Crossbows.

"Launcher" abilities cannot be detected, "Ranged" self-made-ammo abilities (Gesen shortbow/Firetooth xbow) can be detected.

This behavior is similar to opcodes 301,341,361,362 - where the "Launcher" ability type (Special=4) doesn't function because they cannot be detected.

What if I want to cast Negative Plane Protection on an SD-ed mage? Shall we set all targetable buffs to power level 0 as well? I am not against that, necessarily, assuming there aren't any other repercussions from it, but I would like it to be consistent.

Power level 0 effects cannot be removed with opcodes 229/230.

doing a quick test I found a downside to the spell sequencer solution: it displays the spell sequencer active portrait icon and this can be confusing for the player. Is this unavoidable? If this is the case, given that in this specific application is very unlikely to occour the magical weapon overriding issue, I think maybe my original solution could be preferable...

As a permanent effect, it's unavoidable.

Putting it in the resurrection spell as instant/zero-duration will avoid the icon though.

Patch all the spell/item/s you want to be able to force their target to cast the spell, adding to them a create magical weapon effect:

ocode: 111 target: 2 timing: 0 duration: 0 resource: YOURFAKEITEM

You also remove any other temporary weapon they may have, since resurrection spells don't have checks against targeting living creatures. (Not that the game doesn't already have such problems - casting Resurrection on a living target will remove most temporary abilities).

 

You can also use Sequencers to force a creature to cast a spell on themselves through another spell:

Opcode 177: Target (Preset) Resource (EFF, Opcode 256: Resource (Spell), Parent Resource (ParSpell))

Opcode 258: Target (Preset), Resource (ParSpell)

(Spell) should have range of 32767(max). (Spell) will be cast by the target, on themselves, at their caster level.

(If the spell forcing the cast is AoE, use Opcode 260 instead of 258, and all effects in (Spell) need to target (Self).)

The Opcode 177 effect can be in the Resurrection ability, or just permanently (timing=9) attached to each creature that needs it.

The opcode 258/260 effect would go in each Resurrection ability, after the opcode 177 if present.

But, once you save, do you have to save again the next round to avoid being affected by the spell again? If so it would be necessary to do a reverse-save to stop it. (but that might interfere with repeated castings...)

When successful, the saving throw on opcode 333 both blocks the spell it would apply, and removes the opcode 333 effect, preventing further triggers.

 

Beltyn's Burning Blood and Shroud of Flame function this way (both IWDEE).

You can force a save every round in the EE with opcode 333 (Static Charge).

It forces a new saving throw for every trigger, terminating if it is successful.

The subspell would just be 6-second effects with no-save.

Opcodes 102/200/201/259 (those that specify a power level) only acknowledge power levels 1 through 9.

The other opcodes (those that only specify a total number of spell levels) do work, and will actually accept power levels up to 2^31 - 1, as can be specified in external EFF files.

Damage Immunity (Resistance >=100) no longer triggers an interrupt in the EE's, they made a hardcoded change to it in the release patch (v2.5.17.0).

Unrelated to the Concentration check from "CONCENTR.2da". It can be bypassed by applying an extra zero-damage effect of a non-resistable type (stunning, untyped), if you really wanted to.

 

Note: This behavior is not currently present in BG2EE (it's last patch was only v2.5.16.6).

If I had to guess the value (BIT2/4) comes from the Special Field of Opcode 12:

BIT2/4 = Fist Damage Only (except not restricted to damage in this case)

 

 

The same does not work with opcode 249, even with a "ranged" fist.

In other words, when the AI casts it expecting it to be Chaos, it gets virtually nothing out of it, while the player can use two mages to cast it twice upon a group of enemies at the same time (or three times), and those enemies are basically completely disabled for five rounds. I'm just not seeing the wisdom of this design. It's very strange to require the spell to be cast multiple times to have any material effect. I could see casting multiple times to enhance the effect, but the initial casting is just so weak.

It's only useless if the party just rested, it will stack with any natural fatigue they have accumulated (or from haste, if it still applies fatigue).

Non-party creatures do not naturally incur fatigue, so it will always require 2 castings against them.

What's really weird is that when I cast the spell upon myself twice or more, my THAC0 gets all screwy - from a consistent 7 (after the initial casting) to 4 on my first attack, 1 on my second, 0 on my third, 7 on my fourth, 2 on my fifth, etc. Don't know how it's calculating my base THAC0 there when the amount of fatigue should not be changing. Anyways, yeah, I'm thinking this spell may need to "simulate" fatigue rather than actually use the fatigue opcode.

Luck will not reduce the effective roll below 1 (or increase it above 20), so the displayed adjustment will depend on your base roll.

How do I decompile these to get human-readable .D files? I ran a DECOMPILE_DLG_TO_D patch on them, but I end up with only .DLG files in /override...

 

And NI's 'Export' action only produces .DLG files.

NI can 'Export' as "as DLG file' or "as Weidu dialog file" (.D file).

Use the export button on the "edit" tab, not the one under the "File" menu.

What's wrong with #bonecir.spl? Looking in NI, it looks okay.

I ask partly because # was the prefix I used in IWD-in-BG2, so that spell probably came into IWDEE directly from my converter. And it's auto-built, so if there's something wrong with it there might be a broader issue with some function I use - although those libraries have been revised lots since then.

In IWDEE it's signature is "SPL" instead of "SPL ".

The character probably won't display in the post, but its character 0x03, while it should be 0x20 (space).

The spell isn't actually used in IWDEE (it crashes if used).

Just for the record, you can't set you own rules for industry standard file format like "// key must start line and cannot contain whitespace". It's perfectly fine to have whitespace before key name for ini files. Nobody will create such file in the first place but in case of such whitespace, it should work. But I'm sure that the probability is extremely low so we are safe. Thanks for contribution.

I was just listing the limitations of what I wrote. I wasn't sure how whitespace should be treated. If the line is:

 text =value

is key variable " text", "text ", " text ", or "text"?

I'm sure the regexp can be adjusted to match.

Would REPLACE_EVALUATE be simpler?

OUTER_SPRINT configuration-default ~%MOD_FOLDER%/configuration-default.ini~
OUTER_SPRINT configuration ~%MOD_FOLDER%/configuration.ini~

DEFINE_ACTION_FUNCTION GetIniKeyValue
	STR_VAR filename=""
	RET_ARRAY ini_content
	BEGIN
		COPY - "%filename%" "%override%" // "COPY -" means no actual changes to the file
			REPLACE_EVALUATE	~^\([^ %TAB%%WNL%]+\)=\([^%WNL%$]+\)~	BEGIN
			// key must start line and cannot contain whitespace
			// value is everything after the "=" until the newline/end
				TEXT_SPRINT $ini_content(~%MATCH1%~) ~%MATCH2%~
			END	~~
END
PRINT "%configuration-default%"
PRINT "%configuration%"

LAF GetIniKeyValue STR_VAR filename="%configuration-default%" RET_ARRAY ini_content END
ACTION_IF FILE_EXISTS ~%configuration%~ THEN BEGIN
  LAF GetIniKeyValue STR_VAR filename="%configuration%" RET_ARRAY ini_content END
END
ACTION_PHP_EACH ini_content AS key=>value BEGIN
  PRINT "%key%: %value%"
END 

the effectiveness of that strategy is quite delicately dependent on the order in which the engine applies the sequencer components, and I don't know what controls that.

It's a combination of the order you select them for the sequencer, and the speed of each spells projectile. So depending on the set of spells it can be entirely reliable.

(Because, just so I'm clear: if (stat bit_g_e 2) returns true, then (stat bit_g_e 1) will also return true... right?)

No, I screwed that part up, but it can be fixed.

 

Make 4 subspells with Opcode 171:

one with 1x Opcode 171, one with 2x Opcode 171, one with 4x Opcode 171, one with 8x Opcode 171

 

Running spell applies:

Opcode 326: stat (1 << X) 8 subspell1

Opcode 326: stat (2 << X) 8 subspell2

Opcode 326: stat (4 << X) 8 subspell3

Opcode 326: stat (8 << X) 8 subspell4

Looks like the subspell adding the innates is removing them before adding the new one, resulting in there always being just "one".

Otherwise it looks like an issue with effect order, as I don't run into issues with a simple test of the effects.

As the title says. Can I generate a list of known wizard spells of level x through level y in a dialogue?

 

EDIT - or alternatively, create a list of spell scrolls currently in your inventory? That one should be possible... isn't it what Cromwell does?

Use Response/State Triggers?

HaveKnownSpell()/HaveKnownSpellRES() (EE only)

 

HasItem()

@Jarno: I don't think it's possible to do a "only up to 6 creatures"-type AoE projectile, though it is possible to make it apply to only party members. I don't think it's necessary if the spell only grants move speed bonus and +1/2 ApR and nothing else, especially when no other AoE buff has that sort of targeting, though.

It's simple in EE through the projectile:

Offset 0x200: BIT15

Offset 0x244: 6

Offset 0x246: 1

Hits 6d1 targets.