Next Release Notes

Version 0.613 When Changes Escape

(Released December 30th, 2017)

New IBL light source that is much bluer and also brighter, changing the look of the dark side of ships and objects.

No more bloom! After much (much) experimentation (on video, even: https://youtu.be/WGVcdQhH0SQ), bloom was found to be lacking in a lot of ways. We've come up with a way to get the glowy look simply by using HDR emissive colors that give the illusion of glow thanks to changing shades at oblique angles.

Revised version of "Ark One" that splits up the textures and meshes a bit differently, mainly for purposes of the bloom-less HDR emission.

Also redid the LOD1 of this, and that kicks in way faster and saves a lot of vertices throughout most gameplay situations.

And added an LOD2 of this that adds crazy efficiency if there are a lot of Arks on one planet.

A new Arcen Visual Solomesh Ship variant has been added that lets us have much simpler ship definitions that are cheaper to move around on the CPU, and draw more efficiently, and which are simpler to set up.

Focused gravity generator graphics are now in place.

The fighter has its new graphics, as well as a larger scale.

The scale doesn't work quite that well with the formation size currently in use, but the formation will be corrected later.

Fixed some problems with the mouseover ship tooltips being too "sticky" (choosing to show what it had been showing versus what was actually under the mouse now), leading to the whole thing feeling very unresponsive especially with the build menu buttons.

Thanks to Kahuna for reporting.

The ship mouseover now shows the name of the owning faction again.

Thanks to BadgerBadger for suggesting.

Map type consolidation. Maze A-D is now "Maze" with 4 subtypes. The other grid types are also consolidated into Grid with subtypes and Clusters Microcosm is now a subtype of Clusters.

Fix a visual bug where ships were not dying properly. Also fix an audio bug where the explosion noise was being played at the wrong time.

The Dyson Sphere now spawns different types of ships based on the faction intensity.

Player can choose between ArkOne (the original Ark) and the Rorqual Hegira when starting the game.

Main menu updates:

The ship on the main menu now has some little ions coming off its forward pulse drive. A happy accident of some other experimenting.

The ship on the main menu now also has thrusters. This was the last piece of the main visuals for that, and it's something we took care of while on a different main mission for the game, so to speak.

Modifying your in-game speed now displays nicely with Coarse speed enabled as well

Updated ship visuals:

Bomber and Eyebot updated and imported, same as Fighter, noted above.

Lightning Corvette imported, LODS created and integrated to the game.

Autocannon_Minipod LODs and integrated into game.

Raider LODs and integrated into game.

Coprocessor LODs and integrated into game.

Data Center LODs and integrated into game.

Design Template LODs and integrated into game.

Version 0.612 AI Hunters and the Turrets that Stop Them

(Released December 19th, 2017)

Redid the faction color set to have a lot less "those two colors look really similar" overlap.

Fixed a number of bugs with the Devourer and the Zenith Trader; mostly in the routing code.

Fixed a number of bugs with tracking "nearby unengaged mobile strength"; notably it counting AI guard ships and not properly populating all the relevant lookup tables due to the order of computation.

Added general support for "sort_order" attribute on all xml tables, though the only current use is in the lobby faction custom option dropdowns.

Moved build menu item eligibility logic into external code, so modders can see (and potentially tweak) the rules for what types of units the AI can build.

The Hunter Fleet

The "threatfleet" mechanic from AIWC has been incorporated: threat ships that get "bored" from having to wait too long on a local front go and join a coherent offensive fleet to look more broadly for ways to annoy the player.

It has been adapted to AIW2 as a separate faction, and it's learned some new tricks about force composition.

In AIW2 it is known as the "Hunter Fleet".

It's also shown on the Roamers galaxy display mode.

The Warden Fleet

The Special Forces has evolved a great deal from its early AIWC implementations (basically a randomized patrol route across the whole galaxy) to a coherent defensive menace.

Accordingly, it has been renamed to the "Warden Fleet".

Both the Warden Fleet and the Hunter Fleet, when they're idling at a staging point, will now "cash in" fleet ships for guardians to bring them up to a roughly 1:1 ratio of guardian strength to fleet ship strength.

The Warden Fleet is now more likely to hang back a hop or so from the front.

Unless it thinks it's strong enough to camp right up to the border; depends on where your forces are.

The Hunter Fleet uses similar logic: when it's small it will probably hide fairly far away, but as it grows relative to your border force strength it will creep closer.

AI Battle Logic Revisions

Changed the "hunker down" logic of AI guards that are heavily outmatched to just huddle at the controller, and not charge out to try to kill something.

The idea is that they're probably waiting for the Warden Fleet to break the siege.

Changed the "abandon planet" logic of AI guards that are massively outmatched to instead use the "hunker down" logic if the Devourer is present.

This way the Devourer doesn't free entire MkIV/V planets worth of guardians as threat to come kill you.

Changed the "retreat" logic of AI (threat or abandoning guards) to strongly prefer wormholes not covered by hostile shields.

UI Refinements

Fixed a bug where the game still handled most keyboard input when the Save-Game window was open.

When the Settings window is open, pressing escape now closes it.

When the Save Game or Load Game windows are open, pressing escape now closes them.

Now closing the Save Game window only unpauses your game if the game was unpaused when you opened the window.

Now closing the Settings window unpauses your game if the game was unpaused when you opened the window.

New-Game Experience Refinements

The option to start with the first planet is no longer an option: you just do.

Thanks to... everyone, for indicating that we should do this.

Added an option for starting with your Ark and Starship Constructor already set up to build everything and rally it to the Ark.

Note: this conduct (Conduct_StartWithBuildQueuesSetUp in the external code project) is fairly straightforward (if you know C#) to duplicate and put whatever setup you'd like in there, as sort of a "macro".

Thanks to BadgerBadger for inspiring this change.

Your starting starship constructor now seeds next to your controller, which is a minor change but saves the step of moving your controller next to the constructor to include it in the controller's defenses.

Defense-Game Rework

Weapon turrets no longer cost power.

So the only major restrictions you face with these are:

There's a cap that's per-planet, per-type, and per-mark-level.

Building them costs metal and takes time.

And so spending tech on these now has a clear benefit, whereas before the combination of the power limit and the cap limit made that dubious.

Also note: the power of these units and/or their caps may come down for balance, but there's not much of a reference point to judge against yet.

The no-power-cost turrets can now only be built on planets you control.

Power costs have been doubled, back up to their levels before later changes, since weapon turrets no longer require it.

There's no longer a power boost from researching techs that grant power-using units.

The "Basic Turretry" build pattern, which would just dump your full power budget into stuff around the building unit, has been replaced by:

Core Shields

Spends 1/4 your total power budget (or whatever is left) on shield generators around the controller (if it's friendly, otherwise it's around the building unit).

Core Turrets

Spends 1/4 your total cap (or whatever is left) of each non-power-using turret type around the controller.

Core Other

Spends 1/4 your total power budget (or whatever is left) on non-shield power-using stuff like tractors, grav generators, etc around the controller.

Of all three, this is probably the one where you want to make the choices yourself, but you can use this if you'd like. Modders are free to tweak it or a duplicate of it.

Other patterns are planned, for distributing things out to defend wormholes, etc, but I ran out of time for this release.

Version 0.611 The Special Forces Have Arrived (Again)

(Released December 13th, 2017)

Fixed a regression where the resource bar was blocking mouse-edge-scrolling on the top edge of the screen.

Thanks to BadgerBadger for reporting.

Now when you mouseover a planet on the galaxy map with a selection that you could give a move command to that planet, the game highlights the path that would be taken.

Thanks to BadgerBadger for suggesting a way to do this, and many others for reminding us how important this AIWC feature was.

Reorganized the timing loop during the pre-game lobby phase to remove the non-mapgen side-threads, since they were leading to the game getting "stuck" where you couldn't quit the lobby and the game itself wouldn't really run properly.

Thanks to sestren413 and BadgerBadger for reporting.

Shield Starships and Shield Guardians now use a new dedicated-shield-generator durability class that basically guts their dps but makes them do their real job much better.

The Ark now also uses this, but has had its overall strength reduced substantially to maintain roughly the same total shield strength. This also means that the Ark is much less scary to the AI in its strength computations, while its main contribution to your combat ability remains similar.

Added the ability to pick a color for each faction in the lobby.

Thanks to BadgerBadger for providing an initial implementation of this.

Fixed a bug in last version's change to Clusters maps that broke ClustersMicrocosm maps.

Thanks to BadgerBadger for the fix.

Special Forces

The old part-of-the-normal-AI implementation (which was partly in Core code, partly in External) has been completely removed and replaced by an entirely separate Special Forces faction (implemented only in External code).

It even gets its own distinct faction color.

I heard reddish-mauve has the most doom.

Rather than regional fleets, the SF has gone back to a more AIWC-like single fleet, though alternate SF types can be modded in.

In the lobby you can pick a sub-type of SF, but for now there's only the one (Normal).

The SF faction currently has no means of acquiring resources (budget) on its own, but the main AI periodically makes donations to it with the strength it previously used to build SF units.

The old implementation had acquired a number of bugs that made it mostly a non-issue to the player. The new implementation has been tested quite a bit and it has been certified as Able To Ruin Your Day. Thankfully, it retains the AIWC logic of being generally unwilling to enter planets you control.

Added a "Roamers" galaxy display mode that shows the position of the SF hideouts (which are where its guardian units spawn) and the numeric strength it has at each planet.

Version 0.610 Pay No Attention To The Golem Behind The Curtain

(Released December 8th, 2017)

Fixed a bug from the last few versions where the resource bar's tooltips wouldn't show.

Thanks to FalseMyrmidon and BadgerBadger for reporting.

Fixed a number of issues that still prevented high-shot-count units from efficiently using their shots in a way that accounts for overkill.

Increased the Devourer's rate of fire dramatically, while keeping its (insane) DPS roughly the same.

Combined with the overkill-efficiency fixes, this thing is now a genuine killing machine. Don't be in the way.

Finally added an AIWC-like "You Won!" and "You Lost!" display, for when your king or the AI's is down.

Thanks to many who have reminded us of the complete lack of visual acknowledgement on this point.

For modders: you can copy the "Intensity" custom_field element to any other faction (that's visible in the lobby) and it should work. To actually use the value you'll need to call faction.Ex_MinorFactionCommon_GetIntensity() in your logic and do something based on it.

From BadgerBadger: the Clusters map type now has a number-of-clusters dropdown with three options.

Low gives the old Clusters behavior (generally 6 clusters).

Medium and High each given higher numbers of clusters in different arrangements.

Thanks, Badger!

From BadgerBadger: Now the name of a wormhole glows red when a wave is going to come through it.

Thanks, Badger!

From BadgerBadger: Now destroying a warp gate that a wave was going to come from has an impact:

If a wave has been scheduled but the humans are not yet alerted to it, the wave will change warp gate/target planet but stay on schedule. As a player you won't notice all this.

If the player has been alerted to the incoming wave then that wave gets cancelled and doesn't arrive, but the next wave will be a bit stronger.

Thanks, Badger!

Goodbye, Alloy, But Thanks For Teaching Us A Lot

We've removed the Alloy Shader Framework from our project, for a variety of reasons with potential incompatibility with future versions of unity, and the general pain-in-the-rearness of packing maps in unity for it.

Instead we now are using shaders created by Chris that give an identical look to the Alloy versions, and the same or better performance, and which are compatible with metallic+roughness+occlusion maps that we bake directly in Substance Painter instead of having to handle those in unity.

This saves us a ton of time (hours upon hours, in the end), gives the same or better visual result, gives the same or better performance, and has no compatibility worries with future unity versions.

The custom player ark Rorqual Hegira has been updated to use our new direct-from-substance-painter packed map shader, rather than the stuff packed via Alloy, and in playing around with this some we actually now have a very cool wet look to it that we felt like was thematically appropriate for this particular Ark.

Version 0.609 Hotfix

Put in some protections against a null-controller-for-UI-element situation.

Thanks to BadgerBadger for reporting.

Fixed a number of issues where the new lobby layout didn't use elements large enough for the text to fit on lower resolutions.

Lightened the background of the in-game top bar HUD.

Thanks to TheVampire100 for suggesting

Narrowed the ship tooltip to not let the descriptions run into the middle of the screen so much.

Sending the camera to a location using the Angled camera type now uses a specific height offset for the planet or galaxy map view rather than trying to use whatever the current height previously was. With the prior method, because of the recursive nature of the additive offset, you'd get zoomed out further and further, ad infinitum. Now it's predictable.

Thanks to Draco18s for reporting.

Version 0.608 Interface Evisceration

(Released November 28th, 2017)

Fixed a bug with the overkill-prevention that was causing live ships to not be shot at when they should have been.

Fixed a longstanding bug with UI scaling where text inside textboxes would get its top and bottom chopped off at scales below 1 (especially below 0.7), because the scaling apparently could not be applied to the internal vertical padding of the textbox. That padding has now been removed (and the text vertically.

The minimum UI scale is now 0.3, because below that it's hard to imagine anything being useful even at very high resolution, and it was possible to get "stuck" there unless you hand-edited a settings file.

Fixed a bug where very slight hull damage to the Ark could cause it to request repairs (preventing other stuff from getting repairs) that cost zero metal (which prevented that request from being fulfillable).

Thanks to BadgerBadger for the report and save.

The logic for picking which ship type an Advanced Research Stations will grant is now done during mapgen rather than at the time of capturing the station, so that the name of the type can be shown.

Fixed a bug where the Design Backup Servers and Experimental Fabricators and Experimental Turret Controllers were not showing the name of the stored/granted ship type in their tooltip.

And now ARS's will do this too.

Thanks to BadgerBadger for badgering us about this one.

When you take an AI planet, thus causing an AIP increase, and that in turn causes the AI to unlock a new ship type, the resulting Design Backup Server can no longer seed on the planet you just took (partly because you can't hack it anymore, since the AI no longer holds it).

Fixed a minor UI bug where opening the list of galaxy display modes would show it a bit off to the left instead of just above.

Housecleaning:

Fixed a bug on the galaxy map icons and ship gimbal icons that was causing repeat setting of object names.

Fixed an issue with the external visualization project not properly referencing the external main code dll, leading to inability to compile in visual studio for modders or us developers (Compiling via batch file still worked fine).

Fixed an issue with the unity modding and gui project no longer having a reference to the rewired (input) core dll for some reason.

We previously had two text-rendering systems in the game. One that was based on our older technology from our 2D days (well, since something like Bionic Dues at least), using bitmap fonts and whatnot; and the other that was based on TextMeshPro.

We now just have one text-rendering system, the new and better one. The old system was pretty much just used for wormhole names in the planet view, although it was also used (and drawing incorrectly huge) if you told your ship to draw its "gimbal name." We haven't had any ships that do that in quite some time, though, and that's mostly a debugging thing.

With removing the older text system for the bitmap fonts, that means that the wormhole text system had to be overhauled, which has an immediate visual impact.

Now the font is better on the wormholes, and the text stays clearer as you zoom in on it.

Additionally, it's now possible for code to set the color of all or part of the text on wormholes, and we can use icons in text, and whatever else. Note that the galaxy map was already using this text system.

There is now a "highlighted team color" hex code and internal color available for when we want to mouseover something that is team-colored and have it brighten.

Using the new text goodies, wormholes now show the team color of whoever owns the planet on the far side of the wormhole. If you hold ctrl and hover over the wormhole, then it shows the new "highlighted color" of the owner. If the planet on the far side is un-owned, then it just shows as white and then uses the yellow highlight color when you ctrl+mouseover it.

The Game Setup (i.e. pregame lobby) UI has been completely rearranged in a fashion that's more like AIWC.

The factions are now accessed through a tab like Map and Options, rather than being a sidebar on the right. This allows more room for controls to customize those factions.

Fixed a bug where factions marked "must_be_at_most_one" were not enforcing that rule in the game setup window.

The logic for what text (and what color) a wormhole shows is currently determined by the active galaxy-display-mode (so it's readily moddable), but it may be moved somewhere more appropriate in there is such a place in the future.

Completely ditched the icon-based ship tooltip window, since feedback was overall very negative on the whole approach.

Instead, there's a more compact text-based tooltip that may be sufficient for 1.0 (with refinements), or may need to be itself ditched in favor of something else.

Thanks to everyone for the feedback, it is very helpful; please keep it coming :)

Incorporated a fix from BadgerBadger to make the Nanocaust not always show as a huge pile of Threat.

Thanks, Badger!

Version 0.607 Don't Die Harder, Die Smarter

(Released November 18th, 2017)

Greatly increased the area in which you can move in the Angled camera view, since the way that the zoom-out works there gets pretty funky if you hit the edge; and just feels odd when you hit the edge in general, in that particular mode. Now it's unlikely you'll hit the edge.

Incorporated a fix from BadgerBadger to make the Nanocaust not claim "influence" over a planet from the presence of any of its ships, but instead only if it's a NanobotCenter.

Thanks, Badger!

The "towing" effect of tractor beams no longer applies to ships that are currently projecting a shield.

This is to avoid a bizarre (albeit amusing) condition where the shield is bumping the tractor-er around at faster-than-normally-possible-speeds and the tractor-er is towing it, causing the push to continue, causing more towing...

For modders: you can now set the ShouldNotBeConsideredAsThreatToHumanTeam flag on a unit to prevent it from showing up in the Threat or Attack totals at the top of the screen, even if it is otherwise considered threat strength. You can later clear that flag if you want it to start showing up in those totals again.

Thanks to BadgerBadger for inspiring this change.

Added a "Ghost" AI Type that specializes in cloaked stuff.

There are now all-new wormhole graphics -- six variants, actually. In existing savegames, only the first variant will be used.

In new savegames it will randomly assign wormholes to be one of the six, and will make sure that both sides match each other in terms of which is chosen for the links between planets.

Simulation Performance Improvements

Note: when we say "Simulation" we mean the underlying game calculations (which are run on separate background threads). The main-thread visualization of the game runs at a fairly absurd speed regardless of what the sim is doing, and often if you don't crank up the game speed you won't notice any slowdown from the simulation, but any improvements we make to this performance increase the chance of you getting the game speed you're asking for.

Now if the underlying simulation is running faster or slower than expected (by at least 10%) it shows a percentage next to the game-clock; the tooltip explains it as well.

Basically if you crank up your frame frequency (not frame size) and your cpu can't go that fast, it shows a red percentage showing how far short you are.

After this release's changes, one of the developer test machines (laptop, decent but not special) starts seeing those red percentages at the 300% speed mark in a new game; we're interested to know where different tester machines hit that point.

Roughly 33% increase to no-active-battles sim performance by implementing the Ostrich Algorithm for shield-protection: If there's no shots flying on a planet, and none of the factions that are on that planet are hostile to any other faction on that planet, completely ignore all shield logic on that planet!

Also implemented the Ostrich Algorithm for targeting logic, bringing the "planning" part of the sim down to a level that it's generally not restricting the simulation rate unless there's a big battle going.

Threat/Wave AI Improvements

It's now possible for a faction to give ships a wormhole order that refuses to wait on the normal threat logic.

AI ships launched in a cross-planet wave now use this.

Thanks to BadgerBadger for suggesting.

AI threat ships can no longer retreat until they have spent an average of 30 seconds on the planet.

The AI lobby has expressed outrage at this enforced stupidity, and has received a pat on the head.

So if a large force has been there 29 seconds, and a small force comes in to join them, they may still all retreat within a few seconds due to the average. This is because _part_ of the force retreating would go beyond intentional-stupid.

Thanks to BadgerBadger and others for reminding us that insta-retreat is less fun for the meatbags.

Fixed a bug where various AI distances (like the distance a ship would wait away from the target wormhole) were basically set to zero.

Thanks to BadgerBadger for the report leading to this discovery.

AI ships waiting against a planet now wait in the vicinity of their current planet's controller, rather than the vicinity of the target wormhole.

Thanks to BadgerBadger for inspiring this change.

Rewrote the logic for selecting which planet an AI threat force retreats to; previously it was just a mode of the "send threat on raid" logic, which prioritized the ease of being at the destination over the ease of getting there.

Now it broadly prefers neighbors with a favorable ratio of friendly forces to hostile forces.

And other than that, it picks the wormhole closest to the average center of the AI force.

This means that some ships will likely bypass easier escape routes, but it's better to take the risk of higher losses in exchange for avoiding the certainty of a divided force that can be more easily defeated in detail later.

Note that this is all in external logic, so if a modder wants to make an AI type whose ships always retreat to the nearest wormhole, that's quite doable.

Thanks to BadgerBadger for suggesting.

When considering where to send Threat Raids, and when to actually commit to an attack (that is, when to stop the wait-before-entering-wormhole order), the AI now considers nearby unengaged hostile mobile strength in a manner similar to AIWC:

It's "nearby" if it's within 3 hops. The threat-raid logic considers such strength less the further out it is.

It's "unengaged" if it is not matched by strength on its planet that is hostile to it. So if there's a 2000-strong human fleet on a planet that still has an 1000-strong AI force (mobile or static), that fleet only contributes 1000 strength to this calculation.

It's "mobile" if it can go through wormholes.

Note for modders: these numbers are accessible like TotalStrength, MobileStrength, etc, but as an array where UnengagedMobileStrengthByHopCount[0] is what's on that planet, UnengagedMobileStrengthByHopCount[1] is what's on that planet's immediate neighbors, and so on up to index 3 (nothing further out is tracked). You can also get these numbers for Friendly, Neutral, or Self strength this way, if that's helpful to you.

Thanks to tadrinth for the suggestion.

Fixed a longstanding bug where the "Standard" eligibility filter, that's supposed to be a combination of "AIP is high enough to use this Mark Level", "This design does not need to be unlocked, or the AI has already unlocked it", and "The player has not corruption-hacked this design" was, instead... none of those. It just let it use whatever. Whoops.

Thanks to BadgerBadger for bringing this to our attention again.

Basic Behavior AI Improvements

Now when doing galaxy-map pathfinding for units:

The game generates two paths:

The normal one that prioritizes minimum number of hops.

A conservative one that prioritizes minimum danger from the AI.

Note: a planet with more friendly strength than AI strength is considered safe.

If the conservative path has the same number of hops as the normal one, it's used instead of the normal one.

If you want your ships to avoid pathing through a planet even though it means more hops to get from planet A to planet B, use the "do not path through here" standing order for that planet.

Thanks to BadgerBadger for suggesting.

Made several changes to targeting, shooting, and damage logic to make units fight more efficiently:

Like AIWC, AIW2 now tracks the amount of damage a unit expects to take from all the shots "in the air" heading at it.

When that expected damage amount is beyond 20% overkill, ships start refusing to target that unit, and ships already targeting it stop firing at it.

If the firing ship was in the middle of a salvo, it gets a proportional refund on its reload timer.

So it will generally still only fire on the one unit, but it will reload and get to find and attack another target sooner (potentially the very next frame).

All weapons now have the flag that lets them kill multiple ships in a squad in one shot; this may or may not be permanently necessary but for now it's very helpful in keeping the math tractable for efficient fighting.

Interface Improvements

The V key now toggles Pursue mode, since the UI button for pursue is now behind an extra keypress.

Thanks to BadgerBadger for the suggestion.

Now when you're placing a structure, if that structure has a weapon range or a tractor range it is shown as a ring around the placement point.

Thanks to DarkArchon for reminding us of this AIWC feature.

Balance Improvements

Tachyon emitters (decloaking) are now about 10x as powerful, meaning that you'll rapidly decloak AI attackers against you, but large cloaked attacks are still dangerous because it takes time to get through them all.

Thanks to FalseMyrmidon for reminding us that decloaking didn't really seem to happen.

Power costs have been roughly halved, to make it easier to defend yourself while we sort out a better long-term design for how you increase your power income.

Thanks to DarkArchon and many others for feedback on this.

Changed the higher ships-per-cap and rates-of-fire to not be quite so high, due to a bug where the most extreme cases (laser gatlings, etc) were calculating to do less than 1 damage per shot and thus rounded to zero, and couldn't even fire or be considered military ships for the M key, etc.

Thanks to BadgerBadger for the report leading to this discovery.

Moved the data of how many ships-per-squad (and the visual formation of how to arrange them in a squad) from GameEntity to the Granularity entry, and added a few Granularity entries to account for different formations of the same number of ships.

It's now much easier to directly adjust the number of squads per cap (for instance, if you want bombers to have 20 squads of 5 instead of 10 squads of 10, you change ships per squad of the MildLowCap entry from 10 to 5).

Version 0.606 Input-astrophe

(Released November 15th, 2017)

Moved the sidebar another step towards the AIWC sidebar by having ships of different mark levels (but the same base type) stack in the same cell.

Accordingly, the mark level is no longer shown on the sidebar (as in AIWC).

Incorporated a feature from BadgerBadger where the wave countdowns are no longer projections based on the current AIP and stored wave budget, etc, but are instead announced times of arrival as they were in AIWC.

Which, of course, involved changing the underlying wave logic from "spawn instantly as soon as you have the budget" to a much more AIWC-like "when you have the budget, schedule a wave".

Yes, all of that was handled by modding.

Thanks, Badger!

Incorporated some fixes to when-loading-savegame nanocaust bugs, from BadgerBadger.

Thanks, Badger!

Fixed a since-forever bug where every time you ran the application it would create a new "profile", leading to the profile/ and profile/backup/ directory getting pretty insane.

Now it will do a one-time clearing of those directories (nothing particularly important to the testing phase was kept there).

And create a single profile that it will properly remember and load each time you start the application.

The ability to create an alternate profile and choose between them is something for later.

Keyboard Input Improvements

The inputmappings.dat file now supports an arbitrary number of alternate mappings per bind; useful if you (for example) want to have Equals, Plus (usually shift+Equals), and KeypadPlus all increase gamespeed.

Thanks to lessster for inspiring this change.

The following default alternate bindings have been added:

Pause (P) now responds to the Pause/Break key as well.

Thanks to FalseMyrmidon for reminding us of this one.

Increase game speed (Equals) now responds to Plus and KeypadPlus as well.

Decrease game speed (Minus) now responds to KeypadMinus as well.

The key for opening the context menu (0) now responds to BackQuote as well.

The console used to respond to that a while ago, but the default for that has been F3 for a while.

Thanks to FalseMyrmidon for the suggestion.

Fixed a bug from the bottom-bar-extinction where pressing T would not succeed in opening the Tech menu.

Thanks to BadgerBadger for reporting.

Fixed a bug where spinning between builders with the B key would result in the selected build-tab not changing even though the newly selected builder did not _have_ that same tab.

Thanks to BadgerBadger for reporting.

Now the unit-command context menu no longer automatically opens when you have a selection.

Instead you have to open it the same way you open the top-level context menu when you don't have a selection (namely pressing 0, BackQuote, or clicking the visual button in the bottom-left corner).

The effect is that now the context menu handling of number keys will now never interfere with control-group selection keys unless you deliberately open the context menu.

Thanks to FalseMyrmidon, Draco18s, and others for inspiring this change.

The open-system-menu keybind (default Escape) now directly opens the Save/Load/Settings/Etc menu, instead of just the top-level context menu.

Fixed some issues that were preventing assignment to a new control group by pressing Ctrl+(group number).

Thanks to FalseMyrmidon and others for reporting.

Mouse Input Improvements

Fixed a regression introduced in 0.603 where you could no longer hover over or click icons in the main game view. It was still letting you click ships or band-select icons and ships, but directly clicking one icon (or hovering over it) was out.

Now when bandbox selecting, if there are both mobile military units (includes the Ark) and non mobile military units, only the mobile military units will be selected.

When holding shift to add to the current selection, if there are any _unselected_ mobile military units to add then only they will be added. If there are none of those, non-mobile-military units will be considered.

Thanks to FalseMyrmidon and many others for reminding us of this feature from AIWC.

Clicking a planet on the galaxy map now immediately switches the view to that planet, rather than only selecting it (and switching the view on the second click).

If you want to simply select the planet (useful for setting standing orders, etc), you can do so by holding alt and left-clicking the planet.

Thanks to DarkArchon, Draco18s, and BadgerBadger for inspiring this change.

Camera System Upgrades

Rather than simply having different zoom modes for the cameras, the game now has full-out different camera code that is possible to execute. This way we were able to completely recode the cameras for the galaxy map and main planetary view from scratch, as we wanted. And modders can make their own cameras, too, for that matter -- these can be chosen-between using dropdowns in settings, for the galaxy map and planetary screen separately.

The original intent here was to just ditch 100% of the old code and start fresh... but then as we started thinking about that, we realized that someone was going to have some nature of complaint about that, most likely. So instead we've spent a while porting the old system into the new structure, and so the old methods of camera control are "gone" in a global sense, but "still there in their entirety" in the sense that their exact same feel and code and values is now a pair of sub-options in the new camera system.

That took substantially more time than expected, but we figure it's a good starting point for some variants of camera controls that someone might want to cook up someday, who knows. Our own replacement camera systems aren't based on the old code at all, and you can tell that in the feel of them.

Thanks to a variety of users, most notably DarkArchon, BadgerBadger, and Otagon, for inspiring these changes.

Fixed a variety of bugs with the middle-mouse-drag-panning in the old camera system.

First of all, it now doesn't halt your dragging when you get over top of a GUI element.

Secondly, it no longer uses the acceleration/deceleration that people didn't like, and how far it moves is no longer increasingly-intense when you're zoomed in.

Something about this still doesn't feel right, but it's not part of the control scheme that we ourselves make use of, so it's something that an enterprising modder may want to tweak around with. It's in UpdateMouseDragControl in OldStyleCameraBase.cs in the external visualization code project, under the Cameras subfolder.

Thanks to BadgerBadger for inspiring these changes.

The default old-style cameras are able to zoom out a bit further than before, to ensure that you can always see the entire galaxy map at once with them.

Thanks to Cyborg for reporting.

Holding down the shift key now also speeds up the zoom in and out process in the free-look camera and the new camera modes.

Note that this already was something that speeds up the actual movement of the camera in any mode. Something like the Ctrl or Alt key will conversely let you slow down the camera for more precise positioning.

Free-look Camera

Added a new free-look camera for both the galaxy map view and the planetary view.

In this mode, the usual camera controls are completely disabled, however all the stuff like doing drag-selection and giving ships orders and so forth remain in place.

You can toggle in and out of this mode via caps lock (by default) or an in-game menu button.

In this mode, WASD moves you forward, backward, and left/right in a first-person-shooter style. Q and E move you down and up, as in the unity editor. Holding shift makes you move faster.

In this mode, by default the camera does not turn with the mouse (unlike an FPS game), since that would make it pretty fundamentally useless for anything other than sightseeing. Instead when you hold whatever you have the "pan with mouse" button set to (by default it's middle mouse held down), then it acts like an FPS game, although your mouse cursor does remain visible and functional.

This mode is implemented as a form of add-on that is tacked onto the existing camera control modes. This is something that lets us have this mode be consistent across all of the camera modes, OR lets a specific camera mode implement a variant (or wholesale replacement) of this, at their discretion. For now we're opting for consistency.

This was something a number of players have asked about since early in the kickstarter, and which we've finally put in. It helps remove the need for the camera to automatically start bending horizontally as you get it lower toward the playing field, since now you have control of that yourself. And it also helps avoid that frustration of not really being able to get juuust the right view so you can see some ship (either by getting close enough or far enough away or just high enough).

The free-look camera mode now includes an edge-rotation ability where it will slowly rotate your viewport when you put your mouse at the screen edges, like other rts games (or the other mode of the cameras here) do for panning. You can turn this on and off in the settings independently of the edge-panning in the other mode.

In free-look mode, you can now use the zoom in/out keyboard buttons the same way as W and S.

Additionally, using the mouse wheel to zoom in and out also now works in this mode, and snaps immediately between increments. The other types of movement are all smooth, but this one just snaps immediately, which is kind of satisfying and definitely useful.

The amount that this moves per click of the mouse wheel can now be set in the settings menu as well, again independently of the other camera modes.

The free-look camera is now clamped in its up and down angles to some reasonable values (80 degrees down, 40 degrees up) so that you can't accidentally spin yourself way out of seeing things properly, or put yourself into an inverted view. These values can of course be adjusted by modders, but it's an extremely forgiving range already for a game of this type.

The "zoom toward mouse cursor" now works in free-look mode for when you are using the mouse wheel or the keyboard zoom. The keyboard zoom now has its own speed setting for in freelook mode, and is based on that rather than the normal WASD movement speeds of freelook mode.

The free look camera is now constrained to a rectangular box area around the planet or galaxy (in whichever case) so that things can't drift super duper far off into the ether.

New Camera Types

A new camera type has been added that is "free-look only," and which basically is just the usual free-look mode available in all other modes, but without any potential of switching to some other mode, or any need to switch out of free-look mode. This may be welcome for folks who like a Homeworld-like feel (kinda-sorta), and it was something that was surprisingly pleasing to Chris to play in, despite his not normally being a fan of that style. So here we are, it's an option for anyone who wants it, the first to join the old two camera types.

A brand new "top down" camera mode has been added, based in part on the code from the new free-roaming camera mode (which you can toggle into from the top-down mode as with any other mode).

This mode has no acceleration/deceleration on its movements, and thus things feel snappy and immediate.

The grab-and-pan logic here feels exactly like you'd expect to, and much more like AIW Classic.

The edge panning and grab panning are both contextually stronger or weaker based on your zoom level.

And in general there should just be much happiness here. Note that the viewport never bends forward in a cinematic way or anything like that -- if you want that sort of view, then hit caps lock to go into free-look mode, and then you have way more freedom than ever before.

Another new camera mode, simply called Angled, is now in place. This one is based generally on the top-down camera, but instead it has the view at a 45 degree down-angle.

This causes some "interesting" edge cases with zoom and movement, but we think we have all of those handled at this point.

This is set as the default for the main game view for now, since it gives a more cinematic view of the battlefield, and something that feels more modern, as well as able to have more information on the screen at once (thanks to depth) without having to zoom out a ton.

That said, we figure modders may want to hack at it some and see if there are any tweaks that people prefer in general.

And right now the galaxy map is defaulting to the top-down view, although arguably it benefits just as much from this view as the planetary view does. You can change that in the settings window, as with any of the modes.

We're probably done with tuning these things ourselves for the next little while, but if people don't like this one we can change the default for the time being if there aren't tweaks that someone else wants to suggest for the algorithms or numbers. All of that is in the Angled.cs class in the Cameras folder of the external code visualization project.

Player Budget Policies

Added the "MetalBudgetPolicy" XML table, which encapsulates logic about player metal expenditure previously contained in the core code.

In the top-level context menu, added new option "Policy"

Which in turn opens a new menu with currently one option: "Budget"

Which in turn opens a new menu with one option for each row in that new MetalBudgetPolicy table.

Triggering one of those options sets your faction's metal budget policy to that one.

Currently defined policies:

Spend Freely

The normal behavior you're used to.

Stockpile (1/3)

Does not allow spending that would bring your metal stockpile below 1/3 of your maximum storage.

Stockpile (2/3)

Same as previous, but it aims for 2/3 instead.

The actual percentages are easily tweakable in the xml; both use the same underlying C# class.

Battle Support

This is a bit gratuitously specific, and is partly just a demonstration of what modders can do with this feature, but it will probably be useful in situations where you're running out of metal in the middle of a battle.

Prioritizes repairs and squad-replacements for units that are on a "contested" planet.

"contested" = "local hostile strength is at least 10% of local friendly strength"

"prioritizes" = "these get first dibs on the metal; if there's not enough for them then nothing else gets any"

Next, prioritizes build queues that are rallying to a contested planet (or that don't rally and are _on_ a contested planet); similar with self-building (turrets) and rebuilding-remains that are on a contested planet.

Next, if there's a small (5% of storage-cap) reserve of metal left, does anything that's left _except_ claim capturables that cost a ton (golems).

Finally, if there's still that metal reserve left, works on the golems.

When using a budget policy with a reserve amount, and your projects are going at less than 100% progress because of that, your metal stockpile is displayed in red.

Version 0.604 Hotfix

(Released November 11th, 2017)

Incorporated some changes from community member BadgerBadger:

Descriptions for various units.

Fixed galaxy-map-display-mode tags for various units.

Display of which planets are under the influence of the Nanocaust.

Thanks, Badger!

Fixed a bug where the remains of turrets/etc still counted in strength computations, granting human vision, etc.

Thanks to BadgerBadger for the report leading to this discovery.

Turret/etc remains now draw in a much more grayed-out color in the main display.

Turret/etc remains now no longer show in the sidebar.

Now when you have multiple claimable units at once, the cheaper ones are reclaimed first, to avoid a golem stalling capture of a planet's resources.

Thanks to BadgerBadger for inspiring this change.

The game now aggressively assassinates the "Screenmanager Is Fullscreen mode" key in the unity-generated player "prefs" file, since if it's set to true it makes it impossible to click buttons on some platforms, and the game's own settings file is where we actually store the info on whether to open in fullscreen mode (in a way that doesn't kill button-clicking).

Thanks to lessster and RabidSanity for their reports and thorough research.

Version 0.603 Banishment of the Bottom Bar

(Released November 9th, 2017)

Fixed a bug where setting a planet to do-not-path-through would make it basically impossible to give galaxy map orders to units on that planet.

Thanks to jmuzz for reporting.

Fixed an apparently longstanding bug where the particle effects were not showing up at their proper locations for explosions due to the particle effects being activated before being moved to the right spot (gotta do that the other way around!).

UI Upheaval

The sidebar now includes a section at the top with all of your defined control groups, similar to how AIWC handled it.

The control group buttons along the bottom of the screen are gone. They still respond to the same number keys, and you can click their cells in the sidebar to select them.

The menu button that was at the right end of that is now in the left-hand corner.

Added a visible button for switching between Planet View and Galaxy View, just to the right of the "Menu" button's new location.

The bottom-bar arrangement of various menus is gone.

Instead the "Menu" button (now in the bottom-left corner) opens its commands in a vertical list just above it.

Similarly, when you have a selection, the relevant commands show in that space.

And now when you enter a nested menu under that it just shows the most-nested one, rather than trying to show all of them at once.

The "Menu" button will change its text to point up at the list of items, and to say the name of that current menu.

The unit and planet hover-tooltips now show in the upper-left corner just under the top-bar, so that they don't overlap with the build menu or context menu.

The game version stamp continues its lap around the screen and is now displayed just to the left of the unmovable "development mode" stamp in the bottom-right corner.

There's now a brief description of your current selection (and whether it is a control group or just an ad-hoc selection) now appears above the bottom-left context menu, since the commands that will appear just below it pertain to that selection.

When on the galaxy map, two additional buttons now appear to the right of the button that toggles between galaxy-view and planet-view:

"Display Mode", which shows the name of the display currently being used, and clicking it toggles a list of available display modes above this button (clicking those switches the view).

"Find Planet", which opens BadgerBadger's Find Planet screen.

The "Galaxy" menu has been removed from the top-level context menu that pops up in the bottom-left, since its functions are now available on the "surface" in galaxy-view.

The "Debug" menu has been moved from the top-level context menu to the system menu, so it's more out of the way.

The build menu is no longer opened from the context menu; there's no button there for it anymore and instead it just always shows when your selection allows for build commands.

It also always shows any item that you could build if you unlocked it, with the exception of bonus ship types you haven't gotten the first mark of. Those locked items are shown dimmed out.

It also no longer tries to take number-key input, and so appears in a more AIWC-like fashion with the tabs, cells, and queue all showing at once without you first having to select a tab.

Your selection now triggers the build menu even if it has non-builders or multiple distinct types of builder; but it only applies to the first builder type encountered.

Better handling of the multi-builder-type case would be good, but needs to wait for now.

There's now a "Hide Build Menu" button at the bottom of the screen when you have a builder in your selection.

Clicking it hides the build menu, obviously, and switches it to a "Show Build Menu" button.

The build menu can take up a fairly large area of your screen, hence this toggle, but the build menu defaults to shown.

The Tech menu, while still toggled on and off from the top-level context menu, is now more separated and no longer tries to take number-key input, and so appears in a more AIWC-like fashion.

The Objectives menu is now handled much like the Tech menu: still toggled from the top-level context menu, but visually separated into the larger, central zone also used by the Build and Tech menus.

Opening the Objectives menu closes the Tech menu, and vice versa. Neither can be opened at the same time as the Build menu as the latter requires a selection (which causes the menus to be different).

Major New Moddable Area: "Visual Sim Layer"

A super major overhaul of how the "visual simulation layer" code is structured has been undertaken, moving the vast majority of it into external (moddable) dlls.

This allows for the same kind of modding control that people have enjoyed for things like the AI, map types, the GUI, and so forth.

Specifically, this gives control over where and how ships and squads render, how special effects render and are triggered, if things like material swaps happen when ships are dying, if a ship is taken out of a squad and then spirals loose for a while before exploding, and that sort of thing.

None of this stuff has any effect on the actual gameplay, but it can have a big impact on how clear and polished the actual game feels when you're looking at ships.

Not only does this make things moddable, but it also makes it quicker for us to make changes since the compilation turnaround time is quicker now.

This does add a THIRD layer of indirection on the visual simulation layer, which is frankly insane in a lot of respects, but that's what you get when you have a modding layer of indirection on a framerate-indpendent approximation visual display of an underlying secondary-thread coarse simulation, and that general approximation already has a layer of indirection thanks to being shuffled to a secondary source-locked dll (whew that was a mouthful).

Anyway, so the use case for this is pretty insane, and the code slightly reflects that, though most of the complexity is hidden from anyone who might do modding.

Speaking of, Chris partly implemented some stuff relating to the following, but it doesn't quite work yet (doesn't show anything at all). If someone wants to poke at it, then that would speed some things along. The bits to look at are:

Another example of the sort of thing this lets people do is change how ships come into being -- if they are "fired" from their producer to the squad they are in, for instance, as our early concepts went (but were never implemented). A variety of things we might not have time for are things that other people can experiment around with as much as they care to.

The AIWarExternalVisualizationCode project now has a reference to our ArcenAIW2ThirdParty dll, which allows more code to be moved into it.

When there is some sort of other error that happens when the game is launching, it no longer has a ton of "multiple audio listener" warnings logged like crazy, clogging up the logs from seeing the root issue.

Alloy Physical Shader Framework

The amazing Alloy Physical Shader Framework has gone free and open source!

This is something we've used in other projects for quite a while now, but since it wasn't something we could let modders use or make freely available until now, we weren't using it here.

Well... now that's all changed, and we're able to have -- yet again -- higher-fidelity graphics at not much extra performance cost.

These shaders are slightly more complex and thus require a bit more computation on the GPU, but it's not something any GPU that meets the rest of our system requirements would care about at all. In terms of the actual cost to VRAM and RAM, the usage is identical, since everything is packed into very efficient material maps.

This was a very surprising development and something we're really excited about, since it lets us give you better visual fidelity along the lines of what we see in Substance Painter when we're doing our work there.

Version 0.602 Nice Sidebar You've Got There

(Released November 6th, 2017)

Put in a small change to the height of the title field on the tooltip, to hopefully solve the "no title visible" error that people have been sometimes seeing. It was probably a GUI scaling thing with the fact that overflow is set to ellipsis rather than just allowing the overflow, but for now we just made the field bigger.

Thanks to BadgerBadger for reporting.

Dramatically improved the lighting quality by blending in a mix of realtime global illumination from a great HDRI light source (IBL, basically), mixed with a bit less stark lighting from the actual directional light we have.

For anyone who was watching the video of our work in Substance Painter and noted how the downgrade happened to the visuals when we moved the same model into Unity, this fixes the bulk of that even without moving to more complicated shaders.

Ambient light sources are cheap on the GPU, as is the single shadowless directional light, so we're firmly off to the races in that regard. :)

Moved the various "try to spend (wave/reinforcement/etc) budget" implementations to external code. Only the AI faction actually implements these, but it's possible to have another faction do so, and either way it's useful to be able to see/modify the AI's implementations.

Fixed a bug where the AI was always getting the tutorial-specific AI type (that didn't send waves or do much else aggressively).

Thanks to BadgerBadger for reporting.

The Zenith Dyson Sphere is now the Zenith Badger Sphere... ok, not actually renamed, but community member BadgerBadger has largely rewritten its logic to behave more like AIWC's dyson faction.

Thanks, Badger!

Added built-in way to track which planets are under the "influence" of a faction (like the Nanocaust) without that faction actually owning the planet's controller. The Controlling faction and the Influencing faction need not be the same.

The Dyson is now considered to have influence over its home planet.

It has also switched from a blue-variant to red, to distinguish it from the normal AI blue-ish color. Maybe it just got angry.

The galaxy map logic for name display now:

Again shows in the pre-game lobby (but without mark levels).

Never shows the owner in parentheses (relies on color of text for that).

Uses the color of the "influence" faction, if there is one, rather than the owner.

The Galaxy display modes now just ask for text for each planet's name-text and low-text, rather than also getting a color, since the color can be achieved more satisfactory by embedding color tags in the text itself.

Fixed bug where adding other factions and changing what faction was in a slot would cause those factions to have the color of whatever faction was originally in that slot.

This was due to support added in preparation for picking colors in the lobby, but since that support isn't there yet (having proper indicators of what color you were selecting is a bit tricky) it now just uses whatever the "normal" color is for that faction.

Thanks to BadgerBadger for reporting.

The control group "Behavior" menu now has a third option: "Build Policy", which currently has four options:

None

Behave normally; if a queue is already populated (including by a policy) it will not be removed.

Everything

All constructors in this group will queue up 1 of every ship type they can build.

This is updated roughly once a second, so it will pick up on new ships you unlock and anything else that changes the list of buildable types.

Long Range First

Like Everything, but if any of the buildable types have longer range than the others, it only builds from the longest-range available (until the cap is full or something else prevents building more of them, then it moves to the next-longest range group, etc).

Cheap First

Like Long Range First, but instead of preferring longer-range stuff, it prefers stuff that is costs the least metal per squad.

It's pretty easy to add more via C# modding, just look for the "BuildQueuePolicy_Everything" class as an example.

Now that the build queue policies are available, your Ark no longer begins the game producing all three triangle ships. You can quickly get it to do so by clicking the Ark's control group, followed by "Behavior", followed by "Build Policy", followed by "Everything"; or use the number keys corresponding to those buttons.

Incorporated a bunch more improvements to Badger's Nanocaust faction.

Thanks, Badger!

Our old-style way of handling LOD2 and LOD3 has been simplified, and now a single material is used no matter what the LOD is.

In the short term this will mean that some ships will look odd-colored at a distance, so please bear with us on that as we update those ship meshes.

For now we've corrected the Fighter and the Space Dock. Most of the Really Big Ships already won't need correcting on this, since they rarely had an LOD2 or higher.

All vestiges of the "flame trails" stuff has been removed from the game.

This is a major performance improvement compared to rendering the flame trails from ships (which did look cool, unfortunately), and even with them just being disabled but still present this is actually a pretty decent performance bump because of the lack of processing that has to be done for their transforms as ships move around. It adds up.

This was a cool thing that we showed in all our kickstarter videos with the ships having neat contrails, and unfortunately when brought to scale the performance was surprisingly worse than we expected. So we're going with cool static formations, instead.

Fixed a bug where increasing the speed beyond the point that your computer could simulate, and then decreasing back to a normal speed, would continue to make the clock "run fast" for an additional period of time proportional to how long you had run at the higher requested-frequency.

Thanks to BadgerBadger for reporting.

Added warning messages if a long-range-planning thread takes longer than 10 seconds, since some parts of the game cannot proceed until the long-range-planning phase concludes. For example, the "quit game" process needs to wait until the current planning is done to avoid the planning thread crashing into a bunch of null exceptions as the gamestate is dismantled.

Thanks to BadgerBadger for bringing the need to our attention.

Fixed a bug where the game would try to handle the bottom-bar number keys after quitting a game, leading to various exceptions.

Thanks to BadgerBadger for reporting.

Fixed up the dropdowns so there are never any cases where they don't draw their current selection in their main box just because the text doesn't fit.

The ability to set either a target framerate (ideally 120) or a vsync option is now in place in the settings. It now defaults to 120 target fps, although has an option for "unlocked," which is the previous default.

This prevents people's computers from running their fans on overdrive when they were getting like 400fps previously.

Thanks to a bunch of people for suggesting this. Over and over. And over. ;)

Improved the main menu so that it has a cool scene of a ship floating there with the logos on the side of it and bits of dust and lighting flying past. We'll make that even cooler in the future, likely, but at any rate it's much better than the old scene with just the logo showing up blandly there.

Thanks to Cyborg for suggesting we look at this general thing.

Revised (Effective) Grav Well Scale

All ships are now about 75% the size they were, to make the space on a planet less tactically cramped, because the actual "size" of a planetary grav well is so much smaller than it was in AIWC.

You can still get them to look about the same if you zoom in a bit further, if you're going for a screenshot or something like that.

We'll likely mess with the camera some later on so you can really see them better in a variety of ways, too. Right now it's all about the relative size to the grav well, and the camera can kind of do whatever.

The ship definitions can now be set to scales other than 1,1,1 in the asset bundles, and they will properly show up at those other scales in the game itself.

As mentioned in a recent video, we're moving to a system of having only a single actual model and texture for each of the 5-mark ships like guardians that previously had 5 unique models and textures. This saves a lot of VRAM and RAM, and allows for us to put more polish work into each ship.

This does mean throwing out a lot of past work by Blue and Cinth, which is definitely painful, but we've all agreed that looking forward this is the best choice at this point. We are still scaling those ships up or down based on mark levels, though, so the effect is quite similar in the end. Go figure!

Revised Sidebar

Abandoned the sidebar experiment in favor of doing something very much like AIWC's sidebar:

Rather than squares, the cells are now rectangles that are taller than they are wide.

The little white "tick marks" along the right edge are gone, and instead there's an actual number shown in the bottom of each cell.

Also, it no longer uses multiple cells to represent types with more than a max number of units present (formerly 17).

The firing/fired-upon/shielded/cloaked indicators along the left side of each icon are now gone, since they were really only useful when each icon only represented one (or maybe a few) units.

The sidebar itself is now positioned on the right side of the screen, instead of the left.

The version and display and the ongoing message display (only used in the tutorial, so far) are now on the left, to not conflict with the sidebar.

The sidebar itself is now a bit wider, to match the width of the summary text (that gives you total number of squads and total strength per section), allowing more to be shown in fewer rows.

The sidebar icons are no longer colored based on Me/Enemy/Ally (which was irrespective of the actual team colors), but based on the owning team color.

Thanks to Cyborg for suggesting.

All of the prior logic for how the colors for icons were set has been removed. Previously it was based around hue, saturation, and value; now it is based around diffuse color math instead.

This allows for vastly-simpler hex-code definition of team colors (so anyone can add colors with ease).

It's also more efficient as a shader on your GPU, not that most GPUs probably notice the different.

And it's also something that allows us to make the visual colors between the in-game floating icons and the hud icons match exactly, since they can share diffuse multiplication but can't share fancy shader math.

There's basically no downside, although when we originally set out to do the HSV approach we had thought that the ability to have highlights in the icons would be useful (and then we never actually used that at all).

Thanks to Cyborg for inspiring this change.

Added a couple more player colors, just for the heck of it since it's now so easy.

Fixed a bug in our hex-code parsing math for hex colors that was leading all of our colors to be too bright and faded. Now the colors as specified in xml actually come into the shaders with the same rgb values; previously they were being offset up in the brightness range.

Version 0.601 Grumpy Ark

(Released November 2nd, 2017)

The game now supports having different types of "zoom handlers" for the galaxy map and main planet view. These can now be chosen in the settings menu from a dropdown.

It's also possible for modders to create new ones, and we've got two in there by default at the moment.

The default for the planet view has changed to the "Deep Angles" (formerly "ChrisAlternateScrollHandler"), whereas the default for the galaxy map is remaining "Flat Strategic" for now.

Thanks to Cyborg and BadgerBadger for suggesting.

All 36 of the spacescape backdrops are now substantially darker and less saturated, leading to a much more muted and serious look to the game.

Thanks to Cyborg in particular, but also to an extent Badger, for bringing this up.

Moved the main AI planning logic into external code (SpecialFaction_AI.DoLongRangePlanning)

There's not a ton here, as much of the logic is handled at different levels, but there's various core things like "make this threat wait until it has a critical mass", "release this waiting threat because it has a critical mass", "make these guards abandon posts in face of overwhelming assault", etc.

In the process, fixed some bugs where this logic was applying to various other non-AI, non-player faction ships.

Thanks to BadgerBadger for reporting those bugs.

Removed the concept of the "world" object having a "master AI type", since individual AI factions can now have their own AI type.

There's still only the one such faction, but this was an important step in preparing for multiple ones.

The main piece that had to be moved here was the concept of what ships an AI has unlocked from AIP points. Used to be game-wide, is now faction-specific.

For now design-corruption is also now faction specific, but there will likely be a way added to make the corruption "spread" so that you get the same effect as in AIWC: once it's corrupted, no more of that design get spawned.

Thanks to BadgerBadger for reporting some strange side effects of still having the master-type after adding the per-faction types.

The Timing menu has been removed, and its functions are now performed simply by:

P already toggled pause.

Equals (plus) now increases frame frequency (the way AIWC sped things up, more or less)

Minus now decreases frame frequency.

Ctrl+Equals (ctrl+plus) now increases the frame size (a different way that is more effective but makes the sim more coarse).

Ctrl+Minus now decreases the frame size.

Decreasing frame frequency below Normal is now possible, similar to how you could go into "the minus speeds" in AIWC.

Thanks to BadgerBadger for reminding us of that functionality, and its usefulness.

The top row of the "Time" section of the top-bar GUI now says what % speed you have set the frequency to, if it's not 100%. It also uses a different display if you're using the coarse-simulation mode of increasing the frame size.

Fixed a bug where the various "this unit is disabled" reasons were not stopping constructors from building ships. So a dead-and-rebuilding starship constructor would keep pumping out starships during the rebuilding, rather than waiting until after it was done.

Thanks to BadgerBadger for the report and save.

Fixed some race conditions that could cause an error when clicking the start-new-game button on the main menu multiple times in a short period of time (often the multiple press was unintentional).

Thanks to BadgerBadger for reporting.

Fixed some race conditions when quitting the new-game-setup window, where it was discarding the gamestate too hastily. Now it uses the same quit logic as the in-game quit button.

Fixed a bug where ArcenSettingTable.Instance.CopyCurrentValuesToTemp() was not being called before entering the new-game-setup window, which caused all kinds of ruckus when the Generate button was clicked, as that button calls ArcenSettingTable.Instance.CopyTempValuesToCurrent(), since that could lead to a bunch of not-really-values being copied all over your settings.

This made the game hang, and your UI at almost-invisible scale when you next ran the game.

Thanks to Stilgar, BadgerBadger, and others for reporting.

The player's Ark has now been "roughed up" so that it looks more battle-worn and part of the thematic universe here.

UI scaling is now done in increments of 10%, instead of a much more granular number.

Moderate amounts of UI scaling (down to 70%) now correct the size of text inside textboxes to not get the bottom cut off.

A more general solution to this issue will need to wait until some other mysterious bugs are solved.

Version 0.600 Tutorial Engine

(Released October 31st, 2017)

Fixed a problem with the new UI display code where pausing could lead to divide-by-zero errors (since it led to sim steps of zero-game-time).

Thanks to BadgerBadger for reporting.

Fixed a null exception in the Assault targeting logic.

Thanks to BadgerBadger for reporting.

Refactored how the automatic-selection-changes happen (so when you have a control group selected and a new ship is added to that control group, it is also added to your selection, etc) to avoid some race conditions that could cause index-out-of-bounds errors.

Thanks to BadgerBadger for reporting.

Fixed an issue where the "clear"/"none" option for the assign-control-group menu and the assign-rally-group menu was all the way on the right but still whatever number would be next (as opposed to always 0 or 9, etc). Now it just goes on the end of the visible row.

Actual Tutorial! Vol. 1

The main menu button for opening the wiki tutorial page now simply says "Tutorial" and starts a preset 3-planet scenario intended to teach the basics of the game.

De-Uglification, GUI Batch

Added dozens of fonts to the AIW2ModdingAndGUI project, although most are not in use. These are fonts that we've purchased over the years for use in mostly sci-fi titles, though many were never used or were only used with borders or whatnot on them.

The tooltip titles are now using a boldened sci fi font, while the numbers are using a font with a bit better kerning that makes them easier to read, and the description text is using a bit blander of a font that should be easier to read.

This likely won't be the end of the fonts saga (when is it ever), but it certainly moves things in the right direction.

Thanks to Badger for suggesting the font work be done now.

Notably, the fonts for areas OTHER than the tooltips are not altered yet. That's a bigger and more complicated job.

The background image for the tooltips has been completely replaced, as it was very cartoony before and one of the most jarring elements about trying to learn the new game in some ways.

The new version is very dark, rather than having the bluish tinting to it, specifically because we want the graphics on top of the tooltips to have a neutral background, and to really "pop" for the sake of visibility.

The color scheme for the various buttons in the game is also now a graysih color, and they use a "sliced" image effect to give better clarity to the graphics along their edges while keeping an unadorned, nondistracting-from-foreground-content center.

Dropdowns have also now gotten the treatment to where they have the gray/black theme and are less visually distracting.

Textboxes are now in the new GUI style, and have a bit of an extra marker to them making it clearer they are textboxes.

Version 0.528 De-uglification, Part 1

(Released October 21st, 2017)

Some basic ugly-reduction for the Main Menu:

Moved buttons to the bottom of the screen where they no longer overlap the title text.

Reworded some of the buttons so their text fits better and doesn't go to ellipses.

The Debug-connect-to-blah-blah button is now "Join Multiplayer Game" and instead of reading an IP from a file it prompts you for an IP address with a textbox, and clicking the button in that sub-window actually does the connection.

The "Hide GUI" / "Show GUI" button has been removed from the interface. Its function is now achieved through Ctrl+F12.

The version number is still up there in the upper-right corner, but it's much less obtrusive without the hide-gui button there.

Rearranged the game-setup (i.e. "lobby") menu in a less haphazard way.

The "Factions" and "Map Options" are displayed by clicking buttons of those names in a column along the left side. Other sections will be added there, as needed.

The show-map-type-options conduct (and its button) have been hidden, since it was just a UI thing and now that's handled in a different way.

Heavily reorganized the resource bar at the top of the screen to have text fit in its space (leading to ellipses or odd line-wraps, etc).

Also folded the wave warning timer and the "current planet name" display into that, further removing the "loose" data display from early alpha debugging purposes.

Changed font size of bottom bar buttons, and the text of several buttons, to have text fit in its space.

Currently there's a bug where the various menus where you pick from control groups sometimes put the "clear" or "none" option all the way at the right of the screen. Will fix that for next time, just ran out of time for today and wanted to get the rest of this out.

Version 0.527 Factious AI

(Released October 19th, 2017)

More only-useful-to-modders refactoring: removed SetOfGalaxies, since it was just a List<Galaxy>, and put that list directly on World_AIW2.

Fixed a multiplayer-only null reference exception in the UI code for the lobby that made it basically impossible to start a multiplayer game.

Subsequent testing showed that, happily, the sim was still in sync.

Thanks to BadgerBadger and others for reporting.

XML Modding: The "copy_from" syntax which allowed defining GameEntity or EntitySystem as "exactly like this other one, but with these fields changed" is now generally supported for all xml definition files.

The behavior may not be exactly as expected or desired, especially when handling child nodes; if you use it and find the results strange please let us know.

The "draw bags" defined in the XML for the AI to pick units from can now take a "weight" attribute for each item.

This allows, for instance, the new "Sniper" AI type to have a relatively normal set of draw bags with everything _possible_ but sniper units 10 times as _probable_ (and long-range-missile units 5 times as probable).

This applies both to the AI's picks of what to build or spawn, and its picks of which ship types to unlock (at the beginning of the game and later).

So unlike AIWC an AI Type that has an affinity to a specific unit type is not _guaranteed_ to start the game with it, but it is much more likely (and if it doesn't get it straight off, it probably will after a few AIP increases).

New AI Types:

Shield Ninny

Has half the defense budget for turrets and fleet ships, but double the defense budget for shields.

Adopts the "Burlust" school of defense: "If you see anything that resembles enemy, forget you were ever on guard duty and jump into the nearest bar fight". In other words: if you attack one of its planets in any force at all, expect all of its guards to bee-line for you.

Strongly prefers units with short-range weapons.

Gives you a strong advantage in a range duel, but if they get close they're going to do a lot of damage.

The Game Setup window (i.e. Lobby) now has controls for configuring the different factions in the game:

The player ("Human Remnant")

There's nothing you can change here yet. Color, handicap, and that sort of thing will go here.

The AI ("AI Sentinels")

Along with a dropdown for selecting the AI Type.

An "Add New Faction" button that lets you add special factions.

The old on/off toggles for the special factions have been removed.

One button for each Faction you've added

Along with an "X" button next to it to remove it.

The faction button itself is a dropdown where you can pick the type of faction (Devourer, Dyson, Nanocaust, etc).

Nothing else to configure here right now, but this is where stuff like Intensity would go, and there can be more than one such dropdown.

NOTE: the faction config stuff only shows if you don't have the map-type-specific config showing, since they use the same visual area.

NOTE: the dropdowns still have a weird bug where expanding them opens them to about 1-and-a-half rows down from the top, so you can't see all the options at first. This is especially the case when there's not enough options to prompt the appearance of the scrollbar. You can use the scrollbar to get to the first item (even when the scrollbar is not showing, clicking over there and "pulling" down basically works).

We have a fix for this, but it makes all the text in those dropdowns turn into boxes, so we're still looking into that.

Version 0.526 Pay No Attention To The Computer Behind The Curtain

(Released October 13th, 2017)

The "granularity" of a ship type is now simply a literal integer in the xml instead of a multiplier. Multipliers are normally the way to go, but it just wasn't working for situations where we really wanted control over how many ships there were in a cap (starships, notably).

Some code refactoring to help clarity for modders (and us) :

Merged the CombatEncounter sub-object of Planet into Planet, since it was a vestigial distinction from TLF/SR and was fairly inconvenient here.

Renamed WorldSide to Faction and CombatSide to PlanetFaction

The latter is still somewhat awkward, but I couldn't think of an appropriate noun so I just went with the raw "association table" name, since it's literally an association between a Planet and a Faction.

Refactored all the stuff that was referenced by Engine_AIW2.(whatever) to match the pattern used elsewhere of Engine_AIW2.Instance.(whatever)

Version 0.525 Targeting Priorities: So Many Things To Shoot, So Little Time

(Released October 12th, 2017)

Fixed some longstanding issues where issuing commands and doing other selection-related stuff on the galaxy map would only involve units you had selected on your "current" planet. Now they will generally involve any units you have selected anywhere.

Incorporated an addition to Badger's "AI Defenses" galaxy display mode: it now shows the total AI strength on each planet. Thanks, Badger!

Made a further change so that the strength number is color-coded based on how it relates to the strength of your current selection.

For modders: Renamed the GetLocalSide functions on World and Planet.Combat to GetLocalPlayerSide, to be clearer.

Where Pre-Assault prioritizes making it easier for you to physically overrun the enemy, Siege focuses on establishing long-range superiority and then on crippling the enemy's ability to resist further attack.

Specifically it prioritizes enemy snipers, long-range weapons, followed by shields and then medium-range weapons and finally short-range weapons. That may leave a bunch of melee and non-weapon (tractor/grav/etc) stuff until the end.

Defense

Prioritizes enemy units that are very effective against your shields, and then those effective against your undefended (i.e. structural) targets.

Useful for sniping enemy plasma units right as you enter a planet, so your Ark (or other shield generators) can provide effective cover longer into the fight.

Retreat

Prioritizes enemy units that are at least as fast as your group's slowest unit (so turrets are generally ignored), and aims for the fastest ones and the nearest ones first. After that it focuses on anti-shield and anti-structure enemies.

Useful if you're fighting just to keep your fleet alive while moving to a less dangerous position.

Fixed a longstanding bug where saving a game with ships assigned to a control group, and then loading that game back, would result in every single such ship having its own mostly-unrelated copy of the control group.

Incorporated descriptions for many fleet ships and starships from BadgerBadger (many from earlier documentation).

Thanks, Badger!

Incorporated BadgerBadger's fix to make the Armor Ship to actually do engine damage as it was supposed to.

Probably too much, but previously even fairly beefy units just sort of disappeared when not protected by shields, and all but the beefiest shield generators were mostly just bubbles to pop.

Feedback welcome, and you're welcome to test further adjustments yourself by changing the "balance_seconds_per_fight" value in GameData/ExternalConstants/KDL_VanillaConstants.xml

Another iteration on power and fuel costs:

Bonus power from researching a turret-ish tech has been doubled.

Perhaps too much, let us know. We do want it to be worthwhile to spend some science on defense.

Fuel costs adjusted up about 1/3rd of their last adjustment down (which was a halving from the original values).

Version 0.524 Improvement Variety Pack #1

(Released October 7th, 2017)

In the code, renamed SelfStance.Me to SelfStance.Self.

Only matters for modders, but it is helpful for clarity there.

Thanks to BadgerBadger and Draco18s for suggesting.

Added modding support for Galaxy Display Modes to set the text and color for each planet's "name" text and it's "lower" text (which thus far has only been used for showing the current threat strength there).

Thanks to BadgerBadger for suggesting.

Incorporated some UI improvements from community member BadgerBadger:

Fuel tooltip now shows production and consumption (normally you only see the net).

Power tooltip now shows local production and consumption (normally you only see the net).

Warp warning is now red during the last minute before it launches.

Thanks, Badger!

Fixed a bug where opening the build menu with the SelectBuilder keybind would not close other parts of the bottom menu, leading to weird overlaps.

Thanks to BadgerBadger for the report (and finding how to fix the code, for that matter).

Fixed a bug that prevented loading saves where the absolute path has spaces in it, on Windows at least.

Thanks to Burnstreet, RabidSanity, and BadgerBadger for reporting and investigating.

Ships that are cloak-boosted (i.e. by a planetary cloaker) now take much more "cloak damage" from firing their own weapons, if they do not have any cloaking device of their own.

In practice, this means that you still can't see them before you attack, and they'll still get some shots in against you before you can respond, but anything not normally cloaked will be revealed fairly early in the battle.

Thanks to BadgerBadger for inspiring this change.

Now when you give ships an attack order they no longer automatically "fan out" to attack from different angles. That behavior had some aesthetic appeal but it tended to disrupt formations to an annoying (and tactically disadvantageous) degree.

Flagships no longer get their own line in the sidebar.

Waves no longer spawn at warp gates (unless they have no choice) but instead have gone back to the old behavior of spawning at (around) a wormhole on the target planet.

Thanks to RabidSanity and BadgerBadger for suggesting.

Version 0.523 Indefensible Interface

(Released October 6th, 2017)

Moved the logic for placing initial AI defenses, re-placing AI defenses after a successful reconquest, and placing normal over-time AI reinforcements into the AIDefensePlacer concept in the external code project, so you can mod the logic or create alternative logic.

The default AIDefensePlacer set now includes not only variants that place the controller (and main defense ball) further from the center, but also variants that include one or two additional strong points with their own anchored guardians and turrets.

The AI's static defense logic now has separate budgets for turrets and unarmed shield generators.

Incorporated four new map types contributed by community members:

Octopus

Central zone with a number of "arms", planets within the arms interconnect a fair bit, but not much between arms.

Credit to Tadrinth (some work from BadgerBadger)

Simple

Reminiscent of AIWC's Simple map type; just a big blob of planets mostly connected to their nearest neighbors.

Credit to BadgerBadger

Swirl

A bunch of nested ellipses that appear to be on different "planes" or "rotations". Similar to Concentric but with a great optical illusion.

Credit to Draco18s

Density Map

Craziness-level: Velociraptor. This one actually loads a bmp file off disk, detects the different colored zones (different parts of a spiral-arm-galaxy pattern), and seeds planets in each of those zones. The intra-zone connections are then added, followed by a small amount of connections between bordering zones to complete the graph.

Credit to Draco18s.

Incorporated the map-type-specific lobby controls contributed by community member BadgerBadger.

For now this just applies to the two maps contributed by Badger, but the framework is great progress.

Thanks, Badger!

Integrated an improved metal display from community member BadgerBadger.

Thanks, Badger!

Integrated Badger's mouseover tooltips for the resource bar elements.

Thanks, Badger!

Galaxy Map Display Modes (which are moddable) can now determine the color of each of the links between planets.

The default behavior is to show:

Team color between two planets owned by the same side.

Red between two planets owned by different sides hostile to each other.

Green between two planets owned by different sides friendly to each other.

Thanks to BadgerBadger for reminding us of how helpful this kind of thing was in AIWC.

Version 0.522 Variations On A Theme

(Released October 3rd, 2017)

Fixed a bug where the balance_planet_resource_multipliers field of ExternalConstants was required even for partial records (a partial record should let you omit most anything).

Thanks to BadgerBadger for reporting.

Incorporated Badger's updates to the Nanocaust faction (mainly to use the new External Data and External XML Config support).

Thanks Badger!

PRISM post processing and Amplify Bloom are no longer used in this project.

We are instead returning to the unity post-processing stack -- presently their V1 version, but within a month or two we'll shift to V2 as that comes out of beta. Right now the V2 one may have a few linux incompatibilities.

On the subject of bloom:

There's a bit of a flicker in the bloom in the V1 post processing stack that won't be there with the V2 version, but we were getting some crazy smearing in the most recent way we had Amplify set up, anyhow. It was also requiring something like 6 full-screen blits, so really increased the pixel draw capabilities your machine needed to have.

The general attitude toward bloom at the moment is "less is more." We have some shader tuning on individual ships to do, and likely another few rounds of post-processing tuning and color grading work in general to do. But overall, the goal is to have something that looks sophisticated and modern and sleek rather than a carnival riot of happy colors and Tron-style glows.

On the subject of color grading:

We're now doing some color grading in general, which includes tonemapping that shifts the HDR lighting back down into an LDR range.

As a part of this, we've tweaked the contrast a little bit, and also shifted the color warmth to be a bit more in the cool range (just a tad), as well shifting saturation down slightly in a global sense. This doesn't really fully get the job done on color grading, and we're unsure how we feel about the new look (it takes some time away to then look back at it and see for sure; at least a night or a weekend), but this seems to be a positive step toward making this more presentable.

Since we're using unity post-processing, you're also free to go into the modding project and tweak the color grading or come up with your own LUT if you like, and share with us. If you have something that we prefer, we can build it in. Right now there's no way to mod those things directly into the game yourself, but you can see how they look in the test scene in the modding project.

We've also removed an unused tool from the project called Curvy, which we had intended to use for the ships flying in flocking formations.

The problem right now is that those flying animations are just too darn heavy to do on the CPU side. It causes a propagation of events down the unity transform hierarchy and into the physx simulation as well. We could potentially delay and batch the physx syncs as of the upcoming version 2017.3 of unity, but that's still in beta and at any rate that would potentially introduce micro-stutters.

The overall solution that we'd take if we had infinite time on this would probably be to use shader code to translate and rotate the ships as they move on paths that are calculated on the CPU. We had a preliminary version of that working, but it's a super time-intensive thing and isn't something that seemed like a good time investment right now for the project.

Instead we are making an effort to have better formations of ships within their squads, so that they're arranged in interesting fashions that make sense. The craziness of flocking ships is something we can always return to try at some point in the future if it's desired by players, and we have budget from the game selling well, and unity continues to evolve in helpful ways.

Completely revamped how the game tracks summary strength data, i.e. the way each planet knows "how much human strength is on me" and "how much AI threat strength is next door waiting to attack me", etc.

Now instead of being hardcoded as a humans vs AI thing it tracks the information for all sides (including special factions) related to all other sides, and uses the distinctions of Me/Friendly/Neutral/Hostile instead of Human/AI.

The behavior which results from this is still largely the same as before, but some bugs were fixed that were always causing the AI to dogpile you when you attacked, etc.

Wormholes are no longer always placed near the grav-well ring. Instead each planet picks whether to place them in that outer-ring, or in a ring at three other defined distances, or to have each wormhole be at a randomized distance from the middle.

Note that wormholes are still always placed in the direction of the connected planet, which is the key difference from Classic that we were pursuing here.

Added the "AIDefensePlacer" XML table, which for now just determines the placement of the AI controller (and thus the main defense ball). More notably, it allows for different planets to use different algorithms.

Version 0.521 Fuel/Power Rebalance and Custom XML Data

(Released September 18th, 2017)

Incorporated Badger's updates to the Find Planet function, which add the ability to search for the Devourer, Dyson Sphere, Super Terminal, Zenith Trader, or Nanocaust (hub).

Thanks, Badger!

All fuel-consuming units now consume half as much fuel.

You're supposed to bounce back and forth between Fuel being the limiting factor on your fleet, and Science, and in some cases Metal (if you choose only metal-poor planets and/or are careless with your units), but it was mostly Fuel in the previous balance.

Thanks to BadgerBadger for inspiring this change.

Now techs that let you build power-consuming units give a permanent boost to your power production.

Specifically, every 1000 science you spend on these techs gives you +10%, so 2500 total gives +25%, etc.

This allows you to increase your static defense "cap", though planets that have a higher base power production will still be relatively better places to defend.

Thanks to BadgerBadger for inspiring this change.

Added support for modders to add their own custom data to individual xml records in the Configuration folder.

This is not nearly as flexible as the custom data modders can attach to in-game objects (you can only use the bool, Int32, float, FInt, and string types), but that's generally sufficient to work all sorts of havoc.

For example usage, search external code for this comment:

//NOTE: this is not "real" logic, just a demo of how to use custom xml data; it will fire right after you start a new game, if you have the Devourer enabled

Then uncomment the lines immediately underneath and start a new game with the devourer enabled and check the log.

Version 0.520 Formations

(Released September 15th, 2017)

Added Group Behavior button to the commands menu when you have a control group selected.

Under that is a Formation button.

Under that there is a "None" button (for default movement order logic) and one button for each Formation defined in the xml.

Added Formation folder to the GameData directory, and the new Formations are defined here.

And implemented in C# external code.

So the formation author is handed a control group and the point clicked by the move order, and can decide where each ship in the group should actually go, or what they should do instead.

Currently available formations:

Blob

Arranges the group's ships around the biggest shield-generator in the group (or just the strongest unit, if none has shields) in two wedges of concentric arcs, with the shorter-ranged stuff up "front" and the longer ranged stuff in the "back".

This tends to keep more units under shield coverage than the default behavior allows without obsessive micro, and it can look fairly cool, but there are certainly more optimal formations that could be achieved.

Reverse Blob

Just like Blob, but with the fore and aft wedges reversed. Useful if you are executing a Brave-Sir-Robin maneuver because it keeps your short-range stuff closer to the things shooting at you.

Though currently this is only a marginal difference because it's packed in close to your core unit rather than at the extreme edge of the shield (it's arguable which is preferable).

Fixed some longstanding issues where units with move orders would only move "close to" the target point and then stop. It was logic that worked fine in TLF and Starward Rogue, but not so well here, and lead to fast ships zipping back and forth because they never got close "enough".

Marginal reduction in starship caps to make them less individually weak.

Made starship radii better fit their actual model (makes it easier to have groups of them without them decolliding across half the planet)

Now when you have a unit rally to a control group, and the unit reaches the lead unit and cancels its rally command, it now copies the lead unit's orders to itself (so it's more likely to keep up without further explicit orders).

Thanks to BadgerBadger for suggesting.

Version 0.519 Who Thought A Settings Menu Could Cause A Platform-Specific Temporal Paradox?

(Released September 9th, 2017)

Several Guardians now have their Mk 2 - 5 models:

Widow, EMP, Shield, Sniper, and Stealth Guardians have all their models

Two Starships now have their Mk 2 - 5 models:

Carrier and Siege Starships have all their models

Dyson Sphere graphics are now hooked up

Hopefully fixed up OSX and Linux builds to not die/go-crazy as soon as they start.

Thanks to BadgerBadger and Sounds for repeatedly testing fixes.

Intra-update on September 11th: we got it fixed on the OSX thing, finally.

Version 0.518 Active Selections and Capturing the Uncapturable

Incorporated BadgerBadger's updates to the Nanocaust special faction, including the ability for the player to hack the original Nanocaust controller to convert the faction from an enemy-to-all menace to an ally against the AI.

Thanks Badger!

Swapped the Pursue and Control Group command buttons so that Pursue is 1 again.

Thanks to BadgerBadger for suggesting.

Rebuilt all the unity bundles and executables for all platforms, with some settings rolled back to previous values, in hopes of resolving a crash-on-startup bug on OSX.

Fixed longstanding bug where it was generally impossible to claim or repair golems and various other things due to the large metal costs and hp counts causing an arithmetic overflow. Now the math is ordered in such a way as to not overflow.

Thanks to BadgerBadger for the reports and saves.

Control group selections are now "active" or "sticky", in that if you select a control group, and don't manually modify your selection, any new ships that appear on that planet as part of that control group (either through being constructed or coming in via wormhole) are automatically added to your selection.

If you change your selection manually in any way after that point, the stickyness stops.

Reworked the "do I draw the selection ring for this unit?" logic to actively check each visual unit each frame for its selection status, rather than only updating the visual state whenever the interface "selection" state changes. The latter is theoretically sufficient but in practice we wind up with lots of stuff being selected but not showing it after switching planet views, and enemies winding up with selection circles around them apparently due to some kind of object recycling, etc.

Version 0.517 External Data and Group Control

(Released September 7th, 2017)

Added a Control Group button to the commands you see when you have a selection. Clicking it brings up a list of buttons:

One for each control group you already have.

Clicking this adds all your selected units to that group.

And a button for creating a new one, if you have fewer than the max.

Clicking this creates a new group in that slot, and adds all your selected units to it.

And a "None" button.

Clicking this removes all your selected units from whatever groups they are in.

Build queues now default to looping.

Added an "External Data" architecture which allows modders to store and retrieve arbitrary data, and to have that data persist across save/load.

On the following:

The World object

Each PlayerAccount object

You probably won't need to do this, except for UI-related stuff in multiplayer games

Each WorldSide object

This is where you would put faction-specific stuff, including for special factions

Each Planet object

Each GameEntity object

I.e. ships and shots.

For example usage, open the ExternalCode project in visual studio (or monodevelop) and search for "DoomData". There's also a small (but critical) piece in the xml file in GameData/Configuration/ExternalDataPattern/

To actually run that stuff, change DoomData.DoDebugTestingLogic from false to true.

Thanks to BadgerBadger and Draco18s in particular for inspiring this addition.

Fixed a bug that was preventing games from loading properly in the previous version.

Thanks to BadgerBadger for reporting.

Version 0.516 UI Scaling and Rally Commands

(Released September 5th, 2017)

Added a UI Scale slider to the settings menu, so if you find the UI is taking up too much of your screen you can bump that down to something less than one.

Going too far tends to produce buttons where the text doesn't fit properly on it, since the engine scales text by font size and buttons by a scale multiplier. The font sizes obey UI Scale as well, but it's not exactly the same.

Added BadgerBadger's "Set Defaults" button to the settings menu.

Clicking it just sets all the toggles and textboxes and sliders back to their default positions. Clicking save will then actually change your settings to those values, as normal.

Thanks Badger!

Incorporated a small change from BadgerBadger so that starting the game with the first planet already owned also adds a Starship Constructor to your starting units.

Thanks Badger!

The sidebar text that used to show Squad Count and Ship Count now shows Squad Count and Total Strength, since strength is a much more useful number than ship count.

Thanks to BadgerBadger for submitting the code for this.

Units with internal build queues (Starship Constructor, Space Dock, Ark, etc) now have a "Rally" button on their command menu. Clicking it brings up another row of buttons, each corresponding to one of your Control Groups, and one "Clear" button.

Clicking one of the group buttons makes all future units produced by this unit:

Assigned to the target control group

Note: this does not assign the producer to that group, though you can do that separately

Have orders to go find the primary (strongest) unit in that control group, wherever it is in the galaxy.

So if they're not on the same planet, they'll find a path to the primary unit's planet.

And if they're on the same planet, but not near the primary unit, they'll move over to it.

If the primary unit moves to a different location or planet, these rallying units will update their orders to adjust.

Once they get within a short distance of the primary unit, they drop this "rally" behavior and respond normally.

Version 0.515 The Settings Menu Of Doom

(Released September 2nd, 2017)

(0.514 was quickly succeeded by this)

Ships in squad formations now take on the rotation of the transform that is in the squad, allowing us to create formations where all the ships (usually turrets) are not facing the same way.

Fixed bug where the at-mouse tooltip would draw under certain other elements.

Finally added a Settings menu!

As part of this, we pulled most of the game's settings out from hardcoded fields to externally-defined data (in xml).

So if you want to have persistent settings which apply to your mods you can do that, though you'll have to use slightly different functions to get and set the values (GetIntBySetting, SetIntBySetting, etc).

Also as part of this, we implemented a whole new way of populating a UI window with controls, entirely through C#.

XML is still the preferred way for windows with fixed sets of simple controls like the main menu.

Unity prefabs (in the modding-and-gui project) are still the preferred way for windows with really complex nested controls like the Ship Detail Display.

But if you need variable numbers of controls, laid out in a simple way (like a table with columns of different types of controls; more complex than a ButtonSet), this new method is the way to go.

ALSO as part of this, we implemented support for vertical and horizontal sliders.

So the new window looks at all the externally defined settings, and for each one of those adds a row of controls to the window.

There are more settings than there is screen space, so the game's first scrollbar has been added to let you go through the collection.

Added slightly later: dropdowns, for now just one sub-type of dropdown for the fullscreen resolution setting.

There's also support for "hidden" settings of the following types: bool, int, float, FInt (fixed-point non-whole-number for sim math, don't use float in the sim); these don't show on the settings menu but modders can use them to store and retrieve configuration, e.g. for custom map type parameters).

Fixed some issues where keyboard camera movement would not work when the mouse was over certain UI elements.

Fixed a bug where band-box selection was basically broken when the Ship Detail Display was visible.

Thanks to BadgerBadger for reporting.

New squad formations added in!

Version 0.513 Tooltips For Your Tooltips

(Released August 25th, 2017)

The ship detail display now uses the awesome new icons from Blue, and thus has far less text than it did.

The ship detail display now continues to show for 2 seconds after your mouse is no longer over the ship.

When the mouse is within the ship detail display it continues to refresh that 2-second timer.

The individual icons and text elements inside the Ship Detail display now have mouseover tooltips that:

Float just to the right and below the mouse cursor, but don't run off the bottom or right of the screen.

Size to fit the text being displayed, and wrap long lines.

Disappear after about half a second of the mouse cursor not being over something that should cause a tooltip.

The above is just standard behavior that you would presumably expect. Many hours and electrons lost their lives in the war to persuade our engine of this.

The planet tooltip no longer shows at the same time as the ship detail display when mousing over the icon of a unit that shows on the galaxy map.

The planet tooltip will be reworked into another detail display fairly soon, but for now this was necessary to avoid overlap.

The Ship Detail display no longer shows anything in the spaces for Engine Damage Resistance and various other resistances if the unit has the "normal" value for that stat.

Perhaps the empty space is not desirable from a usability standpoint and it would be better to have grayscale versions of the icons for these resistances so you can tell what it is that they don't have. Your thoughts are welcome on the forum :)

Numbers in the Ship Detail display now round to the nearest thousand and show "k" for numbers >=100,000, and to the nearest million and show "m" for numbers >= 100,000,000. So for example "500,000" is written "500k".

The Ship Detail display now shows a % next to the hit point total for either build-progress (for stuff like turrets under construction) or current health (for built stuff that is damaged).

When this is active the display of max health is more aggressively rounded, so at 1000 it rounds by thousands, and at 1000000 it rounds by millions.

Fixed missing-localization error message when claiming a golem or other unit that causes AIP on claim

Version 0.512 Hotfix

(Released August 20th, 2017)

Fixed a bug where the ship-detail tooltip would try to show for a ctrl+mouseover'd wormhole. Also fixed the inner bug where it would barf if somehow applied to an entity with null for mark level.

Thanks to BadgerBadger for reporting.

Set M as the default key for "select all mobile military on this planet".

To properly apply this to existing installs, we added support for the "default_should_override_unbound_user_binding_if_older_than_version" element in the InputAction xml nodes. It will only override your setting the first time you load the game in the new version, and only override it if you had no key defined for that binding before.

Thanks to BadgerBadger for suggesting.

Version 0.511 Unity 2017.1 Upgrade

(Released August 18th, 2017)

Upgraded our version of the unity engine to 2017.1p4, from version 5.6p3.

We had planned to do an upgrade eventually anyhow, but our hand was forced by the security vulnerability UNITY-SEC-844.

Note that this security vulnerability affects developers, not customers, but we felt it was a good idea to go ahead and update as soon as we were informed about it.

If you're modding the game using the unity editor, you'll also need to upgrade to that new version.

Fixed a bug in the prior version of the game that was preventing building the external code dll because of a couple of API changes that we made that were not properly reflected.

Thanks to BadgerBadger for reporting.

Version 0.510 Hotfix

(Released August 15th, 2017)

Put in a variety of small tweaks in the external code library to suppress harmless compiler warnings that nonetheless cluttered up our view (and that of modders) while compiling.

Put in some wrappers for sub images and sub text so that when there's an index out of range exception we no longer have to do a bunch of guesswork; it tells us what index it wanted and what the length was, so our time looping around in instrumentation is a lot lower.

It also now tells you the name of the type of element it is (eg BuildImageButtonBorderless), since that can also be a source of hunting around in the dark.

Previously, there were cases where we had one prefab referencing another prefab inside the modding and gui project. This was convenient!

However, it turns out that when the child prefab is updated, it doesn't flag the parent as also updated, and no amount of fiddling makes it trigger that flag.

That, in turn, means that the child of the parent winds up not being properly sent to players via the build.

To get around that, we're no longer referencing one prefab from another within the asset bundles themselves.

Instead we're creating those linkages in our own prefab xml setup using the new xml tags has_child_prefab, child_prefab_bundle, and child_prefab_filename.

Note that this doesn't have any effect on prefabs like the Dropdown, which reference elements INSIDE their own existing .prefab file. That's perfectly fine. The problem was when one .prefab file was referencing some completely other .prefab file.

This is what was causing the mysterious index out of range exceptions in the prior version.

Thanks to BadgerBadger for reporting.

Version 0.509 Player Targets What?

(Released August 14th, 2017)

You can now programmatically change the font size and spatial offset of text bits on an ArcenUI_ImageButton.

The ability to change color this way was also added recently.

You can now programmatically change the spatial offset and size of image bits on an ArcenUI_ImageButton.

The ability to change color this way was also added recently.

You can now programmatically change which sprite is shown by an image bit on an ArcenUI_ImageButton.

The texture must be in a unity asset bundle loaded by the game, and it must be configured as a sprite in the unity editor. This is pretty easy, but it does have to be done.

You just pass in the name of the bundle containing the texture, and the path-within-the-bundle to the texture, and it takes care of the rest.

The build queue item currently under construction now shows its estimated time to completion just above it.

Note that it currently assumes the builder has access to enough metal to work at normal speed; this will be refined.

Thanks to BadgerBadger for suggesting.

The build and tech buttons now always use the size of unit icons used with flairs (even if the unit type has no flair), to keep the display consistent and allow the remaining-cap count to be a bit larger visually.

That count is now larger, also.

Thanks to BadgerBadger for suggesting.

Fixed bug where the start-in-control-of-first-planet lobby option caused warp gates to not spawn anywhere (instead of just not on the human homeworld).

Thanks to BadgerBadger for reporting.

Replaced the ship/ship-type mouseover info in the bottom-left with an actual detail "window" which uses layout and icons to communicate much of the previous-text information.

Most of the icons are currently placeholder "text" (images of text); that's still underway.

This also includes the Description field from the ship's xml, which the previous display did not.

Renamed the I-IV tab to Fleet, since it includes MkV stuff anyway, if you have it.

Replaced player_units_do_not_attack_unless_taking_planet (which took true, defaulted to false) with target_type_for_player, which takes:

AutotargetAlways

Default behavior.

AutotargetIfTakingPlanet

What "true" used to mean for the old flag.

NeverAutotargetButAllowManualTarget

Like "true" on the old flag, but does not even autotarget when the planet is marked for taking (can still right-click to attack).

This is now set on AIP reducers like the Data Center.

NeverTarget

Your units will never ever aim at this target.

This is now set for missile silos and design backups, since those are of no value to you unless you hack them (and hacking them destroys them).

Thanks to Draco18s and BadgerBadger for suggesting.

Carrier, Missile, Implosion, and Lightning Guardians MKs 2-4 visuals now in place, added instead of the Mark 1 versions of their respective types that had been used previously.

Widow Guardian Mark 1 visuals now in place and wired up to be used by all 5 marks, plus the dire version, of the guardian. Actual other variants coming later.

Version 0.508 The Adornment Of The Buttons

(Released August 10th, 2017)

Build menu and queue icons now show:

In the upper left corner, the number of squads you can construct until you hit the cap.

If this number is zero, it is shown in red.

Just below that:

If you do not have enough fuel to build more of that unit, it shows a small fuel icon.

If you do not have enough power to build more of that unit, it shows a small power icon.

Queue icons are now shown with a different button background color rather than being an entirely different prefab.

Tech menu icons now show:

In the upper left corner, the number of science points it costs to unlock that unit.

If this number is more science than you have, it is shown in red.

If you've already unlocked this unit, the number is not shown at all.

Just below that:

If you have unlocked this unit, it shows a small green checkmark.

If you have not unlocked this unit, and cannot because you do not have a prereq, it shows a small padlock icon.

It also darkens the button.

If you have not unlocked this unit, and cannot because you do not have enough science, it shows a small science icon.

Using the number-key navigation in either the build or tech menus (push one number to select a column, another to select the cell at the corresponding row) now shows a white outline around the buttons in the selected column after the first number.

Version 0.507 When Menus Attack

(Released August 7th, 2017)

Build menu moved back to left side of screen, and back to a horizontal arrangement, but now on top of the build menu instead of under it (so basically exactly where it was in classic)

And now uses the icons for the queue menu instead of just the

Thanks to BadgerBadger for the suggestions.

The build queue buttons are now a different color, to make it easier to tell them apart from the normal menu buttons.

Moved the ship/squad counts for player vs enemy to the sidebar, no longer cluttering up the bottom-right info section.

Thanks to eRe4s3r for reminding us to move that.

Re-implemented the Tech menu, based off the new Build menu.

Thanks to BadgerBadger for reminding us of how non-functional the tech menu had become.

Version 0.506 Hotfix

(Released August 4th, 2017)

Fixed null exception in the new mark-based-color tooltip code.

Thanks to BadgerBadger for reporting.

Removed the debug line that's been in tooltips since forever, showing the numeric location of the unit.

Thanks to BadgerBadger for reminding us.

The sidebar no longer shows metal/fuel/science/hacking resource points, or the controller, since they're always present.

Thanks to BadgerBadger for suggesting.

Version 0.505 Tooltips And Build Menu

(Released August 3rd, 2017)

The build menu now shows icons instead of names for actual "click this to build this unit type" buttons.

The tab-selection part of the menu is still text, similar to AIWC.

The approach we tried with "show a horizontal list of types, then a horizontal list of marks above that" is gone, in favor of a more AIWC-like grid where the columns are the types and the marks/variants are arranged vertically upward.

The number-key navigation still works: the first number from 1-9 selects that column of the grid (and gives it a visual highlight, which is more subtle than intended because adding a new icon/layer to that is an involved process), and the second number from 1-9 actually clicks the button at the corresponding row in that column (1 is the bottommost, 2 is the next one up, etc).

The Escape key now does what the 0 key did: close any open bottom-bar menus and open the master menu.

So to get the old Escape behavior of opening the system menu, you press Escape followed by 1.

And the 0 key now does what it used to: acting as a tenth button for whatever the topmost bottom-bar menu is.

Fixed bug where the sidebar icons (and now the build menu icons) were not scaling correctly at different resolutions, leading to overlap of other elements at some resolutions but not others.

When a button click in the interface is "denied" in the sense that you click something that isn't allowed to happen at the moment, it now plays a buzz sound effect rather than the normal click sound effect.

When you are clicking your campaign name in the load savegame menu it no longer makes the big booming sound effect of starting the game. However, actually clicking the specific savegame entry inside the load campaign submenu still does.

Fixed a super annoying bug where shots would zip off into an area kind of near the center of the planet and then to their target under certain circumstances. It was a major noticeable visual artifact, for sure.

Fixed a bug where the tooltips over build buttons were not working when you were viewing them on the galaxy map.

The tooltips for planets now say who owns it, or if it's neutral territory.

If the AI owns it, it now shows the mark level for the planet, too.

Did a variety of formatting improvements on the tooltips. If anyone is looking for inspiration for more:

Incidentally!! We can probably use the <space> tags in order to do better layout of things like the top bar, and then have icons for things that would otherwise use the <sprite> tag more under our control.

As noted in one of the dev diary videos from this week, the support for the sprite tag is pretty flaky at best, and rather than using a bunch of labels this would save us some draw calls (when rebuilding part of the gui).

Either way, it's all one draw call once it's drawn once, until it changes again, and it's only the part of the gui (the "window") that changes that has to be updated at any given time.

Fixed a bug with the tooltips where they would keep showing the last thing you were hovering over unless you started hovering over something new.

This has introduced the occasional flicker in a couple of instances. We'll have to see what we can do there.

Previously, data on the galaxy map would get noticeably stale in terms of frequently not showing the mark level after the planet name, or not showing an ownership change, etc. This now automatically self-corrects every 400ms if something is wrong and you are on the galaxy map.

Thanks to BadgerBadger for reporting.

Version 0.504 Big Ship Graphics Batch + Test And Revise Pass #3

(Released July 31st, 2017)

Player homeworlds can no longer have hacking points, to avoid motivating reloading until you get a planet with hacking points.

Player homeworlds are now always great at science, good at power, and normal at metal and fuel, again to avoid motivating starting the game over and over until you get the resource mix you want.

Added Galaxy button to the right of Planet on the master menu.

Moved the Find Planet button from Planet to Galaxy

Added a new Display button to Galaxy, which opens a list of Galaxy Display Modes

Currently that's just Normal (what you used to get before) and Resources (which shows the resources each planet is better-than-normal at producing)

These modes are defined in external code so you can greatly change what they display, if you are so inclined.

Incorporated BadgerBadger's improvements to the Nanocaust faction.

Now less likely to dominate your game in the first hour.

A random flagship, golem, and ARS are now seeded within 2 hops of your starting planet (and thus within the initial known-map range).

Redid the build menu layout to be more consistent with the layers-of-bars-on-the-bottom approach, where the first layer lets you pick the tab you want to build from, the second layer lets you pick the type of ship/unit you want to build, and the third layer lets you pick the specific mark/variant you actually want to be queued up or "loaded" onto the mouse cursor for direct placement.

Each of these layers now fully responds to the 1-9 keys, like other menus, if you like that sort of thing.

The queue display itself has been moved to the right-hand side of the screen, and laid out vertically, to visually and spatially distinguish it from your build menu.

Fixed a bug in the external code project files that was breaking the build process if you tried to build those projects in a normal steam install instead of in our development environment.

New Graphics Implemented For 34 Ship/Structure Classes!

200 megs worth of compressed textures and meshes added to the main asset bundle (up to 1.2gb total for those)!

These have been in progress for months by Blue and Cinth, and are just now being actually wired into the game fully because of the particular way our work pipeline goes.

The breakdown of all this is below, and this isn't remotely all the stuff that we have nearly-done, so more will come soon.

It's worth noting that the radii and squad sizes may not be quite right on them in this initial wiring-up.

When paired with the existing ships that already had graphics, this is actually all but three of the remaining bonus-style ships slated for version 1.0 of the game!

"Bonus-style" ships are basically the little squads of ships that you can start the game with, or unlock via Advanced Research Stations or similar. There are lots of other kinds of ships and structures (more TYPES of other ships/structures far outnumber the types of bonus ships), but these are most numerous in your fleet when talking sheer numbers of actual entities flying around.

The following "drone" type entities now (newly) have full graphics:

Implosion drones.

There are still four other types of drones that just use the little rock stand-in graphics. These are either in progress or slated to be completed in the next month.

The following AI guardian type entities now (newly) have full graphics:

Note that most of these will have five unique stages of graphics for each of the five marks, but for many of them they only use the mark 1 graphics at the moment for all 5 marks. In those instances, the graphics for all 5 marks are done already, but we haven't finished processing the higher-mark models into the engine yet.

The there are a number of other guardians that still use the rock-type graphics for the moment, even though there were a bunch of other guardians that already had graphics. Lots of guardian types in this game!

The following starships now (newly) have full graphics:

Note that all of these will have five unique stages of graphics for each of the five marks, but for now all of the ones in this batch only use the mark 1 graphics at the moment for all 5 marks. In those instances, the graphics for all 5 marks are done already, but we haven't finished processing the higher-mark models into the engine yet.

Siege starship, carrier starship.

Combined with the 4 existing starship types, that's all of the starship types for version 1.0 of the game. Compared to bonus ship types or guardians, there are relatively few starship lines.

When combined with all the AI structures that already had graphics, this is now all of the ones for 1.0 now having graphics!

...with the exception of the interplanetary guns, actually. That's a stretch goal that has 5 very huge guns that are not in yet, and they technically fall under this category. But they're not in the game just yet, anyway, and are on our list for soon, visually-speaking. :)

The following ship types now have actual proper icons shown rather than showing unknown and text:

Version 0.502 Mostly-Invisible UI Work

(Released July 14th, 2017)

Bottom-left tooltip now aligns to the top of the master menu area.

The alignment is still a bit rough, but at least it reacts to an increase in the occupied vertical space.

Completely reworked how UI layout from the old "everything is relative to the edges of the screen" approach that was heavily based on Unity's transforms, anchoring, etc, to an "everything is relative to the edges of the thing which contains it" approach.

This now supports a variety of alignment types, including "as far top/left as possible" "as far bottom/right as possible" "in the middle" and "left/right/above/below this list of other windows", each of which can be used separately for the x and y axis.

Note that any UI mods you may have will probably not work after this release until they're updated. The KDL_UIWindows.xml file should have the necessary information on how to adapt your stuff.

The Build and Tech menus currently sit higher on the screen than they should, will be fixed soon.

AOE shots no longer hit a protecting shield (or other target) more than once when detonating.

Most AOE weapons now have a maximum number of targets they will hit per shot.

The 0 key, which normally opens the master menu (commands not related to your selection) when you have no bottom menu open, will now always do that no matter where you are in the bottom menu structure, allowing key sequences like 0-7-1-1 (select all mobile military on the planet) to have a consistent behavior even if you currently have a selection or have a sub menu (or menus) open.

Version 0.501 Test And Revise Pass #1

Note that this one was a little slower coming, just because of some life stuff going on. Other than that we theoretically should be moving into quicker release cycles. ;)

Adjusted the shader to try and lighten the Experimental Fabricator model a bit.

Added the attribute " y_offset_of_icon="20" " to the fortress xml entry to help with the flickering issue.

Adjusted the radii on several ships and turret types to help with overlapping selection boxes.

Added "Start With First Planet" toggle button to the lobby, defaults off. If on:

The planet you start on begins with the controller and resource spots under your control.

There's no initial AI presence on the planet you start on.

Your Ark starts next to the controller on that planet instead of near the edge of the grav well.

Your starting AIP is what it would have been after conquering the first planet.

Thanks to... well, everyone, for letting us know that fighting that first battle every time got old.

As framework for the start-with-first-planet option, the "Conduct" table has been moved out to external XML. It's basically just a boolean value you can check for in mapgen or whatever other external logic, but you can also add arbitrary per-sim-step logic if you like. Whether it works or not is up to you, of course, but it's a pretty flexible hook.

Fixed a number of issues that were preventing your "last game lobby settings" from persisting across executions of the application.

Turrets and (most) other structures that you place directly will now leave remains, as in AIWC, that can be rebuilt by a controller, Ark, or Flagship.

By "rebuilt" is meant "switch it back into self-building mode".

There's a 5 second delay between an entity's death and when it can be rebuilt. That delay is in the external constants file if you're curious.

Fixed bug where pressing escape in the lobby would cause a null reference exception.

It now correctly exits the lobby.

The "Free Roaming Defender" button, since the text doesn't even remotely all fit on the button, is now called "Pursue", so you can at least see whether the mode is on or off for your current selection.

A number of buttons in the lobby have also been modified to better fit their text.

Various balance numbers (metal cost, power cost, fuel cost, science cost, speed, range, etc) are now rounded to a more readable number if that is within 2% of the "real" value.

This could stand some refinement, but even at this point it makes the tech menu a lot easier to read.

Included BadgerBadger's "Find Planet" function in the planet action menu.

Thanks, Badger!

Integrated BadgerBadger's addition of the concept of a "campaign" to the save/load menus.

Thanks, Badger!

Fixed bug where the algorithm that decides which planets are good at which resources could sometimes assign a zero production of metal, energy, fuel, or science to a planet.

Note: it's intentional that most planets do not have the hacking resource at all.

The Basic Turretry pattern now spends 25% of its budget on shield generators.

Shield generators no longer project their shields when disabled by paralysis, still-building, etc.

Fixed bug where shield generators were galaxy-wide-cap instead of planet-cap.

Fixed bug where player-owned carrier-starship drones would never return to their parent ship because they always thought enemies were present.

Made drones like the carrier starship drones die if their parent ship dies or is on a different planet.

Added IndividualBehaviorLogic tracing type, for inspecting the low-level individual ship logic that takes over in the absence of any commands from the owner (things like FRD are handled here, as well as carrier drone return-to-carrier behavior).

The "engines out" colorization of the mark level icons has been made less garish and instead has text saying "ENG" over it on the bottom.

Added new "out of order" display for the mark level icons that says "OFF." This is for stuff that is dead and going to be rebuilding.

Version 0.500 Ship Batch 7 of 7

(Released June 27th, 2017)

New Ships! (Note That More Are To Come Pre-1.0, But Not Pre-Early-Access)

The AI Master Controller is now armed.

And its on-death behavior has changed.

Botnet Golem

As in AIWC, fires large salvos that cause victims, once dead, to become zombie units of the same type that attack their old enemies but do not take orders from anyone.

So these zombies (not the golem itself) are the first third-party or "special faction" units.

Unlike AIWC these shots are no longer insta-kill, but quite powerful nonetheless..

For now zombies just stay on then planet where they start, and FRD.

Devourer Golem

Special Faction unit, one is seeded somewhere on the map at the beginning of the game (if enabled in the lobby).

Attacks everything within range (except controllers/warp-gates), and generally wins. When it does damage, it gains a portion of it back in health, to keep it going on those long hauls through the AI's territory.

Randomly picks another planet somewhere on the map to go to.

If you feel like reprogramming the galactic wrecking-ball, this routing code is in SpecialFaction_Devourer.DoLongRangePlanning()

When it reaches destination, rinse, repeat.

Good idea to not be wherever this thing is. Thankfully it's slow.

Will need rebalancing to avoid it causing a win/loss on its own (in the last test, it wandered through the AI Homeworld and took down the AI Master Controller singlehandedly), but we're working on an approach that doesn't involve unintuitive immunities.

Zenith Dyson Sphere

Special Faction unit, one is seeded somewhere on the map at the beginning of the game (if enabled in the lobby).

Unarmed, and immobile, but immensely hard to kill.

Periodically produces units to go to other planets and attack enemies, similar to AIWC, but instead of the single "Dyson Gatling" unit type from AIWC it simply picks from a subset of the AI's MkV Guardians. You want to know how it got those guardians? You've seen that episode, right?

Like in AIWC, the Dyson's units have different allegiances depending on who controls the Dyson's planet:

If the AI controls that planet, the Dyson hates everyone.

If a player controls that planet, the Dyson hates everyone except the AI.

If no one controls that planet, the Dyson hates everyone except the players.

Unlike AIWC, the Dyson's preivously spawned units will automatically "update" to follow any changes to those allegiances.

Also, "hates everyone" now includes other special factions, like the Devourer and Zombies (which currently means that the Dyson's units will Nom your Botnet zombies even if it likes you; we'll probably change that later).

As in AIWC, the Dyson's units won't attack an AI controller/warp-gate. Still feels kind of lame, but the alternative is either uncontrolled AIP growth or potentially-tons-of free extra territory for the player. Suggestions welcome. It'd be fun to have factions like the Devourer and Dyson be unrestrained in their ruckus-causing, without throwing the player's game into continual chaos.

As with the Devourer, will need rebalancing to avoid eventually flooding the galaxy with special-faction guardians.

Zenith Trader

Special Faction unit, one is seeded somewhere on the map at the beginning of the game (if enabled in the lobby).

Unarmed, but hard to kill.

Randomly wanders the galaxy.

When present on the same planet as your Ark, your Ark gets an extra build menu that lets it build things like Ion Cannons, Black Hole Machines, etc.

Like AIWC, the trader is friendly to all factions, and all factions are friendly to it.

Unlike AIWC, there's one exception: the Devourer knows the Trader is not to be trusted. We suggest making your Trader purchases before the two of them meet.

Dire Guardians:

Dire Teuthida Guardian

Spawns Teuthida drones, which zombify things they destroy.

Dire Hunter Guardian

Spawns Hunter/Killers (this takes a long time for each one), which are actually stronger than the Hunter Guardian itself. An H/K's main weapon is called a "Plasma Torpedo Shotgun", which tells you all you need to know.

Post-Processing Stack And Related

Upgraded to Unity version 5.6.2f1 from 5.6.1p1.

This introduces some bugfixes for windows and linux on the player side, and fixes a memory leak in the profiler for us on the editor side.

As it turns out, the experimental post-processing stack v2.0 that unity has in beta and warned "don't use in a production environment" is indeed not ready for a production environment. ;) Was worth a shot.

The new 5.6.2f1 won't even build for DX11 on the version of the PP stack we were using, and it was causing strange graphical artifacts for at least one tester.

Thanks to 5ounds for reporting the strange seizure-strobes. ;)

Yet AGAIN we've completely redone the post-processing stack. What's up this time?

We're using the FXAA implementation by Amplify Solutions, since that's quite battle-tested.

We're using PRISM post-processing to handle some color grading, minor vignetting, and sharpening. The difference in quality from the sharpening plus the FXAA is pretty notable even if you already had MSAA cranked up. It all works in tandem.

We've also returned to Amplify Bloom once again, since that just is unparalleled in terms of its overall quality and its ability to ensure temporal stability. We've actually cranked up the temporal stability to an unusual degree, and have a much wider radius of faint bloom, so that we get a softer effect (it was getting pretty grating in recent versions) and so that also we get an effect that has a bit of a trail after bright sources because of the temporal delay. Looks bad in setup scenes, looks great in battles.

One of the reasons that we had moved to the unity post-processing stack was that since it is free and open-source we could simply include that in the AIW2ModdingAndGUI project. Other than the FXAA solution, these other bits are not open source. But it's important to be able to see what you're actually going to get as a result in-game when you're making something in the AIW2ModdingAndGUI project... so we just compiled the non-editor code into our own dlls, and then removed the front-end editor code from that particular project. Problem solved.

Experimented around with Graphics Jobs again, which is a feature that we've tried on and off with unity.

It's definitely causing a lower overall framerate in this particular game, and more choppiness, so we turned it back off and won't be including it.

Most likely this is because of all of the instancing that we do, and the fact that offloads a lot of the work of dynamic batching already.

Upgraded to Amplify Shader Editor v1.0.0.012, which adds a few new goodies for us and a couple of bugfixes.

Version 0.450 Sound!

(Released June 22nd, 2017)

Post-Processing Stack Revisions

We completely redid our post-processing stack AGAIN, this time based on the not-yet-fully-stable (whee!) unity stack v2, which is still in development.

Why use this? Well, Chris was getting really sick of the over-done bloom that he was winding up with the older PP stack, and couldn't fix it with any settings he could use. The newer PP stack has not only a better control over bloom, but also a much better auto-exposure tool. The HDR tonemapping tool seems borked at the moment, but the auto-exposure tools is yielding better results for us than we got with the Neutral tonemapper in the PP stack v1 anyway. Would have been nice to use ACES, but oh well.

With the new exposure correction, we've actually brightened things up a tad, and there's a hint of what you might think of as eye adaptation, although that's really more a factor of exposure averaging and is a very subtle effect.

We're also now using SMAA on the CPU side in addition to the pre-existing MSAA we use on the GPU side. Previously we were not even using FXAA on the CPU side, though we were thinking about it. TAA is now available in PP stack v2 in the Forward rendering path, which we're excited about, but it doesn't yield sufficiently crisp results yet. So for the moment SMAA it is.

Why all this fuss over the post-processing stack? Well... sometime soon we have to start doing screenshots that people will start showing around on websites and seeing on Steam, so it's pretty important that things look nice enough.

Sound Effects!

We now have a bus-based sound mixing solution in place, based on unity 5's advanced mixing capabilities, but then expanding that even further.

In our case we're setting up both directional and 2D sound sources with custom falloffs, and a maximum number of "voices" per bus, and advanced customization for clusters of sound effects (time delay between individual sound effects playing, between sound effects for the whole cluster, and even failover to a different sound effect cluster if the first cluster is still on cooldown).

This allows for us to really tune and mix the sound the way that we want, including music ducking, and general sound ducking for various types of vocal audio.

This also allows for us to have voice commands that play, but not too frequently, and for them to "fail over" to other types of sound effects to indicate orders receipt when the voice command version is on cooldown.

Thanks to qipoi for suggesting this functionality regarding the voice commands playback and failover.

Hugely reworked our music pipeline, as part of our new sound pipeline in general, so that it's all now piped through a central audio mixer that supports audio ducking for the music and for other sound effects as-needed for things like voice alerts and things of that nature.

It also allows for us to have certain explosions just drown everything out in an impressive way, and in general allows us to do sound mixing by bus, which can be tuned in the AIW2ModdingAndGUI project.

The game now has proper volume handling, which it didn't have before even for the music.

These volume settings are layered on top of the volume settings from the mixer, and it all gets translated over nicely.

Players simply select a volume between 0 and 100 for any particular type of sound that they want to adjust.

Note that for turning off sounds or voice or music entirely, it's more efficient to simply use the toggles for those so it's not silently playing those sounds or music.

The types of sound that can be adjusted are:

Master (affects literally everything, music, etc).

Music (just affects music)

Sound (affects all non-music sounds).

Voice (just affects spoken voice lines).

Combat (affects all the sounds of battle).

Given that the actual underlying bus volumes are in -80 to +20 dB ranges, where 0 is the default (unaltered) state, and we may have altered the bus defaults in the mixer itself...

The game takes the inputs for the "volume" as a 0-200 range, then transforms that into a multiplier against the default volume of the bus.

Specifically:

If you choose 0 volume it just goes to -80, if you choose 100 it stays at the bus default, whatever that is.

If you choose anything between 1 and 99, then it multiplies the inverse cube of the percentage of that by the starting volume of the bus.

This helps to offset the logarithmic falloff of dB reduction from 0, and feels pretty natural.

It does mean that since we're only using the cube, and not the fourth or fifth power, that in general things still go pretty unexpectedly extra quiet below 40% or so, though. But this gives the most gradiations in the audible range.

If you choose anything between 101 and 200, then it multiplies the flat percentage of that by the difference between the max (20 dB) and the starting volume of the bus, added to the starting volume of the bus.

This gives a great deal of precision in making things slightly louder, but doesn't really hide the logarithmic rise where you have to go to 180% or so to get a really substantial (10dB or more on average) rise out of the result.

Overall this isn't quite the most natural way to handle the volume siders above 100%, but it does give the most precisions, which is probably for the best. And it's still easy enough to tune.

There are now computery sound effects for giving attack, move, wormhole-path-move, and construction orders.

The ones for placing construction units are particularly satisfying. :)

