Sam.

Yeah so a while back my computer went kaput. After working on restoring my system for hours every day for 2.5 weeks, I was able to get it back. Sadly I lost a month and a half of changes, including the month I spent working on this. I'm particularly disheartened because this was the most sophisticated WeiDU code I had ever written, and I was proud of it. I have started the arduous process of recreating it from scratch, but deep down I suspect I will not quite be able to reproduce the divine inspiration that went into the original. I don't have an ETA at this point. Apologies to all.

This intrigues me greatly. Is the engine code to use such a file implemented enough to be functional? Avenger, could you rummage around in the source code to back out the file format like was done for VEF by Ascension64? That file format was (IIRC) completely unused until Ascension64's discovery of it, but turned out to be quite powerful and useful (if still under utilized).

Expand container "Items purchased" list. Below are some suggestions from my EET game: Bag of Holding can store all items (except Containers (36), and perhaps Familiars (38)). [Example being MISC61.ITM (Bandit Scalp) in my game which has a category of Tattoos (39) which can't be stored in a bag of holding.] Ammo Belt can store (throwing) Daggers (16) Ammo Belt can store (throwing) Axes (25) Scroll Case can store Notes (50) Potion Case can store Bottles (56)

Time for an update. Right now I can: Repair a couple increasingly uncommon bugs with tileset headers: 1 with PVRZ-based tilesets and 2 with palette-based tilesets. Remove tiles from PVRZ-based and palette-based tilesets using one of two methods: Pop (removes N tiles from the end of the tileset), and RemoveAt (removes N tiles from the tileset starting at the specified tile). Add tiles to palette-based tilesets using one of three methods: Push (add a number of tiles to the end of the tileset), InsertAt (insert a number of tiles into the tileset before the specified tile), and Replace (replaces a number of tiles starting at the specified tile, adding tiles to the end of the tileset as necessary). Create a new palette-based tileset from a series of tiles. I'll be working on exporting a palette-based tileset as a series of tiles next. In the meantime, tho, I'm looking for some design input concerning adding tiles to a PVRZ-based tileset and creating a new PVRZ-based tileset. I won't be messing with the PVRZ files themselves, so that leaves us with the ability to Push, InsertAt, and Replace the 12-byte data blocks of the PVRZ-based tilesets. This can be achieved in a number of ways. First, one could pass PVRZpage, XCoordinate, and YCoordinate to three variables of the add function. This would mean you would have to call the Add function for each tile you want to add. The down side to this is that with the current implementation, the tileset header must be read each time the function is called. Not the most efficient, but not terrible. One bonus to this would be the freedom to generate tile data on-the-fly, having to store nothing on disk. Second, one could have each PVRZ data block saved to a separate 12-byte binary file. The files are passed to the Add function via a REGEXP (just like the palette-based tiles currently are). This has the bonus of being directly parallel/comparable to the current palette-based implementation so would be the easiest for me to code. Downside is the inefficiency of filesize on disk, greater number of files shipped with/managed by the mod, and unnecessary number of disk reads. Third, one could have the entire series of tiles one wanted to Push, InsertAt, or Replace in a single binary file. Better efficiency all around, but perhaps less flexible depending on one's needs. Fourth, one could pass a variable to the Add function that contains all the tile data blocks to Push, InsertAt, or Replace. Basically a combination of options one and three. How this variable is populated would be up to the modder using the function. The Create function would use the same procedure as the Add. Thoughts?

I've been working on it, but it has turned into a bit bigger of a project than I originally envisioned. I'll try to work on it some more over the next few days. My project will have some limitations, however: Due to a limitation of WeiDU, it will NOT be able to patch files larger than 16777211 bytes (~16 MB). It will NOT be able to convert a full area graphic into a TIS (tileset): this would require complex image quantization techniques better suited to dedicated external programs. At this time, the scope of the project will be limited to patching tilesets: e.g. modifying the WED file etc. will be left up to you. At this time, support for PVRZ-based tilesets will be limited. Again, not sure how useful all this will be in the end (largely due to the first bullet), but I'm enjoying the challenge.

What's next on the your agenda, then?

With some suggestions I was able to figure out the compression bit. Current version of the updated code can be found here. I apologize for straying a bit OT, Lundar.

Did you try COPY_LARGE? Probably not because he needs to edit the file. You know, the only restriction the said command has is that you can't do that. From the documentation:

Well I just blundered into why no one has bothered to do this before: WeiDU's filesize limitations with COPY. This makes the whole concept useless for any decent size area, such as the ones you'd usually bother adding open/closed door tiles to. WeiDU really does suck... I'm basically half way through anyway so I may continue creating the necessary functions as an academic exercise, but they probably won't be that useful in the long run .

Well, the tutorial is here ... there's ugly weidu code in various mods that add areas one could go and take a look at. And you do really nothing with a door... as it's just a graphical binary element on the map. You need an entrance(&exit) point that transfers you from one map to another. The DLTCEP tutorial is there for that as well. I'm aware of this old tutorials, but they can't patch in the door bitmaps. All other stuff like polygons, entry points etc. are pretty easy to add via weidu. You can modify vertexes, regions and other relevant stuff, but you can't patch in a stupid door to the area, because there can be no door without a bitmap If you already have a BMP of the tile you want to patch into the TIS, the code to do so is not that difficult. In fact much of the needed code has already been written, one would just need to write a wrapper function/macro around it. If this actually hasn't been done before (which surprises me), I'd probably be willing to take a crack at it.

I have studied your code and found the following: // Count of Cycles is not signed, so should use BYTE not SBYTE Code does not take into consideration that: 0th cycle may already have more than 1 frame (was already processed). 1st cycle may be blank (no frames), thus has no frames to add to 0th cycle. The “Large” frame may arbitrarily be Frame_0 or Frame_1. Same goes for the “Small” frame. This must be taken into consideration. The Frame Lookup Table may store the frames as {0,1} or as {1,0}, thus simply adding 1 to the frame count of the 0th cycle may produce unexpected results. My current working version is: DEFINE_PATCH_FUNCTION ~gw_convert_inventory_bam_to_ee~ BEGIN // Read bam. // --------- READ_ASCII 0x0 sg (4) // Signature READ_ASCII 0x0 sn (3) // Short signature // Decompressed if needed. // ----------------------- PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN READ_LONG 0x8 dl // Uncompressed data length DECOMPRESS_REPLACE_FILE 0xc (SOURCE_SIZE - 0xc) dl END ELSE BEGIN dl = SOURCE_SIZE // Uncompressed data length END // Add "small" frame as second frame in the first sequence. // -------------------------------------------------- PATCH_IF (~%sn%~ STRING_EQUAL_CASE ~BAM~ = 1) BEGIN READ_BYTE 0x0a cc // Count of cycles READ_SHORT 0x08 fc // Frame count READ_LONG 0x0c fn // Frame entry offset READ_LONG 0x14 lu // Offset (from start of file) to frame lookup table READ_SHORT (fn + (fc * 0xc)) c_fcc0 // Count of frame indices in 0th cycle PATCH_IF (cc = 2) AND (c_fcc0 = 1) BEGIN // only 2 cycles = inventory bam (ground and description have 1 or 4 frames). only 1 frame in 0th cycle = not already processed READ_SHORT (fn + (fc * 0xc) + 0x2) c_fic0 // Index into frame lookup table of first frame index in 0th cycle READ_SHORT (fn + (fc * 0xc) + 0x4) c_fcc1 // Count of frame indices in 1st cycle READ_SHORT (fn + (fc * 0xc) + 0x6) c_fic1 // Index into frame lookup table of first frame index in 1st cycle PATCH_IF (c_fcc1>=1) BEGIN // 1st cycle mush have at least 1 frame in order to add a frame to 0th cycle READ_BYTE (lu + c_fic0) FLT_0 // Get frame used by cycle 0 READ_BYTE (lu + c_fic1) FLT_1 // Get frame used by cycle 1 WRITE_SHORT (fn + (fc * 0xc)) 2 // Sets 0th cycle to have 2 frames WRITE_SHORT (fn + (fc * 0xc) + 0x2) 0 // Sets 0th cycle to start at FLT index 0 WRITE_BYTE (lu) FLT_0 // Sets 0th FLT entry to the frame used by cycle 0 WRITE_BYTE (lu + 1) FLT_1 // Sets 1st FLT entry to the frame used by cycle 1 END END END // Recompressed if needed. // ----------------------- PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN COMPRESS_REPLACE_FILE 0 dl 9 INSERT_BYTES 0x0 0xc WRITE_ASCII 0x0 ~BAMCV1 ~ WRITE_LONG 0x8 dl END END // of DEFINE_PATCH_FUNCTION There may still be edge-cases that aren't handled properly, but this modification adds some robustness to your code. However, this code will always copy a modified version of the file to the destination directory (whether or not the actual BAM V1 contents were changed) simply because WeiDU uncompressed and recompressed the BAMC file using a slightly different ZLIB implementation than whatever was used to compress the original. I don't like this in the context of BAM Batcher (nor in the context of processing arbitrary in-game BAMs to re-expose the small item icons), but don't know how to avoid it. Any ideas?

G3 and SHS were down for a few days recently. G3 is obviously back, but SHS is still down. Has anyone poked Liam?

@Gwendolyne Well this is downright cool. Can I implement this in BAM Batcher? You will be credited of course

I am no expert for bams honestly, just an observer here. Maybe due to those changes you mentioned sometimes they are not displayed or odd or oddset for mod made items. It probably depends on how the author once made them. This may oe may not be something in the above mentioned mods, I do not know them myself. Itt was just a reminder that of you try them in EE they may work or have minor issues but nothing that should hinder you from trying. If you (or anyone else for that matter) run across vanilla or mod-added BAMs that don't display correctly or don't match current EE standards, please bring them to my attention: I would like to investigate them further. Structural errors, incorrect dimensions or offsets, wrong orientation (e.g. weapon item icons oriented in the wrong direction), item icon shadows in the wrong direction: these types of thing are generally easy for me to fix. Anything requiring actual artistic talent or voodoo magic with Photoshop... not so much

What's the issue with the BAMs? If it's just the description images being 1 frame instead of 4, I can probably batch convert those fairly handily. If it's that the description BAMs won't match the darker SoD theme, that's harder. EE BAMs have gone through several iterations of various changes over the years. Is there a discrepancy between the old and newest item BAMs?

IIRC creatures whose animations have large circle size or large personal space (I don't remember which) are hard-coded not to chunk. If no chunking animation=no exploding death, it may be one theoretical workaround. Not knowing what you're trying to do with this, tho, I can't speak to relevance...

I don't have one I care to use. Any other options?

I got a Personal Message (PM) here at G3 within the past week, but I didn't notice it for 3 days. I did not get an email notification about the new PM despite Email notifications for "Notify me of replies to my personal conversations" being checked in my User CP. I double checked and my email address displayed in my User CP is the correct one. Searching through my email history, I haven't gotten an email from The Gibberlings Three since 2012. What's up with that, and is there anything I can do on my end to fix it? -Sam.

EET requires SoD.

*Sighs* After some further testing, how BAMs are handled and behave depends largely on the game engine and even more so on the specific context in which it is used. In fact there is so little consistency I am disinclined to invest any more time testing. A short summary: All tested engine variants appear to support RLE. PST and BG1/ToSC are the only game engines I have found that do not support BAMC files. PST and ToSC sometimes assign the TransColorIndex as currently described in the IESDP (i.e. can be located anywhere in the palette), and sometimes force it to be Index 0. By "sometimes" I mean depending on the context in which the BAM is used. Other games appear to force the TransColorIndex to be zero, but this is hard to confirm with absolute certainty without access to the source code. All games have BAMs with frame dimensions greater than 256, but IESDP currently hints (or outright states) that the maximum allowed frame dimensions for most games is 256*256. No game engine I tested appears to have a true "hard limit" when it comes to BAM frame dimensions, but certain usage contexts do have "local" restrictions. For example, inventory item icons in vanilla games traditionally have "local" size limitation of 64x64 pixels for the large frame and 32x32 for the small frame. However, I got a 300x300 pixel single frame BAM to display in ToSC without any apparent problem. Larger sized (e.g. 500x500 px) frames also displayed, but cause a memory buffer overflow type of error on ToSC. In ToB on the other hand, I got a 1024x1024 px frame to display with no apparent issues. I tried a 2048x2048 px frame in ToB and it displayed fine but slowed the game down to an unplayable level. Supposedly the EE engines have lifted the "local" size restrictions (such as for spell animations) even further. The end result of all this is that there doesn't appear to be any way to automatically detect if a random BAM has exceeded any sort of semi-universal size limitations, or for that matter even which palette index is actually the TransColorIndex .

It looks like palette index 0 is always treated as transparent color, regardless of how this palette entry has been defined (at least in the EEs). Older IE versions don't work the same way. There are various rendering codes even in the same engine (depending on hardware or software rendering). Though i don't know where this particular info came from, i can very well accept that some engine versions treat the transparent green value as transparent. You're right. ToSC behaves (for me) the way currently described in IESDP: 1st occurrence of RGB(0,255,0) is the transparency index (regardless of where it is located in the palette). Back to the topic of Alpha values, current behavior means that, e.g. RGBA(100,100,100,255) would render exactly the same as RGBA(100,100,100,0) thus any palette entry with AA=255 can be set to AA=0 with no change to how the animation looks or behaves in-game, yes?

It looks like palette index 0 is always treated as transparent color, regardless of how this palette entry has been defined (at least in the EEs). This seems to be the case in ToB as well. I don't have ToSC installed at the moment to test it there, but presumably it would be the same. It is astonishing this has gone so long without being noticed (or noted). Any other surprises, quirks, or documentation errors in the BAM V1 format I should know about? Edit: Also, is BG1/ToSC the only game that does not support BAMC files?

I've been re-investigating how the alpha bit of the palette entries work recently, and I'm hoping someone else can either confirm or deny my findings. To me, it appears that an Alpha value of 255 is fully visible (opaque?) while descending values increase the transparency. An Alpha value of 1 appears to be fully (or nearly fully - see below) transparent. However, and Alpha value of 0 seems to be fully visible (opaque) even if other palette entries have non-zero Alpha values. I would have expected an Alpha value of 0 to be fully transparent if any other palette entry had a non-zero Alpha value. As that does not appear to be the case, I am left with a question: 1. Is an alpha value of 1 completely transparent, or is the only way to make a pixel completely transparent to set it to the TransColor:

I searched for a bit and that's the only bug related to Unique Containers in Tweaks Anthology I could find. Without a .debug file, line number/file for the error, etc. I can't even try to come up with a workaround/fix for the issue (assuming it hasn't already been fixed by the 'unofficial' Beta 5.

Thanks - I can live without all of those, though I did like the Unique Containers tweak... Could you please point me to the bug report concerning Unique Containers?