Sam.

Where does the key "Information" point to for a mod that has a readme, a forum, and a website all hosted online, and not necessarily at the same base URL? Also, if you mandate everyone conform exactly to "an industry standard", you must point to strict documentation of that standard. Preferably, the standard and documentation would be rigorously maintained by a recognized authority. Ideally, the format chosen would be established and widespread enough to be *natively* supported by many programming languages, and IMO be human-readable.

Isn't it more elegant to format your INI file as valid WeiDU variable assignments and INCLUDE it?

Thanks for looking.

The EEs have 32-bit bitmaps that have a Windows BMP Version 5 header, which is not documented in the IESDP. A decent explanation of the BMP file format (I generally find it more useful than what is already in the IESDP) can be found here, and a breakdown of the Bitmap V5 Header can be found here. For reference, I'll provide an overview of the structure along with values from a file (1CHELMX6.bmp) that is typical of those found in the EEs: ;;;;; 32-bit Windows 5.x BMP ;;;;; http://www.fileformat.info/format/bmp/egff.htm https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/ns-wingdi-bitmapv5header BMP Version 5 (Microsoft Windows 5.x) Offset Type Size Data Description Typical Example From EE 0 WORD 2 FileType File type, always 4D42h ("BM") BM 2 DWORD 4 FileSize Size of the file in bytes 120458 6 WORD 2 Reserved1 Always 0 0 8 WORD 2 Reserved2 Always 0 0 10 DWORD 4 BitmapOffset Starting position of image data in bytes 138 14 DWORD 4 Size Size of this header in bytes 124 18 LONG 4 Width Image width in pixels 160 22 LONG 4 Height Image height in pixels 188 26 WORD 2 Planes Number of color planes 1 28 WORD 2 BitsPerPixel Number of bits per pixel 32 30 DWORD 4 Compression Compression methods used 3 34 DWORD 4 SizeOfBitmap Size of bitmap in bytes 120320 38 LONG 4 HorzResolution Horizontal resolution in pixels per meter 2834 42 LONG 4 VertResolution Vertical resolution in pixels per meter 2834 46 DWORD 4 ColorsUsed Number of colors in the image 0 50 DWORD 4 ColorsImportant Minimum number of important colors 0 54 DWORD 4 RedMask Mask identifying bits of red component 0x00FF0000 58 DWORD 4 GreenMask Mask identifying bits of green component 0x0000FF00 62 DWORD 4 BlueMask Mask identifying bits of blue component 0x000000FF 66 DWORD 4 AlphaMask Mask identifying bits of alpha component 0xFF000000 70 DWORD 4 CSType Color space type 1934772034 (sRGB) 74 LONG 4 RedX X coordinate of red endpoint 0 78 LONG 4 RedY Y coordinate of red endpoint 0 82 LONG 4 RedZ Z coordinate of red endpoint 0 86 LONG 4 GreenX X coordinate of green endpoint 0 90 LONG 4 GreenY Y coordinate of green endpoint 0 94 LONG 4 GreenZ Z coordinate of green endpoint 0 98 LONG 4 BlueX X coordinate of blue endpoint 0 102 LONG 4 BlueY Y coordinate of blue endpoint 0 106 LONG 4 BlueZ Z coordinate of blue endpoint 0 110 DWORD 4 GammaRed Gamma red coordinate scale value 0 114 DWORD 4 GammaGreen Gamma green coordinate scale value 0 118 DWORD 4 GammaBlue Gamma blue coordinate scale value 0 122 DWORD 4 Intent Rendering intent for bitmap 0 126 DWORD 4 ProfileData Offset to profile data 0 130 DWORD 4 ProfileSize Size of embedded profile data 0 134 DWORD 4 Reserved3 Always 0 0

BAMWorkshopII supports an unpaletted BAM format (BAMU) and has the following to say about it: "Beyond Infinity" sounds suspiciously like GemRB. Was this format ever implemented anywhere, or does any further documentation about it exist? Looking at a BAMU, the Header looks like: Offset Size (data type) Description 0x0000 4 (char array) Signature ('BAMU') 0x0004 4 (char array) Version ('V1 ') 0x0008 2 (word) Count of frame entries 0x000a 1 (unsigned byte) Count of cycles 0x000b 1 (unsigned byte) The compressed colour index for RLE encoded bams (ie. this is the colour that is compressed) 0x000c 4 (dword?) Unknown field. One observed value is 0xFF0000FF 0x0010 4 (dword) Offset (from start of file) to palette 0x0014 4 (dword) Offset (from start of file) to frame entries (which are immediately followed by cycle entries) 0x0018 4 (dword) Offset (from start of file) to frame lookup table Note I’m unsure what the 4 bytes at 0x000c are for. Any ideas? OffsetToPalette is usually/always 0, and no palette appears to be stored in the file. Otherwise, Frame Entries, Cycle Entries, and Frame Lookup Table sections are the same as in BAM V1, except that frames do not have RLE. Frame data is stored as 24bpp in the RGB order, and has no scanline padding.

