argent77

Considering the engine limitations and the powergaming potential of the game, it's still quite faithful.

I think that behavior would already be too far away from the original AD&D description. It sounds more like an idea for a tweak mod.

AD&D description of trolls:

Quote

Trolls regenerate at an amazing rate. Starting three rounds after first blood, the creatures recovers 3 hit points per round until healed. Trolls reduced to 0 or fewer hit points fall to the ground, incapacitated but not slain. Incapacitated trolls continue to regenerate and stand up to fight as soon as they have a positive number of hit points. ... A troll reduced to 0 or fewer hit points and immersed in acid or burned with fire is killed.

The current implementation is still quite faithful to the AD&D description.

Not all trolls in IWD can regenerate (e.g. ice trolls). Other trolls seem to be leftovers or incomplete imports from BG2 (or an early patch version of BG2EE) which don't appear in the game. CDTROLL1.CRE is one of them.

14 minutes ago, Luke said:

Unless I'm missing something, in IWD:EE the falling-down mechanism still relies upon scripts...?

The script that was responsible for the falling-down mechanism in oIWD is still in place but doesn't contain any code. Instead it's realized by REG1HP2.ITM (or CIREVE.ITM for revenants) which does basically the same as TROLLREG.ITM in BG2EE.

I have already made a PR which should cover all instances in SoD, BG2EE and IWDEE.

42 minutes ago, Luke said:

Before I forget: in SoD there are certain wolves that also have this falling-down mechanics. As a result, you might want to patch them as well...

That's handled slightly differently where the trigger delay isn't as noticeable, but the patch should work basically the same.

Edit: There is also "BDTROLL1.ITM" in SoD, but I couldn't find out where or whether it is actually used.

Slow doesn't appear to delay the falling-down trigger. Maybe it's delayed from one tick to two ticks, but that isn't noticeable by the player.

I have recently made an attempt to further improve the falling-down mechanism of trolls, which had been initially improved in EE games by moving it from script to spell effect, but still only triggers once per round.

My change includes a second opcode 232 (Cast spell on condition) to the trolls' TROLLREG items which triggers an intermediate spell on "TookDamage()/instant" that executes the original falling-down spell (TROLLREG.SPL, etc.) when the current hit points fall below a certain threshold.

The result of this change is that trolls will immediately fall down and are susceptible to elemental damage without being invulnerable for another full round (in the worst case).

Would such a (quite radical) change of the regeneration behavior be suitable for inclusion in the EE fixpack?

Can you think of unintended side effects this implementation might introduce? I have only tested it with direct damage and continuous poison effect damage, which both worked as expected.

Relevant WeiDU code:

// Intermediate filter spells
ACTION_DEFINE_ASSOCIATIVE_ARRAY reg_spl BEGIN
  // original SPL resref, cur. HP => intermediate SPL resref
  "trollreg", 12 => "#trollrg"
  "cdhgtrl", 12  => "#cdhgtrl"
  "cdtrlblz", 12 => "#cdtlblz"
  "cdtorgal", 12 => "#cdtorgl"
  "cdiwdtr1", 10 => "#cdidtr1"
  "cdiwdtr2", 10 => "#cdidtr2"
END

ACTION_PHP_EACH reg_spl AS keys => resref2 BEGIN
  OUTER_SPRINT resref1 $keys("0")
  OUTER_SET cur_hp = $keys("1")
  COPY_EXISTING "%resref1%.spl" "override/%resref2%.spl"
    LPF DELETE_SPELL_EFFECT
      INT_VAR opcode_to_delete = "-1" // all effects
    END
    LPF ADD_SPELL_EFFECT
      INT_VAR
        opcode = 318        // Protection from resource
        target = 1          // Self
        parameter1 = cur_hp
        parameter2 = 144    // STAT CURHITPOINTS >= [parameter1]
      STR_VAR
        resource = EVAL "%DEST_RES%"
    END
    LPF ADD_SPELL_EFFECT
      INT_VAR
        opcode = 146      // Cast spell
        target = 1        // Self
        parameter2 = 1    // Cast instantly (caster level)
        timing = 1        // Instant/Permanent until death
      STR_VAR
        resource = EVAL "%SOURCE_RES%"
    END
  IF_EXISTS
END


// Regeneration items
ACTION_DEFINE_ASSOCIATIVE_ARRAY reg_itm BEGIN
  // ITM resref => Intermediate SPL resref
  "trollreg" => "#TROLLRG"
  "cdhgtrl"  => "#CDHGTRL"
  "cdtrlblz" => "#CDTLBLZ"
  "cdtorgal" => "#cdtorgl"
  "reg1hp2"  => "#CDIDTR1"
  "cireve"   => "#CDIDTR2"
END

ACTION_PHP_EACH reg_itm AS resref1 => resref2 BEGIN
  COPY_EXISTING "%resref1%.itm" "override"
    LPF ADD_ITEM_EQEFFECT
      INT_VAR
        opcode = 232      // Cast spell on condition
        target = 1        // Self
        timing = 2        // While equipped
        parameter2 = 11   // TookDamage() / instant
      STR_VAR
        resource = EVAL "%resref2%"
    END
  BUT_ONLY IF_EXISTS
END

My guess is that some other mod already tinkered with some of the the savegame names and causes this Tweaks component to fail or not work correctly.

You could perform a changelog on the file if you want to get to the bottom of it. For this, create a copy of "setup-cdtweaks.exe" (or any other setup-*.exe) and rename it to "weidu.exe", then execute this command from the command line in the game directory:

