argent77

I agree with Acifer that the water overlays work as expected in your test sample. Since the background of the water tiles are mostly solid black you'll see a very strong overlay effect from the water tileset. Adding some background to the water tiles will probably reduce the effect somewhat. In that case you could also tweak the "Overlay transparency" field in the ARE file (formerly known as 'Wind Speed') to adjust overlay transparency. Alternatively, do it the SoD way and use WBM video overlays instead:

It could be an issue with DLTCEP. The tool hasn't been updated for years. Does the map load correctly in NI? Did you check the height/light/search map overlays in NI's area viewer?

Did you maybe use the original "wrong" WED file from BG2EE instead? It has a tileset dimension of 80x45 tiles that actually corresponds with a height/light/search map size of 320x240 pixels.

I think you're right. My test script had some flaws which lead to misleading results. The outcome of these actions is indeed random when an unsupported parameter encoding is used. But in that case WeiDU compiles both script actions incorrectly for oIWD and (possibly) oPST.

Thank you. It looks like the game engine can actually handle both parameter encoding variants correctly. However, NI has to use the same encoding as WeiDU is using to prevent the bug mentioned in my previous comment. (And WeiDU made some arbitrary choices regarding parameter encoding for some engine variants.) See comments below.

OP asked specifically about AddexperiencePartyGlobal() which isn't actually used in any of the games. @squiros It looks like you stumbled upon a bug in NearInfinity's script (de)compiler which encodes and decodes the parameters for this script action incorrectly in some of the game engine variants. It'll be fixed in the next release. In the meantime only use WeiDU to compile or decompile your script that contains this action. Edit: The issue in NI has been fixed and can already be tested in the nightly release: https://github.com/Argent77/NearInfinity/releases/tag/nightly

Wares of the Planes is a mod that introduces a large number of weapons and accessories from Planescape: Torment to the Baldur's Gate series. The items can be purchased from a unique travelling merchant who is available throughout the whole game series. The mod is available for BG:EE, SoD, BG2:EE and EET. Version 1.1 improves the merchant portrait, adds a new subcomponent to restore the original PsT portrait and introduces several more unique items. You can grab the mod from the download link below. Download: GitHub Discussion: G3, Beamdog Readme

New release: Wares of the Planes 1.1 Changelog: Added new default portrait for the travelling merchant Added tweak that restores the original PsT portrait for the travelling merchant Added new items for sale: Elixir of Horrific Separation, Moridor's Box

That's difficult since PsT doesn't have any scimitars. But I'll add it to my todo list. Maybe I can come up with something of my own.

This is how it's done in the Spellhold Irenicus encounter: There are actually two different clone actions: CreateCreatureObjectCopy(S:ResRef*,O:Object*,I:Usage1*,I:Usage2*,I:Usage3*) CreateCreatureCopyPoint(S:ResRef*,O:Object*,P:Dest*) The second variant is probably more useful since you can simply choose a coordinate outside of the current viewport to hide the cloning process.

WeiDU caches strings (and other stuff) internally for performance reasons. Reading or modifying the dialog.tlk externally while a mod installation is in progress may not work as intended.

Thank you. I agree that the portrait style doesn't really fit into the BG environment. I'm already working on a more suitable alternative. My Photoshop skills aren't the very best though, so we'll see how it turns out.

That's a good example how deceiving ChatGPT's answers can be. At first glance this script looks plausible (except for two glaring syntax errors), but the code itself is nonsense and looks more like a mishmash from several different (and unrelated) mod scripts.

It should work fine if the "data" folder is specified in the path definitions in Torment.ini (or maybe *not* specified in your case) rather than hardcoded directly in the chitin.key.

I don't know if or how the GOG version is different, but in my oPST (disc) version all biff files can either be found in the root directory or the "CDALL" subfolder. Whether the game (and NI) can find them depends on the path definitions in Torment.ini and how biff files are referenced in the chitin.key.