Tweaks Anthology Version 10 Released

[CamDawg]

On 2/22/2022 at 2:44 PM, Mera said:

Regarding "Disable Portrait Icons Added by Equipped Items":
It properly removes them for the portraits on the right side, as expected (first screenshot, taken at random with google, there's actually no icon with the mod ) but I was expecting to still see the buffs being displayed in the character screen (second screenshot) but it's completely empty too with the mod installed. I thought buffs would still be displayed there as a convenience to keep track of what your equipment actually provides.

Not sure if it's a bug, a technical limitation or whatever but I thought I would report it just in case

Unfortunately these are linked--an item either provides a portrait icon or not. If given an icon, the engine displays it on the portrait and the record screen.

[Awachi]

Is it possible to detach the string and the icon?  It would need a new icon spot, one that is the icon with the normal string associated, and another that is the string but attached to a null bam.

vanilla:  normal icon, normal string

mod: blank icon, normal string

Edited March 8, 2022 by Awachi

[CamDawg]

On 2/19/2022 at 6:26 PM, boof said:

The remove annoying visual component removes all such visuals from spell effects when one of the relevant items are equipped.

For example, I'm running reflection shield on Aerie, but the bubble sphere from spell immunity never shows up on her until I take the shield off.

This is addressed. It's a more complicated solution but AFAICT it's working.

[CamDawg]

8 hours ago, Awachi said:

Is it possible to detach the string and the icon?  It would need a new icon spot, one that is the icon with the normal string associated, and another that is the string but attached to a null bam.

vanilla:  normal icon, normal string

mod: blank icon, normal string

Not really, but there's a possible workaround for the EEs at least.

You'd basically need to dupe the entire set of portrait icons, one with graphics and one without, and then adjust everything to block/display the new ones as needed. (The originals have a fixed number of icon slots, so it's not even an option there.) Even so you'd still end up with odd portraits as the game would hold space for the missing icons. It's a massive workaround (with the multitude of ways it can go wrong) for what is, essentially, an edge case.

[CamDawg]

1 hour ago, CamDawg said:

This is addressed. It's a more complicated solution but AFAICT it's working.

And after further testing: no, it's not. We'll keep the methodology from v10 and mark this as a known issue. The long boring technical explanation, for anyone who's interested:

Removing blur is easy--it's a separate opcode that purely provides cosmetics, so you simply remove it from items like the Cloak of Displacement. The reflection and spell trap animations are more difficult: various opcodes are hardcoded to play spmagglo (spell trap) or spsturni/spturni2 (reflection). Prior to version 9, going all the way back to the original in Ease of Use, these animations were simply replaced with blank frames. While this effectively removed the animations from e.g. the Shield of Balduran, it also meant that any spell or effect that used these also lost the animation. As of version 9 we shifted to using opcode 291, which explicitly blocks these animations, and attaching it to items for which we want to suppress these animations. This worked, to a degree--you no longer get the glowing disc with the Shield of Balduran and spells like Spell Trap and Physical Mirror retained their animations. The one bug--which boof posted about--was that someone equipped with the Shield of Balduran under the effect of a Spell Trap or Physical Mirror doesn't get the animations, since opcode 291 is indiscriminate in its targeting.

So, the clever idea: duplicate the animations, blank the old hardcoded ones, and then move everything (except the handful of items we don't want like Shield of Balduran) to the new animations. This is easy enough. The problem comes because we've now uncoupled the animations and the actual spell effects. With a hardcoded animation, the animation ends if the underlying effect gets nuked, e.g. the animation that accompanies a Spell Shield goes away when the spell expires or when the Spell Shield absorbs a spell. We simply can't do the latter with an uncoupled animation, leading the player to believe they may have protection (because they still have an animation) even though the actual protective effect has gone away.

[Awachi]

5 hours ago, CamDawg said:

you'd still end up with odd portraits as the game would hold space for the missing icons.

Yup, that kills it. 

[Guest Mike]

The component 'Use BG Walking Speeds' should include more animation IDs for the BGT part:

            ("%anim%" = 0xC600)
         OR ("%anim%" = 0xC610)
         OR ("%anim%" = 0xC700)
         OR ("%anim%" = 0xC710)
         OR ("%anim%" = 0xC800)
         OR ("%anim%" = 0xC810)
         OR ("%anim%" = 0xC900)
         OR ("%anim%" = 0xC910)
         OR ("%anim%" = 0xCA00)
         OR ("%anim%" = 0xCA10)
         OR ("%anim%" = 0xCB00)) BEGIN

 

