type=1 // melee

type=2 // ranged

type=3 // magic (default)

type=4 // launcher with ammo

type=99 // all

COPY_EXISTING ~BASILG1.ITM~ ~override~
LPF ~ADD_ITEM_EFFECT~ INT_VAR type=2 opcode = 146 target = 2 timing = 1 probability1 = 100 probability2 = 0 duration = 0 parameter2 = 1 resist_dispel = 0 savingthrow = 4 savebonus = ~-4~ insert_point = ~1~ STR_VAR resource = ~PETALL_#~ END
LPF ~ADD_ITEM_EFFECT~ INT_VAR type=2 opcode = 146 target = 2 timing = 1 probability1 = 100 probability2 = 0 duration = 0 parameter2 = 1 resist_dispel = 0 savingthrow = 4 savebonus = ~-4~ insert_point = ~2~ STR_VAR resource = ~PETANI_#~ END
BUT_ONLY

ADD_ITEM_EFFECT is a little pricky, it only updates magic type abilities by default, but not melee/ranged:

SET type to the type of header to which the effect should be added or 99 for all types. Defaults to 3 (magic).

Also it should be "savingthrow" rather than "save"

I have rather vague recollections that equipped item effects apply in some specific order relative to effects attached to CRE directly. I.e. if you have immunity to that effect, it might work properly against activated abilities, but be ignored by equipped effects. Don't take my word for it, though, I don't remember exact specifics.

