12 replies to this topic

[Ascension64]

An old request from G3 in the tob_hacks thread

Request to tweak 146 (cast spell at creature).

Atm param2 can be either 0 (cast normally, at the level specified by param1) or 1 (cast instantly at character's level). What my problem is, I've sorted all instances of 12 into several 'library' spells, so the original source instead 146s the library at the specified level.

Here is the problem - if I use param2=0 then items display casting gestures, even if the lib.spl itself has speed set to zero, and it stops te attacking sequence, so the char makes a shot then stands idly. Both problems can be solved by using param2=1, but then I can't store multiple headers in a single file. It's not that vital though, since there're not that many items that need to be tweaked.

Still, if it's not too complicated, I want to ask to let 146 recognize param2=2, which would cast instantly and take param1 into account as well.

The effect looks pretty straightforward.
A param2 = 0 sends a message that to ClearAllActions() and then adds ForceSpellRES(S:RES*, O:Target, I:CastingLevel) to the end of the action queue
A param2 != 0 sends a message that immediately executes the CastSpell() basic action

I don't know how this effect is normally used in the game, and for such spells do they have junk in param1?
So can someone point to me some spells I can have a look at?

Edited by Ascension64, 24 February 2011 - 02:12 AM.

[Galactygon]

The effect looks pretty straightforward.
A param2 = 0 sends a message that immediately executes the CastSpell() basic action
A param2 != 0 sends a message that to ClearAllActions() and then adds ForceSpellRES(S:RES*, O:Target, I:CastingLevel) to the end of the action queue

I don't know how this effect is normally used in the game, and for such spells do they have junk in param1?

May I request not to let param2=1 recognize param1? I abuse this behaviour extensively; this is going to break compatibility. Instead I suggest turning param2 into a bitfield with another few bits, like "switching level recognition", or "allow spellcasting interrupt", etc.

So can someone point to me some spells I can have a look at?

The chain lightning component (category Levels 4-6 wizard spells) of SpellPack B6 uses opcode 146 with multiple headers. Link

Note: If you are considering changing opcode 148 as well, param2=2 does something in vanilla that I abuse extensively. This isn't documented in the IESDP. It will cause the targettype specified at 0x02 of the feature block to launch the spell instead of the caster at their own levels without spell launch animations. To test this, add an effect with opcode 148 to any area effect spell with param1=1, param2=2 that casts another area effect spell.

EDIT: Here is my bitfield proposal for opcodes 146/148:
Bit 0: casting the spell uses character level instead of param1=level and casts the spell without animation/interruption
Bit 1: targettype specified at 0x02 of the feature block casts the spell (used by vanilla opc148, but would be consistent if opc146 used this as well). The spell is cast at the .cre's appropriate mage/priest/innate casting level without animation/interruption
Bit 2 (proposed) : Switches casting level behaviour. If bit 0 or 1 is aleady set, the effect will use param1. If bit 0 or 1 is not set, the effect will ignore param1 and use .cre mage/priest/innate level instead.
Bit 3 (proposed) : Switches spellcasting behaviour. If bit 0 or 1 is aleady set, the effect will cause the spell to be launched as a ForceSpell(). If bit 0 or 1 is not set, the effect will cause the spell to be launched as a ReallyForceSpell(), without animation/interruption.
... further bits as needed.
I can think of: spell casting interruption behaviour, unmemorize one instance behaviour

And a requested bugfix: If the .spl that uses opcode 146/148 is launched by a trap, the game is going to crash, because it will be looking at the source .cre when there is none.

-Galactygon

Edited by Galactygon, 19 February 2011 - 12:51 AM.

[GeN1e]

To be fair, I must admit that it is not a can't-do-the-thing-without-it tweak, but purely a matter of convenience - to not swarm the installation with lots of one effect long SPLs.

May I request not to let param2=1 recognize param1? I abuse this behaviour extensively; this is going to break compatibility

If param1=0 then it casts at caster's level for param2=0. Perhaps the same can (if not already) be retained for param2!=0?

[Galactygon]

May I request not to let param2=1 recognize param1? I abuse this behaviour extensively; this is going to break compatibility

If param1=0 then it casts at caster's level for param2=0. Perhaps the same can (if not already) be retained for param2!=0?

I can repatch all my stuff to use 0 for param1 (I am used to putting 1 in the days before it was covered in the IWSDP), but am going to grumble.

-Galactygon

[Ascension64]

My mistake, I swapped the description of behaviours around when describing the params. So, to clarify:

When param2 = 0 (cast normally), it is equivalent to ForceSpellRES(<Resource Key>, <target>, <param1>). If param1 = 0, then <param1> = caster level.
When param2 != 0 (cast instantly), casting ignores param1 and casts at caster level

So...

May I request not to let param2=1 recognize param1?

Yep, that's the default behaviour.

If param1=0 then it casts at caster's level for param2=0. Perhaps the same can (if not already) be retained for param2!=0?

Well, I don't know of any vanilla SPL/ITM using this effect (if you do know one, point me to it). I think it is possible but what param settings needs to be negotiated.

Note: If you are considering changing opcode 148 as well, param2=2 does something in vanilla that I abuse extensively. This isn't documented in the IESDP. It will cause the targettype specified at 0x02 of the feature block to launch the spell instead of the caster at their own levels without spell launch animations. To test this, add an effect with opcode 148 to any area effect spell with param1=1, param2=2 that casts another area effect spell.

EDIT: Here is my bitfield proposal for opcodes 146/148:
Bit 0: casting the spell uses character level instead of param1=level and casts the spell without animation/interruption
Bit 1: targettype specified at 0x02 of the feature block casts the spell (used by vanilla opc148, but would be consistent if opc146 used this as well). The spell is cast at the .cre's appropriate mage/priest/innate casting level without animation/interruption
Bit 2 (proposed) : Switches casting level behaviour. If bit 0 or 1 is aleady set, the effect will use param1. If bit 0 or 1 is not set, the effect will ignore param1 and use .cre mage/priest/innate level instead.
Bit 3 (proposed) : Switches spellcasting behaviour. If bit 0 or 1 is aleady set, the effect will cause the spell to be launched as a ForceSpell(). If bit 0 or 1 is not set, the effect will cause the spell to be launched as a ReallyForceSpell(), without animation/interruption.
... further bits as needed.
I can think of: spell casting interruption behaviour, unmemorize one instance behaviour

And a requested bugfix: If the .spl that uses opcode 146/148 is launched by a trap, the game is going to crash, because it will be looking at the source .cre when there is none.

I am yet to have a look at 148, but first I need to understand how ForceSpell() works in code.

Edited by Ascension64, 19 February 2011 - 05:18 PM.

[GeN1e]

When param2 = 0 (cast normally), casting ignores param1 and casts at caster level
When param2 != 0 (cast instantly), it is equivalent to ForceSpellRES(<Resource Key>, <target>, <param1>). If param1 = 0, then <param1> = caster level.

Mmm, that's the opposite way around:
if param2=0 (normally) then cast at param1, if param1=0 then use caster level
if param2=1 (instantly) then ignore param1 and use caster level

Vanilla scrolls have param1=10 and param2=0, and they cast at 10th level. BG2Tweaks' component sets param1 to 0, which allows for casting at caster's level.

Param2=0 is fully customizable, allowing both param1 and caster's level, but param2=1 is not.

I think the requester had not logged in because it was a guest (perhaps it was one of you?). If I understand the request correctly, the requester wants a param2 = 0 equivalent that allows a custom caster level.

That was me. Although, like I've said, it is more a convenience tweak than a necessity. Not to mention I'm not even going to need it soon, since I put on hold what I originally wanted it for.
The request was to equalize param2=1 to param2=0, allowing the use of custom caster level (param1!=0) for instant casting.

[Ascension64]

Right, yes, I made a few errors there.

It is actually going to be tough (not impossible) to create the exact param2 != 0 behaviour that is sensitive to param1, so if this isn't going to be of that much use, then I'd prefer from staying from it. The reason why param2 != 0 doesn't cause the creature to stop doing stuff is because it operates outside of the normal action queue.

So, I'll probably look at only

And a requested bugfix: If the .spl that uses opcode 146/148 is launched by a trap, the game is going to crash, because it will be looking at the source .cre when there is none.

Edit: I tested the use of this in-game and it doesn't seem to crash. Can you give an example?

Edited by Ascension64, 19 February 2011 - 06:34 PM.

[Galactygon]

Edit: I tested the use of this in-game and it doesn't seem to crash. Can you give an example?

Sorry, I mixed this up with a bug with opcode 177. Attached is Incendiary Cloud with a single header and a single effect. CLUA yourself to AR6012 and open the trapped bookcase. The game crashed on my install.

But there is a bug in that traps will not fire opcode 148 because it has a targettype "self".

Another question: have you tried attaching opcode 146 (with SPWI304) to the knock spell and used it on a door? IIRC that crashes as well.

-Galactygon

Attached Files

•  SPWI810.spl   202bytes   201 downloads

Edited by Galactygon, 20 February 2011 - 03:22 PM.

[Ascension64]

Sorry, I mixed this up with a bug with opcode 177. Attached is Incendiary Cloud with a single header and a single effect. CLUA yourself to AR6012 and open the trapped bookcase. The game crashed on my install.

Containers don't like Use EFF File. I think there is a memory deallocation issue here, which is a bug.

But there is a bug in that traps will not fire opcode 148 because it has a targettype "self".

Why? Aren't traps scripted to ForceSpell() at LastTrigger? The opcode itself looks as if param2 != 0 (cast instantly) casts at the EFF V2.0 destination point, whereas param2 = 0 (cast normally) uses ForceSpellPointRES(S:RES*, [-1.-1],I:CastingLevel).

Another question: have you tried attaching opcode 146 (with SPWI304) to the knock spell and used it on a door? IIRC that crashes as well.

Do you actually want something reasonable out of this? A door is not a creature and standard effects shouldn't work on it.

Edited by Ascension64, 21 February 2011 - 02:01 AM.

[Galactygon]

But there is a bug in that traps will not fire opcode 148 because it has a targettype "self".

Why? Aren't traps scripted to ForceSpell() at LastTrigger? The opcode itself looks as if param2 != 0 (cast instantly) casts at the EFF V2.0 destination point, whereas param2 = 0 (cast normally) uses ForceSpellPointRES(S:RES*, [-1.-1],I:CastingLevel).

My theory - and only my theory is that because containers cannot carry effects as a .cre would, it interacts with opcodes at an internal level (like knock, forinstance). They might've left opcode 148 out. Attached is Incendiary Cloud which casts Fireball via opcode 148. If you open that particular bookshelf at AR6012, nothing will happen, the fireball will not launch.
 SPWI810.spl   202bytes   206 downloads

Another question: have you tried attaching opcode 146 (with SPWI304) to the knock spell and used it on a door? IIRC that crashes as well.

Do you actually want something reasonable out of this? A door is not a creature and standard effects shouldn't work on it.

This came up when I was doing Great Shout, which is meant to open doors and damage creatures. It's using a cone shaped projectile that has the target inanimates flag ticked. I've placed a series of shell spells, and the behaviour was funky when cast over doors and groundpiles. The caster does cast the shell spell through opcode 146 on the groundpiles/containers/doors, but as if parameter2 were 0. Meaning that it will disrupt actions.

Attached are two files: find traps that casts magic missile on all containers nearby each round, and a knock spell that casts chain lightning with a delay of 2. Containers ignore the delay timing - the caster starts to cast chain lightning immediately, as if param2 were 0. Containers cannot store effects, so delays (and probably other timing modes not instant) are treated as instant.
 SPPR205D.spl   250bytes   210 downloads
 SPWI207.spl   394bytes   194 downloads

All I'm looking for is a consistent treatment of opcodes 146/148 (and a correction for opcode 177) when dealing with containers.

-Galactygon

Edited by Galactygon, 21 February 2011 - 12:35 PM.

[Ascension64]

and a correction for opcode 177

Yep, fixed.

My theory - and only my theory is that because containers cannot carry effects as a .cre would, it interacts with opcodes at an internal level (like knock, forinstance). They might've left opcode 148 out. Attached is Incendiary Cloud which casts Fireball via opcode 148. If you open that particular bookshelf at AR6012, nothing will happen, the fireball will not launch.

You've got more insight than I do (since I check the code all the time). Yes, containers only "respond" immediately to:

Use EFF File (this was bugged with a double delete) (0xB1)
Find Traps (0x96)
Knock (0x7D)
Cast Spell (At Creature) (0x92)
Summon Creature (0x43)
Summon Monster (0x7F)
Remove Projectile (0x111)

and they have different code implementations compared to casting on a creature.
There is no implementation of Cast Spell (At Point) (0x94)


I will have a look at the others. Note containers aren't doors, so doors operate with their own implementations again.

[Galactygon]

Remove Projectile (0x111)

What use does this have? Repeating explosions are not stored as containers/doors.

and they have different code implementations compared to casting on a creature.

This explains the inconsistency with opcode 146 param2=1 not being recognized.

I will have a look at the others. Note containers aren't doors, so doors operate with their own implementations again.

I only see opcodes 112, 122, 123, 140, 141, 170, 215, 243 having any use or relevance - but I doubt they were implemented. The developers had Hold Portal/Lock planned (see the icons for SPWI216 and SPWI109), there might be a small chance they started coding something along these lines.

-Galactygon

[Ascension64]

Remove Projectile (0x111)
What use does this have? Repeating explosions are not stored as containers/doors.

Same as normal except no fine-tuning (e.g. timing etc.). It simply sends a RemoveAirEffeccts message.

I only see opcodes 112, 122, 123, 140, 141, 170, 215, 243 having any use or relevance - but I doubt they were implemented. The developers had Hold Portal/Lock planned (see the icons for SPWI216 and SPWI109), there might be a small chance they started coding something along these lines.

Well, the answer is: doors have only the same effect opcodes implemented as per containers. It also has a Use EFF File problem, which I've fixed. 'Inventory' stuff won't work on containers, because their 'inventory' isn't implemented in the same way as a creature's inventory.

Edited by Ascension64, 24 February 2011 - 02:11 AM.