[RELEASE] Urban Assault Level Creator

Welcome back, Ydro! I remember your prototype custom UA Level Editor program from the old Stoudson Corporation website, and I always thought it was a very nice idea.

I have briefly tested the new Level Creator tool just now, and I must say that I am quite impressed with it so far. It supports all comprehensive features and various functions that are essential for creating or editing UA levels in a convenient way.

The scale of the coordinate system is identical to the game engine standard, and the Drak constant conversion ratio for AI and player host stations appear to be correct as well (60000/255 for User and 70000/255 for AI host stations).

Although I wish there was a better way to represent the fundamental differences between the energy system mechanics of AI and User host stations, this is a technical topic that wouldn't be relevant for most users.

I do not have any particular suggestions so far, but I noticed there are some errors in the unit names from the legacy data, which I think should be fixed accordingly. I suggest parsing the language.dll locale file from the English version of the game in order to get the accurate in-game display names.

I will post a message about this new release in the Discord server. I remember there were discussions about the ideas for a new custom UA level editor taking place before, and I'm certainly sure this new level creator will provide a perfect solution for it.

Thanks again for your contribution!

Thank you very much for adding the tooltip and fixing the unit names!

Regarding the issue with missing units from the different Startup directive files, this problem occurs because StartupT.scr file does not include Taer.scr file, which contains the vehicle definitions for new Taerkasten units in Metropolis Dawn expansion.

This file is not included there because it is not a part of the standard initialisation files that are refreshed each time a level with the particular startup directive line is parsed during the campaign. This is an imperative mechanism in order to save and track the updated vehicle stats (via Technology Upgrades) within the user's progress without reverting them to default unit stats.

The same logic technically applies to StartupG.scr and Ghor.scr files, as well as StartupM.scr and Myk.scr files accordingly. However, since there are no new Ghorkov units in Metropolis Dawn expansion, and the Mykonian units always appear as the enemy faction in Metropolis Dawn single-player campaigns, both files are loaded properly into the editor in this context.

There should be various ways to circumvent this issue. One method would be adding an option alternate between the Metropolis Dawn dataset (all files in dataxp folder) and the original dataset (all files in DATA folder). Perhaps it would be also possible to load only the necessary files (from Metropolis Dawn data) separately so the new content can be displayed directly without parsing the files.

Additionally, may I have one more request regarding the tooltip? I think the difference between the energy reservoir mechanics of the user and AI host stations would be worth mentioning there. User host stations have three divided and separate energy reservoirs that are used for specific tasks, whereas AI host stations have one unified energy reservoir that is used for all tasks simultaneously.

I also believe a simple explanation about the special unit upkeep/maintenance mechanics that are exclusive to AI host stations would be helpful as well. But I'm afraid it could be considered excessive for a brief tooltip section. It may be also feasible to describe all these logics in a dedicated Help section.

Thanks in advance!

(Re-posted with the updated information for accuracy.)

These are rather technical topics and there are a lot to cover, which is the reason why I was initially hesitant to bring this topic up here. In summary, the AI energy system works completely different from the user energy system. So comparing their mechanics in an arbitrary environment does not yield good insight on their inner workings.

To start with, the user host station energy battery conversion ratio is [Energy/100*4] from the script value, in order to allocate the amount of total energy into the 3 separate energy batteries of the user host stations with different purposes. So the total energy size of all batteries gives the user AI host station 3 times higher energy than its maximum battery size.

The script energy value is further divided by 4 here because initially there was 4th energy battery that was exclusively used for building construction during the development. The function of 4th energy battery was eventually merged into the creation energy battery in the final version of the game, but the logic remained.

In comparison, the AI host station energy battery conversion ratio is [Energy/100] from the script value, because there is no extra energy battery for the AI host stations. Unlike the user host station, it does not have any extra denominator value since the AI host station only has one monolithic energy battery for all purposes by design.

As a result, the AI host station will have a larger maximum energy battery size compared to the user host station from the identical script energy value. But their total energy reservoir sizes will be similar because the user host stations also have multiple (x3) energy batteries. Therefore, in your above test environment example the AI host station with 400000 script energy value had a maximum energy battery size of 4000, not 1000; which corresponds with the anecdote of your result.

Whilst this may appear like an advantage on surface, this is not necessarily true. AI host stations have other numerous restrictions because of limited resource management capacity - such as unable to separate the system life battery from the creation battery.

