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