argent77

41 minutes ago, subtledoctor said:

There is one file in my override folder that has a space in the filename: "MONKTU 8.DLG."

That's actually a vanilla game file in BGEE which goes back to oBG1. It's most likely unused. There is an identical resource without spaces in the filename (MONKTU8.DLG) which is used by one of the tutorial monks in Candlekeep.

Actually, EET already attempts to deal with Story Mode, but the scripting is incomplete.

Currently in BD6100.BCS there is this block:

IF
  Global("K#StoryMode","BD6100",0)
  StoryModeOn()
  Global("OHSMODE","GLOBAL",1)
THEN
  RESPONSE #100
    SetGlobal("K#StoryMode","BD6100",1)
    SetGlobal("OHSMODE","GLOBAL",-1)
    ReallyForceSpellDeadRES("OHSMODE2",Player1)
    Continue()
END

It removes the Story Mode effects from the protagonist (via spell "OSHMODE2") and sets the story mode variable ("OHSMODE") to -1.

In BDBALDUR.BCS we have this block:

IF
  Global("OHSMODE","GLOBAL",0)
  Global("OHSMOFF","GLOBAL",0)
  StoryModeOn()
  !NightmareModeOn()
  !AreaCheck("BD6100")
THEN
  RESPONSE #100
    SetInterrupt(FALSE)
    SetGlobal("OHSMODE","GLOBAL",1)
    ApplySpellRES("OHSMODE1",Player1)
    DisplayStringNoNameHead(Player1,259613)  // Story Mode: On
    SetInterrupt(TRUE)
END

It' doesn't fire in the ambush area because of the area check and the variable "OHSMODE" already being set to -1.

But further down we have also blocks for all other party members, like this:

IF
  StoryModeOn()
  !CheckSpellState(Player2,STORY_MODE)
  InParty(Player2)
THEN
  RESPONSE #100
    SetInterrupt(FALSE)
    ApplySpellRES("OHSMODE1",Player2)
    SetInterrupt(TRUE)
    Continue()
END

These blocks are still executed, even in the ambush area.

The actual problem is the spell "OSHMODE1", however, which applies the Story Mode immunities. Most effects of the spell are set to target the whole party. Combined with the script block above it will always affect the whole party as long as it is applied to at least one party member.

The quickest way to fix the issue is to add an area check to the Story Mode checks for Player2 to Player6 in BDBALDUR.BCS and extend the spell effect removal in BD6100.BCS to all party members. Story Mode is automatically restored when you regain control over the party in Chateau Irenicus.

From my own tests it looks like only "Effective AC" is used by the game. Even characters with a natural AC progression (like monks) modify only effective AC. Natural AC doesn't appear to be used by the game. I'd say the term "Effective AC" is somewhat misleading, since it doesn't include AC bonuses from stats, items or spell effects.

I'd recommend to install "Hidden Gameplay Options" after Tweaks Anthology to get the most out of the mod.

An increasing number of mods also provide a .ini file inside their mod folders which provides some basic information about mod order. Look for the lines with the "Before" and "After" keywords.

I've tried my luck and coded a WeiDU mod. (Being a WeiDU script) it doesn't provide the fastest execution speed, but it should get the work done.

Download: ExportTilesetDoors.zip

The ground work may already exist in NI but it would still be (more or less) a whole new implementation from scratch to add such a feature. It might be faster (and more customizable for your task) to code something like that in WeiDU. Since 64-bit WeiDU has lifted the 16 MB buffer limit for big files it is actually doable to create some kind of TIS data converter.

Because of the FILE_CONTAINS_EVALUATED() check in bgee.lua. Without any checks the whole code could be reduced to

WITH_TRA ~path/to/other_mod/tra/%LANGUAGE%/mod.tra~ BEGIN
  OUTER_SET title_strref = RESOLVE_STR_REF(@100)
END

