argent77

I guess my previous comment was a bit ambiguous about the mod component's intent. The spell failure issue is part of the quest, which TNO has to solve. I have improved the phrasing to make it clearer.

Have you installed the PST-UB mod? The latest mod release introduced the new optional component "Restored Spell Keys", which is intended to restrict spell casting abilities of The Nameless One in the Outer Planes, unless he has the right protection. You can find out more details in the mod's readme.

Spellhold Studios PS:T Unfinished Business - Reloaded This mod is a continuation of Qwinn's original PS:T Unfinished Business (PST-UB), based on version 4.12, that has been completely overhauled and made compatible with Planescape Torment: Enhanced Edition (PST:EE). This release provides updated Polish translation (thanks memory). Changelog: Updated Polish translation (thanks memory) Download: SHS, GitHub Discussion: SHS, Beamdog Readme

Yes, that script seems to work. But it has some issues as well. A cosmetic issue, as the item is dropped while the petrified/frozen creature still exists. A more serious issue is that you can theoretically unpetrify the creature, which might cause plot-related issues.

Adding immunity to petrification is not enough. Dragomir is also susceptible to Disintegrate and frozen death, which may also destroy the cloak.

The animation definition files have been unified across the games, but the actual graphics and sound resources exist only if the game actually uses them. You can inspect the respective .INI files for the creature animations to see which animation and sound files are expected. For example, the Frost Giant animation is defined by E24F.INI. The "resref" entry defines the BAM animation prefix, so you should copy all BAM files starting with that prefix over from IWDEE to BG2EE. The [sound] section defines the required WAV files used by the creature animation. You'll probably have to copy them over as well.

Another option could be to provide two instances of Dragomir's Cloak. One instance with the "critical item" flag, added to Dragomir's inventory. A second instance without the "critical item" flag, which replaces the first instance when it is in Hexxat's possession.

Auto-haste can be toggled on and off at any time. The protagonist should have a special ability for this, which is conveniently named "Disable Auto-Haste" or "Enable Auto-Haste".

I have only found two mods which may conflict: - Item Randomiser: Randomized items in one of the stores may not be available. - Item Revisions: Replaces content of both stores with different items. IR replaces content of BERNARD.STO with mundane stuff and BERNARD2.STO with several unique items. Other mods, if there are any, would probably work similarly and add the more unique or expensive stuff to the second store. As such, it would probably make more sense to disable the first store and use only the second store instead.

[BG2] Bernard at the Copper Coronet should not open different stores depending on certain quest outcomes Bernard initially provides access to his regular store (BERNARD.STO) and switches over to his improved store (BERNARD2.STO) after helping out Hendak or Lehtinan, which provides better prices and several new items. With this switch all items previously sold to the original store will be permanently lost to you. Moreover, the improved version doesn't provide a scroll case, which is only available in the regular store for some reason. In the EE engine the switch can be made more consistent by updating the regular store to behave like the improved version. ChangeStoreMarkup() can be used to update buy and sell markup, and AddStoreItem() can be used to add the new items to the store. The only difference would be item order, as AddStoreItem() cannot insert items at specific positions. This issue is probably more controversal, since it can potentially affect mod compatibility. Thoughts?

[BG2] Ler at Waukeen's Promenade should not attempt to initiate conversation after meeting Gaelan Bayle Ler, one of the bystanders from the Irenicus/Cowled Wizards incident, is scripted to walk over to the party and talk to you after the cutscene is over. But he can be easily dodged if you move swiftly to the map exit. Observed: Ler still attempts to talk to the party if you return to Waukeen's Promenade after talking to Gaelan Bayle. Expected: Ler should not attempt to start a conversation on his own after talking to Gaelan Bayle. This behavior could be fixed by adding a chapter check to his script (BYSTAND1.BCS).

Thanks for the report. It's been fixed in v0.5.1 of the add_kit_ex library.

If I understand it correctly, the issue of having specialist mage bits included in kit ids affects spell selection during character creation and spell selection for sorcerer kits at level up? The former is probably too insignificant to warrant a rewrite of the ADD_KIT_EX function. The latter, however, is more serious. The problem is that the engine supports only up to 256 single class kits, which would be in the kit id range [0x4000, 0x40FF]. The only specialist mage bits affecting this range are Abjurer (id 0x40, bit6) and Conjurer (id 0x80, bit7). That means kit ids from 0x4000 to 0x403F can be used by mage, bard and sorcerer kits to count as generalist mages by the engine, 0x4040 to 0x407F count as Abjurers, 0x4080 to 0x40BF count as Conjurers, and 0x40C0 to 0x40FF count as both Abjurers and Conjurers. Since the base game uses ids for vanilla kits up to 0x4029 there are only 22 more slots available for generalist mage kits. I could probably improve ADD_KIT_EX to take care of this issue. Since the game engine expects kit ids in sequential order I would have to add placeholder kits to make it work. This will most likely introduce compatibility issues with the original WeiDU function ADD_KIT, although none of them are game breaking. I don't know how many kit mods are using WeiDU's ADD_KIT, but it's probably still a great number mods. Is it really worth it to add such a radical change just to account for some (minor?) quirkiness of the game engine?

