3.312

(Released July 16th, 2021)

Fix a threading problem with the Dark Zenith that could cause errors when you had multiple Dark Zenith and/or Svikari factions on certain CPUs.

Since Badger is the only person to notice this it must be rather hard to hit?

The "Show Destination Point" in the unit hovertext now matches with how ArcenPoints in other debugging code

Add some debugging code for the EntityOrderCollection which was handy for chasing down some engineer order problems.

This code is currently unused, but I bet someone else will need it down the road

Fixed a bug where the game was complaining in the prior build about missing ArcenNetworkLib. It was a compile chain error at the last moment before release that didn't get caught.

Thanks to andreykl, donblas, StarKelp, Zweihand, and Strategic Sage for reporting.

 

3.311 Engineer Multitasking

(Released July 15th, 2021)

Fixed it up so that invalid move orders (orders to move to the null location) are now ignored when they are issued via gamecommand. This is likely a faction or mod making a mistake, or some sort of funky UI interaction, but either way it's something to ignore as invalid input.

Thanks to dEAdOnE77 for reporting.

Updated ambush carrier descriptions to explicitly state the launch of raptor drones. Buffed raptor drone count to scale with mark (0.3 per mark added).

Thanks to Zweihand for updating.

Further Engineer And Line Improvements

The terminology for the metal flows, and engineers building things, has been improved in the tooltips and the menus.

Fixed an issue in the prior version where metal flows that were for the purposes of assisting a factory were not drawn at all.

In general this now means you can see all of the assistance lines, which really clears up what engineers are doing. Sometimes they seemed to only be doing one thing, not what you said, but really they were doing three things, but two of them invisible, and one of those was what you said.

The multitasking of engineers is not new and has been around since the dawn of the game, but now you can actually see that happening for the first time. It's vastly more clear (and quite satisfying) to see what they are doing.

Fixed a couple of issues in the prior version with some extra metal flows being reported, but not actually being on.

In the tooltips, behind the various types of metal flows that a unit can do, it now shows you what it is actually doing with that flow, if anything. So if it's repairing something, or building something, or repairing shields and hull both at once... it shows all of that.

Spire Shipyards now have a construction priority of 200.

Shard reactors 150.

Galactic capitol and city hub 400.

Neural nets now 100.

Great-shield now 380.

If you have the debug output on for the tooltips, you can now see details of the outgoing lines when you view the full tooltip. (Before it just showed the number of outgoing lines, not any details.)

Additionally, if you have the debug info on, you can now see metal flow details for any ship that you're hovering over, with a similar level of detail to the outgoing lines.

When metal flow validity is calculated, it now includes the radius of the two units when determining how far apart they are.

Previously, the assister had to have its center within range of the center of the thing it was going to help.

Now the assister has to have its outer edge within range of the outer edge of the thing it is going to help.

Most assisters are quite small, so on that side it doesn't change much. But if they are assisting something very large, they no longer have to crowd up on it.

Improved the efficiency of units doing repairs a bit when it comes to CPU calculations during the simulation. It now leans a bit more ones from the background thread.

A variety of logic on the engineer metal flows thread is now better about listening to your explicit orders to an engineer even when it has no valid targets in range.

All of the ship to ship lines have been updated in terms of how they draw. Most of them (all but chain lightning) now use the geometry queue rather than the transparent queue, and are based around additive math.

This gives a really dramatic performance boost while having almost identical visuals. But while we were at it, we also made the visuals nicer.

Tractor beams are a nicer texture, repair and starved repair lines are nicer (they were kind of tacky before), and there are all-new lines for assistance to factories or to self-building. Claim lines are now gold rather than green or white, and have a nicer pattern.

Added a new DoForFactionsParallel() method. This has limited uses, but certainly some.

Added a new way that our metal outflows are calculated, especially when it's helpers across factions. This gets even more accurate and prevents helper factions from running themselves into negative metal.