WRITE_BYTE offset & `BIT0 // remove the first bit flag

WRITE_BYTE offset | BIT1 // set the second bit flag

Or WRITE_SHORT / WRITE_LONG, if the field is large enough and you don't care to count it by the byte.

COPY_EXISTING potn26.itm override
  LPF ADD_ITEM_EFFECT INT_VAR opcode=265 target=1 parameter1=1 STR_VAR resource=testvar END

If you only one installation on one machine, i.e. you don't accidentally look in editor at one game and test another; and the script is actually working; and the effect itself works too under some circumstances; then there has to be some obvious error or typo in your blind spot.

I would suspect the target parameter. Or probability. Failing that, immunities or projectile, though it doesn't sound like you have a complex structure there.

As long as only blacksmiths are allowed to buy weapons, you can treat it as repairing the worn out item for the difference in cost.

I think savename.2da was added after debug dialog.

Pretty sure it's the same across all games. IIRC I didn't get a meaningful result for 5 and presumed it was the upper limit, or maybe I just didn't feel the need for more saving slots in debugging.

The quote is from SoD's debug.dlg.

You're better off editing the area then, especially since it's one encounter and not a general script.

You could also make him run away from area exits and into parts of area clear of PCs, but you can't really mark those without placing more triggers (though maybe invisible actors will do, I forgot if it's possible to have non-flying zero-space critters in vanilla). Plus it would probably involve doing extra AI work - from my experience, customized movement routine can take a while to develop, test and finalize.

PS

RandomWalkContinuous() is also an option.

No solution then, at least without editing areas. DavidW had to patch the Gov District to prevent Viconia's would-be-executors from conveniently placing themselves into prison.

That said, is there any reason to use RunAwayFrom() in battle scripts? Imo the only thing worse than enemy archers trying to run away from you through a solid wall instead of switching to melee is the enemy AI prioritizing targets based on their immunities.

I assume you're using 342? Do you overwrite the changed space value back to original? If yes, then stacked 342s are known to be buggy, clear it with 321 instead. If not, then I may not have understood the problem correctly.

Good question... In any case, the only thing I can think about is to use fixed duration (perhaps randomized via percentage probability, perhaps based on reading target's INT via splprot) instead of using intmod table and to 321 it a few seconds in advance. If maze's child effects inherit parent opcode's source string, then it should work.

Cast maze on someone and look at them in the save.

I can't *confirm*, but your observations and knowing that setting a trap fails if there're hostiles in visual range (blind thieves ftw, yes) lead me to believe the rule may apply to any actor, not just party members.

Right, I forgot you were a diehard luddite

Summons - there's usually no other way. It's just that they're too bad with timing to be considered a precise enough tool.

I'm sure I used save vs breath when it made sense to think of trap effects as physical attacks.

412 and 414 are just wrappers for the spls with actual effects. You can ~RemoveSpell(4412) SpellNoDec(4411)~ instead, this solve both the message and visibility issues.

As for not setting another trap... I'd just set a random reasonably lengthy timer between, tbh. Less problem, close result.

You could read the target's AC via splprot, temporarily set its save vs breath (since it's technically a dodge thing...) to the same value, then roll the saves instead of attacks.

I don't remember if it there was a trick to read myself when targeting someone else, however, so the attacker's thaco will be unaccounted for.

summoning invisible creature

When people will finally understand it's a no way to do things   

Maze effect is actually a combination of imprisonment and delayed freedom. Which means exactly what it does - if you cast freedom spell before maze expires, and then imprison the target for good, the hardcoded effect from maze will still activate and end the new imprisonment.

I think 321 should work, though.

Just tried it, and it works fine:

OUTER_PATCH_SAVE x ~Dorn's name is Keldorn Dornwood. KELDorn DORN Dorn.~ BEGIN
  REPLACE_TEXTUALLY CASE_SENSITIVE ~\bDorn\b~ ~Dorna~
END
PRINT ~%x%~

Hmm, now sure if it actually works as I expect it to, but what about ~\([^A-Za-z]?\)Dorn\([^A-Za-z]?\)~ ~\1Dorna\2~?

 though it would be even better if only those whose names start with "Door" would be affected.

Not very reliable because you'll miss things here and there, but I think this will work

READ_ASCII r door_name (32) NULL
PATCH_IF !(~%door_name%~ STRING_CONTAINS_REGEXP ~[Dd][Oo][Oo][Rr]~) BEGIN
  // PATCH_IF FILE_EXISTS_IN_GAME ...
END

Is this check really necessary - whether they have a script? Why not just extend the top of the script without a check? I've done this for area scripts, if there is no script, the baf becomes the script.

If EXTEND works with non-existing files, then I was unaware of it.

Also I haven't had any problems with doors' vision so far.

I guess you've been lucky then... I've had several bugs in SoD due to door's body blocking its own vision.

Door graphics are part of the tileset. Theoretically you could decompress tileset, read the desired tiles and then construct a BAM from the data, but practically this is slightly above the average WeiDU sorcery you can find around the forums, so I doubt there's anyone who'd even think about trying it.

But how can I target doors with Weidu, given that they have different names (though all start with "Door", I believe) and may appear in any order among info triggers and containers?

I'm not sure how can they be mixed up with triggers/containers, since they're all different structures.
 

MKDIR ~my_mod/door_scripts~ // or just make your own folder
<<<<<<<<door_extention.baf
IF
  Range(Player1,15)
THEN
  RESPONSE #100
    DisplayStringHead(Myself,~Player1 detected.~)
END
>>>>>>>>

OUTER_SET door_count = 0

COPY_EXISTING ar1000.are override
  GET_OFFSET_ARRAY doors 0xa8 4 0xa4 4 0 0 0xc8
  PHP_EACH doors AS i => r BEGIN
    READ_ASCII r+0x80 door_script (8) NULL
    PATCH_IF FILE_EXISTS_IN_GAME ~%door_script%.bcs~ BEGIN
      INNER_ACTION BEGIN
        EXTEND_TOP ~%door_script%.bcs~ ~door_extention.baf~
      END
    END ELSE BEGIN
      door_count += 1
      INNER_ACTION BEGIN
        COPY  ~door_extention.baf~ ~my_mod/door_scripts/ag#%door_count%.baf~ // use your own prefix instead of ag#
      END
      WRITE_ASCIIE r+0x80 ~ag#%door_count%~
    END
  END
BUT_ONLY
COMPILE ~my_mod/door_scripts~

MKDIR is not really needed, since you can make a folder yourself, but without it this example wouldn't compile standalone.
 
 

Doors do take useful scripts and can See()

They can, but they can't. Doors have unhealthy tendency to block their own line of sight, so See(), Detect() and Range([PC],30) will all fail about half the time. Only Range() targeting non-dynamic object - i.e. Player1 or LastSummonerOf(), but not [PC] - will work on both sides.

PS I f-ing hate this stupid forum shitware