BrewLAN: An Experimental History — Part 3 feature

Greetings. It has been a while since the last issue of BrewLAN: An Experimental History. Over 5 years in fact. A lot has changed since then. A lot has stayed the same. The BrewLAN logo fits into both of those categories; something that has changed, but is still "the same"™. Like a JJ Abrams reboot. So with that we ask you all, in solidarity, to please rise, or sit, or take a knee, in order to honour part 3 of BrewLAN: An Experimental History.

For reference: BrewLAN: An Experimental History — Part 1 and Part 2.

I'll start with artillery.

You can't spell Suthanus without, wait...

The first unit we shall be looking at in this block is the Seraphim experimental rapid-fire artillery. It's a short story; I wanted to address the fact that with the 'no nukes' game option enabled and with 'game enders' otherwise still enabled, Seraphim were at an obvious disadvantage, since every other race had access to an experimental artillery, in either the Scathis, Mavor, or Salvation. The solution; a Seraphim experimental artillery. I did briefly toy with the idea of having the this artillery disabled when nukes are enabled so that Seraphim only had access to one game-ender at a time, however I talked out of this with the rational that the option of two game-enders is far from as harmful as the option of 0 game-enders, and that it was an unnecessary complication that would most likely only result in confusion and questions, and that overall, it was more beneficial to not have the reverse restriction. An additional interesting point of note, the firing randomness of this artillery is subject to a degree of randomness and to cycles; every now and then it will have pinpoint accuracy, but it's rare enough that you probably wouldn't notice.

You see, Ivan...

Chronologically speaking, this second artillery was started before the aforementioned Seraphim artillery, but it was a breakthrough made during development of that artillery that made this one a reality. 'This one' being 'Ivan' the drop-pod artillery. The name 'Ivan' is taken from the real name of one of my friends who goes by the name 'Noa', so its a wild tangential reference to the Supreme Commander 2 unit cannon.

Initially I couldn't find a way to pass data between the unit and the projectile, so an early version of the 'Ivan' had what was technically 4 different weapons which you could cycle between which had increasing costs, decreasing ranges, and spawned Mech Marines, Mongeese, Titans, or Percivals on impact. The main issue with this, is that having 4 weapons share aiming bones resulted in pitch calculations being wildly inaccurate, and as a result it could not aim at all. An earlier version still only had 1 weapon, which only spawned Mech Marines. This was not an impressive experimental unit. But I digress. The breakthrough to which I was referring comes from the fact that the Seraphim tech 3 artillery, from which the experimental takes its weapon, has the poorly documented feature that it deals more damage to shields than to anything else. 60% more damage in fact. So that GPG could balance this number the same way all other units are balanced, the number is stored in the artillery's blueprint, with the intention of it being passed to the projectile as it fires, however by default very little data, which is all predefined, is actually passed between the two at this point. So to make this work they manually synced this data in the units weapon script. This gave me the example I needed to do the same with unit codes for the drop-pod artillery.

Overnight this transformed the Ivan from a dodgy unfinished artillery that could only fire from a select group of units, to what basically functions like its Supreme Commander 2 counterpart; a land factory with a cannon attached to it which stores units built and passes that data to the drop-pods when it fires. As a result this meant it could also fire units from other mods with no additional effort from either party. And then came many, many hours of trying to work out how to balance this hitting shields. An early idea was to have the drop-pods bounce of shields. This didn't work; shields don't like when things impact with them and continue existing. Following that there was experimentation with having the units dropped with reduced health through the shield. This kills the crab. A Percival with 25% health in the middle of an enemy base is still a Percival in the middle of an enemy base. There is very little you can do to counter that, which is bad. The final solution was to kill them all, but so that it wasn't a total loss for the person controlling the artillery, the total damage dealt to the shield is based on the mass cost of the unit lost in the impact. Mobile strategic missile defence systems lost this way cause 3285 shield damage. Probably not worth the time investment.

The final piece of the Ivan puzzle was to automate it. One of the big differences benefits Forged Alliance had over 2 was that you could set up entire order ques from the factory to the battlefield, however the cannon part, and it requiring ammo to fire, put a degree of separation between those two things. The work around was to give Ivan a 'repeating attack' button. When a target is chosen with the repeating attack command, Ivan will fire its entire payload at that location, rebuild the payload, and repeat. If it has no payload when the order is given, it will wait for the first thing it finishes building and use that as the entire payload. A toggle button is provided to break out of this 'repeating orders' mode. For technical reasons the 'stop' button doesn't and can't work for this.

Yes. Absolutely...

Thirdly is the first artillery chronologically. Because we aren't doing things chronologically, and this also isn't really an artillery. Well, it sort of is. It is the Absolution, the experimental siege tank for Aeon. There isn't much story here; the inspiration for the design is a total mystery... *cough*.

