argent77

New mod for BG2:EE and EET: Skip Chateau Irenicus (Alternate download) It's fully compatible with EET and provides an improved (and less silly) alternative to the (in)famous Dungeon-Be-Gone. The mod will also allow you to pick up all the stuff you missed when escaping to the surface, including mod-added items.

this won't be universal for EET.tp2 since at that point both weidu 239.01 and 239.02 still recognize the game as BG2:EE. Only after EET.flag is in override weidu will report the game as EET (and only after running the installer again). I was only referring to the "double quote" bug from WeiDU v239.02 which also affects every other BG(2)EE mod that makes use of this variable. In EET it must probably be added to both EET.tp2 and lib/EET_end.tp2 to work correctly. Edit: Btw, I've noticed that the option "Show Black Space" is automatically disabled by EET. Is this a technical necessity?

How about quick workaround? Adding this ALWAYS block should fix the USER_DIRECTORY issue in a more universal way: ALWAYS OUTER_PATCH_SAVE USER_DIRECTORY ~%USER_DIRECTORY%~ BEGIN REPLACE_TEXTUALLY ~^\(.+[\/]\)"\(.+\)"$~ ~\1\2~ END END

I don't think this issue should be solved by core EET. As already mentioned, there may be mods that require these items to be found within the game. It's true that you'll have two different stacks of identical ammo or potions, but at that point you should be able to acquire gem bags, potion cases or ammo belts to save inventory space. I'd suggest to add such a component to the EET Tweaks instead. Since it's installed very late in the installation chain it can fix even mod-introduced dependencies to the items in question.

Sometimes I can loot stackable items without "charge". They don't display a number in the inventory screen and adding them to existing stacks don't increase the stack. It's been fixed after a save and reload. I've seen it with a healing potion and an arrow of dispelling so far. Both were most likely random drops. I can't remember who dropped the potion, but the arrow was dropped by a spawned bandit with bandit scalp. Maybe another quirk of the new treasure table system?

Here you go: saves_-_doubled_rasaad.7z I've also included Nashkel's area script and my WeiDU logs, just in case.

I've just encountered a second Rasaad in Nashkel after revisiting the town. Inspecting my saved game I found a third character entry for Rasaad as well, although that one hasn't been placed on any map. Could this be EET-related or is it a BGEE issue? I'm using EET RC3 with the RC4 hot fix and a small number of mods (incl. BG1 NPC Project). Rasaad never joined my party, but I talked to him once already.

The letter is dropped by one of the Ogrillons. However, it's not flagged as quest item, so it might disappear if you come back later to pick it up. The letter is also present in the dead halfling's inventory. But he shouldn't drop anything since he's already dead when the map is loaded.

I can confirm as well. It looks like the fix has not been applied to BG3300.TIS and the two other reported maps. Edit: @K4thos The culprit is COPY_EXISTING in the FIX_WATER function. Since you never install TIS files directly, but instead biff them from a working directory, you have to adapt the function accordingly.

RNDTRES.2DA appears to be special in many ways. For example, you can't define random lists with a chance of generating no item at all. The engine appears to calculate the chances for each item from the available items in the row. The remaining "*" entries are ignored completely. I'm using this file extensively in my Golem Construction mod. To simulate a chance of no item drop, I had to add dummy items with cleared "Droppable" flag to the list. None of the items have a non-zero lore defined however, so I didn't notice that items from this table are automatically identified. I'll make some more tests. Maybe I can find out more.

On closer inspection I can see that all PVRZ files of BG4000.TIS containing transparent regions are different. The most noticeable files are A400009.PVRZ (BGEE) / B400009.PVRZ (EET) and A400021.PVRZ (BGEE) / B400021.PVRZ (EET). Are you recompressing them at some point during installation? Edit: Nevermind, I've compared them with an older version of BGEE. The latest BGEE patch v2.3.67.3 contains the same visual glitches.

Comparing the TIS file from EET and BGEE side by side it looks like the additional tiles at the bottom of the TIS are different in EET. Some are misaligned, others just look differently.

Yes, that is it. It's only misaligned by a single pixel. You can also see it in the area viewer of NI. It must be caused somewhere in the process of installing EET. The original map in BGEE looks fine.

I've noticed that many enchanted items from random drops are already identified, such as protection scrolls or enchanted ammunition. I'm running a number of mods though, so I can't tell whether this is caused by EET or one of the other mods. Can anyone confirm? Edit: I've also noticed a couple of misaligned door tiles in their closed state on map BG4000 (Gullykin).