That should work just the same. Only the OUTER_PATCH_SAVE block isn't needed in that case.

If this is for EE games then this may work:

DEFINE_ACTION_FUNCTION get_journal_title
INT_VAR
  tra_ref = "-1"      // tra reference of a journal entry
STR_VAR
  tra_path = ~~       // path to (external) tra file
RET
  title title_strref  // returns journal title and associated strref
BEGIN
  OUTER_SPRINT title ~~
  OUTER_SET title_strref = "-1"

  ACTION_IF (FILE_EXISTS ~%tra_path%~) BEGIN
    WITH_TRA ~%tra_path%~ BEGIN
      OUTER_SET strref = RESOLVE_STR_REF((AT "tra_ref"))  // resolve tra reference to strref
      ACTION_GET_STRREF strref text   // load string from strref

      // extracting first line (title) of journal entry
      OUTER_PATCH_SAVE title ~%text%~ BEGIN
        SET eol = INDEX_BUFFER(~[%WNL%]~)
        PATCH_IF (eol >= 0) BEGIN
          DELETE_BYTES eol (BUFFER_LENGTH - eol)
        END
      END
      OUTER_SET title_strref = RESOLVE_STR_REF(~%title%~)

      // checking if the journal title actually exists in the game
      ACTION_IF NOT FILE_CONTAINS_EVALUATED(~bgee.lua~ ~createQuest[ %TAB%]*([ %TAB%]*%title_strref%[ %TAB%]*)~) BEGIN
        OUTER_SPRINT title ~~
        OUTER_SET title_strref = "-1"
      END
    END
  END
END

LAF get_journal_title
  INT_VAR tra_ref = 100 // tra reference pointing to a journal entry (or title)
  STR_VAR tra_path = EVAL ~path/to/other_mod/tra/%LANGUAGE%/mod.tra~
  RET title title_strref
END

ACTION_IF title_strref >= 0 BEGIN
  PRINT ~Journal title found: "%title%" (strref=%title_strref%).~
END ELSE BEGIN
  PRINT ~Could not find journal title.~
END

38 minutes ago, subtledoctor said:

And I can potentially whitelist NPCs who can operate as 7th members. (There are only, what, four of them?)

Doesn't work if you install characters with the NPC Generator. It allows every generated NPC to tag along as a follower.

9 hours ago, jmerry said:

In the same vein of extremely minor graphical bugs, wall polygon #281 in Waukeen's Promenade is missing the "cover animations" flag which it should have.

https://forums.beamdog.com/discussion/comment/1187780/#Comment_1187780

(Link to a picture in which it looks like a kid is on the roof)

EE patch 2.6 has generally issues with wall polygons, which worked correctly in previous patch versions.

You can easily spot them with active visual effects (fire shield, etc.), like this instance in the Pocket Plane:

This is just a minor issue which probably doesn't need a fix, but I'll mention it anyway.

[BG2EE] Issue with erroneously placed transparent pixels in tilesets

Some tilesets were apparently incorrectly converted into the PVRZ format, which erroneously produced transparent pixels.

Affected tilesets:
- AR0204: A020401.PVRZ (very minor)
- AR0300: A030014.PVRZ, A0300N15.PVRZ
- AR0900: A090014.PVRZ, A0900N14.PVRZ
- AR5000: A500006.PVRZ, A500007.PVRZ, A500008.PVRZ

Example (AR0900):

In the game itself these are only really noticeable if you know where to look for them, since they are either overlaid by water animations or black pixels.

29 minutes ago, subtledoctor said:

I just never remember to consider triple-classes, because it's never been something that interested me. ADD_KIT_EX doesn't have an explicit example of working with three kits, but that doesn't mean it can't

Installing multiclass kits for three-class combinations should work the same way as for two-class combinations. Using this example, for a F/M/T kit you just have set "kit_class" parameter to 10 (FIGHTER_MAGE_THIEF), and (optionally) provide an additional mage clab table (e.g. via "clab_base_m" parameter).