Fixed a number of misleading things in the metal expenditures on the UI, such as repairs to personal shields that were free or engines showing up as costs.

Fixed some bugs with the benefits of cross-faction repairs not always showing up, at least not in the last build's version. Not sure if it worked prior to that.

Fixed up yet MORE ways in which the target you had selected for an engineer might be ignored if no targets were in range.

Fixed an issue where if you gave an explicit assist order to an engineer, sometimes it would stop too far out of range of actually doing that assistance.

Mod Updates

More Starting Fleets update:

Updated mod description. Updated mod by buffing carrier fleet with additional ramifier frigate and adding the destruction fleet. The destruction fleet is a siege + splash focused fleet meant for destruction.

 

3.310 Engineering Intelligence Injection

(Released July 14th, 2021)

New setting under the network category in personal settings, under a new privacy subsection: Hide IP Address In Lobby And Esc Menu

Normally we show your IP Address in those windows in case you need them. However, if you are planning to stream the game, this is not informmation you would want visible in your stream, so this lets you turn it off.

Please note that you would still need to obscure the actual connection screen with your streaming software, because we can't really hide that IP while still making the screen useful to you.

Thanks to Meggertroll for suggesting.

Put in defensive code in the unity post processing stack v1 code so that it can't spam the player.log while trying to see if some unused components should be turned on. This was new in the prior build, and contrary to being a minor annoyance, it was actually something that was a memory leak and a major performance degradation from how much it was invisibly flooding things.

Thanks to Daniexpert for first reporting how severe it could become.

Simulation Improvements

The "Guarding" field on units been renamed to GuardedUnit.

This may or may not mess with some mods, but we're trying to clear up some semantics and also verify where everything is being used, since misuse internally was leading to some bugs.

The "GuardingOffsets" list field on units has been renamed to GuardOrPatrolOffsetPoints for the same reason. This has multiple uses, and in the end we are keeping those, but making some other changes.

The NextGuardingOffsetIndex field on units has been renamed to NextGuardOrPatrolOffsetPointIndex, which again makes that way more clear.

Various cleanup and fixes related to guarding units and so on:

When serializing a guarded unit, it no longer serializes dead or missing ones.

When deserializing a guarded unit from disk, it therefore now complains about dead or missing ones. When deserializing on an MP client, it no longer overwrites the ID with blank if it can't find it, though. This is an order of operations thing, potentially.

When guards are freed by an alarm, it is now more explicit about freeing patrollers that have no central unit they are guarding, if that's even possible (it may not be, but no chances).

When AddToNewPlanet() is called, it now clears all of the guard and patrol information. Badger had discovered that this was the source of some insanity with engineers running off to places they should not.

There is a new IsMobileAndHasRepairOrAssistConstructionFlowsOrIsMobileMeleeUnitfield used for things that would need a "return to" point during pursuit mode. Mainly engineers and combat factories and similar. The GuardOrPatrolOffsetPoint is now only set for units where that is true when the player gives a move order. This is more efficient in general, and leads to not having some strange data in there for other types of units.

It turns out this is also needed for mobile melee units belonging to players.

During decollision orders, it was assigning the engineer "return to" point, which was a very strange thing and was probably the root of the original problem with them returning to a decollision-like coordinate in the first place. Of course we don't want that in there in general with them moving between planets (and that was already taken care of above), but this certainly didn't help and might have let some issues squeak through, just more rarely.

Added moves_back_after_being_norrised="true" as a replacement for the tag "MovesBackAfterBeingNorrised". This is a lot more efficient to check on units.

Overall things here were not as dire as they could have been, but this should correct some of the issues that people were observing with engineers being a bit looney at times. And if there were other really rare edge cases, this should also catch those.

Thanks to Ryulong, aliyah, and others for reporting.

Fixed a longstanding issue from the last few months where ship to ship lines were sometimes not drawn. This had to do with how we were pooling them, and whether they noticed they had out of date information or not.