So creating units or buildings will always render them vulnerable, and combined with the other energy mechanism factors, it usually results in a situation where the AI host stations in the single-player campaigns are lacking energy most of time with their energy states at the lowest level.

Moreover, the AI host stations also have other hardcoded restrictions like the 2 seconds of unit creation delay, or inability to teleport their host stations unlike the user host stations. These are rather considerable restrictions especially when combined with the AI unit upkeep mechanics.

The main disadvantages of the AI host stations are prompted by the unique AI-specific unit upkeep/maintenance system which have tremendous effects on their general energy system mechanics. This topic is imperative for understanding how the AI energy system works, and how much disadvantages the AI host stations have compared to user host stations during the normal gameplay situations.

In single-player mode, the user can create any units at a fixed cost under any circumstances. The individual unit costs are static for the user, and they do not change no matter how many units the player creates and controls during the gameplay.

Meanwhile, the AI has a dynamic energy cost system for units. The individual unit costs for an AI host station increases linearly and proportionally to the total numbers of units that the AI host station currently controls. This mechanism is rather similar to the unit cost soft limits in multiplayer mode, but the detailed mechanics are different.

The dynamic unit cost system for the AI host station can be expressed in the following linear equation formula.

K = (k/2)+(kn/40)

or more simply,

K = k*(20+n)/40

Where 'K' is the current dynamic cost of the new unit for an AI host station; 'k' is the standard cost of the new unit; and 'n' is the current number of total units that an AI host station has control over.

The result is an arithmetic progression that can be expressed in a linear function with no defined limit. Therefore, the unit creation cost for AI host stations will continuously increase as they create and control more units and flak/radar stations on the battlefield.

For example, an AI host station can create its first 20 units cheaper than the normal unit cost, and its 20th unit (including all individual units and turrets currently present under their control) at a same energy price as the original unit cost. But from there on, the unit creation costs for AI will be higher than the standard values. As a result, the creation cost of its 100th unit will be 300% (+200% higher) of the normal cost.

Likewise, its 200th unit creation cost will require 550% (+450% higher) of creation energy than the standard unit cost value, which is prohibitively high in all regards. The increased unit costs for AI can be only reduced back if the existing units are destroyed. On the contrary, the construction costs for buildings remain identical for AI in all situations, same as the players.

This is why many AI host stations prefer to construct numerous flak stations around their bases in later missions, where their manufacture costs of normal units become excessively high to be practical. Still, the individual flak turrets (and the radar antennae) will contribute to the total number of units under the AI control, which will resultantly affect their attack capabilities in favour of defensive advantages the emplacements offer.

It is also worth noting that individual AI host stations possess independent command & control systems. So when there are multiple AI host stations present for a faction in a level, only one of these AI host stations will be responsible for controlling all pre-deployed squadrons and automated structure components in the level; which means the energy penalty for this 'master' AI host station will be usually greater than the other AI host stations in the same faction that only manage their own units, unless the pre-deployed assets are exhausted.

These designs are implemented in the game in order to manage and control both performance and difficulty of the missions at the same time. However, it is undeniable that it poses a significant handicap only to the AI as the player does not have any hardcoded restrictions by design.

Regarding the unit availability, the AI cannot create units that are not enabled in the level files in the campaign, as their vehicle and building availability is not tracked in the campaign and refreshed each time the level is loaded (as a part of the Startup files directives).

However, the AI can still reinforce same types of units into the existing squadron of the unit, even if the AI cannot create a new squadron of that unit in the level unless it is enabled under prototype enabling. This is probably what you have noticed during your test earlier.

You are free to include the Level Builder Word document file as reference material. But the correct name of that file should be 'Levelbuilder_English.doc', even if the file available on the FTP servers has a different name.

I hope the above information was useful, and please let me know if you have any further questions about this topic.

Hi everyone,

This map editors incredible, but I was wondering if there is a way to get AI host stations to send their units in hordes, as at the moment the units are attacking as soon as they spawn creating a continuous stream of enemies, plus is there a way to change the mission names and mission briefings on the campaign screen, thank you all.

Hello Stellaritely, welcome to the forums!

The total sizes of squadrons or the amounts of units that AI host stations will assign into certain tasks are determined by numerous factors, including the types of activities and the frequencies in their AI host station action module parameters, the total energy sizes on the targets or the 'weight' of the intended target objects, or the ratios between their current energy generation capacity (income) to their allowed activity budgets, and so on.