There are now sound effects that play when you alter your build queue, alter your control groups, "do some other general tweaks, mainly cheats," launch warheads (this one is cool), scrap units (careful of the heart attack), start hacking something, change into hold fire mode or out of it, toggle pause, and unlock a tech.

There are now settings that allow you to mute various parts of the battle sound effects selectively (shots firing, shots hitting, ships exploding). This might be useful to someone else, but it's also helpful for us in testing certain sounds without the mixing.

All of the ships/structures in the game now have explosions set for when they explode.

They fall into 14 different categories of explosion sound effect, two of which are just for warheads.

There are then a further three twos of explosion sound effect that happen for ships that are not at the planet you are presently at, or when you are on the galaxy map.

The game now uses a blend of 2D and 3D (spatial) audio, which is pretty typical for games that are in 3D.

Things that are "HUD sounds" or other non-point-source type sounds just play normally, as does music.

Things that are sound effects coming from a ship or a shot or an explosion have direction and attenuation based on their relative location to the camera.

This makes it substantially quieter in the battle when you zoom way the heck out, which is nice, although different sounds are attenuated at different rates -- the explosions of ships dying attenuates a lot slower, for instance, so you can keep an ear on that easier.

This is something that anyone can tune (in a modding sense) by adjusting the prefabs in the AIW2ModdingAndGUI/Assets/AudioPrefabs/Combat folder.