It looks like you can fix glitched water overlays simply by setting "dummy tiles" as secondary tiles in WED resources. The following WeiDU code should fix the issues mentioned in my previous post: [spoilerT/p> DEFINE_ACTION_FUNCTION FIX_WATER INT_VAR numTilesToFix = 0 // number of tile indices to fix // $tilesToFix(0), ... contain tile indices to fix STR_VAR wed = ~~ BEGIN ACTION_IF (numTilesToFix > 0 AND FILE_EXISTS_IN_GAME ~%wed%~) BEGIN // Setting required secondary tile indices COPY_EXISTING ~%wed%~ ~override~ SET ofsOverlay = LONG_AT 0x10 SET ofsTileMap = LONG_AT (ofsOverlay + 0x10) READ_ASCII (ofsOverlay + 0x04) tisFile (8) NULL PATCH_IF (FILE_EXISTS_IN_GAME ~%tisFile%.tis~) BEGIN INNER_ACTION BEGIN // adding dummy tiles to TIS COPY_EXISTING ~%tisFile%.TIS~ ~override~ READ_LONG 0x08 numTiles WRITE_LONG 0x08 (numTiles + numTilesToFix) READ_LONG 0x0c sizeTile READ_LONG 0x10 ofsTiles FOR (idx = 0 curOfs = ofsTiles + (numTiles * sizeTile); idx < numTilesToFix; idx += 1 curOfs += sizeTile) BEGIN // adding new "black" tile INSERT_BYTES curOfs sizeTile WRITE_LONG curOfs "-1" END BUT_ONLY END // updating secondary tile indices FOR (idx = 0; idx < numTilesToFix; idx += 1) BEGIN PATCH_IF (VARIABLE_IS_SET $EVAL tilesToFix(~%idx%~)) BEGIN SET tileIndex = $EVAL tilesToFix(~%idx%~) SET ofsTile = ofsTileMap + (tileIndex * 10) WRITE_SHORT (ofsTile + 4) (numTiles + idx) END END END BUT_ONLY END END // patching BG3300 (Beregost) ACTION_DEFINE_ARRAY tilesToFix BEGIN 3799 3800 3879 3880 END LAF FIX_WATER INT_VAR numTilesToFix = 4 STR_VAR wed = ~bg3300.wed~ END // patching BG3000 ACTION_DEFINE_ARRAY tilesToFix BEGIN 2588 END LAF FIX_WATER INT_VAR numTilesToFix = 1 STR_VAR wed = ~bg3000.wed~ END // patching BG1802 ACTION_DEFINE_ARRAY tilesToFix BEGIN 1292 1293 END LAF FIX_WATER INT_VAR numTilesToFix = 2 STR_VAR wed = ~bg1802.wed~ END Edit: Optimized code

I found a small number of glitched water overlays in RC3: Water of fountain in Beregost (BG3300) at x=2550, y=3100 Water of basin on map BG3000 at x=1800, y=2070 Water of basin on map BG1802 at x=1800, y=1500

There are no changes to the cutscene but one of the spell animation (exploding Shadow Thief) is slightly longer. Considering EET doesn't overwrite BG2 spells but the animation looks different my assumption is that one of the vanilla BG2:EE spells must have a reference to not existing resource that is now available after importing stuff from BG:EE. Other than this I didn't notice any oddities with the cutscene but will take a look. I've made a video clip out of it for closer inspection. I don't mind the delay of Imoen's appearance, but the Shadow Thief sequence doesn't look natural at all.

There is also a beta version of the Improved Archer Kit available which is compatible with EET. I have to postpone a stable release until WeiDU v240 has been published, however.

The following mods have already been made EET compatible: Golem Construction for Spellcasters (since v2.0) Lighting Pack: Shader Scripts for the Enhanced Edition (since v2.3) Recolored toolbar buttons for BG:EE & BG2:EE (since v4.1)

I found two more issues: 1. I've noticed some delay of the script execution in the SoA starting cutscene. It starts when the golem reports intruders. Everything afterwards is more or less out of sync. Has anyone noticed this too? 2. If you start a SoA game then Imoen doesn't interject when you talk to the golem in the room with our initial equipment. This is because Imoen's script name is "Imoen2" while the golem checks for "Imoen" instead.

Are you sure that you didn't remove fpYUV.GLSL file from your override? That's the file responsible for this effect. Please compare content of this file with the one in EET/base/glsl/ directory. You're right. I forgot to disable my user override folder for that test.

Congrats from me as well. I've just installed RC1 and made a quick test run. The game starts fine. I can select and start each campaign. However, I've already noticed two issues. 1. The GUI is a bit mixed up. It appears to use elements from SoD with the BG2 GUI: 2. There is a graphics bug in the opening map of SoD: The debug files (in case you need them): SETUP-EET.zip SETUP-EET_END.zip

With EET (not at this time- but once it has grown significantly in contents) is there already an idea about general biffing to be applied or is this a thing of the past for the new machine? I don't know if there is still a performance penalty in the Enhanced Editions with great numbers of files in the override folder. However, it's always a good idea to biff the override folder at the end of the installation, except maybe for a couple of mods that are supposed to be re-installed periodically. It may not only increase game performance, a clean installation folder is also easier to manage (and don't forget that the filesystem overhead of thousands or hundreds of thousands of files wastes a lot of disk space).

I wonder why it should be so difficult to post the content of two log files instead of a single one for bug tracking? Whenever I see the request to "post the WeiDU.log" when someone has a problem then I can imagine that it's equally straightforward to "post the WeiDU.log and WeiDU-BGEE.log". Putting the BG:EE WeiDU.log into the override folder is probably a bad idea though. Maybe it's just me, but after the installation process and the final biffing, I'm routinely cleaning the override folder from any "garbage" files.

Since you're already using TileConv, you can reduce archive size a bit further by compressing MOS files into the MBC format. It reduces the 40 MB MOS files down to 12.5 MB MBC files. It's not much, but every little bit counts.