Sam.

Offhand my guess is it might have changed as a result of the pickpocketable slots being soft-coded.

Don't think this belongs here, but "add missing movies" does exactly what it sounds like. I.e. it doesn't replace existing (new) movies with the originals, only adds the missing ones...

https://web.archive.org/web/20191125182746/http://downloads.spellholdstudios.net/w_gui-v0.6b.7z

These posts should probably go here, and I used my PS BAM tool to do those. I broke the task up into 4 separate batch scripts (placed in the same directory as all the BAM files for the dragon animation) and ran them simultaneously to take advantage of my quad core CPU. I'll post these 4 BAT files verbatim, so you'll need to modify them to point to where you extracted PS BAM_x64.exe (instead of the uncompiled AHK version), and modify the BAM filenames and paths as necessary. As an example, these are for MDR3. Run the 1st one until the first pause, hit enter to continue it, and then you can start the other 3. Let me know if you have questions.

It sounds like you failed to update the area's WED file to actually point the doors structures to the new tile numbers where you moved your doors to at the end of the tileset.

Maybe it would be best if I go into a bit of detail about the root cause of these issues, and the general methodology of what eliminating them entails. The Infinity Engine breaks area graphics down into individual 64x64 pixel blocks known as “tiles”. In the EEs, these tiles are stored in PVR(Z) files. PVRZ files are Z-Lib compressed versions of the PowerVR container file format (PVR). This file format supports a large number of texture compression algorithms, but the EEs use the Block Compression (BC) aka DXT family of LOSSY texture compression algorithms. A side effect of the nature of these compression algorithms is that the color of a pixel will “bleed” into the pixels that surround it. This is the root cause of the graphical artifacts that are the topic at hand. Beamdog’s particular variant of the PVR file format seems to be limited to 1024x1024 pixels (16x16 tiles). The most space efficient way to pack tiles into a PVR(Z) file is to add them sequentially until the space is filled, and then start a new PVRZ file. Several of the modding tools available for building PVRZ-based tilesets do exactly this, but because of the color-bleeding nature of the underlying compression algorithms, this will trash your area graphic. Instead, you should only build the PVRZ files from contiguous blocks of adjacent tiles. To put it another way, you must only add tiles to the PVRZ file that are surrounded by the tiles that will surround them in the actual area graphic. This sounds easy enough, but the devil is in the details. For the base area graphic, this is straightforward if you use the proper tool. Use Near Infinity’s Tools->Convert->Image to TIS and select the PVRZ-Based variant for the tileset. This is the only modding tool for building PVRZ-based tilesets that I have found that stores tiles as contiguous blocks in the PVRZ files. But that is just for the base graphic. The problem tiles come in three flavors: true overlays (like water or lava), doors, and tileset animations (like many fireplaces or the crystal in High Hedge). These require special handling. Specifically, you can’t just leave them added sequentially to the end of your area graphic, you have to surround each tile with the tiles that will surround it when placed inline in your area in order to ensure no stray colors bleed into your overlay/door/animation tiles. See my example for High Hedge in the archive above for a demonstration. It is EXTREMELY important to note that once a tileset has been packed improperly and stray colors have bled into your overlay tiles, the damage has already been done. You can’t simply rearrange them after the fact and expect the graphical artifacts to go away!!! You must either go back and start with the original palette-based tileset or you must spend a vast amount of time touching up the graphics by hand. Edit2: Or better yet, when the true original is available (like for custom mod areas), go back to that as palette-based tilesets are also lossy, tho in a different way. Now for the hard part. True overlays (especially water) are formatted/constructed very differently in oBG1 than they are in oBG2 than they are in BGEE/SoD than they are in BG2EE. There are tools out there that can help with the conversion, but if you’re this far into area graphic creation/manipulation you probably already know about them. More to the point at hand, rearranging the overlay/door/animation tiles at the end of the tileset require you to update the area’s WED file accordingly. The structure of this file is complex, and the nature of the required update is different for true overlays vs doors vs tileset animations. In typical textbook fashion, I will leave the details of this as an exercise for the reader. Edit: As far as what tools I use, I use a few AHK scripts I've written myself, ImageMagick, Near Infinity, and Microsoft Paint. And when the occasion requires it, the tools used to help convert the water overlays from one game variant to another.