The major settings to play with there are Max Distance (the furthest out the camera can zoom is 1200, for reference), and then the Spatial Blend and Spread values. Having a Doppler level is also possible, but tends to give strange and muddy results.

You can combine changes here with changes to AIW2ModdingAndGUI/Assets/AudioPrefabs/OfficialMixer (click into that object to get the mixer panel), if you like.

One thing Chris was considering, for instance, was making it so that WeaponsHitting had a max distance of 500, over which it would attenuate, and then increase the WeaponsHitting bus from -23dB up to something a lot more substantial. You'd then have no sounds of shots hitting beyond 500 distance, but much louder sounds of that hitting when you are progressively closer than that.

This isn't something you can mod and just keep modded all that easily at the moment, although you can make a copy of the mixer and then point your xml (using an override) to your mixer instead of ours. The risk being that if we make a lot of changes to the sound buses, which is most likely now while they are new, then yours may stop working and you have to make a copy of.

At any rate, mainly if you want to mess around with that and see if there are values that you feel like give a better result, we'd always be willing to take that sort of thing under advisement. ;) We have BadgerBadger fixing bugs already, goodness. But anyhow, the point being that it's open so that people from the community can fiddle and share their results with everybody if that is an area of their interest.

There is now a set of sound effects for ships entering or exiting wormholes, as was the case in the first game. These are neater, though.

