[Release] OpenUAStudio - All-in-One Urban Assault Asset Editor and Extraction Tool

This is great to see. At one point, opening these files was something that could only be dreamt of.

After playing around with it a bit, I do have a question. I'm interested in adding new skies into the game. Is there a way to replace the sky images in the base files and save a new file (say I wanted to edit 1998_01.bas and swap the image out with some different .png's)? I didn't see an obvious way to do that but let me know if I missed something. I'm less familiar with this part of the game.

I did see an example on the discord where someone made a 3D .obj file with a new sky and added it in UA Open, but trying to make my own version led me down a rabbit hole about how to edit those files.

On the original topic:

I will pin this thread later once I have time to test the new tool briefly. Thanks for the contribution.

To sectlord:

This is technically possible, but it can be tricky to perform and there are some limitations. It may also not yield the desired outcomes in terms of geometry and visual representations since each sky dome file has different skeleton structures for applying and rendering the sky texture files.

It also depends on whether the original UA or OpenUA are used. OpenUA supports easier methods of implementing this, including the usage of external, more industrial-standard formats (I should be able to provide some examples when I have free time later). But these are not compatible with the original UA.

In the case of original UA, it is also necessary to consider the colour palette compatibility since the software rendering mode requires all colours used in the image to be present within its 8-bit 'STANDARD.PAL' palette index. Otherwise the colours that are not part of this 8-bit palette index will come out distorted.

On the contrary, this restriction is not present when the hardware rendering mode is used. But in order to ensure that the graphics assets are fully compatible with both rendering modes in the original engine, the benchmark should be set on the software rendering mode compatibility in mind.

Regarding the method of swapping the images:

The sky texture data stored in *.BAS files in OBJECTS directory are VBMP data. VBMP files are special bitmap files that are used to store textures. They are usually stored in packages and editing them requires special procedures since the format is proprietary.

VBMP files are bitmap files with a custom header and a predefined set of 256 colours. Note that they often have *.ILB or *.ILBM extension but should not be confused with ILBM files.

The colour palette is loaded from a separate palette file. The bitmap data section follows standard Windows bitmap format. The size of the bitmap is 256×256 pixels in all standard UA files.

The most reliable way to extract or modify a VBMP file is to open the *.BAS package file in a hex editor and search for VBMP chunk.

If necessary, I can describe the method on how to achieve this using a hex editor here. But it can be quite complex and there are many factors to consider, such as preparing the correct Bitmap replacement image file with the correct colour palette index. Although I haven't tested yet, perhaps the tool can already support this feature naturally.

Also if this is considered off-topic, then perhaps we could create a new thread dedicated for this topic.

Okay thanks for your response. Maybe it would be best for me to explore implementing skies in OpenUA, since I think some of the skies will look bad in the standard color palette anyway.

If you could give me some examples of the types of objects OpenUA supports, that would help me. Also is there any documentation in OpenUA on this topic? I may have missed it, and I wasn't aware it even had this capability until recently.

The thread has been pinned now.

Regarding the last reply about skies:

Once again, I apologise for the delayed response. I was quite busy with my real-life projects recently, but now I finally have some free time to return to this topic.

The documentation of this feature in OpenUA is not available as far as I'm aware. But it is also very straightforward to apply. It should be (mandatorily) emphasised that this method only works for OpenUA and is not compatible with the original UA engine.

The newly supported industrial-standard formats are Wavefront *.OBJ format and its associated *.MTL format, as well as source image file formats (such as *.JPG or *.PNG formats, etc.) for texture data. The implementation procedure for these formats are identical to the standard file designations. The OBJ files define the geometric skeleton mesh structures of the sky domes, and the MTL files define the properties of the texture materials.

All relevant files should be placed inside a same directory (the standard directory is DATA\OBJECTS) but naturally it is also possible to place them in a new separate folder inside the DATA folder as long as they are loaded correctly inside the LDF files. Once all files are placed in the directory, simply assign the corresponding OBJ file instead the standard BAS format sky file inside the LDF files (e.g. sky = objects/untitled.obj). This will load the object file with all defined properties accordingly.

I have briefly checked again for potential exceptions and irregularities but couldn't find any so far. Therefore, as long as the asset files are in standard formats it should be able to parse normally.

Here is a quick example image of a new sky I took from my study laptop that was implemented inside a temporary cuboid-shaped sky object file.

For the record, as long as the software rendering mode is avoided and only the hardware rendering mode is used, the original UA engine can also support all colours naturally in its graphics assets since they are not bound to any colour palette index.

But of course, it also generally requires various special procedures to handle the task due to the proprietary formats involved (if you are still interested in knowing this method about the original UA, please let me know; we will have to split the topic).