The engine attaches Opcode #18 directly to the Opcode #192 target. A zero-duration Opcode #101 with param2 = 18, placed before the Opcode #192, should prevent the Opcode #18 from sticking.
Unfortunately, that solution makes it so Opcode #18 can't be used at all in the current spell effects list, due to a bug with Opcode #101 not clearing out its internal immunity list correctly, (relevant if you wanted to customize the hitpoint modification, for example).
Question: when a new patch for the game is released, e.g patch 2.6, does every mod need to be updated to be compatible with the new version? And if yes, what warrants specifically the "changes" whenever a game update happens?
The obvious answer to question 1 would be "that depends on the changes the patch introduces" and "probably not all but most". To phrase it differently: to answer this question, one would need to know all mods and all changes of the patch 2.6.
For mods which are NPCs and quest mods for example it would be especially important if patch 2.6 changes state numbering again and changes the way quests triggers work (as they did for Thrix in SoD in the 2.5 patch, for example), these would need to be adjusted. If there are no changes to that, they should work without changes, unless BeamDog changed something that borks the current way of implementing kits or the likes.
So there's no difference between ANYTHING and ANYONE?
As you know, the trigger 'NearestEnemyOfType()' takes object selectors as argument. My question is: what's the point in setting an EA value (if any)? I mean, is there a point in writing something like 'NearestEnemyOfType(CHARMED.0.0.MONK)'? Shouldn't that 'Enemy' in the name of the trigger automatically pick all those object selectors of opposite allegiance (with respect to the active creature)? How does that trigger work exactly?
So there's no difference between ANYTHING and ANYONE?
As you know, the trigger 'NearestEnemyOfType()' takes object selectors as argument. My question is: what's the point in setting an EA value (if any)? I mean, is there a point in writing something like 'NearestEnemyOfType(CHARMED.0.0.MONK)'? Shouldn't that 'Enemy' in the name of the trigger automatically pick all those object selectors of opposite allegiance (with respect to the active creature)? How does that trigger work exactly?
1) That is correct - while they are separate EA values, they each define the same behavior.
2) Also correct, NearestEnemyOfType auto-populates the EA field of the object selector and immediately evaluates it, so it's useless to define the EA manually.
Does anyone know how to create a creature with a rectangular base, instead of circle?
I don't know but do you want to create the infamous gelatinous cube?
Actually it's for my Ice Wall spell, currently I'm using three invisible barrels as a work around. I've also been playing around with the idea of using creatures as destructible environments like walls, but this would really need rectangular bases ?
2) Also correct, NearestEnemyOfType auto-populates the EA field of the object selector and immediately evaluates it, so it's useless to define the EA manually.
If that's the case, then I guess the same holds for 'NearestMyGroupOfType' and the SPECIFIC field, i.e.: 'NearestMyGroupOfType' auto-populates the SPECIFIC field of the object selector and immediately evaluates it, so it's useless to define the SPECIFIC manually => Is that correct?
If that's the case, then I guess the same holds for 'NearestMyGroupOfType' and the SPECIFIC field, i.e.: 'NearestMyGroupOfType' auto-populates the SPECIFIC field of the object selector and immediately evaluates it, so it's useless to define the SPECIFIC manually => Is that correct?
I've been trying to use Near Infinity to create a weapon that will cast a spell on a backstab, cast a different spell on a crit, and cast yet another spell on a backstab that is also a crit. The first two were easy enough to figure out, but getting it to do something special on a critical backstab is proving insurmountable. Any of you folks who actually know what you're doing have any ideas?
I've recently found out that 'SpellRES()', 'ForceSpellRES()', 'ReallyForceSpellRES()' and the like support a third parameter, i.e.: I:CastingLevel (in so doing, you can instruct a creature to cast the specified spell as if it were at the specified level – that's really handy).
to ACTION.IDS without the risk of screwing something up?
Could you also confirm that the same does not hold for the non-RES versions – for instance, '113 ForceSpell(O:Target,I:Spell*Spell,I:CastingLevel)' does nothing (i.e., the spell will be cast using creature's level instead of the specified one...)
@Luke93: Correct, the RES variants treat the first I: parameter as the casting level. The non-res variants treat the first I: as the spell id - so it doesn't apply to them.
There should be no issue appending the altered signature(s), (just don't remove the originals and you should be fine). I guess it depends on how the script parser you are working with handles it, but NI works just fine, so I assume the rest will too.
Could you also confirm that the same does not hold for the non-RES versions – for instance, '113 ForceSpell(O:Target,I:Spell*Spell,I:CastingLevel)' does nothing (i.e., the spell will be cast using creature's level instead of the specified one...)
Most likely because it expects the level value in the same integer slot as the spell.
Here's SpellLevelRES("SPWI112",(target),1):
1 0 0 0 0"spwi112" ""
While this is SpellLevel((target),2112,1) (2112 = SPWI112):
AFAIK it's not an issue for BCS scripts, since they're already compiled, but for dialogs and weidu, it will cause problems.
The engine will only look at the first instance of a unique label when running dialogs, while weidu expects you to use the last instance.
A dialog with the action:
Weidu's problem is similarly related to the ordering, except it will still install successfully so long as both action variants are still listed in ACTION.IDS, though it will still spit out parse warnings.
Yep, you're right, just tested.
Hopefully, it's not that bad. I find them useful when scripting creatures like Balors – if you follow P&P, you should set Level to 13 but Caster Level should be 20 => 'ReallyForceSpellLevelRES("RES",(target),20)'.
In so doing, you can avoid creating aliases of existing SPLs that scale with level / setting the creature's Level to 20 (see OHNVBALR.CRE).
Most likely because it expects the level value in the same integer slot as the spell.
Here's SpellLevelRES("SPWI112",(target),1):
1 0 0 0 0"spwi112" ""
While this is SpellLevel((target),2112,1) (2112 = SPWI112):
2112 0 0 1 0"" ""
Sorry, what are you saying exactly? Is it actually possible? I mean, it's not that relevant since the RES variant also works for SPELL.IDS entries, but...
Sorry, what are you saying exactly? Is it actually possible? I mean, it's not that relevant since the RES variant also works for SPELL.IDS entries, but...
Not possible, it's as @Bubb described - the non-RES versions reserve the first integer slot for the spell (2112) instead of caster level, so it doesn't work.
Sorry, what are you saying exactly? Is it actually possible? I mean, it's not that relevant since the RES variant also works for SPELL.IDS entries, but...
Not possible, it's as @Bubb described - the non-RES versions reserve the first integer slot for the spell (2112) instead of caster level, so it doesn't work.
Does anyone know how I can give a character the ability to cast a spell? I already created an innate spell that will hopefully do what I want, but I need the character to be able to cast it once per day and I'm not sure what code to use.
I'm thinking it's ADD_KNOWN_SPELL, but I need to add this to an existing CRE file as the result of a banter. And I'm not sure if that's actually possible. Any ideas? I need to do this with several different spells over the course of several different banters so a solution that doesn't involve continuously copying and patching the CRE file would be preferred.
If a spell is flagged as IS_REMOVED, the engine removes it from a character's known spells / removes all memorizations on initial chargen. I suppose the main use would be to allow a spell to be "removed" in a patch, and then any old characters you import will have the spell automatically removed. (This isn't checked for levelups, only once at chargen).
Comments
An idea about this bit, not sure about the rest.
The engine attaches Opcode #18 directly to the Opcode #192 target. A zero-duration Opcode #101 with param2 = 18, placed before the Opcode #192, should prevent the Opcode #18 from sticking.
Unfortunately, that solution makes it so Opcode #18 can't be used at all in the current spell effects list, due to a bug with Opcode #101 not clearing out its internal immunity list correctly, (relevant if you wanted to customize the hitpoint modification, for example).
The obvious answer to question 1 would be "that depends on the changes the patch introduces" and "probably not all but most". To phrase it differently: to answer this question, one would need to know all mods and all changes of the patch 2.6.
For mods which are NPCs and quest mods for example it would be especially important if patch 2.6 changes state numbering again and changes the way quests triggers work (as they did for Thrix in SoD in the 2.5 patch, for example), these would need to be adjusted. If there are no changes to that, they should work without changes, unless BeamDog changed something that borks the current way of implementing kits or the likes.
For instance, 2.5 made some under-the-hood UI changes necessary to mod some spells.
But Beamdog refuses to answer.
Beamdog's initial ETA was December, 2018. I was referring to November of the same year.
I don't know but do you want to create the infamous gelatinous cube?
1) That is correct - while they are separate EA values, they each define the same behavior.
2) Also correct, NearestEnemyOfType auto-populates the EA field of the object selector and immediately evaluates it, so it's useless to define the EA manually.
Actually it's for my Ice Wall spell, currently I'm using three invisible barrels as a work around. I've also been playing around with the idea of using creatures as destructible environments like walls, but this would really need rectangular bases ?
If that's the case, then I guess the same holds for 'NearestMyGroupOfType' and the SPECIFIC field, i.e.: 'NearestMyGroupOfType' auto-populates the SPECIFIC field of the object selector and immediately evaluates it, so it's useless to define the SPECIFIC manually => Is that correct?
Yep!
I've been trying to use Near Infinity to create a weapon that will cast a spell on a backstab, cast a different spell on a crit, and cast yet another spell on a backstab that is also a crit. The first two were easy enough to figure out, but getting it to do something special on a critical backstab is proving insurmountable. Any of you folks who actually know what you're doing have any ideas?
I've recently found out that 'SpellRES()', 'ForceSpellRES()', 'ReallyForceSpellRES()' and the like support a third parameter, i.e.: I:CastingLevel (in so doing, you can instruct a creature to cast the specified spell as if it were at the specified level – that's really handy).
My question is: can I safely APPEND the following
to ACTION.IDS without the risk of screwing something up?
Could you also confirm that the same does not hold for the non-RES versions – for instance, '113 ForceSpell(O:Target,I:Spell*Spell,I:CastingLevel)' does nothing (i.e., the spell will be cast using creature's level instead of the specified one...)
There should be no issue appending the altered signature(s), (just don't remove the originals and you should be fine). I guess it depends on how the script parser you are working with handles it, but NI works just fine, so I assume the rest will too.
Here's SpellLevelRES("SPWI112",(target),1): While this is SpellLevel((target),2112,1) (2112 = SPWI112):
The engine will only look at the first instance of a unique label when running dialogs, while weidu expects you to use the last instance.
A dialog with the action:
ForceSpellRES("SPPR111",Myself)will fail if they are ordered in ACTION.IDS as: while dialog with the actionForceSpellRES("SPPR111",Myself,15)will fail they are ordered in ACTION.IDS as Weidu's problem is similarly related to the ordering, except it will still install successfully so long as both action variants are still listed in ACTION.IDS, though it will still spit out parse warnings.Yep, you're right, just tested.
Hopefully, it's not that bad. I find them useful when scripting creatures like Balors – if you follow P&P, you should set Level to 13 but Caster Level should be 20 => 'ReallyForceSpellLevelRES("RES",(target),20)'.
In so doing, you can avoid creating aliases of existing SPLs that scale with level / setting the creature's Level to 20 (see OHNVBALR.CRE).
Sorry, what are you saying exactly? Is it actually possible? I mean, it's not that relevant since the RES variant also works for SPELL.IDS entries, but...
Fine, I apology for the misunderstanding.
I'm thinking it's ADD_KNOWN_SPELL, but I need to add this to an existing CRE file as the result of a banter. And I'm not sure if that's actually possible. Any ideas? I need to do this with several different spells over the course of several different banters so a solution that doesn't involve continuously copying and patching the CRE file would be preferred.
AddSpecialAbility(S:ResRef*)
Thanks. Would the special ability be the name of the spell itself? So AddSpecialAbility(Spellname)?
[HIDESPL.2DA]: Do you perhaps know what "IS_FINAL" and "IS_REMOVED" mean?
IS_FINAL appears to be unused.