Some legacy mods set the storage capacity to 0 which makes them "truly unlimited", but that has been shown to cause problems like you describe in the past. The better practice for "truly unlimited" storage is to set the capacity to one less than the maximum possible value of the field (a signed integer?), but 999 should be perfectly fine. If you are on a classic game, there might have been a TobEX component that had something to do with containers (I can't remember for sure). If you're on the latest version of an EE game, try to reproduce the behavior without mods installed, and if you can report it to BeamDog. Other than that, I'm not sure what to suggest.

Have you installed some version of bottomless bags of holding?

Post it or PM me and I'll take a look at which internal formats the BMP is using.

Use Infinity Animations instead?

BAM Batcher comes with a few resources and templates that might or might not be helpful. There is an overview in the Tools section of the readme.

Wow thanks! Could you write a tutorial on how to use your tool? Setup-PS_Tileset.tp2 is a working example that displays almost all of the functionality offered by the tool, plus it intentionally uses some bad inputs (where noted in the comments) to show that it handles them properly. That main TP2 file has inline comments explaining what each call to the function library is doing, plus I tried to make sure the library itself (ps_tileset_lib.tpa) was well commented. If you have specific questions, I'd be happy to answer them the best I can.

Thank you for the examples. It seems I am still doing something wrong, tho: gives: Edit: I figured it out.

So I have a folder of MOS V2 + PVRZ files I want to install to the override folder of an EE game. It looks like I need to use the WeiDU functions INSTALL_PVRZ, UPDATE_PVRZ_INDICES, and FIND_FREE_PVRZ_INDEX to make sure I don't overwrite anything already in the game, but I don't quite understand how they are supposed to be used. Could anyone please either post an example or point me to one? TIA, Sam.

If you need any help figuring out BAM Resizer, just let me know.

Sadly, no... I guess I should have thrown in that disclaimer with my initial statement, sorry. I'm still hoping this gets implemented sooner rather than later.

[...] If you have a decent hex editor you could manually add some dummy tiles to the TIS files to make them work. BH1000.TIS requires one addition tile and BH2201.TIS requires four additional tiles. This is exactly the type of thing PS_Tileset is designed to do. Adding the missing tiles to both tilesets is a total of 3 function calls away. If you upload both of the original tilesets for me, I can show you how.

I mirror a copy (that has had HTML syntax errors corrected) here: http://readme.classicadventuresmod.com/TobExReference.html

I haven't done exhaustive testing, but it seems the EE engine (and probably also ToB) do not like it when the RLEColorIndex is not zero (0). The EE engine transforms the color of the RLEColorIndex into transparent (Green) while ToB renders it even more poorly. There goes some potential compression...

There was some discussion here: http://forums.pocketplane.net/index.php/topic,29685.0.html Your best bet may be to avoid any commands specifically designed to work with 2DAs and parse the files manually e.g. with RegEx yourself.

It hasn't been extensively tested yet, but here is a function library to do stuff with tilesets: PS_Tileset Note that if you want to add bitmap tiles to a PVRz-based tileset, you will need to run Tile2EE to convert it to a palette-based tileset first, then convert it back.

I broke down and wrote it anyway, which concludes my initial vision for the project. The first beta release containing the full feature set can be found on GitHub.

I have updated the library with a new function, ps_tileset_replace_palette_entry, that replaces palette entries with a new color. So say there was a tileset with a tile that contained a pure green pixel, which would look odd. You can use this function to replace every pure green pixel with some other color. I feel like there was a fixpack somewhere that did something like this. A problem arises if you need to replace the color of a single pixel without entirely removing that color from the tile (like if that bad green pixel was in a door or water overlay tile that intentionally uses green for the transparent sections). To replace the color of this pixel, you would first look to see if the color you want to replace it with was already in the palette. If it is, great you're done. If it isn't, you would next have to look for an unused palette entry. If every palette entry is used, you would look for duplicate palette entries, combine them, and then use the free entry. If there are no duplicates, you're left with calculating the nearest-neighbor color within the existing color pool. I have basically already done this for BAMs in a different language (AHK) so I know how to do this, but rewriting it in WeiDU would constitute significant time and effort. While this last function would complete my initial vision for this tileset function library, I'm a bit hesitant to put forth the effort if there is no need for it. Other than this, my library (along with Tile2EE) includes the capability to do anything with a tileset I could envision anyone wanting to do that couldn't be done better with just a well placed WRITE_BYTE. Thoughts? Anyone know which fixpack I vaguely remember or how it went about replacing green pixels?

After entirely too many months of delays, here is an initial beta that anyone is welcome to play around with. The function library comes with a test suite to demonstrate a variety of its capabilities and to purposefully trigger various warnings and errors. IMO it can do quite a lot with tilesets that AFAIK has never been done with WeiDU before, but keep in mind that until WeiDU's filesize limitation has been resolved (hopefully a solution is in the works), it won't work on large tilesets. Also note that if you need to add tiles from bitmaps to a PVRz-based tileset, you will first have to use Tile2EE to convert it to a palette-based tileset, add/replace the tiles, then use Tile2EE again to convert it back to a PVRz-based tileset. Feedback, bug reports, suggestion, criticisms, etc. are all welcome.

IIRC the deck itself (if you acquire the item) is 'stacked against you' . You can't draw the best cards unless you have previously made a "bad" draw. I've always thought this was a stupid nerf (presumably added for "balance") that went against the randomness and luck-of-the-draw nature that is the deck's essence. I'm not sure either (or even both) of these warrant a new tweak component, tho. A global un-nerfing tweak would be awesome, but it would be quite a bit of work and there would never be a consensus on what should be included.

In the same vein (although presumably with a bit different implementation) as tilesets and their headers being stored separately? I find it hard to imagine why this type of thing would have been done in the first place. My only guess is that it resulted in fewer computational steps for the images to be send to the graphics card, or otherwise facilitated marginally faster rendering of the graphics?