Posts by Schloss Charlottenburg

Indeed, apparently this algorithm is determined by the model keyword taking the robo string as the argument value, and therefore applies to all host stations (with their own unique Robo Extension arrays).

The detailed mechanism appears to first calculate and store the remainder values from the modulo operation from the vehicle ID numbers, and then assign the values as labels into the allocated memory of the Robo extension arrays of each Robo definition.

At this point, I'm confident that this is an old part of the legacy protocol when the robo_data_slot was directly employed to define these behaviours, and so originally there was a support for maximum 16 functional host stations parsed from a single .SCR file; at least in theory.

Also as you mentioned, the Robo Viewangle parameter in an .LDF file computes normalised eigenvectors for Y-axis rotation (yaw angle) in 3D rotation matrix transformations of the Robo Viewer. It is defined in degrees instead radians which is widely employed in the majority of the UA engine scripts (viewangle * pi / 180).

Quick Update: I cannot seem to replicate the issue with Robo viewer camera when robo_data_slot value is set to 0. I have tried the following options:

• Change all robo_data_slot values of all standard host stations in the default Robo.SCR file to 0.
• Change all robo_data_slot values of all standard host stations inside a level definition file to 0 via modify_vehicle keyword.
• Added new custom host stations in the default Robo.SCR file and changed all their robo_data_slot values to 0.
• Added new custom host stations inside a level definition file with their robo_data_slot values set at 0 via new_vehicle keyword.
• Created new custom Robo data files, copied all standard host stations from the Robo.SCR file, and set all rbo_data_slot values to 0.
• Created new custom Robo data files, added new custom host station definitions there, and set all robo_data_slot values to 0.

In all cases above, the Robo viewer cameras worked normally as per definitions. Perhaps there are something else I might be missing with my methods?

---

EDIT: After additional experiments, I think I may have found some answers. But it is still not perfectly clear. I will explain them below.

Apparently, the dividend variable for the modulo operation referenced in my earlier post was a pointer variable storing the vehicle ID numbers, which means that the game parses the vehicle IDs of Robo type entities into account, take the modulus of 16, and store the resultant remainder values for certain mathematical/algorithmic operations.

In my experiment, changing robo_data_slot values did not seem to yield any difference in the test results. However, I noticed that when there are multiple host stations with vehicle ID numbers that result in congruent modulo 16 from the above modulo operation (e.g. 168 % 16 and 184 % 16), it appears to 'overwrite' (potential buffer overflow?) the Robo camera viewer data of the other host stations that also belong to congruent modulo 16.

Although such instances appear to overwrite the camera data of the host stations, the actual host station vehicle IDs themselves in levels are the same vehicle numbers that are assigned inside the level definition files, and therefore remain unchanged. Also, the overwritten camera data seem to always originate from the vehicle IDs with higher numbers (e.g. Robo vehicle 200 Viewer data will overwrite the Robo vehicle 184 or 168 Viewer data).

The standard host station vehicle number IDs in the original Robo data files were assigned in number orders that clearly avoid this condition from triggering which is most likely intended. I cannot confirm whether this behaviour is fully intentional and left out on purpose or simply a potential oversight legacy from the deprecated robo_data_slot routine yet, but it is still quite interesting nonetheless.

Here is a list of the original single-player mode Robo vehicle number IDs and their operations so far:

Quote

Resistance Host Station (56 % 16) = 8

Turantul II (57 % 16) = 9

Myko Station (58 % 16) = 10

Turantul I (59 % 16) = 11

Taerkasten Flying Fortress (60 % 16) = 12

Sulgogar Queen (61 % 16) = 13

Black Sect Station (62 % 16) = 14

Target Drone Station (132 % 16) = 4

Turantul I (Metropolis Dawn Ghorkov) (176 % 16) = 0

Turantul II (Metropolis Dawn Ghorkov) (177 % 16) = 1

Taerkasten Flying Fortress (Metropolis Dawn Taerkasten) (178 % 16) = 2

Display More

More information pending.

Interesting. After reading your post I have investigated a little further on this topic and so far I have noticed the following.

About the 16 integer limit I mentioned earlier, it appears to be used in some kind of a modulo operation (i.e. 'variable' % 16). Although nothing is certain yet, for an array starting from 0 it could potentially allow some values up to 15. But what values?

There is also a presence of another pointer reference which seems to take a variable that employs the above math and applies to what appears to be a set of principal diagonal of an identity matrix used for calculating 3D rotation matrix (i.e. m11/m22/m33).

If we take some liberty and assume these matrix elements are used for calculating the orientations of Robo viewer/camera, then it may have some indirect effects on determining these data slot extensions. I should test this inside the game scripts directly.

Thanks, although I have not investigated it in detail yet, I presume this could be an universal limit constant that takes all available parsed scripts from the default data scripts directory into account, which means it could potentially override the above method I suggested earlier about having separate Robo and Startup files.

It is also worth mentioning that while OpenUA does have an increased maximum Robo limit in the level definition files (more than 8; but it did not pass the integrity and performance test yet, so this 'feature' should be considered experimental), I have not checked if it also supports an increased maximum limit for unique Robo types in the script files.