Overall the fix was to just structure this so it was more clear, and that sorted out the issues on its own.

Thanks to Strategic Sage, trigorin, Isiel, Darkshade, Gdrk, Daniexpert, and others for reporting.

Engineer Logic And Metal Flows

Please note. While engineer logic seems to be better than before, we are still observing them making choices contrary to the new rules, as well as sometimes running back and forth in strange ways. Those bits are under investigation, but we figured we'd do a beta release anyhow in the meantime.

 

Fixed a longstanding bug in engineer move code that made them move in fits and spurts toward distant targets.

Rather than moving gracefully from spot to spot (and going all the way there without being indecisive), their movement orders were instead "go 8/10ths of my assistance range and then reconsider who to even help." That... is not logic that makes sense or that is helpful.

The logic was an accidental inversion. We calculated the angle from the engineer to the target, and then a point at that angle from the engineer that was 8/10s of the assistance range of the engineer. The engineer was told to go there. This is wrong/

Instead we now calculate the angle from the target to the engineer, and then a point at that angle from the target that is 8/10ths of the assistance range of the engineer. This properly gets the engineer to go in range, and then actually help the target.

Engineers greatly prefer to help targets in range of themselves, so the odds of them getting indecisive like before is very very low. The problem was when they stopped in the middle and rethought things.

Why 80% of their range? Well, because there are usually a clump of them. This gives them room to decollide without going back out of range. Them moving in a clump is actually one of the more efficient ways to get things up and running as fast as possible, so making room for that was always a good idea.

Thanks to Daniexpert, Detlef, and others for reporting.

Added a new construction_priority="num" field for units.

This is by default 0 for everything.

Engineers now have priority 600, since engineers helping build other engineers first is wise for getting things off the ground.

Command stations now have priority 500, since engineers helping build those is the next most important thing.

Forcefields now have priority 400, since that's the next most important thing.

Factories now have priority 200, since getting them producing ships sooner than later is good.

Metal harvesters / asteroid mine and powerplanets now have priority 150, since that's economically a very fast need.

Tractor arrays and turrets now have priority 50, to get them up sooner than later.

This is all configured in xml, so it can be adjusted by modders or volunteers or otherwise.

Normally these construction projecets will be the first things that engineers do on their own, unless there is an emergency repair that is required.

Added a new emergency_repair_priority_if_below_percentage="num" for units, with an optional emergency_repair_only_if_engineer_modulus_of="num"

The former is set to 70% for all command stations at the moment, and 90% for the home command. They often go down fast once they are targeted.

Forcefield generators are set to 70% on the former, BUT a modulus of 4 for the latter. Essentially what this means is that roughly 1 in 4 engineers will break off to repair forcefields that are this damaged. The numbers will never be even close to exact, because it's based on their PKID, which is not linearly distributed between them. So it could be grossly different from 1/4; anything from 0% to 100% of them could do it.

Essentially, engineers will now:

First do any emergency repairs. In some cases, only some engineers will be diverted for emergencies based on the definition at that target.

Then do the construction of all sorts, based on priority.

Then sort for the highest priority flow, and if there are multiple of those, then the closest.

Flow priorities are something that have been in the game forever, and they have always been quite useful, but now we're overriding those with some better logic for multiple passes, essentially.

Also players can give overrriding orders and they'll do that thing until it's finished (for instance if you want some on factory assistance from early on in).

Thanks to various folks for suggestions, including yupyip and Wuffell.

Several efficiency improvements have been made in the code for engineers figuring out which targets they can repair.

Remains rebuilding now works for allied units, not just your own. This is probably only relevant in multiplayer, but would work with NPC factions if any started using that mechanic.

We didn't make an option for this, because it's so cheap to do (flip the remains back into a to-construct state) that it's not going to bother anyone. The actual repairs that would happen after being flipped from remains back to normal would only happen if you have Repair Allied Units on, and that's where the costs are.

