[code] Code fixes, aka stuff we can't fix

[Luke]

On 3/23/2022 at 7:13 PM, Bubb said:

Here's something that's up for debate, quoting past me:

  Reveal hidden contents

Bug(?): Should backstabs (which invert a creature's AC Dex modifier) make a creature with a Dex penalty harder to hit?

Could you confirm that

1. it's not restricted to thieves but to any CLASS/KIT listed in "backstab.2da" / "sneakatt.2da"
2. the attacker's weapon does not need to be suitable for backstabs / sneak attacks (i.e., not necessarily usable by thieves)

[Bubb]

10 hours ago, Luke said:

Could you confirm that

1. it's not restricted to thieves but to any CLASS/KIT listed in "backstab.2da" / "sneakatt.2da"
2. the attacker's weapon does not need to be suitable for backstabs / sneak attacks (i.e., not necessarily usable by thieves)

It's exactly this:

Quote

1) Attacker must have a backstab multiplier of 2 or higher
2) Attacker must be STATE_INVISIBLE
3) Attacker's weapon must not be RANGED

class/kit doesn't matter, sneakatt.2da doesn't matter, weapon backstab suitability doesn't matter.

Edit - And to clarify, RANGED is referring to Item ability -> Type = Ranged (2)

Edited March 25, 2022 by Bubb

[Luke]

12 hours ago, Bubb said:

It's exactly this:

class/kit doesn't matter, sneakatt.2da doesn't matter, weapon backstab suitability doesn't matter.

Edit - And to clarify, RANGED is referring to Item ability -> Type = Ranged (2)

OK, thanks for clarifying.

So if I enable "Game Option: 3E Sneak Attack", the whole thing does not apply...?

[Bubb]

9 hours ago, Luke said:

So if I enable "Game Option: 3E Sneak Attack", the whole thing does not apply...?

It still applies. Even though the backstab multiplier isn't used to calculate damage under "Game Option: 3E Sneak Attack", the creature still has its multiplier calculated / assigned.

[Sam.]

[Bug] The EEs do not support a compressed color index (offset 0xb) separate from the transparent color index in BAM files, as the classic engines did.

What is currently happening
The EE engine treats the compressed color index AS the transparent color and therefore does not support a compressed color index (offset 0xb) separate from the transparent color index.

What should be happening
The EE engine should support a compressed color index (offset 0xb) separate from the transparent color index.

Steps to reproduce the bug

1. Save the attached BAM file to the override folder of a BGEE/SoD/BG2EE game.
2. Start a new game with a default character.  If the character does not start off with a quarterstaff, CLUA one in (STAF01).
3. Observe the rendering of the staff's new bam (what should be a rectangular scroll).
4. Compare how this BAM is rendered to how it is rendered in oBG2, which properly supports a compressed color index (offset 0xb) separate from the transparent color index.  This is a regression compared to the original engine behavior*, which is described in the IESDP.

If available, a fix
This must be fixed at the engine level.

Notes
While the effect in-game is minimal, a handful of BAMs in the BGEE, SoD, BG2EE, and possibly PSTEE do use a compressed color index that differs from the transparent index.  This may also affect mod added item icons.  For example, in BGEE, there is:

• EXPLODE.BAM = 127 (This one does happen to correspond to the transparent color index, but only in oBG1)
• FIRE.BAM = 128 (This one does happen to correspond to the transparent color index, but only in oBG1)
• MOVES.BAM = 224
• OPTIONS.BAM = 222
• PORTBTTS.BAM = 195
• PORTBUTT.BAM = 195

NearInfinity and BAMWorkshop II render the attached BAM correctly, but BAMWorkshop does not.

* When I originally submitted this bug on the old Beamdog Redmine, I provided a very similar BAM.  At the time, I tested in oBG2 and it rendered correctly, but did not in the EEs.  When I remade the BAM for this post and tested again, it did not render correctly in oBG2 either.  It appears this may be one of the odd cases where hardware/graphics card settings/game settings affect how the BAM is rendered.  Unfortunately, the original Redmine report (and thus the original BAM) is no longer available.

istaf01.bam

