kjeron

9 minutes ago, subtledoctor said:

EDIT - looks like they are not from SCS. FIND_TRAPS is added by @kjeron's Trap Overhaul mod.

Confused - is it adding a duplicate spellstate for FIND_TRAPS, or is it adding the spellstate for FIND_TRAPS to an index already in use?

It still uses an older function that doesn't account for indexes listed in hexadecimal, and always adds new entries to the bottom of the file.  Aside from that it should account for occupied slots and any existing FIND_TRAPS spellstate.

(kit | 0x4000) will avoid the possible issue of whether "kit" already includes the 0x4000.

Alternatively just apply op181 to the kit.  timing=9, parameter1=12, parameter2=0.  Older game version will not display the "red"/unusable overlay in the inventory though.

If this is a Bard kit, know that certain instruments are setup as shields.  You can exclude them when applying op319, but not with op181.

3 hours ago, Fouinto said:

Hi,

Is it possible to make a colorblind component for scrolls* ?

The purpose of this component would be to show the "state" of each scroll (impossible to cast/learn for the current char, castable, learnable, already learnt) with something else than colors.

I don't even know if it's doable...

Thank you

Yes, at least in the EE's, the files used are STORTINT.BAM (red/unusable), STORTIN2.BAM (blue/unidentried), and STORTIN3.BAM (green/learnable).

These overlays apply to all items though, not just scrolls, and only one displays at a time, with priority going to blue/unid, then red/unusable, then green/learnable.

So it could show unidentified with a "?" in each corner, unusable with a  "X" in each corner, or learnable with a "O" in each corner, or nothing in none of those applied.

5 hours ago, Lianos said:

Regardless how low the intelligence is, lifeforms will still react because of reflexes. They would try to escape from the pain when beaten up or even strike back. These reactions are not tied to intelligence.

Since the game takes a different approach here (starting at the definition of intelligence) that renders the affected character incapable of performing any action, I think he is indeed helpless in terms of gameplay mechanics.

Morale failure still functions while feebleminded, which is what the game uses to handle that type of instinctual reaction.

They are still very much capable of trying to escape or retaliate, unless you've buffed them such that they no longer fear death.

24 minutes ago, Bartimaeus said:

Ah, sorry, misunderstood. O.K., will look into.

@kjeron Thanks. One of those could be used with like a duration of 1, I suppose, simply to trigger the helplessness state for a moment.

You would need to extend it to at least 2 rounds - the contingency only checks states once/round (modified by haste/slow).

25 minutes ago, Bartimaeus said:

I'm not sure what the exact parameters of "helplessness" are - do you know what other states qualify? I can't make the feeblemindedness state trigger helplessness by itself, but it might be possible to trigger it with another effect.

While both of them disable the player from selecting the character and their inventory,

• Helpless renders all attacks against the creature as automatic hits.  Most/all sources of Helpless also hold the creature in place and disable their AI.
• Feeblemind just disables AI scripts.  A feebleminded character is only helpless from the players perspective, no different from panic, confusion, or berserk.

Only the Sleep(39), Stun(45), Paralyze(109), Web(157), Hold(175), Hold2(185), and Puppet Stats(237 - project image) opcodes apply STATE_HELPLESS.  Anything that applies those opcodes effectively will as well.

Time Stop is functionally identical to helpless but does not actually set the Helpless state.

Not even being dead counts as helpless (normal, petrification, or frozen).

Not sure what you mean, they are all defined.

40 minutes ago, Lauriel said:

EDIT: Are these only used by save games?

Generally yes, technically no.

They are no different from any of the other sections, you can add them to the area file and they will function, there just isn't much reason to do so.

1 hour ago, subtledoctor said:

Setting the value to 2 is an option, I don't have any indication that it doesn't work...

Setting the value to 2 has the same inverted success/failure issue, it just replaces "luck" with (Constitution / 2 - 5).

RET makes no distinction between INT/STRING, whichever that variables was last set to before the function ends is what it will return as.

No, you can't set a string in a function and have it persist afterwards without using RET, no different from an integer.

If you want to break only one or the other, you can always add op160 or op136  as a global effect to the spell.

It's possibly more reliable than setting BIT9:

• unlike BIT9, it will still break them when cast through a sequencer/contingency.
• unlike BIT9, it will still break them when the spell is cast instantly through op146.

2 hours ago, Bartimaeus said:

Thanks for the fuller explanation of what's going on. And this change is brand new to 2.6 at least in regards to using item abilities?

Prior to v2.6, item abilities still broke invisibility when targeting others.

2 hours ago, Bartimaeus said:

Correct me if I'm wrong, but this seems like the EEs are now in a situation where you cannot imitate original game behavior. Original game behavior was that you can target yourself with single-target spells such as Cure Wounds (or indeed Magic Missile) without breaking invisibility...but nobody else, friendlies OR hostiles. Now the two options presented to you are you can either target everyone freely...or no-one, not even yourself. If so, I feel like this may have repercussions for SCS's AI spellcasting...

Correct

BIT10 (Hostile) breaks both sanctuary and invisibility, triggers "AttackedBy()", and allows it to be blocked by spell-level immunity when self-targeted.

BIT9 (Break Sanc/Invis) breaks both sanctuary and invisibility.

No spell or item breaks sanctuary or invisibility without either flag anymore, which was the whole point, to remove the previously hard-coded restrictions.

Damage still triggers "AttackedBy()", but has otherwise never carried the other effects of BIT10 "Hostile" by itself.

Magic Missile has never been and is still not considered "Hostile" as far as the game is concerned.  You could always cast it without breaking sanc/invis, they were only ever broken when casting it because you happened to targeted someone else - no different that casting Cure Light Wounds on them.