A new "Assist Allied Factories" setting has been added in the galaxy map options, under allies economics.

As with "Repair Allied Units", this works with both NPCs and other players. In this case it is about helping with boosting factories, though. This defaults to on.

Previously, player engineers would never assist allied faction's factories at all.

Thanks to Chthon for suggesting.

Also added "Factories Build For Allies" to the same location:

With this enabled, your factories will build ships for the fleets of allied factions. Note that specialized factories (like Spire ones) will always build for allied fleets of their sort, regardless of this setting.

This also defaults to on.

Thanks to Chthon for suggesting.

Previously, the list of fleets that a factory was building for was calculated separately on the main thread and was inaccurate.

It's now calculated right where the actual assistance logic happens, on a nice background thread for extra speed, and thus also gives fully accurate results.

Additionally, this no longer includes fleets that are empty or where all the ship lines are disabled from construction, or where the fleet can't build anything in a factory style.

Added a new "is_ignored_by_factories" option to units so that we can mark things like metal harvesters that don't self-construct but also don't get built by factories.

This helps us limit down the list of fleets where there's actually something for a factory to help. Previously this wasn't visible in the UI, but was wasting a very minor bit of time on the backend (and with the other recent changes, now it was visible in the UI).

Split "Repair Allied Units" into two settings: "Repair Other Player Units" (defaults to on) and "Repair NPC Allied Units" (defaults to off).

Thanks to Zeus for inspiring this change.

The internal logic for how construction assistance is calculated as desirable has been adjust a bunch to make it smarter.

There were a number of funky things that could happen in there before, but the logic has been streamlined and now matches the above logic described.

It was also possible for engineers in pursuit mode to invisibly help other units beyond their actual assistance range, and that was only detectable based on the metal flows pane. That's also fixed.

The revised method for this allows for engineers to have targets that are out of their range (and then decide between them in the moment), but not to magically boost things that are extra far away.

Thanks to Daniexpert for reporting this latter problem.

In multiplayer, if your engineers are helping to claim something on the planet of another player, then when claimed the unit or structure will belong to the planet owner instead of you.

These units can be freely swapped around anyhow, but generally this sort of claim-sniping is accidental and frustrating.

Thanks to Tzarro for reporting.

Structures under construction should no longer complete themselves if it would put you into negative energy balance.

Brownouts are already more forgiving, but in general this is good policy.

The way that metal is spent by engineers assisting construction of units, or assisting factory production of units, is now completely different.

Now rather than showing as excess construction costs on the target (in the metal expenditure details), it now shows as an engineer expense separately.

This also fixes an issue in that it was charging the other faction rather than you. So if Alice has engineers help Bob build a thing, Bob was paying for those engineers, which is kind of missing the point. Now Alice pays for the work of her own engineers.

This pretty much only comes up in multiplayer, and has just been on our todo list for a long while. Engineers doing repairs has always worked properly (so if Alice was allied to the Dark Spire and repairing their ships, it would charge her and not them, etc. Same with Alice repairing Bob ships).

Previously we had a single "AssistConstruction" metal flow purpose (action) for engineers and otherwise, and that was problematic for a lot of reasons.

Essentially, helping build a structure or helping a factory churn out units are two different actions with different code needed to really have the intelligence work properly, so we have AssistSelfConstruction and AssistFactoryConstruction now.

You can still define ships in xml as having "AssistConstruction" and it will give them the same benefit to both of those things internally. So this won't break mod xml.

However, we are making the deliberate choice to make it so that, for instance, the Engineering Factory cannot assist the construction of other factories (just structures).

We have also had to add a new "Assist Allied Construction" option, since this is now distinct.

With this enabled, your engineers will assist the construction of allied faction structures.

Added a new personal setting in the debug category: "Include IDs On Targets In Metal Flows Window"