All of the various buttons in the game can now have a click_sound xml attribute set on them, to choose between sound effects for them to play when clicked.

This also applies to dropdowns, image buttons, button lists of various sorts, etc.

By default buttons all now play the sound effect "ButtonNormal" when clicked. You can override this to silence if you need to for a given button that also plays a sound effect via a command that is executed, if you need.

A different sound effect, ButtonStartGame, is played when you start a new game or load an existing one.

Shot Visuals!

The forcefields and the ship-to-ship lines have been moved into the modding and gui project so that anyone can edit them.

Improvements have been made to how the various lines look, from their shaders, while we were at it.

All of the shot graphics have also been moved to the modding project, for the same reason.

For now taking away the side-specific bullet colors. Frankly this makes it a lot harder to differentiate bullets by type, which is more important.

The armor-piercing bullets now have their real graphics, which is the pre-existing orange tracer shots, but made a lot shorter.

Note that the tracer-style shots are heavily affected (in terms of how long they are) by the speed at which they are moved. So there are now three different variants for use in different speed scenarios. This is super easy to mod if someone is changing around shot speeds dramatically and wants the shots to look similar to how they do at the current speed.

All of the not-yet-done shots now use the old green-style enemy shots, to make those easy to spot and then fill in the real data for.

FINALLY got a version of the fusion rocket shot visuals going that we're actually happy with. It has to look nice, but not too close to the other stuff. Exaggeratedly-large so you can see it, but not so much so that it's cartoony. Nicely colored, but emissive and bright enough you can see it at a distance. And on and on.