[marchitek]

Small things from my side. Engine problems that I think don't result with any bug in unmodded game but can be cause of troubles for modders.

 

1. AddXPObject() action produce awkward feedback message when used with negative values. This is handled correctly for AddExperienceParty(). See screenshot:

Spoiler

 

2. Reducing XP of character below zero results with maximum XP value for this character. I know that there was many bugs like this in vanilla BG, TBH I don't know if there were fixed in EE. I would expect the same behavior as reducing stat below zero: character death OR it could just stay at zero in such cases (like it is with gold value).

[RoyalProtector]

Another thing that is probably not fixable without engine fixes: cleric-thieves lose access to some innate abilities, seemingly whenever the number of innate abilities surpass a certain number. In order to see them again, you have to spend others first. I suspect the thieving button inside is causing some sort of issue, and it eats up one innate spell slot somehow. In the past I had "fixed" this by making copies of innate abilities, marking them as "Spells" in NearInfinity and finally adding them to my character with EEKeeper.

Or, how Time Stop's duration is not consistent. You can tell easily with Shadowstep. If you add another effect that lasts for 7 seconds, you'll see that TS sometimes ends before the other effect, or after.

Edited April 10, 2022 by RoyalProtector

[Bubb]

v2.5+ pathfinding and party members getting stuck:

Quote

1) Pre-v2.5.16.6 group-targeting did very little adjustment to the character placements. The only verification it did amounted to checking if the main target, (where you clicked on the map), was passable. This meant that if you clicked near a wall and half of your characters ended up with an invalid target, those characters would just give up at some point.

v2.5.16.6+ tried to fix this. If characters ended up pathing to an impassible spot on the map it would fall back to routing them to the main target. Well, this means you can get multiple party members all walking to the same exact spot — this happens frequently in tight spaces.

2) The bumping code was broken. I don't know the specifics here, but it appears a change to some multiplayer sync function causes characters to no longer get out of each other's way in very tight spaces. This also means that if they end up occupying the same part of the map they get stuck.

#2 can be mitigated with a single-byte patch to the exe.

[Endarire]

@Bubb

Will 2 be fixed in a near term EEex version?

[Bubb]

op182 is supposed to apply the EFF in res2 if the target has the ITM in res1 equipped. This is bugged -- it treats the found slot-index as a boolean, so it always applies the EFF unless the ITM is in SLOT_AMULET.

And this isn't really a bug, but op182 (if it worked) and triggers HasItemEquiped() + HasItemEquipedReal() don't consider SLOT_MISC19 (the magical weapon slot, used by op111) as an "equipped" slot. It would be nice if there was a way to check it as such.

[Bubb]

op236, param2=3 (Simulacrum) is supposed to apply a level-drain effect to the clone equal to [(average of LEVEL, LEVEL2, LEVEL3) * 40%]. The code is bugged for dual class characters -- instead of using the character's average level it uses the level count of the original class.

This means dual class mages usually end up with Simulacrums that are substantially more powerful than intended.

Edited May 22, 2022 by Bubb

[subtledoctor]

I mean theoretically that’s fixable, but it would be a fair amount of effort and might be fragile. Might be better off addressing it in tweak mods. 

[Bubb]

2 hours ago, subtledoctor said:

I mean theoretically that’s fixable, but it would be a fair amount of effort and might be fragile. Might be better off addressing it in tweak mods. 

I'm curious, what would this look like? I imagine it would entail some serious spell-system abuse.

[CamDawg]

Since only humans can dual-class, you can add effects to simulacr.spl targeting humans, and then further farm out that through further stats checks by class, (say, fighter-mage) and then further filter those by appropriate checks for level1/level2 and then apply additional level draining as needed.

It'd be horrible and would likely break in a face of a stiff breeze, but it's theoretically possible.

[Bubb]

@CamDawg Thanks!

-------------------------------------------------------------------------------------------------

Another one:

The SPEED column in WSPECIAL.2DA is ignored by the engine — High Mastery and Grand Mastery do not provide bonuses to speed factor as they should. This can probably be fixed via modding but posting here to highlight the engine bug.