When this is on, any targets of metal flows (left click the metal indicator in your HUD) will include the IDs so that you can tell when there are referrals to the same unit versus different ones.

Fixed an issue where if you had given a direct order to an engineer to assist something, it would do some or all of the following:

Not go repair that thing because it was out of range.

Go and do lots of other kinds of repairs that were completely invalid, but charge you for them (aka, don't just boost the factory, but also self-build it when it's already built, and repair its hull when it is at full hull), in addition to whatever it was you intended them to do.

Visual Improvements

The shaders for the characters in the background on the main menu hangar scene are now more traditional. They no longer look glistening and metallic, and the rolling normal maps that caused an aliasing-like distortion is no longer there.

The scaling of the expansion logos on the main menu has been adjusted so that none of them are cut off, and all of them have a similar font size (before, shorter titles wound up taking up the same amount of horizontal space, making their font much larger).

Adjusted it so that ship to ship lines do not disappear when you pause the game.

It was still decrementing their time to live timers, when really it should not have been while the game is in a paused state.

Fixed a super mega ultra longstanding issue from the last five years where shots would gradually ease in and out of motion when you paused the game.

Also, things like explosions, lightning blasts, and most other special effects now pause when the game is paused. So does the planet rotation in the background.

Things that are purely vertex animations, like stationary structures rotating, or forcefields pulsing, do not pause.

Individual ships now do a better cleanup pass on themselves if they think they might have had lines associated with themselves.

If those lines are not related to themselves, then it's time to remove the references.

If those lines ARE related to themselves, but are on a different planet or have timed out, then they delete them and remove the reference.

Found an issue where we were resetting our line IDs back to zero at various points making indexing them a massive problem.

This in turn was probably what was leading to some lines getting left over on the screen from time to time.

ArcenGameObjectResourcePools now keep explicit track of every item they have ever created. These are in both managed and unmanaged memory, so that's kind of a wise idea.

Added a DoForEveryIArcenGameObjectResourcePoolable() on that class for us to be able to iterate these from code.

There is now a DeactivateAndReturnToPoolAnyIArcenShipToShipLineIfActiveAndMistakenlyEnabled() that is run every frame, looking for invalid lines.

Overall it should be pretty efficient, because there's only a pool of a thousand or so lines to begin with, and almost all of them are dormant most of the time.

We have tested this and found that it is actively clearing some lines, potentially those that were not quite yet to the point of clearing themselves from some other context (since this particular action can only happen on the main thread). The CPU impact is negligible, and this should make it impossible for lines to hang around even a single frame longer than they are supposed to be.

Thanks to ZeroTheHero and others for reporting.

The Spire Repair Center now has a proper shortname for the sidebar, instead of still saying Spire ENG Center.

Thanks to Darkshade for reporting.

Random "UnityEngine.PostProcessing.EyeAdaptationComponent.get_active ()" exceptions should no longer ever happen. They didn't hurt anything, but were annoying.

Thanks to Badger, Daniexpert, and Strategic Sage for reporting it. Chris was also seeing it.

Stinger bolts and certain other weapons previously had text that read along these lines: "If the target has a max bubble forcefield strength of more than [10,000], then the above weapon does [4x] damage to the target's shields (personal or bubble-forcefield)"

This has been corrected to say "If the target has a max bubble forcefield strength of more than [10,000], then the above weapon does [4x] damage to the target's bubble-forcefield."

Thanks to GreatYng for reporting.

Mod Updates

Kaizers Marauders:

The Fortified Forceshield Generator now uses moves_back_after_being_norrised="true" instead of the tag "MovesBackAfterBeingNorrised".

 

3.309 Hangar Staff

(Released July 12th, 2021)

Hacking Estimate Improvements

Hacks against planets (weaken turrets/guardposts) now have a strength estimate

The following minor faction hacks now also have estimates

The DZ Library hack to get ship lines

