argent77

I think you (or a mod) has enabled a debug feature that displays the reference numbers of all game strings. To disable then, go into the user directory of the game "Documents/Baldur's Gate - Enhanced Edition Trilogy" and open the file Baldur.lua. Search for the string "Strref On" (without the quotes) and check if it's set to 1. In that case change the 1 to 0 and save the changes. Make a backup of Baldur.lua beforehand, just in case.

Spellhold Studios Trials of the Luremaster for BG2:EE Trials of the Luremaster for BG2:EE is a port of the Icewind Dale expansion. It is now available for BG2:EE and EET! The mod allows you to take part in an adventure where you can explore a haunted castle, test your mettle in challenging combat and lift an ancient curse. In addition to the original adventure, the mod provides various story and combat improvements as well as interactions from all of the Bioware and Beamdog NPCs. Download: SHS, GitHub Forum Readme

I wrote an unofficial WeiDU wrapper for an external conversion tool some time ago to make dealing with iOS/Android texture format exceptions easier. You can find it attached to this post. (Note: Because of patent issues the tool may not work correctly on macOS or Linux. I don't know if this issue has already been solved in more recent versions of the tool. Afaik, patent protection for the responsible texture formats should have expired some time ago.) MOS files for maps are no longer needed since EE patch 2.0. For earlier EE patch versions MOS image dimensions were slightly bigger than for the original games (about 166.67% of original size to be precise).

Update: It looks like the global variable "FOG_TYPE" can be used to select a specific fog definition that should be used by the map. It refers to the (numeric) value found in the first column of FOGPT.2DA. Example from SoD's BD6100.BCS, which enables a specific fog effect after progressing the main story to a certain point: However, once FOG_TYPE is set it doesn't seem to be possible to return to map-specific fog definitions (for any map using fog). Setting it to 0 doesn't work. Not sure if this is intended or a bug.

They are updated dynamically via SetPlayerSound(). You can find them in the respective SoD NPC scripts (e.g. bdminsc.bcs, bdedwin.bcs, etc.).

It looks like ssl.exe included in RC7 is a 64-bit executable. It can't run on Windows XP (or any 32-bit versions of Windows Vista or later). On Windows 7 or later you can check it yourself by right-clicking on ssl.exe. Select "Properties" and switch to "Compatibility" tab, the drop-down list of "Compatibility mode" should list Windows XP among other versions if it's a 32-bit executable, otherwise it will only list Windows Vista and later versions.

Yes, the code looks fine. Just remember that PVRZ filename scheme is made up from the TIS filename minus second letter, followed by a two-digits pvrz index (e.g. AR1234.TIS -> A123400.PVRZ, A123401.PVRZ, ...), so you have to rename all your PVRZ files accordingly if you rename your TIS.

There are several issues when using the old TIS format in EE games: 1. Glitches: As you already mentioned above, there may be thin black borders around some or many tiles (depending on zoom, current viewport, renderer, etc.). 2. Performance: Old palette-based tilesets are noticeably slower than PVRZ-based tilesets. To solve these issues you can either provide two tileset variants (one for original games, another one for EE games), or perform on-the-fly conversion. I have written a tool for this (tile2ee) some time ago. It also contains a small WeiDU library that makes the conversion process much easier to deal with. I'd suggest to include PVRZ-based tilesets in the mod and convert them on-the-fly to palette-based tilesets if a non-EE game is detected. The easiest way to generate PVRZ-based TIS from the old tileset variant is with Near Infinity. Place all the area files (are, tis, wed) in the override folder, select the TIS in NI and select Export... => as PVRZ-based TIS. MOS files aren't strictly needed anymore for areas in EE games (afaik since patch 2.0). Btw, PVRZ files are not a replacement for TIS. They are paired with TIS instead: TIS contains tile definitions (texture indices, tile size and position, ...) while PVRZ contains the actual graphics data.

I don't think there are platform-specific differences for any of the EE games. The error message mentioned in that other topic doesn't necessarily have something to do with playing on a Mac. I was able to install the involved mods flawlessly on my macOS BG2EE test installation. I'd suggest to ask @Wisp for help to get a more definite answer though.

I don't have a Mac either (unless you count a macOS virtual machine). But unless you have to execute platform-specific code, it should be enough to provide a macOS WeiDU binary, renamed to setup-mymod, as well as a shell script like this, called setup-mymod.command: command_path=${0%/*} cd "$command_path" ./setup-mymod Replace "setup-mymod" with the name of your setup binary. Make sure to save the script with unix-style line endings. The following stuff is optional, but might help less experienced macOS users to install the mod without further preparations: macOS and Linux require binaries to be configured with the "executable" file attribute. Unfortunately Windows doesn't support unix file attributes. If you have access to Linux, you should prepare and zip it on that platform. Set executable attribute for setup-mymod and setup-mymod.command, and pack everything into a zip archive: chmod +x setup-mymod setup-mymod.command zip -r -9 mymod-v1.0.zip * Or use a file manager for these steps. On Window the same can be done in a Cygwin environment. The console commands from above should also apply to the Cygwin console.

Another oddity I noticed some time ago: if a spell contains effects in multiple probability ranges (e.g. 0-9, 10-19, 20-29, ...), you might experience effects triggering from two or more (or zero) independent ranges on rare occasions. This is caused by a quirk in the game engine if auto-pause conditions "Spell cast" or "End of round" are active.

I found the relevant comments regarding GOG patches: http://gibberlings3.net/forums/index.php?showtopic=28161&p=261964 and http://gibberlings3.net/forums/index.php?showtopic=29600&p=263267 It deals mainly with missing SoD files though, so maybe it's not related to your problem. In any case you have to update the games to the latest patch versions (BGEE v2.5.17.0 and BG2EE v2.5.16.6) to make them work with EET.

Since you mentioned that you have the GOG version of BGEE. I've read somewhere that their latest incremental patch of the game is incomplete, missing some files that are essential for an EET installation. Afaik, a full reinstall of the game should fix this problem.

If mod components with READLN can be omitted by player, it's not too much of the problem. But if READLN are part of the main component, it makes player life miserable. Good adoption of Solution 2 can provide both ways of providing value: from user input or from actual configuration made by player itself. Apart from LightingPack which use ACTION_READLN to read custom gamma value, is there any other mod which use ACTION_READLN? Not many. And as I mentioned before, all of the relevant components can be safely omitted in a mod manager: 1. Banter Accelerator: Provides a component where you can enter custom banter frequency and probability values as simple integers. 2. Lighting Pack: Provides a component where you can enter custom values for brightness, contrast and gamma as real numbers within specific ranges. 3. DLC Builder: Requires user input for the DLC filename. This mod is not intended for regular gameplay. 4. DLC Merger: Provides a component, where you can specify the DLC archive you want to merge. This component is mainly intended to merge custom DLCs created by DLC Builder.

Removing READLN completely and using .ini files or a similar approach might be acceptable for a mod manager. But at the same time it will pose an unacceptable obstacle for players who want to install mods manually (which I usually do). Moreover, WeiDU can be used for all kinds of applications. I'm using it a lot internally, e.g. as debugging tool or to get something done quickly. READLN is a good (and currently only) method to add some kind of interaction to the installation procedure. Apart from that, I'm using READLN sparingly in my mods, and only in situations where it doesn't make sense to provide any kind of presets or default values. None of these components are crucial parts of the mod, and may be omitted in a mod manager.

We are happy to announce that NPC Interaction Expansion Project (IEP), a grand endeavour to uplift non-romancing relationships with Bioware NPCs to the high quality standards set by modern mods in regard of depth and complexity, has been expanded once again now adding Valygar to its fold. An old La'Valygar project got revived, enhanced, edited and renamed by fluke13, Lava Del'Vortel and Jastey, turning into a full-fledged Valygar Friendship. With this mod installed, you should be able to experience up to 12 dialogues in SoA and up to 5 dialogues in ToB. Note that the mod has changed greatly when compared to its previous incarnation. The most prominent changes from La'Valygar project are additional proofreading and editing, new talks, and improvements to the old ones. Download Forum

That appears to be a bug in the latest BG:EE 2.5 patch. The same tweak seems to work correctly in BG2:EE though, so you could install EET to play the BG1 part with this tweak.

Afaik, the Boards o' Magick Item Pack makes heavy use of various kit usability flags for their items.

That's an interesting thought. Unfortunately I couldn't make it work in my tests. It appears messages for opcodes 220 and 221 are really hardwired into the game executable. Looks like the best I can do is defining a custom feedback message. Fortunately the EE games don't suffer from this hardcoded issue. Specifying strref -1 suppresses feedback entirely.

Pure 32-bit Windows installations are rare, but still available (even for Windows 10). Except for specific mods (such as SCS) it is safe to ship mods only with 32-bit WeiDU binaries for Windows. Btw, DLC Merger doesn't require a 64-bit binary to merge SoD. It is only recommended if multiple user-created DLCs (e.g. made by the DLC Builder) have to be merged with the game.

I can see nothing out of the ordinary with that component in my game. Maybe it's triggered only in combination with other mods?

I think I can solve that mystery. NUMWSLOT.2DA in IWD:EE uses Windows-style line breaks, which WeiDU's regexp interpreter doesn't cover when checking for line endings ($). To fix it, open setup-cdtweaks.tp2, go to the component's script section (around line 12290 in v5) and replace the line REPLACE_TEXTUALLY ~\([ %TAB%]+\)[123][ %TAB%]*$~ ~\14~ by REPLACE_TEXTUALLY ~\([ %TAB%]+\)[123][ %TAB%%MNL%]*$~ ~\14~

Thank you, that's very insightful. And it also explains why the effect doesn't work as expected. I'm trying to apply opcode 187 (Set local variable) via 177. No matter how I set up parameters, the effect is always applied directly with fixed timing mode 9 and all parent resource info cleared. Looks like I have no choice but to add another opcode 187 instance to the removal spell to reset the global.

Enhanced Edition games provide the very useful effect opcode 321 (Remove effects by resource) to remove selected spell effects from a creature. Sadly, the original BG2 engine doesn't provide such a feature. However, it is possible to exploit opcodes 220 (Remove effects by school) or 221 (Remove effects by secondary type) to accomplish a similar effect if you use a custom school (via mschool.2da) or secondary type (via msectype.2da) for the spell effects. These two opcodes are available to both BG2 and EE engine, but have the ugly side effect of printing a message to the game log, regardless of whether a message is defined or not. Is it possible to suppress this feedback somehow? Or are there other/better options available to accomplish the same effect as the methods above? Bonus question: Is it possible to preserve the secondary type of an EFF resource (or inherit it from parent spell) applied via opcode 177?

Order of parameter types for both DEFINE_(ACTION|PATCH)_FUNCTION and LAUNCH_(ACTION|PATCH)_FUNCTION is fixed at INT_VAR -> STR_VAR -> RET -> RET_ARRAY. Changing order will trigger a syntax error. See WeiDU Documentation for more details. Edit: You can specify the parameters themselves within a section in any order though.