The weapon is basically the massive Oblivion cannon from the Tempest, with a few minor statistical tweaks. There are two other things of note one is that the tactical missile defences it possess is probably the best in the game, because I balanced it against Cybran tactical missiles, which turned out to be absolutely overpowered. Honestly, who thought it was a good idea to have a missile that breaks into 5 other missiles when shot down by a thing that only exists to shoot them down? Anyway, as a result of making them work against Cybran at all, they ended up overpowered against the other three races, and I was fine with this. The final thing of note, is that for some reason, because the game contains no experimental units that can hover in the base game, hovering experimental units added by mods don't get the 'experimental pathing' which means they won't try to path over other units and buildings like any other experimental, so they can end up getting stuck behind walls of buildings. One attempt at a work around for this included defining it as a flying unit, and having its hover distance be very low. This idea was killed by a glitch so daft it prompted me to post a video about it.

Indeed...

And that about wraps it for the 'artillery' section. Next, the 'do nothing' section. So called because each of these do nothing in isolation to help you win.

First up; the Seraphim experimental quantum gateway. Literally does nothing on its own, because there need to be at least two for any functionality. And that function is instant transportation from one to the other. They function exactly like the Einstein–Rosen bridge portal devices found in the Stargate universe. Even down to the part where you can connect to other peoples gates. Connecting to an enemy gate causes the shield protecting exit from that gate to be raised, so expect the first bunch of things sent through to only cause damage to that shield, as opposed to actually re-materialise. Another thing of note, the animation it performs while connecting is actually dynamic. It is based on the location of the target gate.

Like a light in the darkness...

The other two in the 'do nothing' section are so do-nothing that I never posted screenshots of them. Actually that has more to do with the fact that one uses the model of the QAI mainframe from the campaign, and the other uses the model of a random civilian building. The second of which I do plan to change. The diametrically opposed duo are basically a glorified stealth field generator and a glorified radar. They both have additional features, but that is what it boils down to.

Darkness, the glorified stealth field generator, on top of generating the largest stealth field, also sends out a pulse that cripples omni sensors. It has had many iterations, functionally speaking, mostly with over-complicated features such having a multiplier on the strength of the effect based on how far away the target was, but they all caused issues with performance and stability, and were eventually killed off for a flat effect. Targeted omni sensors need to be over a certain radius to be affected. Functionally this means that ACU's and the Galactic Colossus are unaffected by it.

The Panopticon, on the other hand, on top of having the largest omni and radar radius in the game, also has an effect taken right from the 'spies' technology in Age of Empires II; that is that it gives you line of sight on all visible non-command units you have intel on. It used to specifically exclude things near a Darkness, but upon giving the Darkness a stealth field, and making the Panopticon only give line of sight on units you actually have intel on, it became redundant and actually harmful to make the distinction. Now as you might expect, this line of sight is far from free. The cost is calculated based on the cost and movement capabilities of each unit being tracked. Buildings are cheap, they aren't going anywhere. But mobile units cost, and as the units up in size, so do their costs. Expect to pay top dollar to see where those experimental units are. Oh, and don't forget that Monkeylords come with stealth, so you probably can't see them at all.

I should buy a boat...

Factories next. This is partially a revisit of a section from part 2, but is at least 75% new content. The revisit part is that previously I mentioned that to get the desired effect of the Gantry, it made mobile experimental units Gantry-only, and then made a decoy unit for the engineers that became what it was supposed to be afterwards. This is no longer the case. Not-so-recent breakthroughs in overwriting the orders given by buttons in the UI have granted the ability for them to be the same unit, with two different build styles.

There are actually 4 different factories, but I never gave the Seraphim one a 'final' model, so I never showed it off in screenshots.

They are all unique, for a cycle of factories; the Aeon Independence Engine only makes aircraft, the Cybran Arthrolab only makes land units, the un-pictured Seraphim factory only makes naval units, and the UEF Gantry does all of the above, with a toggle switch and context sensitivity as to the terrain it is situated on.

Their names are all various references: Gantry is from a unit in an old Total Annihilation mod which I thought was cool; Independance Engine is a reference to that film with Will Smith and Jeff Goldblum, with the UFO that blows up the White House; Arthrolab is a portmanteau of Arthropod, since it makes spiders and crabs, and lab from the Total Annihilation Kbot labs. The name of Seraphim one comes from the sound one makes whilst making obvious, but unintelligible, excuses whilst a significant other attempts to remove your tongue for placing it where it ought not have been.

A cool hidden feature of the group is that when allied engineers of other factions of sufficient tech level are nearby, they gain the ability to make the experimental units of those factions. The UI for this only updates when a new construction is begun, or for the Gantry, when build menu is changed to or from air units.

There is actually a time-lapse video of the Arthrolab, but it is Patreon only. Available for the low-low price of $1 per release. And that's like, what, 1 a year? at best? The UEF and Aeon factories both pre-date when I started recording production, and the Seraphim factory hasn't gotten a 'proper' model yet. So they don't have videos.

Suiseiseki would be proud...

Continuing with the theme of things that can build, a unit with probably the most troubled and drawn out production histories in the entire mod. The Seraphim Iyadesu. Originally an experimental engineer. This was overpowered. Then an experimental field engineer, with less engineering speed. This was still overpowered. The current iteration is dubbed an experimental 'reconstruction engineer'. The power level of this has yet to be proven. Is it over 9000? Only time will tell.