The "Get Scourge Allies" and the "Cause DZ to appear" hacks

The Contact Outguard hack as well

Like all hack estimates, these are ballpark at best.

The hacking history now also records the approximate response to your hacks when appropriate

From a discussion with an anonymous newbie dunce wearing a silly hat

Battle Indicator QoL tweaks

The goal is to make the indicators more likely to be useful indicators of important battles that you care about

Indicators no longer appear on unexplored planets

Indicators no longer appear on Dyson or Nomad planets unless you have forces there (these indicators tend to be Always On)

Indicators are now allowed to appear on AI planets if you have forces there.

Very small battles that don't involve your forces won't appear

Prompted by a discussion with Metrekec and Evil Bistro

Main Menu Hangar Scene Visual And Performance Improvements

The shaders used for the ships and walls and such on the main menu have been completely reworked.

The logos on the wall have been made a lot more efficient. The DLC ones were causing many extra draw calls, while the Arcen one was 400% more polygons than it should have been ugh!

The main menu now uses the Deferred rendering pipeline, which is more efficient when you have a lot of light sources, rather than using the Forward render pipeline. This is something we did in our title Release Raptor, and other unreleased titles, but it never seemed to have relevance in AI War 2 until now.

At this point, the main menu was doing double or triple work a lot of the time, according to our investigating with the Frame Debugger, because it had multiple light sources hitting many large objects that each had lots of draw calls.

Now that this is in deferred rendering path, the overall visuals of the main menu hangar scene are a bit different. The lighting is different, and overall blends differently.

The first thing that needed to be adjusted was the ships themselves. They're now darker and more menacing, fitting better with the theme here.

The second thing is a few of the materials which were overly reflective when in the Deferred path. Those have been adjusted.

Thirdly, we were already using Screen Space Ambient Occlusion (SSAO) on this scene to make it look nicer, but that has been made much more substantial so there is more of a feeling of contrast between light and shadow, and because otherwise some of the background elements seem to otherwise be disconnected from their surroundings based on how their materials were.

At this point, it's clear that one of the remaining MAJOR sources of load on the main menu is the Reflection Probe, which is running in realtime. It's time-sliced to do all the sides at once every so often, so essentially it causes a quadrupling of load every few frames.

But just what exactly are we meaning to reflect? The dramatic skybox is really what we want to see from this reflection probe that we can't get any other way. In the past, with the reflection probe doing all the work, it was impossible to do more time-slicing or anything else to make it more efficient or it would look jerky. But now that we're in the Deferred pipeline here, we have a depth buffer (beyond the basic zbuffer) and way more info.

With that in mind, the first step was to disable the reflection probe and see if we could get that to work. Short answer: not really. The scene is super dark and strange without the reflection probe at all.

The next step is to implement Screen Space Reflections (SSR), which again is something we've used in other projects many times. We just went with the basic Unity implementation, as we don't need something super fancy.

The initial results from THAT are actually quite impressive. Most notably, it makes the reflections from the emissive light sources a lot more dramatic. That's cool! But, of course, since the skybox is a very small part of the screen, it contributes very little light to it. So overall the scene is very dark and doesn't have that periodic bright lightness to it like before.

Next step is turning back on the reflection probe, but time-sliced to only update one side at a time (previously this caused things to look jerky). Since we're now blending two layers of reflection, the jerkiness is entirely gone!

But even so, now it's time to turn our attention to what the reflection probe is reflecting. It simply needs to reflect the sky. Not the walls, not the floor, not the ships -- the SSR already takes care of those things, and in a none-frame-jittery way. Those are the bits that jitter even now. PLUS, it's drawing all that geometry for the reflection probe that makes it take so long. What if it... skipped most of that?

