Sam.

NP. That's what I expected you to really be after based on the topic title, but your line of questioning was erratic enough I thought I'd try to cover a broad view of the basics just in case .

From what I can discern, what you're asking about is a bit of a mixed bag. An executable's (EXE, DLL, etc) "resources" including FileVersion, ProductName, etc. can be edited with Resource Hacker. See the "Version Info" field, although in recent versions only if it has not been compressed with an EXE compressor like UPX or mpress. Many of these fields show up in the details provided by Explorer. Many other fields (such as name, timestamps, etc.) are NTFS metadata or extended attributes. FileAlyzer can view these, but can't edit them. Various programs can edit some of these programmatically, but I'm not familiar with a single program that can edit ALL NTFS metadata/attributes. As an example, AutoHotkey can be used to edit modification time, creation time, and last access time. To further complicate things, many file formats, especially multi-media files like WAV, MP3, MPEG, etc. can have metadata embedded in to the file format which Explorer can directly display (either in the main window when set to Details or under a file's Properties as you have shown). These can include Artist, Title, Album, etc. And to make matters even harder, Explorer can display attributes read directly from some file format's internal structure, such as an image's dimension. MediaInfo is a fantastic tool for displaying (but not editing) this type of information. It would help to know exactly what you are after.

@Gordian I've been looking through your list of mods for inspiration on my next EET install. What is MIH_EQ?

Back in 2009 with the bigg's instructions, I disassembled the ToB EXE and made a list of all the (then) INI settings which the game read. How exhaustive is this list? Does it cover everything, just what is not covered in the default game GUI, or some selective subset of the above?

FWIW, here is the even more minimalist MVE file without the probably unnecessary shutdown chunk: BLANKER.MVE I still think you could pre-make a BIFF of these, and just overwrite the original BIFF with the custom one and not alter the CHITIN.KEY file (as per Miloch's strategy).

At a minimum you'd still need EE compatibility for Tweaks Anthology. Recursively deleting the appropriate WBM files from the game directory is probably the simplest way to go.

Compiling a BIFF inherently modifies CHITIN.KEY, doesn't it? ?

After thinking it over, you may not even need the shutdown chunk as we haven't initialized any audio or video. I'll make one later just in case. FWIW, CamDawg has already added this to the to-do list for Tweaks Anthology.

IIRC Disable Startup Movies just overwrote the MVEs with zero byte files, but the download link is bad so I can't check. However, by looking at the MVE file format description and actual MVE files, I believe the attached is the minimal "valid" MVE file. Haven't tested it and NI doesn't like it, but the latter isn't entirely unexpected as there is no data to decode, just header, magic number, shutdown chunk, and end chunk. BLANK.MVE

"usable" may be a bit of a stretch. For me, the new forum software seems to be using up a huge amount of screen space to display comparatively little content.

PS BAM can do all this, or I could add the necessary functionality. With hundreds or thousands of frames this large it wouldn't be particularly fast, but it would be automated so you could just let it run in the background. A quick automated pre-pass with ImageMagick to clear up the fuzziness at the edges of the shadow and ensure the shadow colors are set properly, and you wouldn't have to do anything manually. I'd be willing to do it, or help, or provide a detailed guide.

This is the programmer within you that says this. "The count" starts for me from the "first" color, not zero'th one, as we are not dealing with ones and zeros only, aka binary, but of decimal one. Yes, even though it might be flagged as zero in the binary data(I have no way to verify this). Which is why we use the ordinal form of the word "one" rather than the word itself. And if it's not obvious, there's no such a thing as "zeroth" in English, as it doesn't make sense. And yes, wikipedia is wrong. I say the count starts at 0 because the internal structure of the binary file format starts counting from 0. This is an objective fact. Please keep your verbal vomiting to yourself.

The count starts at 0. You will receive the best results by assigning a unique shadow color to your shadow catchter material, for example a strong red (RGB 255.0.0). BAMWorkshop 2 used a pink color to determine where shadows are present. That way the shadows are assigned to palette entry #1 (the 2nd palette colour) and there are no "false" shadows in the darker portions of the creature. This makes a lot of sense, however, depending on which games you intend to use the animations in, there are definitive reasons to ensure the shadow color is in palette entry 1 and that it is set back to pure black. For greatest compatibility with all engine and graphics settings variants, no other entry in the palette should be pure black.

It would seem I've gotten old.

There are several version of stutter debugging tools out there that, while not quite what you're looking for, are in that direction. They won't give all the information you're looking for, but will tell you which blocks are firing. Combine that with either TobEx or the EE's CLUAConsole LogMessages() and LogSet() functions, and you can save the info to file. Stutter related tools How to gather clues when debugging stuttering

There are guns with a rate of fire of over 1 million rounds per minute. Just 10 attacks per round, please...

Yes. Don't do it unless you intend to start a new game, and even then you're probably better off waiting a bit longer for V10 to be released.

Toggling the flag would be easy. Not breaking NPCs, special encounters, etc. in doing so would be much more effort.

If it's calculating true analytic (not numerical) solutions to the full no-assumptions Navier–Stokes equations, I'm very interested in that. Moreover, if DavidW has solved the Navier–Stokes existence and smoothness problem, that would be pretty cool.

Thank you both, I have gotten it working. Another question: is there a COPY_LARGE version of COPY_EXISTING? Or more to the point, is there a way to get the filesize of a biffed file too large to patch?

When I run ACTION_DEFINE_ARRAY foo BEGIN 1 2 3 END DEFINE_ACTION_FUNCTION xyz STR_VAR foo = "" BEGIN ACTION_PHP_EACH foo AS k => v BEGIN PRINT ~%v%~ // should print 1, 2 and 3 END END LAF xyz STR_VAR foo END with the MODDER flag on, I get this warning but if I run ACTION_DEFINE_ARRAY bar BEGIN 1 2 3 END DEFINE_ACTION_FUNCTION xyz STR_VAR foo = "" BEGIN ACTION_PHP_EACH foo AS k => v BEGIN PRINT ~%v%~ // should print 1, 2 and 3 END END LAF xyz STR_VAR foo = bar END there are no warnings but 1 2 3 are not printed. What am I missing?

Oh you're awesome! Thank you. Let's start off simple, and then we can add layers of automation/safety as we get more comfortable with the process. For a test, I decided to move a door from AR0200 to BD0010 in BGEE w/ SoD. The first step was to use NI's Area Viewer to figure out which tiles I wanted to move. I determined I wanted to move tiles 2985, 2986, 3054, and 3055 from AR0200.tis to tiles 140, 141, 160, and 161 in BD0010.tis. To double check my maths, I used this to blank out those tiles to make sure I got the right ones: // Test that we've picked the correct tiles by blanking them out and then check with NI's area viewer or in game COPY_EXISTING ~AR0200.tis~ ~override~ LPF ps_tileset_add_tiles INT_VAR Pos = 2985 MaxCount = 2 PVRz_Page = "-1" PVRz_X = 0 PVRz_Y = 0 STR_VAR Method = "Replace" RET Count END // Blank out a tile in a PVRz-based tileset using a manually specified tile LPF ps_tileset_add_tiles INT_VAR Pos = 3054 MaxCount = 2 PVRz_Page = "-1" PVRz_X = 0 PVRz_Y = 0 STR_VAR Method = "Replace" RET Count END // Blank out a tile in a PVRz-based tileset using a manually specified tile BUT_ONLY COPY_EXISTING ~BD0010.tis~ ~override~ LPF ps_tileset_add_tiles INT_VAR Pos = 140 MaxCount = 2 PVRz_Page = "-1" PVRz_X = 0 PVRz_Y = 0 STR_VAR Method = "Replace" RET Count END // Blank out a tile in a PVRz-based tileset using a manually specified tile LPF ps_tileset_add_tiles INT_VAR Pos = 160 MaxCount = 2 PVRz_Page = "-1" PVRz_X = 0 PVRz_Y = 0 STR_VAR Method = "Replace" RET Count END // Blank out a tile in a PVRz-based tileset using a manually specified tile BUT_ONLY Looked at them in NI's are viewer, and they were the right ones so I uninstalled this code to reset them. The next step was to determine which PVRz file the 4 tiles from AR0200.tis were using, and what the X and Y offsets were. COPY_EXISTING ~AR0200.tis~ ~override~ LPF ps_tileset_info INT_VAR Verbose = 2 Log = 1 END // Log verbose output of PVRz-based tileset to file BUT_ONLY Looked at the log and extracted: Last bit of info we need is an unused PVRz index for BD0010.tis. Looking for B0010**.pvrz files in NI, we see that 00-02 are used, so 03 is free. Now let's install the new door: COPY_EXISTING ~A020008.pvrz~ ~override\B001003.pvrz~ COPY_EXISTING ~BD0010.tis~ ~override~ LPF ps_tileset_add_tiles INT_VAR Pos = 140 MaxCount = 1 PVRz_Page = 3 PVRz_X = 128 PVRz_Y = 704 STR_VAR Method = "Replace" RET Count END // Overwrite tile LPF ps_tileset_add_tiles INT_VAR Pos = 141 MaxCount = 1 PVRz_Page = 3 PVRz_X = 192 PVRz_Y = 704 STR_VAR Method = "Replace" RET Count END // Overwrite tile LPF ps_tileset_add_tiles INT_VAR Pos = 160 MaxCount = 1 PVRz_Page = 3 PVRz_X = 128 PVRz_Y = 768 STR_VAR Method = "Replace" RET Count END // Overwrite tile LPF ps_tileset_add_tiles INT_VAR Pos = 161 MaxCount = 1 PVRz_Page = 3 PVRz_X = 192 PVRz_Y = 768 STR_VAR Method = "Replace" RET Count END // Overwrite tile BUT_ONLY And it works. Again, much of this could/should be automated further, but now we have an outline of what to do.

I have realized I had forgotten about a vitally important fact which led me to give you bad information which in turn has likely caused you no small amount of frustration and wasted time. I sincerely apologize. This is untrue. This was terrible advice. Here's why: from the IESDP: If you're wanting to replace tiles in BD0010.TIS, then your exported tiles should be BL0010.TIS and the PVRz file it references should be B0010xx.PVRZ. Here, L is part of your modder prefix and xx is the original index of the PVRz. You should then be able to install the files with Argent77's function and then replace the tiles with PS_Tileset. However, I'm thinking this whole process of exporting tiles is entirely unnecessary. I'll try to come up with a working example of how I'd do it.

I said that it would be a bit trickier, not that it wouldn't be possible. The first thing you'll need to do is figure out which PVRz file(s) the tiles you are interested in are pointing to. You should be able to use the ps_tileset_info function to look it up. You should then fall into 1 of 2 categories: 1. The PVRz file names referenced do NOT already exist in the game you want to add them to. If this is the case, just dump the PVRz files into the override folder and proceed as I previously suggested. 2. The PVRz file names referenced DO already exist in the game. In this case, you'll need to remap them. Export the desired tiles with the ps_tileset_export_tiles function, but specify "tis" as the OutType. You'll also need to extract the referenced PVRz files from the game, using NearInfinity or WeiDU. Rename your new mini-tileset to any valid name not already in the target game, preferably with your modder prefix if you have one. Next, use this method to install the tileset into the target game and update the PVRz references. Now proceed as I previously suggested, but using this newly updated tileset. Afterward you can delete the TIS file, but make sure to leave the PVRz files in the game.

There are two primary types of tilesets: Palette-based tilesets and PVRz-based tilesets. A tile from a Palette-based tilesets contains a palette of 256 colors and a block of pixel data pointing into the palette. A tile from a PVRz-based tileset is just a pointer into a PVRz file, which is a Zlib-compressed PowerVR texture using one of several compression algorithms. There is no mechanic in WeiDU to access the contents of a PVRz file, largely due to the filesize limitations of WeiDU, but even if that were not a factor, the complexity of the task would be a huge barrier. Because of this, PS_Tileset CANNOT mix tiles between palette-based and PVRz-based tilesets. That's why approach #1 wouldn't work even if the BMP was the correct format; approach #2 doesn't work, not sure where you were going with #3, but if you were converting it to Palette-based tileset that won't work; why #4 gave you a RAW file instead of a BMP, but with this one you're on the right track. IF AND ONLY IF both BG0200.TIS and BD0010.TIS are both PVRz-based tilesets AND both are already in the same game (along with their associated PVRz files), then you should be able to export the tiles from BG0200 (ps_tileset_export_tiles) and use them to overwrite tiles in BD0010 using ps_tileset_add_tile with STR_VAR Method = "Replace". Again, these "tiles" are just pointers into a PVRz file. If both tilesets (and their PVRz files) aren't already in the same game, things are a bit trickier.