[Release] BASet - Urban Assault SET.BAS Extraction and Texture Tool

  • Hi everyone,

    I would like to release BASet, a small modding tool for Microsoft Urban Assault / OpenUA:

    BASet is designed to inspect and extract data from the original game SET.BAS archives.
    It does not include or redistribute any original Urban Assault assets. You need to use it locally with files from your own copy of the game.

    Current features:

    • Extracts embedded resources from SET.BAS
    • Exports raw embedded assets into organized folders
    • Supports texture extraction from embedded VBMP data
    • Converts extracted VBMP textures to PNG
    • Converts extracted VBMP textures to ILBM
    • Converts edited PNG textures back to ILBM
    • Exports BASE/KIDS metadata and scenegraph information
    • Includes a simple Windows GUI
    • Creates logs and manifest files for easier inspection

    The tool currently recognizes and extracts resources such as:

    • VBMP texture data
    • SKLT skeleton/model data
    • ANM / VANM animation-related data
    • BASE/KIDS structural metadata

    This is mainly useful for modding, research, asset inspection, and future OpenUA tooling.

    Important note about repacking:

    BASet is not intended to rebuild or repack SET.BAS archives.

    The original archive format is old, proprietary, mostly obsolete, and not something I want to encourage people to rewrite or modify directly. Instead, the better long-term direction is loose/unpacked asset loading.

    In my experimental OpenUA build, the engine can load uncompressed loose data directly when it is found. This means extracted and edited files can be placed outside the original archive, and the engine can use them without modifying or rebuilding the original SET.BAS.

    License:

    BASet is released under the GNU GPL-3.0 license.

    [GitHub Release link]

    This is still an experimental modding tool, but it is already useful for inspecting SET data and working with textures/models in a safer and cleaner way than editing the original archive directly.

    Feedback, tests, and bug reports are welcome.

    Edited 2 times, last by WINDSGN (July 8, 2026 at 10:59 PM).

  • The fragmented loading mechanism of the individual decompressed SET.BAS package data and asset files is a feature that is already natively supported in the original game engine as well as the main branch of OpenUA repository. Although there are some files that have to be manually created (such as slurps.lst, colside.skl, or colcross.skl) and placed inside the corresponding locations accordingly in order for this method to work properly.

    Therefore, in theory this new tool should be compatible with the original UA game and all iterations of the OpenUA branches by default. I may have to test this new tool in the near future, and while I agree that the repack function is not strictly necessary, it would be also preferable to have it than not since writing a parser for this task wouldn't be too complicated or time-consuming to achieve.

    Another good potential failsafe feature would be rendering the official/vanilla files 'read-only' by default when inspecting with this tool, which can be disabled as necessary. This will prevent accidental modification or corruption of the base game files from inexperienced users. However, it is only a minor suggestion similar to the abovementioned function.

  • The fragmented loading mechanism of the individual decompressed SET.BAS package data and asset files is a feature that is already natively supported in the original game engine as well as the main branch of OpenUA repository. Although there are some files that have to be manually created (such as slurps.lst, colside.skl, or colcross.skl) and placed inside the corresponding locations accordingly in order for this method to work properly.

    Therefore, in theory this new tool should be compatible with the original UA game and all iterations of the OpenUA branches by default. I may have to test this new tool in the near future, and while I agree that the repack function is not strictly necessary, it would be also preferable to have it than not since writing a parser for this task wouldn't be too complicated or time-consuming to achieve.

    Another good potential failsafe feature would be rendering the official/vanilla files 'read-only' by default when inspecting with this tool, which can be disabled as necessary. This will prevent accidental modification or corruption of the base game files from inexperienced users. However, it is only a minor suggestion similar to the abovementioned function.

    Thanks for the clarification.

    Right that OpenUA already has some support for loading loose/extracted files through its virtual filesystem. I probably should have worded my previous message more carefully: what I meant is more specific in my experimental build I added a SET loose override layer for Data/Set_/Loose/, especially for resources that are normally embedded inside SET.BAS, such as ILBM textures, SKLT resources and bitmap animations. The existing filesystem/mod mechanism was already there. My change is mainly about allowing extracted SET resources, including embedded ones, to override the original archive contents without rebuilding SET.BAS, while keeping vanilla fallback behavior.
    In this override path, 4-letter extensions such as .ILBM, .SKLT and .BASE can be read directly as they are, instead of being forced - truncated to the older 3-letter forms like .ILB, .SKL or .BAS. The fallback to the legacy 3-letter names is still kept for compatibility. Another nice improvement is that the experimental build can now also load PNG replacements directly, so for some texture overrides it is no longer necessary to convert everything back to the original ILBM format and i am still learning the internal resource system

    Edited once, last by WINDSGN (June 21, 2026 at 1:59 AM).

  • I see, thanks for clarifying as well. As long as the tool can fully support backward compatibility for the original game routines and the new extra methods are not directly changing or altering the original mechanisms, I think it is a perfectly valid addition.

    When I could finally start some experiments once again, I might be able to verify and cross-check if there are any conflicting issues present when the original game engine routines are called and applied. The truncated format label support sounds like a nice little feature to me.

    There are also some alternative format support (more industrial-standard rather than proprietary) methods implemented inside OpenUA already, but they are not very well-documented. I don't remember much about it at the moment, but it should be verifiable inside the main branch of the code repository.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!