There is a glaring engine bug in the SetGlobalTimer() script action in PST:EE. The script action computes expiration time based on the real time value instead of game time, which causes GlobalTimer[Not]Expired() triggers to return meaningless results. The timer has usually already expired by the next timer check. The effect is mostly apparent in mods. There are also several instances in the unmodded game, but none of them appear to be game-breaking.

To work around this issue it is possible to use the (only one) PSTEE-specific script action that is still based on game time:

SetGlobalTimerRandom(S:Name*,S:Area*,I:Min*GTimes,I:Max*GTimes)

This action is not without issues either. If executed with the same value for Min and Max from a dialog action block, the timer will compute a random value between 0 and Max instead. Using values that are one apart seems to work though.

Implementation is actually rather straightforward, since save slots can be customized in EE games. I've tested it on my local installation without apparent issues.

Theoretically it is possible to add more predefined save slots, but they will most likely interfere with manual saves from pre-EEFP'ed games.

Unlike in BGEE or IWDEE, there are no "chapter saves" created in PsTEE. The reason for that is obvious, as PsT doesn't use chapters to advance the plot.

However, I think that "chapter saves" are useful in situations where you screwed up and don't want to start the whole game or substantial portions anew - which can be the only choice if you only rely on autosave and quicksave. I propose to implement that feature in PsTEE as well. Afaik, the same was implemented by one of the later Beamdog patches for IWDEE.

PsTEE's SAVENAME.2DA contains 3 (or maybe 4) unused entries (slots 3 to 5/6) which could be used for story-progression purposes. Since there are no chapters, it is more difficult to decide when these saves should be created, and how they should be named.

My suggestions are:

Slot 3: At the beginning of the game, right after waking up in the Mortuary (and having completed your first talk with Morte).

Name suggestions:
    000000003-Mortuary
    000000003-Waking up in the Mortuary

There is no autosave created at all when you start a new game, so in the worst case you have to start all over again if you screw up.

Slot 4: Arriving at the Lower Ward from the Alley of Lingering Sighs.

Name suggestions:
    000000004-Lower Ward
    000000004-Arrival at the Lower Ward

In my opinion this is a logical point in the plot progress where another save would make sense. Arriving at the Lower Ward opens up access to all of Sigil and allows you to make use of the worldmap travel feature.

Slot 5: Right before teleporting to Ravel's Maze.

Name suggestions:
    000000005-To Ravel's Maze
    000000005-Departure to Ravel's Maze

The trip to Ravel's Maze is basically a "point of no-return", so a save at this point would be useful.

Slot 6: Original name of the save is "000000006-Start-Combat-Save". Slots of that name can also be found in all the other EE games, so it's possible that this slot is reserved by the game engine. Otherwise it could be repurposed as well.

There is also a "Final Save" slot defined but unused in PsTEE. I'd suggest to create it when TNO reaches the final boss map.

I'm unsure whether this proposal fits into EEFP or would be more suitable for Tweaks Anthology. It is an addition to PsTEE, but a consistency fix as well, since all the other EE games already provide chapter saves by now.

Thoughts?

8 minutes ago, Guest TinekeFrineke said:

argent77, thanks so much! I looked all over the internet for this problem, but it is a known issue after all!!! I'll go install it right away.

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.

4 hours ago, Guest TinekeFrineke said:

Hi I am playing Planescape Torment EE but I have a problem: as soon as I exit Ravel's maze, I have a "Spell Failure" status. I reverted to a much older savegame but the same problem.

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.

1 hour ago, polytope said:

Does this kind of script block still work?

IF
  Die()
THEN
  RESPONSE #100
    DropInventory()
END

Iirc, the items of a disintegrated/frozen creature are actually retained (even though the creature's sprite is gone), as with a stoned one, not dropped as you'd see with most death types.

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.