[CamDawg]

Unlike the character animations, all of these did not have their animation speed increased in BG2. Even when the adjustments are made by Tweaks, all of these are still slower than the character animations.

[CamDawg]

22 minutes ago, CamDawg said:

all of these did not have their animation speed increased in BG2.

I should clarify: this is AFAIK; someone like @Gwendolyne may know definitively. Since they're already slower than the adjusted character speeds (character's 7 vs. 6 or 5 for these) I'd not mess with them regardless.

[Sam.]

1 hour ago, CamDawg said:

I should clarify: this is AFAIK; someone like @Gwendolyne may know definitively. Since they're already slower than the adjusted character speeds (character's 7 vs. 6 or 5 for these) I'd not mess with them regardless.

I have a vague tickle in the back of my mind that says for some animation types (perhaps only on some engines), the walking speed is primarily determined by the number of frames in the walking sequences.  Thus e.g. IWD style animations may move at a different speed than BG style animations within the same engine, simply because by default they have a different number of frames in the sequence.  Does this ring a bell with anyone?

[Enkidu]

I encountered a possible issue with the universal clubs component in v10. As a dragon disciple, I can't choose club proficiency, but as a sorcerer I can.

[jmerry]

Which proficiencies a class can take is controlled by WEAPPROF.2DA (in the current version of the game). Each class or kit gets a column there. Except that plain sorcerers don't, and use the information for generalist mages instead. Looking at the copy of the mod there ... changes for generalist mages, specialist mages, and wild mages, but no mention of dragon disciples. Looks like an oversight to be fixed.

Here's the relevant  snippet from the mod as of v10:

  COPY_EXISTING ~weapprof.2da~ ~override~ // allows mage proficiency in clubs
    FOR (column = 22; column < 30; column = column + 1) BEGIN
      SET_2DA_ENTRY_LATER ~weapprof~ 20 column ~1~ // Specialist Mage
    END
    SET_2DA_ENTRY_LATER ~weapprof~ 20  4 ~1~ // Mage
    SET_2DA_ENTRY_LATER ~weapprof~ 20 53 ~1~ // Wild Mage
    SET_2DA_ENTRIES_NOW ~weapprof~ 1
    BUT_ONLY

There needs to be a line added for Dragon Disciples. Maybe within an "if" block for compatibility reasons, but this is the line to make the actual change:

SET_2DA_ENTRY_LATER ~weapprof~ 20 57 ~1~ // Dragon Disciple

Until this is added, it's easy enough to hotfix on your own. 2DA is a human-readable plain-text format; just open the copy in the override with a text editor, find the DRAGON_DISCIPLE column, and change the entry in the CLUB row from 0 to 1.

Well, that sort of thing would work well for most 2DA files. This particular one is absurdly wide, which might cause issues finding the right spot.

Edited March 10, 2022 by jmerry

[CamDawg]

You know, the dumb thing about this is, in the very next component I have code to dynamically detect sorcerer kits and then modify them in weapprof, but didn't think about the club component.

[Enkidu]

Thanks, fixed it manually as per your instruction.

[Gwendolyne]

On 3/9/2022 at 1:00 AM, Sam. said:

I have a vague tickle in the back of my mind that says for some animation types (perhaps only on some engines), the walking speed is primarily determined by the number of frames in the walking sequences.  Thus e.g. IWD style animations may move at a different speed than BG style animations within the same engine, simply because by default they have a different number of frames in the sequence.  Does this ring a bell with anyone?

I can't confirm this officially, but according to all my testings, I would agree. For example, I had to add a global effect adjusting the movement rate in all the .cre files using my horses and unicorns animation to render a smooth walking.