Therefore, we moved the skybox into its own layer, and two blocking planes as lighting mats to prevent certain kinds of unrealistic light bleed. It's like a movie set, the lighting gets bounced how we want by stuff just off camera. At any rate, now the reflection probe just reflects those dark mats and the sky, and it blends perfectly with the SSR at a teeny tiny fraction of the processing power, AND it's time sliced. Major win.

Finally, by using Mesh Combine Studio, we were able to split the main hangar itself into more sub-objects and also batch them a bit more efficiently. Overall this is a lot more efficient than sending a ton (12) of submeshes to the GPU all at once. For weaker GPUs in particular, or weaker GPU buses, this was probably the main bottleneck. Overall we also were able to scrape out even some more polygons with this.

Oh yes, and we also no longer draw the loading screen and all its special post processing effects behind the main hangar scene. That was a real waste of processing.

The final result is a scene that looks very similar, but actually more grounded and dramatic, plus way more efficient. Draw calls are down from the 300s to the 120ish range, and total vertices drawn are now about 60-something thousand rather than over 400 thousand. The actual UI part is still drawn with a Forward camera and is still as sharp and normal as ever. Because of the revisions to how the reflection probe is integrated, more of the scene actually gets lighting contribution from the outside sky, which also looks even better. Chris's machine went from about 100fps on it to closer to 140fps.

Okay, another round of major changes to the main menu scene. The prior version that we had completed for this build was very high performance, but... bland. The lighting was not reflective at all, and so there was this odd flatness and dullness to things. That's no good at all.

Then also we lost some of the combination work, and had to recreate it from better-looking originals that actually turned out to be quite low-poly. So that completely reworked the roof rafters and the front door area.

We then added in a ton of uv emission animations and uv normal map animations, which are things that make static surfaces seem to come alive in various ways. We added more details in various points, too, to continue to break things up.

The reflection probe is back and no longer time-sliced at ALL, but this winds up only sacrificing 6fps on the really old OSX machine because of the layer mask used for it, and that helps bring the scene back to life more.

But even so, it would be great if this felt more alive in general, so we added distant lights in the rafters, lights along the launch strip, and so on. There's also a new robotic arm that can be animated later, but for now it sits still.

Another longtime request was to have some people moving around in here. At first I added just two folks fully suited-up talking to one another by the door. Their conversation is randomized and all in body language.

After discussions on discord, I also added a third guy standing nearby ignoring the first two and looking really impatient with the door. He swings his arms, checks his watch, stomps his foot, crosses his arms, and a variety of other things over time. There's also a fourth guy who sits way over by himself amongst some machinery he is probably not supposed to be in. He just kind of sits there bored, looking around a bit.

The launch animations had a few problems that were apparent now with the revised exit doors, and so those all have been updated slightly to make them more smooth and so that there is no "pop out" period in terms of the reflections.

With two characters, fps on the ancient mac was 30 fps. With four characters, it's 29. But it's still far more smooth than it used to be on that machine, while also way more visually interesting. In other words it's not a laggy 30fps, unlike before (where it was 24fps anyway). On my nicer machine, I get around 75-90 fps still, and the fan doesn't even turn on. Hopefully that will be the case for more people, although that machine is running a GTX 1070 M.

After more discussion on discord, a small transparent safety barrier was added on the side where most of the characters are. It would not meet OSHA guidelines, but it will keep them from the worst of falls.

We temporarily experimented with characters that were having floating conversations, but there's no way to make that look fully natural because hand motions would normally impart a spin, and that would devolve quickly. You can see videos of all these intermediate versions on discord, if you're curious! It's in the watch_chris_art subchannel.

More Visual Updates And Additions

All of the wormhole graphics have been updated to a new particle effect that is a bit more funnel-like, and which shows brighter colors for the various types of planet you might be looking at through it.

It still doesn't have a mouseover effect, which is a bit odd and something we plan to improve at some point in the future.

Thanks to nas1m, NR SirLimbo, and Evil Bistro for seeing some of the particle work I was doing and suggesting it be adapted to the wormholes.