Items that cast spells instantly function no differently than spells that cast other spells instantly.  Instant casting generally ignores the subspells header flags.

Items/spells that cast spells non-instantly will generally respect those two flags in the spell header: scrolls in the vanilla game don't have either set and break depending on the spell they cast.

There are 4 sizes:

• L: Human (Male), Halforc (Male)
• N: Human (Female), Halforc (Female)
• M: Elf/Halfelf (same animation)
• S: Dwarf, Gnome, Halfling

It's not just about height though.

Elves have the skinniest body, which the wing animation accounts for, leaving gaps to avoid overlapping it.

The other animations also have various subtle differences, for example, the human male "head turn" proceeds in a different manner than elves, resulting in the wings turning to the left while the body turns to the right.

Even filtered through op177, the effect can still easily become permanent as per timing mode 1.

ACTION_PHP_EACH does not evaluate the array name, so the "bar" array is never considered. You would need to use:

ACTION_PHP_EACH ~%foo%~ AS k => v BEGIN

4 hours ago, Allbrother said:

Would that fix it? Or does 'unrecovarable' means it somehow blocks the ChangeGeneral action. If that works, we could set a variable for each general type (there's like what, 5?) prior to turning them into familiars then run this for each, right?

Unrecoverable as in there is no record of it's previous value.  You can still set it to anything you want afterwards.

4 hours ago, Allbrother said:

Apparently the act of summoning a critter somehow prevents it from becoming a familiar, but doesn't prevent it from having its allegiance changed to neutral. Which just blows my mind

Summoning does indeed have some weird internal mechanisms.

A summoned creature is also unable to Turn Undead, yet they may still Turn Paladins.

Follow the trail:

• Spell: Bolt of Glory (SPPR612.SPL)
  • SPPR612.SPL | Projectile: 359 | Bolt_of_Glory (BGLRY.PRO)
    • BGLRY.PRO | Smoke: 0x1010 | BOLT_OF_GLORY
      • 0101.INI | ResRef: BGLRYU

DECOMPILE_AND_PATCH indents the decompiled text, similar to how near infinity displays it, so it won't be the beginning of the line.  This is the first block of SHOUT.BCS during a DECOMPILE_AND_PATCH:

IF
  OR(2)
    StateCheck(Myself,STATE_STONE_DEATH)
    StateCheck(Myself,STATE_FROZEN_DEATH)
THEN
  RESPONSE #100
    SmallWait(5)
END

The multikit spell (QD_MCT01.SPL) applies immunity to itself through a separate subspell, preventing it from running a second time (it runs the first time on any trueclass character, since both trueclass and multikits share the default clab).

Also, because the multikit spell applies the individual kit abilities through separate subspells, the kit-scrubber can't remove any kit abilities of any previous multikit (I think only important it you try to change out of a multikit).  The EFFs use "cast spell", and that resource's effects are not touched by the kit-scrubber.  The first-level multikit spell (QD_MCT01.SPL) could probably include preceding op321 for each such subspell it applies and op172 each ability it grants to avoid this, but not tested.

27 minutes ago, CamDawg said:

Save is fixed, projectile is correct. IDMOLD is cast by the target of Mold Touch in order to spread it, so ignore center is there to force a spread target other than the mold source, the original victim.

If it's being cast by the disease opcode, then no, the target is not considered the source for "Ignore Center", the original caster is.  You would need to save and reload between triggers for it then default to the diseased.

For the same reason, Shroud of Flame should use "Ignore Center", since its subspell is cast through op333 and delayed, both so that the initial target is except from the aoe, and to enforce the MR check of the subspells effects.  Only the first, instantaneous trigger of op333 will use the original caster for "Ignore Center", all further triggers (or all triggers if it uses a delayed timing mode) will use the target instead.

Unrelated: Consider adding MISSILE.IDS entries for all added projectiles.

You need to move the "SmallWait(3)" down a line, after the "DisplayString()", but still before the "Continue()".

At it's current location, the "DisplayString()" from the block above, and the SetToken from the block below, occur simultaneously.  When this occurs, the new token takes priority, regardless of the order of the actions.  The following will set the token to "Bullet" before the string display occurs:

IF
    True()
THEN
    RESPONSE #100
        DisplayString(LastSummonerOf,71626)  // <ITEM-NAME>....
        SetToken("ITEM-NAME",6633)  // Bullet
        DestroySelf()
END

As will this:

IF
	True()
THEN
	RESPONSE #100
		DisplayString(LastSummonerOf,71626)  // <ITEM-NAME>...
		Continue()
END
IF
	True()
THEN
	RESPONSE #100
		SetToken("ITEM-NAME",6633)  // Bullet
		DestroySelf()
END

8 hours ago, lynx said:

If -1 works like that, that's more like an autohit than bypassing armor.

It's 32767, not (-1|65535), but you are correct that it is actually an autohit, no different than attacking a helpless target.

@Guest From the in-game description, "bypass armor" simulates touch attacks - bypassing AC from armor and shields, but not from other sources. IWD2 is the only game coded with such AC bonuses, as it's Armor Class opcode is setup differently.

1 hour ago, Chosen said:

I encountered the same issue and I think problem is green dragons use the same breath script used by the green dragon in the ToB (Fll'Yissetat?) so they deal damage as if they were great wyrms. We need a totaly different breath scripts for young and adult green dragons in Siege of Dragonspear. It is probably a case of zealous overwriting.  

The default Green Dragon Breath in SoD deals only 6d6 (save/half) at level 1 and 10d6(save/half) starting at level 14, which allows the two dragons to deal different damage amounts.

The default GDB in BG2 deals 24d6 (save/half).  It's the same resource, so it's possible something is overwriting it incorrectly.