And here's my attempt at cleaning up the dark background. I'd say it's a noticeable improvement. There is still some pixel flicker if anyone would like to clean that up.

Here's the fix for the horizontal line through the crystal in High Hedge AR3202. I have included screenshots of before and after in the archive. This should be compatible with both BGEE and SoD. The background of the animation still looks a bit dark compared to its surroundings, so if an artist in interested in cleaning them up I have included the images in the resource folder. Send them back to me and I'll rebuild the TIS. Also, I really need more upload space here.

It's not so much an alignment issue as it is an artifact of the compression algorithms used in the PVRZ format. I started a topic about this type of graphical issue here. Feel free to start listing specific occurrences there.

And fireplaces in houses. The way to eliminate these graphical artifacts is to go back to the palette-based original and take each overlay tile (including for doors) and each animation tile at the end of a tileset and surround it with the tiles that would surround it when it is rendered inline in the tileset. Only then do you convert it to PVRZ. Like argent77 says, this is a very tedious task to do by hand, especially for areas with lots of doors.

Just replace the EXE with one from another mod that works (renaming it). All mod Setup- EXEs are just renamed copies of WeiDU. You can extract them manually with NearInfinity if you want, it's just more work.

I think that makes it the WPMSL*.BAM and WPNSL*.BAM series of BAMs. Can you extract the sling animations from your game and send them to me? For all character sizes the file names would be WP*SL*.BAM. Or you can use this little mini-mod to extract them for you: download link.

Sounds like it might be an issue with the sling animation itself. Try equipping it on a character of a different race (taller or shorter), as they use different BAMs.

So you can move it around your inventory and look at the description, and it's fine: it only crashed once you equip it? Have you tried equipping the real Arla's Dragonsbane to see if it works? No, you shouldn't.

PS_Tileset might have some useful code if you want to go the WeiDU route. Alternatively, you might could use NI's Area Viewer to export the original area as a PNG, then check the "Draw closed" box to flip the doors and export that as a PNG, then use a program like ImageMagick to diff the two, keeping only the changed pixels. From there it might be possible to use ImageMagick to export each distinct region of changed pixels as separate images, but I'd have to do some research to be sure. Edit: Well never mind about the ImageMagick route. I tested it and even after the first step it is apparent there are surely more straightforward routes to get what you want. I'd show you but I've run out of upload space...

I kind of got burnt out on it and needed to take a break, but it has been a good while since then so I'll see about bumping it back up on the priority list.

That sounds like a cool component, tho. I'd like to backstab with Crom Faeyr.

Sure, but then it's not in alphabetical order .

Everyone with CDO probably just cringed. At least put the correct spelling on top so as to not propagate the misspelling unnecessarily?

@Juniior BG:EE Classic Movies doesn't mess with BGEE.lua, it just overwrites the MOS files directly. I'm thinking something else is at play, either you haven't installed the DLC Merger before ALL other mods, or you're using a GUI mod that either isn't supported or you're installing them in the wrong order.

I think I have the multi-lingual version of oBG2, but not oIWD. Here's the original version of the files in English from oIWD: NARR_CH6_oIWD.WAV chap0A.WAV

I had the same thought, but if someone else is volunteering..., here you go: [as I have run out of space to upload attachments at G3...] NARR_CH6.WAV

I knew your were series, but somehow I didn't fully believe you until you did it lol. Well played, sir, well played.

This went so long without a comment I just figured everyone silently passed on it. For the record, the animation shadows on the wyvern use the normal pure black in palette slot 1 (counting from zero) which the engine renders as semi-transparent (probably ~50%). When rendered over a white/light background, it looks grey. The 70% vs 80% is referring to a scaling factor on the height of the shadows.

The difference is the save. With Hold Person, you get a save which means the greater the disparity between the levels of the low level caster and high level target, the less likely the target is to be affected. The mechanic is fair. By contrast, Breach (as one example) bypasses MR and gives no save. That's fine for affecting abilities/spells at a similar or lower level than itself, but the mechanic becomes unfair if it works equally against the highest leveled abilities and spells that a mortal or demigod can obtain. Doing so invalidates the level disparity, which seems broken to me. Keep in mind that my view that HLAs shouldn't be trivially counteracted by comparatively low level spells isn't the primary topic at hand, nor was it my primary argument for why Breach specifically shouldn't work on Hardiness. This was: This.