backstabibility

[Avenger]

Ok, so what you actually want is to split the 'backstab every hit' flag into two separate flags.

 

I suggest:

 

1 - disables invis requirement and position (as per original)

2 - disables position only

 

 

(This can be easily acquired with slight exe modding)

 

   if ((abilMain.attackType != ITEMABILITYATTACKTYPE_RANGED) &&
	(cds.stateFlags & STATE_INVISIBLE || (cds.m_BackstabEveryHit==1) ) &&
	cds.m_BackstabDamageMultiplier != 1) {

	if (creSource.o.EnemyAlly > EA_GOODCUTOFF || //not good
		cds.m_BackstabEveryHit ||
		ObjectCommon_InBackstabPosition(orTarget, orToTarget)) {

[the bigg]

I guess that would be even better, as you could then make an item (or whatever) that allows you to backstab from the front, rather than allowing that for every party member. I'd do this via mask, though:

bit 0 not used

bit 1 ignore invisibility

bit 2 ignore position

   DWORD backstabEveryHit = cds.m_BackstabEveryHit;
  BOOL iniIsLoaded = getIniBooleanValue();
  if (backstabEveryHit == 1 && iniIsLoaded)
  backstabEveryHit = 6; // so that the 'original' meaning of value == 1 is preserved
  if ((abilMain.attackType != ITEMABILITYATTACKTYPE_RANGED) &&
	(cds.stateFlags & STATE_INVISIBLE || (iniIsLoaded ? backstabEveryHit & 2 : backstabEveryHit)) &&
	cds.m_BackstabDamageMultiplier != 1) {

	if (creSource.o.EnemyAlly > EA_GOODCUTOFF || //not good
		 (iniIsLoaded ? backstabEveryHit & 4 : backstabEveryHit) ||
		ObjectCommon_InBackstabPosition(orTarget, orToTarget)) {

[Ascension64]

I could use scripts to apply 'backstab every hit' while invisible and remove it while not invisible, but that's not what I'd call 'straightforward'. Besides, the reason why I asked is that I thought that TobEx had to rewrite the full function (even if all you're doing is changing a single value); under that architecture, once you've rewritten CCreatureObject_TryBackstab to add an hack, adding another hack to the same function is essentially 'free' - or am I missing something?

You are correct. The code I have posted is actually straight from my local TobEx build.

@Avenger: feel free to re-use any code you like. I won't guarantee its efficacy though.

 

The rest

cds.m_BackstabDamageMultiplier is an all-or-nothing in vanilla, so extra values are workable.

A warning about using derived stats as 'ordinal data', stacking can give you undefined effects.

I can work around this through my current detour of CDerivedStats::operator+(CDerivedStats&). However, since #303 (0x12F) Spell Effect: Backstab Every Hit [303] only sets the cdsCurrent value (never touches cdsDiff), I think that no safeguard is required.

[Ascension64]

Description for backstab flag

 

-----Configurable Backstab Restrictions
Adds new item ability flag bit 25 'Toggle backstab restrictions'
When bit 25 is not set, only non-ranged items usable by thieves can be used for backstabbing
When bit 25 is set, items normally usable for backstabbing are unusable for backstabbing, and vice versa
For a ranged attack that hits, both launcher and ammo abilities are checked for bit 25 and backstabbing toggled if any one ability has bit 25 set

Examples:
	Usable by thief		Ranged		Bit 25 Off	Bit 25 On
Dagger		Yes			No		Backstab	No backstab
Warhammer	No			No		No backstab	Backstab
Arrow		Yes			Yes		No backstab	Backstab (bit 25 can be set either on Arrow or Bow)
Throwing Axe	No			Yes		No backstab	Backstab

Based on and incompatible with tob_hacks

Options:
-0: disabled
-1: enabled

[the bigg]

For a ranged attack that hits, both launcher and ammo abilities are checked for bit 25 and backstabbing toggled if any one ability has bit 25 set

What if bit 25 is set on both the launcher and the ammo?

Also: you might want to use [ code ] to make your table readable.

[Ascension64]

For a ranged attack that hits, both launcher and ammo abilities are checked for bit 25 and backstabbing toggled if any one ability has bit 25 set

What if bit 25 is set on both the launcher and the ammo?

Also: you might want to use [ code ] to make your table readable.

As described above, any one of them can be set to turn backstabbing on (identical to tob_hacks). This would allow turning backstabbing on via the launcher itself, or by specific ammo.

 

 

And here is your backstab every hit mod. A param2 value of 1 preserves vanilla behaviour.

-----Configurable Backstab Every Hit
Modifies the backstab every hit opcode parameter 2 to configure whether STATE_INVISIBLE and position matters in a backstab

Description
#303 (0x12F)  Spell Effect: Backstab On Condition [303]
Parameter #1: Irrelevant
Parameter #2: Type (bitfield)

Description:
The targeted creature(s) will backstab on the conditions set by the 'Type' field.

Known values for 'Type' are:
0 Normal conditions (attacker must be invisible, attacker must be in 90-degree arc behind victim)
1 Ignore invisible requirement and positioning requirement
2 Ignore invisible requirement only
4 Ignore positioning requirement only

Options:
-0: disabled
-1: enabled

[the bigg]

As described above, any one of them can be set to turn backstabbing on (identical to tob_hacks). This would allow turning backstabbing on via the launcher itself, or by specific ammo.

I would use 'if any one, or both, ability has bit 25 set' in the description for extra clarity - without it, it might be interpreted as 'if both are set, the behavior is toggled twice'.

 

And here is your backstab every hit mod. A param2 value of 1 preserves vanilla behaviour.

Cheers.

[Ascension64]

As described above, any one of them can be set to turn backstabbing on (identical to tob_hacks). This would allow turning backstabbing on via the launcher itself, or by specific ammo.

I would use 'if any one, or both, ability has bit 25 set' in the description for extra clarity - without it, it might be interpreted as 'if both are set, the behavior is toggled twice'.

I love semantics.

[lynx]

gemrb now supports this extra bit for backstabbing, but in the first incarnation. Will change it once we settle for something final.

 

Re Configurable Backstab Every Hit: why not just drop the type 1 and interpret it as a bitfield?

0 Normal conditions (attacker must be invisible, attacker must be in 90-degree arc behind victim)

1 Ignore invisible requirement

2 Ignore positioning requirement

 

So the previous 1 would become 3.

[the bigg]

Re Configurable Backstab Every Hit: why not just drop the type 1 and interpret it as a bitfield?

Because this way you don't have to edit spells and mods to match the new opcode synthax.

[Ascension64]

Re Configurable Backstab Every Hit: why not just drop the type 1 and interpret it as a bitfield?

Because this way you don't have to edit spells and mods to match the new opcode synthax.

I have a priority to preserve of vanilla behaviour. I am unsure what vanilla items use the opcode, though. IESDP says that the param2 value should be set to 1.

[the bigg]

I am unsure what vanilla items use the opcode, though.

Only the 'Assassination' HLA (spcl916.spl), which indeed uses 1 for param2.

[Avenger]

Preserving the behaviour of the original engine is important, even if it isn't used by the original game. (A mod may depend on it). Of course, if just a mod uses an obscure feature, a difference might be fine, in rare cases.

 

We can divert from the original behaviour only if: we cannot implement it (hehe), it is a bug which may harmed even the original game (fillslot action can even cause crash with its slot overwriting crap), the change doesn't affect the original, and wouldn't affect mods (unless the modder used some unspecified feature).