There may be situations where you need to process data that is stored in arrays. This can be done within the main code, but it may become difficult to read and maintain eventually, and you're forced to write duplicate code if you need to perform the same operation more than once. With the introduction of the RET_ARRAY keyword in WeiDU 245 it is possible to outsource array operations to functions. However, WeiDU documentation is very scarce about this feature and leads to the assumption that it is only possible to return newly created arrays from a function. Because of the dynamic nature of WeiDU variables this is not necessarily true. It is possible to pass arbitrary arrays to a function and return them with updated content. This is example code to demonstrate this feature: It is not only possible to update existing array elements but we can also expand the array by new elements. Theoretically it's even possible to use CLEAR_ARRAY, DEFINE_ARRAY and DEFINE_ASSOCIATIVE_ARRAY to completely clear or overwrite the array. In all of these cases we have to use EVAL to access the array itself.

It's an optional component of the mod. But even when installed, you can always leave Chateau Irenicus the regular way to leave them behind forever.

I used my rusty Photoshop skills to block passage to Lower Dorn's Deep by another door that can only be opened with Joril's Badge (see attachment). Imo, it would not really be suitable for the fixpack, since it alters original content a bit too much for my taste. But it could be a candidate for an "Optional but cool" component or a tweak pack. A7-WTGPassDoor.zip

Near Infinity v2.3-20221108 Near Infinity is a resource browser and editor for Infinity Engine games, such as Baldur's Gate or Icewind Dale. It is written in Java and available for Windows, macOS and Linux. This version provides many useful additions and improvements, such as support of the non-interactive BG1 demo and new resource check options. More information as well as a detailed Changelog can be found in the respective topics at Spellhold Studios and Beamdog Forums. Download: GitHub

The duplicate sections still exist in PST:EE, but they don't appear to have any negative effect in the game. "Guard5" is responsible for the guard on the left/lower side of the "Dream World" door in the Foundry, but he's properly spawned by the game.

Hidden Gameplay Options also considers some tweaks from Tweaks Anthology, so it's best installed afterwards. For more hints about install order you could look up the "After" value in the .ini file provided by many mods nowadays, and used by PI. The mod should be installed after anything listed by the "After" line (see HiddenGameplayOptions.ini).

[PSTEE] Non-RES version of script action ForceSpellRESNoFeedback() should be listed in ACTION.IDS This action is supported by the game engine, but doesn't exist as function definition in ACTION.IDS: 466 ForceSpellNoFeedback(O:Target,I:Spell*Spell)

There's no need for INNER_ACTIONs. Table data persists even beyond the COPY scope. Something like this is perfectly viable: COPY ~jtweaks/resource/j8hhexsd.2da~ ~override~ // Table of data for changes READ_2DA_ENTRIES_NOW ~j8hhexsd~ 8 BUT_ONLY // table data is still valid OUTER_FOR (row = 0; row < j8hhexsd; ++row) BEGIN OUTER_SPRINT FileID $j8hhexsd(~%row%~ ~0~) COPY_EXISTING ~%FileID%.cre~ ~override~ WRITE_BYTE 0x273 4 // Class - thief WRITE_LONG 0x244 0x40210000 // Kit - shadowdancer WRITE_BYTE 0x234 $j8hhexsd(~%row%~ ~1~) // Level1 WRITE_BYTE 0x45 $j8hhexsd(~%row%~ ~2~) // Hide WRITE_BYTE 0x64 $j8hhexsd(~%row%~ ~3~) // DetIll WRITE_BYTE 0x65 0 // Set Traps WRITE_BYTE 0x67 $j8hhexsd(~%row%~ ~4~) // Unlock WRITE_BYTE 0x68 $j8hhexsd(~%row%~ ~5~) // Silent WRITE_BYTE 0x69 $j8hhexsd(~%row%~ ~6~) // DetTrap WRITE_BYTE 0x6a $j8hhexsd(~%row%~ ~7~) // Pocket BUT_ONLY END WeiDU loads 2DA data into a 2d-array which can be accessed just like any other array via $array_name(~row~ ~col~). Afaik, the only restrictions with these arrays are that they don't work correctly with PHP_EACH, and you can't return them from a WeiDU function via RET_ARRAY.

[PSTEE] Names of parameters 2 and 3 for ExploreMapChunk() should be swapped in ACTION.IDS Observed: 435 ExploreMapChunk(P:Center*,I:Radius*,I:Mode*) Expected: 435 ExploreMapChunk(P:Center*,I:Mode*,I:Radius*)

PVRZ, more specifically, the chosen texture compression type (DXT1 or DXT5) may result in visible degradation of image quality under certain conditions.

PVRZ compression is to blame. There are many instances like this in all games, especially noticeable in areas with small color differences or darker colors.

Great job with the documentation! I've noticed one fix missing from the PsTEE docs, though: [PSTEE] The Baator map (AR1000) should be populated with more enemies Screenshots for comparison: These screenshots are quite large. I leave it up to you whether to add them to the gallery or not.