weidu.exe --change-log savename.2da

It should list all mod components that modified the file.

It also creates copies of earlier revisions of the file if there were mod components listed by the command above. One of them might fix the quicksave/autosave issues by renaming them back to "savename.2da" and putting them into the override folder of the game. Make a backup of the original "savename.2da" in the override folder first.

I couldn't reproduce this error but I found a typo in the mod script which might be responsible for this issue.

Could you download and unpack the attached zip file into the folder "cdtweaks/lib" in the game folder where you unpacked the Tweaks Anthology mod? Accept to overwrite the old file when prompted. Then try installing that component again.

personalized_save_names.zip

1 hour ago, rucker11 said:

Trials oft he luremaster v4.1 (does the xp fix collide with the one from EET fix?)

XP reducer from the mod only affects creatures and quest XP from mod-related content. The EET XP reducer works globally on all game content. You only need to install one of them, otherwise quest XP will be reduced twice.

All Infinity Engine games support weather effects, except PST and PSTEE. Even fog works across the EE games (but vanilla IWDEE lacks the necessary fog tables for that.)

The 'Snow' weather effect in IWDEE can be difficult to see because the engine appears to use the native screen resolution to render snowflakes, which can be hard to see on higher resolutions.

18 minutes ago, LV426 said:

By the way, what file browser is opening when running the mod? Something built-into Java?

The "Open File" dialog is provided by the Swing GUI framework which Near Infinity is based on. It is (mostly) platform-independent, that's why it doesn't provide many options and integrates badly into the system. That GUI framework is ancient (first release: 1996), so it's unlikely it will ever get another feature upgrade.

There are actually three different variants listed for action 34 in IESDP:

One of them can be used to select the ability. However, the item seems to be chosen by item slot instead of a resref.

But you're right about the missing fourth variant. It should be listed even though it isn't defined in ACTION.IDS. There's already a precedent for this. Action 293 StartDialogOverride() lists the undefined variant for talking with conversable items.

On 9/22/2023 at 2:20 AM, LV426 said:

Greetings!

First time using Near Infinity and I have an issue with it on Linux. When the launching the application, a blue file browser appears, pointing to my home directory.  The problem is that the Baldur's Gate directory is under the `.steam` directory, which is hidden by default. Inside this file browser, there is no way to display hidden files or search for hidden directories. Thankfully, I was able to get around this issue, by creating a symbolic link of the Steam directory, but I feel like that is a hacky solution.

Both the Flatpak and NearInfinity.jar have the same issue with this file browser. My default file browser on the system is Nautilus.

I'll see if there is a way to turn on hidden file display in the "Open Game" file dialog in NI.

As a workaround you could place the NearInfinity.jar into the game directory and start it from there. NI will automatically detect the game in that case.

Moreover, the Flatpak version of Near Infinity should have set up a file association with the "chitin.key" file of the game. In that case you can simply navigate to the (hidden) folder of the game and open the chitin.key in the file manager.

The WeiDU docs don't appear to list all shorthand syntax that is supported by WeiDU.

The best list I could find is in the WeiDU source itself: https://github.com/WeiDUorg/weidu/blob/master/src/dlexer.mll

Not all script action variants are listed in ACTION.IDS. You have to add the function signature first to make it accessible from scripts, like this:

APPEND ~ACTION.IDS~ ~34 UseItemAbility(S:Object*,O:Target*,I:Slot*SLOTS,I:Ability*)~ UNLESS ~UseItemAbility~
CLEAR_IDS_MAP

The latter command is important for WeiDU to register the ACTION.IDS changes.

On 9/27/2023 at 4:57 AM, paladin84 said:

I tried both approaches with NI (to and from png and directly TIS files from the installed mod on classic BG2 to TIZ + PVRZ) but I still have glitches. To be clear, they are not everywhere (as if install classic version TIS files on BGEE). For instance, there are couple of glitches like on the attached image for the huge map (5120x3392).

Even with the optimized texture layout imposed by the NI conversion there may still be some glitches around the dynamic parts of tilesets. That's probably the best result possible with the currently available tools.

1 hour ago, Arkie said:

1. I did TIS to PNG , then PNG to TIS+PVRZ coversion in NI.

2. I think tile2ee has this functionality...

1. Using NI for palette-based TIS -> PVRZ-based TIS conversion is currently the best approach. Both conversion via Mass Exporter or selecting individual TIS files and choosing the option "Export... -> as PVRZ-based TIS" work equally well. The conversion through an intermediate format, such as PNG, doesn't work as well since it loses WED tile layout information in the process (which is responsible for the black lines after conversion).

2. The best way of using tile2ee is to include PVRZ-based tilesets in the mod and use the tool to convert them back to palette-based tilesets on-the-fly for the original games. This script from my Djinni Companion mod uses this approach, for example.

I'm especially worried about that line:

Quote

This is the latest in a string of layoffs and studio closures Embracer has sanctioned, with the company attempting to streamline operations to become a "highly cash-flow generative business."

It looks like this is an ongoing process that has most likely not yet ended.

2 hours ago, Frenzgyn said:

Beamdog's forum again under maintainance? I get a "503 Service Temporarily Unavailable" since yesterday, but the main site works... any news about it?

Seems to be back online.

The numerous downtimes lately may be related to the recent layoffs. That doesn't bode well for the future of the forum.