Add a new door to the area (with tiles!)

[Ardanis]

Instead of adding your door image to the tileset, make it a BAM file and place in the area as ambient animation. Positioning can be calculated based on the tile size and tile offset.

You can set time of day when animation is active, so one for day version and another for night will work fine. Dusk and dawn are problematic, however, because of dynamic lighting adjustment. I've seen it almost working for dusk with day animation's light source flagged off, but not for dawn.

Edited July 1, 2017 by Ardanis

[Constantine]

Instead of adding your door image to the tileset, make it a BAM file and place in the area as ambient animation. Positioning can be calculated based on the tile size and tile offset.

You can set time of day when animation is active, so one for day version and another for night will work fine. Dusk and dawn are problematic, however, because of dynamic lighting adjustment. I've seen it almost working for dusk with day animation's light source flagged off, but not for dawn.

Thanks, maybe I'll try it out. Please remind me what're the maximum BAM dimentions? I vaguely remember that it can't be of any size you want.

[Gwendolyne]

In vanilla games, it is 256 x256, but you can use split bams. I display a 540 x 320 animation bam split into 6 cycles checking the "Draw all cycles" box in the Animations tab.

[Constantine]

In vanilla games, it is 256 x256, but you can use split bams. I display a 540 x 320 animation bam split into 6 cycles checking the "Draw all cycles" box in the Animations tab.

Thanks alot.

[argent77]

You haven't mentioned whether the mod is for the classic games or the Enhanced Editions. In the latter case TIS files are much smaller (several kb instead of MB) and can easily be modified with WeiDU. File format is described in more detail in this post. It's just a matter of adding one or more tile data blocks and providing a small PVRZ file with the new graphics.

Theoretically it would also work for the classic games if you don't mind converting the TIS to the new EE format with tile2ee, making your changes and converting it back (with the same tool).

[Jarno Mikkola]

Theoretically it would also work for the classic games if you don't mind converting the TIS to the new EE format with tile2ee, making your changes and converting it back (with the same tool).

Yeah, that's not going to happen on the fly. Aka inside a weidu patch mod that adds/patches the areas during install.

[Constantine]

You haven't mentioned whether the mod is for the classic games or the Enhanced Editions. In the latter case TIS files are much smaller (several kb instead of MB) and can easily be modified with WeiDU. File format is described in more detail in this post. It's just a matter of adding one or more tile data blocks and providing a small PVRZ file with the new graphics.

 

Theoretically it would also work for the classic games if you don't mind converting the TIS to the new EE format with tile2ee, making your changes and converting it back (with the same tool).

It's for EE. Well, that's a relief. Now if only Sam will provided us with the right code

[Gwendolyne]

It is not that easy because you must modify both the tis and the wed files.

[Sam.]

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.

[Gwendolyne]

It would be of great use in case of adding new doors to an existing map: for example, modifying the two existing tiles and adding two alternate tiles at the end of the tis file.

[Sam.]

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?

Edited July 12, 2017 by Sam.

[Constantine]

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?

Oh dear. I honestly have no idea which way is the best! Let's just keep in mind that you probably won't be needing to insert tons of tiles at once. I was thinking of shipping several BAM (or maybe BMP) files with the mod and inserting them into the certain TIS file during the installation (along with the other necessary modifications to the are files of course). Something like that. Anyways, do you already have a release date yet?

[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.

[lynx]

"Release early and release often."

[Sam.]

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.