I'd like to make a version of Web that only affects about a 5-10' radius around the target. The vanilla Web projectile has:
Trap Size: 256 Explosion Size: 256
That's more or less the only thing I can see that seems to relate to the effect radius. Does that 256 value correspond to the area of effect of Web (which I think is about 30' or 40')? So, would I reduce one or both of those values to about 50 to create a Web effect about 1/5 the normal radius?
@SirBatince - You need to edit each spell file for the druid/ranger-only spells to remove the "Cleric/Paladin" exclusion flag. The flag will be set (as shown below) for druid/ranger-only spells. Uncheck the flag.
How can I prevent a summoned CRE from being banished and at the same time prevent enemy spellcasters from wasting Death Spell (and other similar spells) ?
Is it enough to set its gender to NIETHER (like if it were a familiar)? The problem is that if I change its gender from SUMMONED to something else, then this CRE will not be considered as a true summon ----> it'll be possible to exceed the summoning cap of 5 CREs.......
Can anyone help me with Area modding please. I've ran into a problem with my closed doors - getting the grid lines appearing. This problem seems to be on all games, I've seen it on bgee and the screenshot is from iwdee. I've tried everything I can think of around pvrz and searched the internet for solutions. I'd really appreciate any help on this one, it's freezing up a couple of large mods for bgee and iwdee.
Edit: fixed it, turns out "Nearest Neighbour scaling" is my new best friend
The ini is there, but the bgee (without SOD) doesn't have the new palette for some reason. I haven't tested it. Add that bmp to your override and see if it works now. If it does work after that, it would be good if you add this to the support bugfix website, so it can be fixed in the next update.
Basically - I had a look at both bgee and SOD for you and the only difference I found was bgee missing that .bmp file which is references as a palette in the ini file.
@Luke93: I think you can fix this just by running ModMerge. It sounds like the problem is that the SoD resources simply don't show up in BG folders because they're stored separately on your device.
If you've run ModMerge already, I'm guessing it's a missing IDS entry or something.
Opcode #317 is supposed to set *only* the state/flag IMPROVED_HASTE (and not ordinary Haste), right?
I'd like to give a certain CRE the bonuses of ordinary Haste (parameter1 = 0) and at the same time don't want the AI be able to detect it... So the question is: opcode #16 or #317?
@Luke93 No, opcodes 16 and 317 function identically. Their parameter2 determines the form of Haste (Normal, Improved, Weak). All of them set STATE_HASTED. Improved/Weak function by setting an additional STATS value, which modifies the behavior of STATE_HASTED: 155 : IMPROVEDHASTE 185 : ANIMATION_ONLY_HASTE
The only difference between 16 and 317 is that some items/spells/abilities will specifically block/remove opcode 16 but not 317 (Monks are immune to opcode 16 but not 317).
You would have to alter the scripts that detect haste to check for those stats not being set, or better, set a dummy marker spellstate to check.
Would be better to use opcode 1 (timing 9) than to alter the base stat. Altering the base stat will be overriden by Bows/Throwing Daggers or any other item that sets APR. It's still not haste (Haste doesn't always grant +1 APR, it won't alter effect frequency Regen/Poison/etc..), but as long as it's close enough. It will stack with haste though, which could be too much.
I see (good point on the frequency regeneration/poison). Could you provide additional details about that dummy marker spellstate?
The fact is that I don't want the AI to be able to detect it because it's not supposed to be dispellable (thus the enemy should not waste Remove Magic and the like......)
The fact is that I don't want the AI to be able to detect it because it's not supposed to be dispellable (thus the enemy should not waste Remove Magic and the like......)
The AI shouldn't be detecting STATE_HASTE for Removal in the first place, or it will be wasting them on Whirlwind/Greater Whirlwind as well. Any scripts using it to target removal spells need to be fixed.
STATE_HASTE should only be detected to prioritize targets for Slow (which would be valid counter either way), or for recasting Haste on self.
The fact is that I don't want the AI to be able to detect it because it's not supposed to be dispellable (thus the enemy should not waste Remove Magic and the like......)
The AI shouldn't be detecting STATE_HASTE for Removal in the first place, or it will be wasting them on Whirlwind/Greater Whirlwind as well. Any scripts using it to target removal spells need to be fixed.
STATE_HASTE should only be detected to prioritize targets for Slow (which would be valid counter either way), or for recasting Haste on self.
If that's the case, I can safely use opcode #16 (parameter2 = 0) and I'm done, right?
There still are some scripts that check STATE_HASTED for remove/dispel magic. They are WRONG, but they still do it. If that's acceptable you can use the haste opcodes.
There still are some scripts that check STATE_HASTED for remove/dispel magic. They are WRONG, but they still do it. If that's acceptable you can use the haste opcodes.
If I had to guess, they check it in order to cast Remove Magic on someone who's just applied an oil of speed..... I mean, POTN14.itm doesn't use opcode #328, so checking for STATE_HASTED is probably correct in this case......
There still are some scripts that check STATE_HASTED for remove/dispel magic. They are WRONG, but they still do it.
Sorry to bother again, but this means that the AI may waste a Remove Magic against a sword spider summoned by WIZARD_SPIDER_SPAWN (it makes use of opcode #16 via mage06.itm)? Not a big deal (I think)......
Anyway, can you confirm that the scripts that check STATE_HASTED for remove/dispel magic do it in order to counter the effects from POTN14.itm (Oil of Speed)? I'm trying to learn how to make good combat scripts.....
Sorry to bother again, but this means that the AI may waste a Remove Magic against a sword spider summoned by WIZARD_SPIDER_SPAWN (it makes use of opcode #16 via mage06.itm)? Not a big deal (I think)......
Yes. Creatures that have inherit haste effects on their weapons, anyone using whirlwind attack/greater whirlwind attack, or any other non-dispellable form of haste will cause these scripts to waste dispel magic on them. It is strange that there is an opcode to detect dispellable effects, but no script trigger to do so.
Anyway, can you confirm that the scripts that check STATE_HASTED for remove/dispel magic do it in order to counter the effects from POTN14.itm (Oil of Speed)? I'm trying to learn how to make good combat scripts.....
AFAIK, there is no detectable difference between any source of haste, at least as used by the vanilla scripts for the purpose of countering haste. They only make a distinction of Normal/Improved Haste when deciding to re-cast haste on themselves.
You can detect whether the target has normal or improved haste, but neither the source or if it's dispellable.
Here's an example of one of those script blocks:
IF
RandomNum(3,1)
!GlobalTimerNotExpired("dbDispel","LOCALS")
!StateCheck(Myself,STATE_INVISIBLE)
!StateCheck(LastSeenBy(Myself),STATE_SILENCED)
!StateCheck(LastSeenBy(Myself),STATE_STUNNED)
!StateCheck(LastSeenBy(Myself),STATE_SLEEPING)
OR(7)
StateCheck(LastSeenBy(Myself),STATE_HASTED)
StateCheck(LastSeenBy(Myself),STATE_BLESS)
StateCheck(LastSeenBy(Myself),STATE_DRAWUPONHOLYMIGHT)
StateCheck(LastSeenBy(Myself),STATE_BLUR)
StateCheck(LastSeenBy(Myself),STATE_MIRRORIMAGE)
CheckStatGT(LastSeenBy(Myself),0,IMPROVEDHASTE)
CheckStatGT(LastSeenBy(Myself),0,STONESKINS)
THEN
RESPONSE #100
SetGlobalTimer("dbDispel","LOCALS",FIVE_ROUNDS)
ForceSpell(LastSeenBy(Myself),WIZARD_REMOVE_MAGIC) // SPWI302.SPL (Remove Magic)
END
It will waste the Remove Magic spell (or at least it wastes the time casting it, since ForceSpell is a cheat-cast and does not expend the spell) on any form of non-dispellable Haste, Bless, DUHM, Blur, Mirror Image, or Stoneskin, such as the Cloak of Displacement (Blur).
Thanks for clarifying. From what I see the fact that you cannot detect whether a certain opcode is dispellable or not seems to be the main problem ---> I'll add a feature request for that, it'd be so handy......
Comments
((flags_1st_tier BAND 0b00000010) == 0b00000000)
256 = 16' radius (often listed as 15' radius in spell descriptions)
80 = 5' radius
160 = 10' radius
they're in the same pool so i imagine it shouldn't be too far fetched?
Is it enough to set its gender to NIETHER (like if it were a familiar)? The problem is that if I change its gender from SUMMONED to something else, then this CRE will not be considered as a true summon ----> it'll be possible to exceed the summoning cap of 5 CREs.......
Edit: fixed it, turns out "Nearest Neighbour scaling" is my new best friend
Try adding this to your override folder
Basically - I had a look at both bgee and SOD for you and the only difference I found was bgee missing that .bmp file which is references as a palette in the ini file.
If you've run ModMerge already, I'm guessing it's a missing IDS entry or something.
That is not a solution for all those people who don't have SoD or play on mobile (where the two games are two different games.....)
I'll try adding the bmp file linked by @fluke13 and see what happens......
I'd like to give a certain CRE the bonuses of ordinary Haste (parameter1 = 0) and at the same time don't want the AI be able to detect it... So the question is: opcode #16 or #317?
Their parameter2 determines the form of Haste (Normal, Improved, Weak).
All of them set STATE_HASTED. Improved/Weak function by setting an additional STATS value, which modifies the behavior of STATE_HASTED:
155 : IMPROVEDHASTE
185 : ANIMATION_ONLY_HASTE
The only difference between 16 and 317 is that some items/spells/abilities will specifically block/remove opcode 16 but not 317 (Monks are immune to opcode 16 but not 317).
You would have to alter the scripts that detect haste to check for those stats not being set, or better, set a dummy marker spellstate to check.
Alternatively, I can use opcode #126 (also used by The Paws of the Cheetah) and modify by 1 the Attacks per round in the CRE file (offset 0x053)?
Altering the base stat will be overriden by Bows/Throwing Daggers or any other item that sets APR.
It's still not haste (Haste doesn't always grant +1 APR, it won't alter effect frequency Regen/Poison/etc..), but as long as it's close enough. It will stack with haste though, which could be too much.
I see (good point on the frequency regeneration/poison). Could you provide additional details about that dummy marker spellstate?
The fact is that I don't want the AI to be able to detect it because it's not supposed to be dispellable (thus the enemy should not waste Remove Magic and the like......)
STATE_HASTE should only be detected to prioritize targets for Slow (which would be valid counter either way), or for recasting Haste on self.
Anyway, can you confirm that the scripts that check STATE_HASTED for remove/dispel magic do it in order to counter the effects from POTN14.itm (Oil of Speed)? I'm trying to learn how to make good combat scripts.....
It is strange that there is an opcode to detect dispellable effects, but no script trigger to do so. AFAIK, there is no detectable difference between any source of haste, at least as used by the vanilla scripts for the purpose of countering haste. They only make a distinction of Normal/Improved Haste when deciding to re-cast haste on themselves.
You can detect whether the target has normal or improved haste, but neither the source or if it's dispellable.
Here's an example of one of those script blocks:
It will waste the Remove Magic spell (or at least it wastes the time casting it, since ForceSpell is a cheat-cast and does not expend the spell) on any form of non-dispellable Haste, Bless, DUHM, Blur, Mirror Image, or Stoneskin, such as the Cloak of Displacement (Blur).
Thanks for clarifying. From what I see the fact that you cannot detect whether a certain opcode is dispellable or not seems to be the main problem ---> I'll add a feature request for that, it'd be so handy......