The current status of the abilities of the Iyadesu are thus: Once it finishes reclaiming a wreckage it gains the schematic of what that wreckage once was. For each schematic it gains a drone containing that schematic. It can store up to 8 schematic drones. The schematics can be duplicates of schematics in other drones. The drones assist with engineering actions performed by it. The drones are labelled and can can be targeted specifically by enemies. Losing a drone causes it to lose access to that schematic unless it has at least one other drone with duplicates of that schematic. Everything that is reclaimable, or leaves a reclaimable wreckage is technically fair game. It can technically gain the schematics of civilian buildings, however the default UI doesn't allow for selecting units without a defined tech level, so you have no way of telling it to build them. I have no plan to rewrite the UI for this, but won't restrict other people who wish to.

I don't even remember the original rationale for calling it the Iyadesu. At this point it is called Iyadesu because that is what it has always been called. ~desu

*Flight of the Valkyries intensifies*...

This one is hardly new. It's over 4 years old at this point *cringes internally at the inexorable passage of time*, but it has seen development since the last entry in this column. 5 years ago. Don't look at me in that tone of voice. I'll try to keep this one short, since we all know the Centurion.

The development history of the Centurion has been well documented, its seem buffs, nerfs, several re-textures, and all the rest, and still looks like an awkward rectangle.

One play tester even went as far as working out that if you initiate self destruct 8 seconds before it would arrive at a Paragon, it will land perfectly on said Paragon with no regard for shields or anything else.

It is even the reason for the cessation of development on the mod to add realistic camo colours to UEF units, because even though that is actually an unimplemented feature of the base game, it causes movement manipulators of weapons and gunship engines to break, essentially T-posing any unit. While this isn't the fault of the Centurion, it is the unit I noticed it on. You can actually see it on the red and yellow desert scenes. The grey one is actually the default skin, so the engines are facing the correct direction for a landed craft.

A few other interesting things of note for the Centurion: It has a seldom used rear-facing laser cannon mounted to the bottom of it. It can two shot air superiority craft, but only if they get in its very narrow and short firing arc. It has an AI routine that is obsessed with pancakes. Pancakes in this sense referring to the act of 'pancaking' Paragons; crash landing into them for the intended purpose of crippling someones economy. This routine includes ballistic calculations on par with English military artillery calculations from the World War eras. That is to say approximate and hopeful. The routine has also had more iterations than I care to admit just to discourage 1 specific play style from 1 specific play tester, just because it's a tactic you would never be able to get away with easily in a game against a real player.

The end is never the end is never...

All things end at the beginning they say. So it seems fitting that this would end with a reboot of the first experimental I tried to make back when I had no real idea what I was doing. That first experimental being the Doomsday Machine; a point defence inspired by the Doomsday Machine from Total Annihilation. It was a train wreck. Over half a decade later its spiritual successor, its re-imagining, its reboot, is basically inspired by the Annihilator from Total Annihilation. It actually isn't, directly at any rate. If it was it would have been named Annihilator. As it happens I only realised this parallel while I was collecting names I had crowd-sourced for a poll, and entered it hoping for the best. Its design is actually based on my developed preference for a do-one-thing-the-best style of experimental unit design, and from a gap in my table of experimental units for a UEF defensive structure to inversely parallel the Iron Curtain. Just as the Panopticon and Darkness inversely parallel each other.

The majority of the development process of this weapon is well documented in my time-lapse video of its production. However what isn't included in that video is the reasons behind any of the choices. For example, the reason it's a beam weapon, is because beam weapons are the only hitscan weapons in Supreme Commander, and railguns are fairly close to being rel life hitscan weapons. I also wanted to make use of the laser I took off the Novax satellite, and it looks more impressive than a projectile that hits its target instantly. Following the video I started experimenting with the other thing railguns are known for; penetration. Near the start of the process I moved it to a fast moving projectile instead of a beam, because it looked like it would be easier to achieve with a projectile rather than a beam, and it was; however on getting it working I realised that the engine has a fundamental flaw which completely ruins the entire thing. The tick rate is too low.

For the majority of people reading this who have no idea what this means, I shall explain. A 'tick' in computing is the shortest calculable time period. In Supreme Commander the lua scripts run every 10th of a second. The engine uses a C derivative language, with a higher tick rate, and core things are handled by that. However, as modders, we have no access to that, and everything custom is handled by lua on top of that. The short of this, is that the railgun penetration effect only works as expected when units that should be hit by the projectile are evenly spaced at the distance that the projectile travels in a 10th of a second. Everything in between those points is ignored. For a slow moving projectile this would work. However this is not a desired effect for a slow moving projectile. I may come back to this with a beam instead of a projectile, but suffice to say, realistic railgun weaponry is not possible in the Supreme Commander implementation of lua.

Well, I have an idea of how I could get it to work, but its hella messy, would need many unnecessary calculations to get it to look as it should and to even work at all, and would be way more book-keeping than this sort of thing should need to have. And would also probably require me to check against game time, and mess with the impact scripts on units and shields. Actually I'm going to try it.

[Edit]: It turns out that removing the damage radius made the correct things take damage. The explosion graphic appears at the base of the target rather than where it should be, but it's close enough without some serious computation to calculate where it should have been..