guyudennis’ random questions

[jmerry]

13 minutes ago, guyudennis said:

 

@jmerry by “mode 1” you meant timing mode = 1 or para2 = 1?

Within the scope of what we were talking about, making innate wrappers to cast the original HLA spells, I would guess the target of 146/148 would always be Self? If that’s correct, then what’s the difference between those Opcodes, again within the scope as mentioned above?

By "mode", I mean parameter 2. Set it to zero, and the payload spell uses the caster level specified in parameter 1. Set it to 1, and the payload spell uses the caster's level to determine its caster level. That's what we want. Also, the casting animation now belongs to the wrapper spell, and the payload spell is instant with no animation.

The difference between opcode 146 and 148 is whether the payload spell targets a creature or a point on the ground. Either way, that final target is determined by the ability target of the wrapper spell, while the 146/148 opcode targets "self".

[Edit: added quote, since this ran onto the next page of the thread]

Edited February 4, 2023 by jmerry

[subtledoctor]

4 hours ago, guyudennis said:

don’t really catch what you meant here?

If Fireball has a range of 30’, and you make a spell that casts Fireball via op148, and you give your spell a range of 30’, snd then you cast your spell at a point 29’ away, then it will fizzle and nothing will happen. Why, I don’t know. Engine weirdness. You have to give your spell a range of 27’, and then if you cast it at someone 29’ away you will walk 2’ closer and then cast it. 

In this context, that would be important for Comet, Dragon’s Breath, Storm of Vengeance, etc. 

[guyudennis]

Thank you, both.

So in a nutshell, I should:

1. duplicate an existing HLA spl
2. edit the duplicate so that:
   1. its spell type is changed to innate
   2. optional: change its location to 4 (innate)
   3. keep only the 1st extended header and delete the rest if there are more than 1 headers; this preserves the original extended header's target, range, casting time and projectile (if any), etc
   4. modify the extended header so that its range is (original range minus 3)
   5. delete all the (extended) spell effects in the remaining extended header, and add an op146 (if the original HLA was targeting a creature [including self-targeting]) or an op148 (if the original HLA was an AoE)
   6. make sure the op146/op148 has SET target = 1 (self) parameter2 = 1 timing mode = 1 SPRINT resource = ~original HLA~

Correct? Did I miss anything else that's worth changing?

[subtledoctor]

1 hour ago, guyudennis said:

modify the extended header so that its range is (original range minus 3)

Only if it uses op148. No need for this with op146. 

EDIT - and the difference is not necessarily [AoE vs. non-AoE]. You use op148 specifically when the original spell has a value of 4 in the header target field. (Some AoE spells use different targeting. e.g. Hold Person. To do this with Hold Person you would use op146.)

EDIT 2 - here’s some code that does this in Weidu. Lines 2179-2210. 

Edited February 5, 2023 by subtledoctor

[guyudennis]

Thank you. That Hold Person example clarified my confusion.

[guyudennis]

Regarding op233...

I want to apply an ability through CLAB that (a) gives a kit 1 proficiency point if he doesn't yet have it, but (b) at the same time do nothing to an existing proficiency if he already has it.

When I use Set if Higher in para2, it achieves (a) but at the same time force overwrites any existing proficiency also back to 1. On the other hand, if I use Increment it increments everything, effectively also achieving (a), but it has the undesired side-effect of increasing any existing proficiency by 1, possibly exceeding what he can legally achieve through normal means.

What I am missing? Or is op233+Set_if_higher somehow bugged?

LPF ADD_SPELL_EFFECT INT_VAR opcode = 233 target = 1 parameter1 = 0x00000001 parameter2 = 0x00000059 timing = 9 resist_dispel = 2 END // modify proficiencies: bastard sword (89)

[subtledoctor]

It’s generally not a great idea to use that with kits. Effects are applied after CharGen so this can be problematic in starts higher then level 1 (SoD, SoA, ToB). 

What you could do is run an op326 effect checking for the proficiency value, and only apply the op233 spell if the proficiency is zero. 

[guyudennis]

Thanks. I will try that later.

[guyudennis]

Ok...call me stupid, or I'm not reading IESDP right...but op326 seems to only reference SPLPROT.2DA, while completely ignoring STATS.IDS?

Let's say proficiency showbow is listed as 105 in STATS.IDS, so I did this:

LPF ADD_SPELL_EFFECT INT_VAR opcode = 326 target = 1 parameter1 = 0 parameter2 = 0x00000069 timing = 1 resist_dispel = 2 STR_VAR resource = ~MY_CUSTOM_SHORTBOW_233_SUBSPL~ END

But when I check my main spell with 326 in NI later. it shows para2 = Class, as is listed in SPLPROT.2DA.

What am I missing?

[subtledoctor]

You need to add a new row to SPLPROT.2DA specifying the proficiency stat and the relation you want to use. See here, specifically the part adding a check for stat 115 (the added row to SPLPROT as well as the next block which identifies the new row number). In your case I assume instead of relation 8 you would use relation 1 to check if the stat equals zero.

[guyudennis]

Thanks, and done.

My misunderstanding came from mistakenly thinking op326 reads both stats.ids and splprof.2da with para2 < 0x100 triggering stats.ids. 

[guyudennis]

Say, if I wanted to change a particular (existing/new) priest kit so that his/her *divine* enchantment spells are harder to save the same way as his/her fellow wizardary specialist enchanter functions in that respect, how would I do it? There does not seem to have a particular opcode to apply these saving-throw-per-school-bonus to creatures directly...

[jmerry]

No easy solution.

- There might be something in EEex. I don't know, since I'm on a Mac and EEex currently only supports Windows or emulated Windows versions of the application.

- You can edit every spell you want this to apply to, turning them into wrappers that cast either the original spell or an altered version with tougher saves through a 326 filter. Naturally, this will be incompatible with all sorts of things. Also, "kit" isn't one of the options you can put into a SPLPROT filter. Thus, you need a marker effect on the caster that can be detected like this.

[guyudennis]

Thank you for the quick answer. I’m also one of those that cannot leverage EEex (I’m on Linux and MacOS).

[guyudennis]

Apart from using (OUTER)SPRINT my_var @tra_ref, are there any other ways to treat tra references as variables directly?

I'm trying to manipulate tra references conditionally at install time, using SPRINT and OUTER_PATCH_SAVE with a variable acting as a manipulateable placeholder for a tra reference, but I'm wondering if there're any other ways to let my alter the tra ref directly without the intermediate variable.