For example, AI host stations will prefer to assign a larger attacking force if they are performing heavy-duty operations such as base conquest or anti-host station type actions, since host stations are usually well-protected in their bases and have a large energy reservoir size. Meanwhile, for defensive or reconnaissance actions the AI host stations will usually create a smaller force that can be managed more flexibly and reactively.

There are also situations where the AI host stations might have high activity budgets for multiple types of actions, but do not have sufficient energy generation capacity to meet that quota due to lacking sectors or too many power stations under their control. This problem is also caused by the unit cost energy upkeep/maintenance mechanics that are unique to the AI host stations, which I just covered in my above post earlier.

Adjusting the AI host station action parameters (budget values) is the most straightforward method to control the behaviours of the AI host stations in levels. It would be helpful if you could provide us with more details on what levels you are modifying, since the official levels have customised AI parameter settings for each AI host station. You may also want to assign higher energy or recharge values if their host stations are low on energy.

Finally, in order to change the mission names and mission briefings, you will have to modify the 'language.dll' file (or 'language.lng' file if you are using OpenUA) that is located inside the Locale folder of the game directory. The mission titles and text are stored inside the individual language localisation files. The language.dll file can be edited with tools such as Resource Hacker, whilst language.lng file can be edited with text editors.

Hi Schloss,

Thank you so much for your response, it's helped me a lot and as soon as I'm able to do so I will play around with the settings and adjust the items you have described, as for providing a level I am currently in the process of building a brand new campaign for the resistance to add more diversity to the game, which I will be more than happy to share with everyone once it's finished,

The mission which the enemies were attacking in a steady stream has 3 of the turantul 1's in a 13 x 13 grid placed across a fortress style mountain, so I'm thinking it's too many powerstations to sector ratio, so I think it will need some adjustments, if you like I can send the level file over if it will help you.

Thank you so much for your help

You're very welcome, I'm glad to know it was helpful! It's also wonderful to hear about your new campaign project as well. In that case, the level file won't be strictly necessary and I can highly recommend experimenting with various AI host station parameters and their environments. Tuning AI host stations in order to better accommodate the individual level layouts and settings has always been an important task when designing levels.

I wish you all the best in your project, and please let us know if you have any further questions or require further assistance. In the meantime, I will search for the official English Levelbuilder document file and temporarily upload it to the website FTP section. This Levelbuilder file contains every key information you need to know about when designing your own custom levels (via text editors originally) and so it is a valuable reference material.

The English Levelbuilder document file has been uploaded at the following FTP link:

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

(To Ydro: I apologise for hijacking the thread!)

Thank you for all your help, there's a bit in the level file which applies directly to conquest and how the squads work, which il be playing around with later,

Once again thank you for everything.

Hi Ydro, welcome back. I'm pleased to know that the above information was helpful!

Thanks for taking my suggestions into account once again. I also wholeheartedly agree that including the detailed information about the AI energy system mechanics and inner workings will be beneficial for level designers. I will have to see if I can test the new version of the level creator soon.

Regarding the unit availability and *.rst files: These files are the restart cache files that are newly generated and parsed each time the certain level is accessed by the user (via clicking Start Mission button at the mission briefing screen). As its name implies, they are mainly used for loading the level data when restarting the level (via Restart Mission button).

It is true that the *.rst files contain separate entries for tracking the unit availability of the enemy factions in the level, but since these files are newly parsed each time the level is accessed by the user, it would be normally refreshed accordingly if the corresponding level definition file was updated to not include any prototype enabling data for the enemy factions in the same level.

However, I have not checked if the different *.rst files generated with different level ID numbers can also affect the unit availability of the factions in the other levels. It would be surprising if they had any effect in this manner, but I don't remember testing it before. The *.rst files are also temporary in nature and replaced by *.fin files once the level is completed, which do not contain any unit availability data.

Back to the AI energy mechanics topics, it wouldn't be that difficult to implement the custom options in OpenUA for disabling the numerous unique handicaps and restrictions that are exclusively applied to the AI players only. In fact, I created an experimental prototype binary patch for the original game executables in order to achieve this task many years ago, but I never released it publicly.

It was partly due to our inclination at taking cautious measures when it comes to sharing any modified game executables that can drastically alter the gameplay logics or behaviours. Still, I can see the merits of such a functionality in the future OpenUA versions as a part of the game modification options and features.