Archived Posts

NOTE: This is a temporary archive thread for the obsolete posts from the deleted topics. For the latest discussions pertaining to the original topics, see OpenUAStudio thread in the pinned section.

This is an interesting new project. It is always nice to see some works pertaining to the proprietary UA file formats being resumed and continued once again since the old legacy projects from the old website that have been put on hiatus for some time now.

Although I would like to mention that the 3D vector geometry nature of the HUD wireframe elements were already known quite well. I personally find it convenient to visualise any skeleton format data as an abstract, full-fidelity vector space (with all standard basis components and transformations).

I may have to test this new iteration of an editor in the coming days. From a cursory observation of the tool however, the vertices data section for SEN2 chunks (commonly located between POO2 and POL2 arrays for some wireframe/skeleton files) might not be strictly necessary considering that (according to my old experimental notes) the primary function of SEN2 arrays is to calculate the dimensional volume check for rendering objects in the 3D world based on abstract cuboid models, which means their vertex counts (8) and subsequent byte lengths (96 bytes) should be standardised and therefore consistent across all applicable models. But nevertheless, it might still be potentially useful for non-standard, custom data assets.

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.

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.