We experimented a ton with trail renderers in addition to the rocket, and having those be the things that are visible at far distances, but that wound up always looking too similar to the other trail renderers (when additive particle blending was used) or extremely chuggy on the CPU (when alpha particle blending is used and thus they needed to sort).

Misc

Fixed bug where golems were not actually being seeded.

Thanks to BadgerBadger for reporting.

Fixed a bug where it was possible for the map seeds auto-generated to be longer than the ones you can key in manually.

Thanks to BadgerBadger for literally fixing the bug himself.

Fixed a bug where hitting B selects additional build units.

Thanks to BadgerBadger for literally fixing the bug himself.

Put in a fix that definitely prevents keybinds from triggering while a textbox is focused (we've been able to test it now).

Thanks to BadgerBadger for reporting.

Added a link to the external tutorial on the main menu.

Thanks to BadgerBadger for literally coding the addition!

Put in a fix where squads should now properly change their ownership color if their current side doesn't match what their previous state was.

An error message stating "Player data archive not found at `/home/user/AIWar2/AIWar2Linux_Data/data.unity3d`, using local filesystem[[email protected] AIWar2]$" on startup on linux should no longer display. It was harmless, but annoying.

Note we didn't get a chance to test this yet, but knock on wood it should work. ;)

Thanks to BadgerBadger for reporting.

World_AIW2.Instance.QueueGameCommand now takes a second parameter that says if it should consider handling local audio/visual feedback of the command being sent.

Generally speaking almost everything in the AIWarExternalCode should have that as true, so that sound effects and such can be played as need in order to register that things have been accepted. But things from the AI should always say false.

Fixed a bug where every full-capacity squad with more than one ship in it was drawing an extra ship.

This doesn't fix isues with squads having more living ships than they should based on ships that died; that's a separate issue.

Thanks to BadgerBadger for reporting.

The game now notices when there are more ships specified to be in a squad than the actual formation allows for, and complains.

In some cases this dramatically reduced stutter that was coming from the GUI.

You can now actually name your savegames.

Thanks to BadgerBadger for literally coding the addition.

Version 0.401 Ship Batch 6 of 7, And Gimbal Perfoooormance!

(Released June 12th, 2017)

The game console has now been fully moved to the AIW2ModdingAndGUI project (source code aside), and has been re-skinned using our own graphics and text mesh pro.

This may not have seemed like a high-priority thing to do, and indeed it was not in and of itself, but it validates a particular GUI creation workflow that we now have, as well as providing a concrete example for that type of GUI.

Basically our existing GUI creation methodology is all based around xml creation of things and populating them certain ways.

But now we can also take an entire GUI canvas, create it in the WYSIWYG unity editor in the AIW2ModdingAndGUI project, and then wire it up in a completely traditional-for-UGUI fashion and after that let it be triggered from the dynamic GUI. These are even loaded using the existing "gui prefabs" logic that the xml-oriented GUI uses.

The end result is just as performant in both cases (and basically identical), and so mainly the question is of which approach is easier for a given piece of the GUI. There's no one right answer. Even the xml-oriented version is using prefabs that have a bunch of nested stuff, but this is just taking it to a completely other level of having the entire canvas/window populated.

At any rate, being able to do this now and having an example of how to do it was well worth the time in this particular build. It should open up options better for the upcoming GUI revisions.

A massively new way of drawing the "sprite gimbals" over squads in the game is finally complete.

We tried a variety of approaches, but for various reasons dynamic batching, instancing, and so forth all yielded subpar results when individual sprites were made up of often up to 6 sub-parts (main icon, border, flair, mark level, and health bar).

We're now baking the sprites into meshes prior to them ever being instanced, which cuts the graphics load of the gimbals to around a sixth of what they previously were.

That said, the sprites themselves still need to be instanced even after being baked, and to do that we need a single mesh for all the types for the most part. So we're hiding data in the uv2 and uv3 channels that let us know which instance properties to conditionally apply to which vertices, which in turn lets these things colorize themselves (via HSV shift) as needed. But since not everything needs to be colorized, our new ubershader for the baked group is now actually more efficient than before, making the savings more than a drop to 1/6th of the previous load from this source.

Performance improvements in this area might not seem like that big a deal, but on a GTX 1070 with 5k ships on the screen, the icons were approximately half of the visual load. Facepalm, right? So this has been a big priority.

The downside of the new approach would seemingly be that now these icons are harder to edit, though, if someone wants to mod. Bummer... except that it's just as easy as ever! :D

We've created editor tools in the AIW2ModdingAndGUI project that allowed us to merge meshes, set the uv2 and uv3 channels properly, and so on. You can re-bake the meshes as desired, and we can do so quite easily as well. You can't do it by xml anymore, but that's a pretty small thing.

Fixed a bug in the prior build where the gimbal icons no longer reacted to player mouse hovering or clicking.

This was because of the changes in the hierarchy of pieces of squad parts in the last version.

Thanks to TheVampire100 for reporting.

When you are placing ships/structures on the map, there's now a filled circle that shows the radius of the footprint that ship will take up. It then also shows the icon of the ship in white over where the footprint is.

Fixed an issue where the missile turret was not assigned its flair properly.

The game now automatically checks its models for missing materials, or materials not set up for instancing.

There were then a number of ships that we fixed that on so that they have instancing set up properly.

The font_size property now actually works on the new text labels in the game (not buttons or anything else presently).

The game now has icons for the various resources, which can be inserted into text with <sprite> tags from text mesh pro.

Unfortunately the process for getting those in there requires the creation of sprite dictionaries embedded in the main game Resources folder at the moment. We will likely alter that at a future time, but for now that's stuck.

The process for getting new sprites in there is pretty convoluted in general at the moment, to be honest, so that's again something we'll have to work on later. But it does work, and it does perform well!

Fixed a bug where "dfgdfg" would show briefly as the planet name in the prior build.

Thanks to BadgerBadger for reporting.

Updated to Amplify Shader Editor v1.0.005, which has a number of new features and some at least minor performance improvements.

Fixed an issue with the AI Warp Gates not having their mechanical parts rotating properly.

Put in some code to automatically tell us when our animators have messed up.

The game now has a nice fade-in effect whenever you're switching planets or in and out of the galaxy map, making things feel more polished.

Fixed a problem with the mod support where every dll had to define a type which implemented the IInitialSetupForDLL interface, and further required a specific naming convention for that type.

Now when loading a dll it looks at all types exported from it and runs the RunInitialSetup() of each IInitialSetupForDLL it finds.

If it doesn't find any, it won't mind.

Thanks to Draco18s for reporting.

The very low end of the camera zoom now has a few more gradations where it shows more of a side-facing view, and then the very lowest zoom level actually looks back UP slightly, allowing you to see tall ships and structures better, and in general get a little more cinematic of a view. This has no effect on the higher zooms.

Thanks to BadgerBadger for inspiring this change.

New Ships

Bonus Fleet Ships:

Vampire Claws

Cloaked melee ships that heal themselves when they do damage.

Vorticular Cutlasses

Melee ships that damage themselves when they do damage (when balanced, their dps will be much higher than vampire claws, for example).

EtherJet Tractors

Cloaked Jets with Tractors. What could go wrong?

Dire Guardians:

Dire Warp Beacon Guardian

The AI can always send waves to the planet this guardian is on, and if it is on alert this is likely to happen.

Not to be confused with the Dire Warp Bacon Guardian (despite internal typos to the contrary), partner-in-crime to the Pancake Golem.

Can be very hard to kill if you don't kill it quick, because of its ability to heal itself from doing damage.

Implosion Guardian

The Dire Implosion Guardian's little (and far more common) brother. They're a real pain in the rear if you're a golem...

Golems:

Seeded like Flagships, you find these, clear their planets, and claim/repair them to gain control of them.

Unlike flagships, these are rarer, claiming them costs AIP, and they don't have the quasi-Ark functions for building/repairing/etc. Instead, they're considerably more beastly than Flagships and some have unique abilities.

Armored Golem

Short-range brawler.

Artillery Golem

Long-range sieger.

Black Widow Golem

Massive paralyzing-tractor capacity, and does engine damage with its shots.

The "if you move while tractoring something, it moves with you" logic has also been implemented.

Regenerator Golem

Regenerates ships you lose on its planet, at the cost of some of its own health.

Cursed Golem

Has powerful fast-firing railcannon, but damages itself in proportion to the damage done.

Hive Golem

Internally constructs hive drones, which it launches in large groups against any threat on the planet.

Version 0.400 Usability and the GUI Pipeline

(Released June 6th, 2017)

Usability Improvements

Reorganized the bottom menu to better emphasize the function most people expect from the number keys in strategy games with real-time simulation. Namely: control groups.

So now the 1-9 buttons along the bottom of the screen are the control groups 1-9.

And the 10th button (button 0) is a "Menu" button that opens the master menu that used to be there.

Though that no longer has the "commands" sub-menu.

If you have a selection, the game shows the commands menu (as a bar instead of a stack) above the bottom bar, and the 0-9 keys map to that instead of control-groups/menu.

And backspace will cancel your selection (if you have no deeper foldouts), thus returning you to the bottom-bar context.

The upshot is that if you select your Ark, you'll see a "Build" button in the command bar at the bottom of the screen, among other things an Ark can do. Similar with other unit-producing things.

The buttons in the command menu (now shown whenever you have a selection) now are only visible if they can be executed with the current selection:

FRD only shows if there's a mobile military ship.

Scrap only shows if there's a non-Ark.

Build only shows if there's exactly one type of builder unit.

Hacking and Warheads only shows if there's the Ark.

Added some direct keybinds for the sake of near-term sanity:

P

Toggles pause.

B

Selects a builder unit on the planet and opens the build menu.

If a builder is already selected, selects the "next" builder, if any.

T

Opens the tech menu.

If tech menu is already open, closes all menus.

Escape

Opens the system menu (save/load).

If system menu is already open, closes all menus.

Space

Closes all menus.

You can change any of the above in your inputmappings file.

Visuals And Moddability

TextMesh Pro has now been integrated into the game (version 1.0.55.56.0b9). We have the paid version, but we're using the free version so that we can include it with the ModdingAndGUI project.

This lets us do a lot more advanced text rendering at no extra performance cost, as well as giving us basic functionality like proper kerning.

The first place we've set to using TMPro is the galaxy map, where now the text is both in a better font as well as a lot more readable.

The actual places where the fonts are set up for the galaxy map, and things are oriented around planets, is now also in the ModdingAndGUI project so that it can be edited by folks as desired.

Darkened all of the new skyboxes to fit with the new HDR rendering.

Made it far easier for people to edit skyboxes quickly, thanks to a new button in the header of the skybox editor.

The ruined network nodes now have proper graphics.

The advanced starship constructor now has proper graphics and animation now.

Dropdowns in the game are now actually fully skinned for the first time, making them consistent with the rest of the GUI.

They also use the TMPro text to show their text, making their text sharp, too.

Their scrolling speed is also finally reasonable when you use the mouse wheel, too.

The fortress and experimental fabricator now both have proper graphics implemented.

We've done EXTENSIVE improvements to the GUI system, with a whole new GUI pipline that is massively more efficient.

Misc

Fixed a bug where saves triggered in the save menu could happen while some changes to gamestate were still ongoing, leading to the data being saved in an inconsistent (and sometimes non-loadable) fashion.

Also added a warning message that will show if this particular corruption happens again, though it shouldn't be able to.

Thanks to BadgerBadger for the report and save.

Fixed a bug that could cause a hang in the mapgen logic.

Thanks to drspikes and BadgerBadger for reporting.

Fixed a bug where various internal tech-groupings were showing as selectable menus (ironically named "Not Shown").

Thanks to BadgerBadger for reporting.

When there is invalid data somewhere on trying to load a ship that does not exist, the game now does a better job telling you what the heck is happening. This would mainly be something helpful to modders and us devs.

Put in massive numbers of performance improvements in how the GUI interfaces with unity.

Put in a bunch of new error checking on the GUI side, so that if things are set up wrong at any point, it now yells instead of failing silently.

Tractor turret tractor-multiplier from 30 => 3.35, which is slightly more than enough for one squad of MkI tractors to indefinitely hold one cap (10 squads) of MkI fighters. Previously it could hold... more. A lot more.

Tractor effectiveness is also now reduced by the tractor turret "squad" taking losses.

Put in some logic to prevent minor gc allocs related to the galaxy map when you're not viewing the galaxy map.

Fixed a bug in the last couple of versions where ship animations were not always playing when there were a ton of ships on a planet.

Thanks to BadgerBadger for reporting.

Bunches of performance improvements have been made to the movements of squads and their icon gimbals.

Version 0.301 The New HDR Visual Stack

(Released May 30th, 2017)

Engine Damage Repair has been implemented.

Works similarly to hull/shield repair, but does not actually cost metal.

Changed balance_seconds_per_fight to 15 from 20, and balance_seconds_per_shot to 2 from 4, massively speeding up the feeling of combat from what it felt like in the prior version. It's now much more like what it was in past versions, without having such bullet spam in giant battles that there's a bunch of slowdown.

Thanks to BadgerBadger for reporting.

Fonts are now sharper in the GUI, although there's still room for improvement. Blurriness causing legibility problems is a definite issue to some extent still.

We've also updated the font on the small buttons at the bottom of the screen to be more readable, although we still want to update that even further in the future.

Thanks to Sounds and BadgerBadger for reporting.

New backgrounds for dropdowns.

HDR Graphics!

We had thought this wouldn't be possible with our visual style as recently as one version ago, but it turns out it is!

Also, prior to version 5.6 of unity, it literally wasn't possible at all, at least not without losing hardware MSAA support (which is the best sort of antialiasing available these days, and fastest).

The game now uses HDR graphics for the main camera, allowing for a better color range and fancier lighting effects, etc.

One of the most obvious examples is the way the rings on the end of the laser turrets glow very bright blue now, whereas before they would white out fast and so we had to keep them pretty non-bright.

We're using a new reflection cubemap against our scenes, and have tuned a ton of the materials to have better values to give themselves really high quality results without an over-blown specular highlight at certain angles to the main scene directional light.

Kinda related to this, we're doing new tonemapping now, which maps back down from HDR to the LDR range better, and helps give us a richer color without things having to be so darn glowy _everywhere_.

The bloom effects have been completely replaced with another set, which is able to use a lot more precision in what it does.

Known Issues

Thanks to the tonemapping, the backgrounds are presently too bright relative to the ships. We simply didn't have time to get to that, and didn't want to hold up the rest of this release over that.

AIW2ModdingAndGUI Capability Updates!

Since this unity postprocessing uber-stack is freely available, and even open source at that, we're now able to show you actually what ships would really look like in the real game when you are working in the AIW2ModdingAndGUI project.

This is enormously important in particular for being able to reliably set up the space nebula backgrounds, which have their characteristics altered some by the post-processing stack and which you need to be able to see in order to properly create them.

As part of this, we're no longer using Amplify Bloom or Beautify.

Also as part of this general work, we've updated all the various shaders and ship models and materials in the examples folder there.

To aid in background creation, as well as in general giving more examples of ships and how their shaders are used, there are a bunch of new ships that have been added to the example project: data center, lightning corvette, mlrs corvette, spider, and starship constructor.

Bugfixes

Fixed a bug in the improvements to shot staggering that caused divide-by-zero errors when the game was paused (because it actually runs zero-length frames during that time so the game can still respond to you).

Thanks to BadgerBadger for reporting.

Fixed a variety of errors that could happen with accidental extra calls to clean up objects (those extra calls are GOOD, since they often are coming from a few sources that need to double check things properly). This should also help performance minorly when objects are destroyed compared to pre-0.300 versions.

Thanks to BadgerBadger for reporting.

Fixed some bugs that could prevent shield repair.

Thanks to BadgerBadger for the report and save.

The sidebar is removed temporarily, since it was so busted anyway and overlapping things strangely.

Thanks to BadgerBadger for reporting some of the related issues it was having.

Fixed some bugs that caused the build menu buttons to collapse into a pile in the bottom-left of the screen.

Thanks to BadgerBadger for reporting.

Reworked the "Quit Game" button on the master menu to no longer be a "immediately chuck the gamestate into the grinder" function, but rather "tell the game that once it's done executing the current sim frame to close the gamestate". This avoids various race-condition null exceptions when quitting while the sim threads are going.

Thanks to BadgerBadger for reporting.

Improved the inter-cluster connection logic of Clusters to be much less likely to draw long connections that overlap other clusters.

Thanks to BadgerBadger for reporting.

Starting State

Okay! We've extended the alpha period beyond what we had originally intended, but we're going ahead and giving out the Early Access keys to kickstarter backers on the date we originally specified. Meanwhile, we're pushing the date for early access back. That link explains a lot of the reasons.

If you're one of the many who struggle with playing the game such an incomplete state, check out the instructions

What Is The Purpose Of This Phase?

Short Answer: To make the game fun, which it is not yet. Please don't fret on that!

Long Answer: There's still a lot to do on the game obviously, as stated in the last blog post. But there's a lot of good stuff here to tinker with now, and we're really looking forward to having more people bashing on it. It's not a "fun, balanced game that just needs some polish" yet, but it will be really useful for us to have more people finding the pain points both in the interface (which is currently atrocious) and the actual gameplay flow (which, from a macro standpoint, is still pretty immature).

The underlying technology and components for making a fun game are here, and that'd a very critical step towards it being a fun and balanced game, but that's not where we are just yet. In a lot of respects we kind of reordered things: the underlying tech is somewhat more advanced and more polished than we had anticipated at this point, and that is pretty important because it gives us a better idea of what we CAN do in the engine. It gives us a better bounding-box for setting up things so that we can build an interface around what is possible, and have the scale of battles reflect what is possible performance-wise, and so forth. On that front, I'm super happy with where we are.

But yeah, the next step is to finish implementing the last of the "before early access" ships, and then to actually make a GUI that isn't eye-gouging as well as a game flow that doesn't have any obvious deficiencies. Right now there are some notable concerns about parts of the game flow regarding how you don't really need to keep territory as much as in the first game, and certain other bits of the feel from a strategic standpoint are "off." Some of that is just because xyz AI feature maybe isn't in place yet, but other pieces are more about the design of certain ships or mechanics. These are things we want to iron out before we go full-Early-Access, and we need the help of folks like you to do so. We're trying to streamline certain aspects of the first game, but we don't want to do that at the expense of what made the original game cool.

The engine for this one is so flexible that we could just recreate most of what the first game was if we felt like it, but we'd really rather not for a variety of reasons that should be apparent to anyone who tried to get into the first game and bounced off it, or who played the first game for a huge number of hours but wanted certain fundamental improvements. Now that all the basic frameworks are getting in place here, we're at a point where we can start thinking about those things.