weapon enchantment detection

[subtledoctor]

Quick request for clarification, and potentially a feature request (or if you like, an implementation request):

I gather that SCS uses stat 109 (listed as "CLERIC_HALLOW" in some IDS tables) for detection of weapon enchantment, via equipping effects with opcode 233 on weapons.  My question is how SCS detects this value.  I assume you use CheckStat(LT/GT)...?

The request is, if you don't already, you could switch to using the Proficiency(LT/GT) trigger when installing onto EE games.  This new trigger only looks at the first 3 bits of the stat in question, ignoring the Original Class proficiency values as well as anything in the 2nd, 3rd, and 4th bytes.  The upshot is, on EE games at least, this would open up the upper three bytes of stat 109 for use by modders, in ways that would reliably avoid conflicts.  Right now, as far as I know, there are only 2 stats that are completely unused by the game or by Detectable Spells etc., for a total of 8 bytes.  Plus two bytes in Tracking, though that's not as useful as a proficiency.  Having another 3 bytes to use would be a fairly substantial boon.

SCS may already do this; though my guess is that you stick with CheckStat to maintain compatibility with non-EE games.  Changing to the Proficiency trigger on EE installs would be extra work to achieve the same behavior; I suppose the point of this post is to highlight a benefit of such a change.

[DavidW]

I detect it with CheckStat, yes - but in fact I hardly ever use it in EE installs (WeaponCanHit()/WeaponCanDamage() do almost everything it needs). I'll look at whether I can incorporate this for the last few uses, but you can probably get away with using it for something else without seriously confusing SCS.

[DavidW]

& having understood the UI issue better, I can say that I won't be using that proficiency (or 110, CLERIC_ARMOR_OF_FAITH) at all in the final version of SCSv32. 

[subtledoctor]

Iiiiinteresting...

[Luke]

On 4/2/2019 at 11:55 PM, DavidW said:

... but in fact I hardly ever use it in EE installs (WeaponCanHit()/WeaponCanDamage() do almost everything it needs).

I'd like to know something about how you use these two triggers. Do you actually trust them?

I mean, they're great if the CRE in question has only one weapon, but what if it has 2 weapons with different enchantment levels (offset 0x60)?

For instance, let's consider DW2RP2GE.bcs (in particular a script block like the one in the spoiler tag below) and a CRE with ranged and melee weapons (e.g., ORC02.cre, BG2EE – its melee weapon 'SW1H07' is not magical, its ammunitions 'AROW02' are magical +1).

Spoiler

IF
	!StateCheck(NearestEnemyOf(Myself),STATE_INVISIBLE)	// Suppose this is true
	See(NearestEnemyOf(Myself))	// Suppose this is true
	Allegiance(Myself,ENEMY)	// Suppose this is true
	!Allegiance(NearestEnemyOf(Myself),ENEMY)	// Suppose this is true
	OR(2)
		WeaponEffectiveVs(NearestEnemyOf(Myself),MAINHAND)
		GlobalTimerNotExpired("seedefences","LOCALS")	// Suppose this is false
	OR(2)
		WeaponCanDamage(NearestEnemyOf(Myself),MAINHAND)
		GlobalTimerNotExpired("seedefences","LOCALS")	// Suppose this is false
	CheckStatLT(NearestEnemyOf(Myself),100,RESISTPIERCING)	// Suppose this is true
	OR(2)
		CheckStatLT(NearestEnemyOf(Myself),75,RESISTPIERCING)	// Suppose this is true
		GlobalTimerNotExpired("targetcompromise","LOCALS")
	Range(NearestEnemyOf(Myself),4)	// Suppose this is true
THEN
	RESPONSE #100
		SetGlobal("validtarget","LOCALS",1)
		SetGlobal("melee","LOCALS",1)
		EquipMostDamagingMelee()
		AttackOneRound(NearestEnemyOf(Myself))
END

 