The metal harvesters, and the empty asteroids when they are not yet built, now have improved graphics (base game).

Essentially, the rocks look like they have better lighting and look more rocky.

And instead of the domes just glowing like a lunatic, they look like they have subsurface scattering (it's a paint effect, not math), and the entire structure looks more weathered and beat-up.

The Swarm Cruiser (ZO) has been updated to now have 3 LODs rather than none.

Various units from ZO with new art:

Lockdown cruiser, Ethereal Cruiser.

Minelayer frigate, Gravitational Rift, Spymaster, Ambush Post, Unstable Gravity Generator.

Starburst (weapon), Gridlock (weapon device), Deadlock (weapon device).

Ambush drone, Hoplite drone, Murderfly, Reclamation drone.

Disabled nomad nexus, Hacked nomad nexus, Crashing nomad nexus.

Demeter's Cornucopia.

Zenith Miner Probe (complete with scanning visual effects)

Tweaks And Fixes

FixedResourceTextStats now requires a name for the resource, and has a string for the resource name in its color. This way it's always accessible.

For Spire Relic Trains, I have rewritten the hovertext for this notification for improved clarity, and also improved the "pick next planet to for relic train" logic to help it find some better planets

Thanks to Evil Bistro for reporting

Renamed our "SelectionManager" class to "PlanetViewSelectionManager," since that was conflicting with a built-in unity class otherwise.

Put in some code to prevent larger damage from anything InitializeSquad() gets wrong, as well as more info to let us know what happened if it does go wrong.

Such as when, for instance, the test chamber is instructed to initialize a ship that does not exist.

Mod Updates

AMU:

Created the utility functions getHopsToAnyAIPlanets() and getMaxHopsToAnyAIPlanet().

Created multiple new rollups for upcoming mods...

GameCommand_MoveAllToPlanet now has an optional destination location where ships will aim to move at.

Added a new GameCommand_MoveToPosition which can be used to simply move something to a position, no questions asked.

When PseudoTransformEntityType_ReturnNullIfClient now copies the seconds until repair is possible and the game second the planet was entered over from the old entity into the new entity.

This fixes transforming entities in AMU-derrived mods from being susceptible to ambush damage modifiers, or potentially having their own damage modifiers apply anew, as well as immediately regenerating shields (most notably and annoying when a Devourer from Devourer Chrysalis became enraged).

The DrawingBagBase class and its children can now use AdjustWeightBy and AdjustWeightTo functions.

Devourer Chrysalis:

Adjusted to AMU changes.

More fixes for the Hydra Devourer type:

Put in another fix for the Hydra Devourer heads having hacks. This required a fix from Vanilla code.

The Hydra Devourer head icons are now much smaller.

The artillery on greater heads can now target down to 7 tx units, and the artillery on lesser heads can go down to 6 tx.

The spawn frequency of heads was reduced to 20% of what it was.

The heads no longer grant science on death. Gaining 50k science from slaying a single head at the frequency those were appearing could be farmed for near infinite amounts of science.

Added instrumentation for an error in the enraged transformation code. It's unknown where it came from, everything looks fine, but if it appears again next time there should be more info.

Thanks to Isiel for reporting.

Kaizers Marauders:

The player variants of all Marauder Raiders are now bigger and have no more icon overlays, freeing the overlay up for the ship count contained.

The Reprocessors: Fixed spawning outside of gravity wells. If there is a bug then please message me on Discord.

Updated the Macrophage Histiocytes mod to not have too-long names for the sidebars.

Devourer Chrysalis:

Fixed some bad wording in the mod description.

Devourer Chrysalis:

The Hydra Devourer lesser heads don't spawn themselves in an infinite, ever-increasing loop any more.

Thanks to Lord Of Nothing for reporting.

Devourer Chrysalis:

Removed all hacks from the Hydra Devourer heads.

Thanks to Lord Of Nothing for reporting.