I was inspecting binaries today and noticed something. If I'm not mistaken, the maximum number of Robo definitions in scripts should be 16. This means the two extra Robo files containing the multiplayer variants of host stations (inetrobo.scr and net_robo.scr) will most likely count towards the total limit.

Out of curiosity, have you tried removing these two files (assuming that they are present and not required for your mod) to check if it will allow adding more Robos into the original game engine without crashing?

Here is an old interview with Stephan Bludau from 1998, one of the original German TerraTools developers of Microsoft Urban Assault.

Happy 28th Anniversary/Birthday, Urban Assault!

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

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.

The German localisation files are hosted on our servers and can be accessed via direct links.

The official UA German Audio and Text files are available at the following link:

https://metropolisdawn.de/downloads/Urban_Assault_German_Language_Pack.zip

The official UA German Video files are available at the following link:

https://metropolisdawn.de/downloads/Urban_Assault_German_Movies.zip

Check the README.txt files inside each package first. If you have further questions, please let me know.

I'm sorry about the delayed reply. I'm currently on vacation and haven't been checking the internet for the time being. I will try to answer the questions in order.

Quote from sectlord

- How many stations does the game support?

The maximum number of supported host stations in a level (via *.LDF file) is 8. Although I don't remember if there was also the maximum number of unique Robo type vehicles that can be parsed in the game (via *.SCR file) at runtime. I'm curious if this is what you are referring to.

Regarding the level definition file parsing, this is a hardcoded limit that is present in the original game engine by design, considering the average computation power of the hardware at the time of game's release and since fully autonomous AI host stations are rather calculation-intensive.

Since this is a hardcoded variable, the only way to circumvent this limit is through disassembly and reverse engineering of the game executable file. If necessary, I can personally look into this topic later.

Quote from sectlord

- Does each station need a unique robo_data_slot parameter, and if not, what does it do?

To my knowledge, robo_data_slot parameter is an obsolete keyword that does not have any special function in the final version of the game.

I presume it was initially designed to control the allocation of the total memory sizes for the Robo extension arrays, but apparently this feature is deprecated and therefore has no effect in the data scripts. So I believe it is safe to ignore this parameter for now.

(If anyone has any extra information on this topic, feel free to share them here.)

Quote from sectlord

- Is there a better way to add more stations than the game allows than adding them in the ldf file for that level only? There's a certain group that will show up in multiple levels, but I also have a couple of factions that will have a different variant between levels.

As mentioned earlier, the standard 8 maximum Robo limit inside the level definition file cannot be overridden normally. However, in the case of parsing unique Robo variant types (again, assuming there is a limit for this), I believe it may be possible to load separate Robo data from different script files based on the pre-processor directives used in the individual level files.

This can be accomplished by saving extra Robo data definitions into a completely new standalone script file (e.g. Robo2.scr), and then create a new dedicated Startup file (e.g. Startup3.scr) that loads this new data script file accordingly inside the level definition files. The same method is generally applicable for other normal vehicles and weapons as well.

It sounds like there is a problem with your installation or the game files you are using. Make sure you are using the clean and verified game files sourced from our Filebase and follow the installation instructions carefully.

In order for the Metropolis Dawn expansion pack campaigns to work correctly, the expansion files must be installed via the official expansion installer file, which also require the original game data files with registry data.

It truly is! The entire system of components will be renovated this time from magnets to detectors. In the case of Proton Synchrotron, I heard they will focus on updating the radiofrequency systems specifically by installing standalone converters for each RF cavity.

Welcome back, sectlord! It's very nice to hear from you again. I hope you enjoy your stay here.

(Incidentally, please let me know if you encounter any issues while using your account. I have executed some command scripts on the website server prior to your account activation, and this may have caused some unexpected changes in the website database.)

After the conclusion of its highly successful Run 3 session starting back in 2022, the Large Hadron Collider (LHC) of CERN has now officially entered Long Shutdown 3; a massive 4-year upgrade programme spanning 2026 to 2030.

During this phase, the LHC will undergo comprehensive maintenance and improvement project schedules, and will be finally upgraded to the HL-LHC (High-Luminosity Large Hadron Collider). This upgrade primarily aims to multiply the instantaneous luminosity of the accelerator by a factor of 10 and higher from the original design, enabling the increased particle collision rates and subsequently improved data acquisition from the future experiment.

HiLumi LHC – Home | CERN

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.

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.

Royal Observatory Greenwich recommends visiting Stonehenge around this time!

Summer solstice | Royal Observatory

The Royal Standard is raised above Buckingham Palace now!

The procession route for today's Trooping the Colour will be routine; from Buckingham Palace to Horse Guards Parade through The Mall. The 41-Gun Salute from The King's Troop Royal Horse Artillery will greet The Monarch at The Green Park today, whilst there is also the scheduled flypast performed by the Royal Air Force flying above Buckingham Palace and Hyde Park. More than 1400 soldiers and 400 musicians will participate in today's parade.

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.