If the currently equipped weapon is BOW03.itm with its corresponding ammo (AROW02) and 'NearestEnemyOf(Myself)' happens to be immune to normal weapons (op=120, param#2 = 2), then 'WeaponEffectiveVs(NearestEnemyOf(Myself),MAINHAND)' and 'WeaponCanDamage(NearestEnemyOf(Myself),MAINHAND)' will return true (because 'AROW02' is magical +1) => BUT its melee attacks will be ineffective (because SW1H07 is a normal weapon).

To sum up: the problem is that these two triggers always refer to the currently equipped weapon and this weapon may have a different enchantment level from the one you're gonna equip – Am I missing something? If not, how do you prevent this situation from happening without using custom spell states?

Edited September 23, 2019 by Luke

[DavidW]

It doesn’t in practice matter. If a creature has a ranged weapon, it tries to attack with it unless it’s hemmed in by meleers. Yes, there is an edge case where a creature is designated as an archer but nonetheless has a melee weapon better than its ranged weapon. But life is too short to catch that.

[Ardanis]

Also even if your melee weapon is useless against nearest target, it's still reasonable to switch to it to deny the enemy the melee bonus (+4 thaco/damage) he would otherwise receive against non-melee target.

[Luke]

On 10/1/2019 at 3:55 PM, Ardanis said:

Also even if your melee weapon is useless against nearest target, it's still reasonable to switch to it to deny the enemy the melee bonus (+4 thac0/damage) he would otherwise receive against non-melee target.

Good point, but it remains exploitable => I can simply send in the Mordekainen's Sword and order everyone else to attack with a ranged weapon...

These two triggers will hopefully solve this issue (provided they get implemented...)

WeaponEffectiveVs(O:Object*,I:WeaponNum*SLOTS,I:AbilityNum*)
WeaponCanDamage(O:Object*,I:WeaponNum*SLOTS,I:AbilityNum*)

They are meant to return true if the active creature can hit/cause non-zero damage to the target object specified in the 1st parameter using the weapon located in the specified slot and considering the ability in the extended header specified by the ability parameter.

Edited October 3, 2019 by Luke

[subtledoctor]

On 10/3/2019 at 4:56 AM, Luke said:

Good point, but it remains exploitable => I can simply send in the Mordekainen's Sword and order everyone else to attack with a ranged weapon...

These two triggers will hopefully solve this issue (provided they get implemented...)

WeaponEffectiveVs(O:Object*,I:WeaponNum*SLOTS,I:AbilityNum*)
WeaponCanDamage(O:Object*,I:WeaponNum*SLOTS,I:AbilityNum*)

They are meant to return true if the active creature can hit/cause non-zero damage to the target object specified in the 1st parameter using the weapon located in the specified slot and considering the ability in the extended header specified by the ability parameter.

God let's PLEASE not make SCS rely on platform-dependent executable hacks... it was reasonable back in the ToBEx days, because the whole game was basically platform-dependent back then.  But now it would deny access to a lot more players.

[Luke]

20 minutes ago, subtledoctor said:

God let's PLEASE not make SCS rely on platform-dependent executable hacks...

I was not suggesting that... I was simply saying Beamdog should implement those two triggers, they'll (hopefully) eliminate the edge case (probably not so "edge"...) me and DavidW were talking about.... Moreover, they'll simplify the so called "weapon handling", i.e., it'll be easier to script enemies that have more than one type of ammo and so fourth...

Edited October 6, 2019 by Luke

[DavidW]

I don’t care about blocking deliberate exploits.

[Ardanis]

On 10/3/2019 at 11:56 AM, Luke said:

Good point, but it remains exploitable => I can simply send in the Mordekainen's Sword and order everyone else to attack with a ranged weapon...

It's a valid tactic, not an exploit. The last thing I would want to see is enemies ignoring the tank sent in for distraction and pelting my mage with arrows instead. That's wrong on so many levels I'm not sure where to begin.

[Luke]

14 minutes ago, Ardanis said:

It's a valid tactic, not an exploit. The last thing I would want to see is enemies ignoring the tank sent in for distraction and pelting my mage with arrows instead. That's wrong on so many levels I'm not sure where to begin.

Please, enlighten me....

I mean, if you cannot damage the tank with your weapons, why should you stop from pelting the mage? Because in so doing the Mordekainen's Sword and similar would be useless? Mmmh...

Edited October 6, 2019 by Luke

[Ardanis]

Smarter AI doesn't always equal AI that is more entertaining to play against. This is one such case.

[DavidW]

From my point of view it doesn’t really matter whether it’s a valid tactic or an exploit!

That said, I’ve never really felt “tank” makes sense in the logic of D&D combat.