v0.1.32 (Early Access)

Czech, Danish, Polish, Spanish and Brazilian Portuguese join German and French. Patch panels go on sale, and you can finally cable one. Every kind of customer can ask you for more capacity now, not just the ones running virtual machines. Machines running functions are counted as busy instead of reading empty. Network gear that is full actually drops traffic, and latency climbs as a link fills instead of sitting flat until it bursts. A load balancer or CDN with nothing placed behind it no longer earns money. This one changes difficulty and income, so read the notes at the bottom before you load a long campaign.

Added

Languages

• Five more languages, all experimental. Czech, Danish, Polish, Spanish and Brazilian Portuguese join German and French. Pick one in Settings. Coverage is the same as the other two: shop, ops console, incidents, customer cards, quests and the loading screen, with the engineer wording behind Tab written separately rather than copied from the plain wording.
• Spanish is written for Spain, Portuguese for Brazil. Both are the variety the whole translation was done in, rather than a neutral blend that reads slightly wrong everywhere.

Patch panels

• Patch panels are on sale, under cable management. They have been in the game's hardware list for a long time, but no part of the shop ever listed them, so there was no way to buy one. A 24 port RJ45 panel now sits beside the trays and hooks.
• A patch panel takes a cable. Its sockets were built to accept nothing at all, so a panel that did reach your rack refused every lead you tried to run into it. It now takes Cat6A and Cat8 leads and turns away fibre, like any other copper socket.
• A 24 port panel gives you 24 circuits. It used to create half that: twelve usable joins on a panel labelled twenty four.
• You choose which side of a coupler a cable lands on. Every coupler has a front jack for a patch lead and a rear termination for a structured run. Both are aimed at from the front of the rack, so you never walk round the back: look at a coupler and you get two targets, the rear one ringed in amber. Before this, the game picked the side for you based on where the other end of the cable happened to be, which meant a switch one rack unit above could only ever reach the front.
• A run into the back of a panel goes round the back. It leaves the cable manager heading straight into the depth of the rack and arrives at the panel from behind, instead of cutting sideways across the face of the rack and through the manager arms.
• A panel is a join, not a device. It has no power and no lights of its own. A cable into a coupler with nothing on the other side shows no link at either end, because the run ends inside the panel. Complete the join and both ends come up together.
• Hovering a cable that runs through a panel tells you both hops. It names the coupler, which of its two faces you are looking at, and the device on the far side of the join, so you do not lose track of what is actually on the other end.

Changed

Your network can now be the bottleneck

• A switch that is full drops traffic. Trunk and backplane congestion raised an alarm, coloured the map and cost you nothing: your servers kept serving as though the switch were empty. It only ever bit function calls. Congestion now costs requests for ordinary servers and for Kubernetes too, worked out per server from the path that server is actually using. A switch a tenth over its limit drops about a tenth of what crosses it.
• A saturated link and a saturated router cost you as well. Same story in both cases: a warning with nothing behind it. The router uses the same figure its own alarm trips on, so the light and the consequence finally agree.
• Latency climbs as a link fills. Every hop cost the same fixed amount whether it was idle or at ninety-nine percent, so there was no warning before a link fell over. A hop now runs at about 0.13 ms while there is room, 0.9 ms at eighty percent, 2.9 ms at ninety, and is capped so a badly congested path degrades rather than dying outright.
• A faster link is now faster even when nothing is congested. Upgrading a 1G run to 10G previously changed your latency by exactly zero unless you were already over the limit. The time it takes to put a packet on the wire is part of the sum now. On a quiet link that is a hundredth of a millisecond a hop, so you will not see it on the dial, but it is no longer nothing, and it grows into a real difference as the link fills.
• "Your network gear is full" is now its own reason. Congestion was being reported as "no route to their servers", which is what you get when a cable is cut. Two opposite problems with opposite fixes, reading identically on the customer's card.
• Traffic coming in uses your network card, not just traffic going out. A server had a budget for what it sent and no limit at all on what it received, so any number of machines could pour into one box and it would swallow all of it. Both directions are metered now.
• A connection swamped from the outside now costs you. Inbound saturation raised the alarm and dropped nothing, so a flood could fill your line while every customer stayed at a hundred percent.

Money

• A load balancer with no proxies running earns nothing. It billed every request at the full rate with nothing placed behind it at all, including for a customer who had bought nothing else. It now bills what it actually serves, and a load balancer with a live proxy is unaffected.
• A CDN with no points of presence running earns nothing. The cached share of its traffic, which is most of it, was billed unconditionally and consumed no hardware. Now it is served by the machines you placed, and shows up in that customer's bandwidth, which read zero before no matter how much they were pushing.
• Storage replication costs what it should. Writing into a bucket kept three copies was costing less bandwidth per machine than keeping one, because the write was being divided across the copies instead of sent to each. Raising durability now costs what raising durability costs. Your bill is unchanged.

Fixed

Customers asking to grow

• Every kind of customer can ask for more now, not just the ones running virtual machines. A customer who bought only storage, only a cluster, only a CDN, only a database, only functions or only a load balancer never asked you for anything, ever, for the whole life of the contract. They were quietly shut out of growing at all. They now ask in the units they actually buy: a cluster asks for workers, a bucket and a CDN ask for space, a database asks for another copy, and functions and load balancers ask because they are being hit harder. Approving applies to the thing they asked about.
• A customer who does not run virtual machines can no longer be sold something your fleet cannot hold. New customers get their ask trimmed to what you can actually serve, plus a little headroom. That trimming only ever looked at virtual machines, so an offer for a forty node cluster, a huge bucket or a content delivery contract with an enormous origin arrived at full size no matter how small your site was, could always be signed, and cost you nothing to turn down. Those offers are now sized against your fleet like every other one, and the signing bonus scales with the trimmed size.
• The capacity verdict on a growth request tells the truth for every service. The panel that says whether you can serve an ask worked it out from the customer's virtual machines. A customer who has none, a cluster or storage tenant, came out as needing nothing at all, so a request of any size showed as comfortable. You approved it and nothing appeared.
• A customer whose contract cannot grow any further says so. Approving used to report success and change nothing in a couple of cases. If the contract has no room left, the approval now tells you instead of thanking you for capacity that was never going to appear.
• Approving a growth request no longer doubles a replicated customer's fleet. The check that decides how far a customer's target can move was counting copies rather than machines, and a replicated or multi-zone customer runs two copies of every machine, so approving anything at all dragged their target up to the copy count. It compounded on every approval. One player watched it reach 112. Loading a save pulls an inflated target back down to what it should have been.
• Replicated customers stop asking at the right size, not half of it. The same miscount ran the other way on the ceiling that decides when a customer is satisfied, so a replicated customer went quiet at half the fleet it was meant to grow to.

Functions

• A machine running functions is no longer reported as empty. Function containers were tracked separately from everything else on the floor, so a server packed with them showed no load in the capacity view, no workloads in the network view, and its status light stayed on idle. The customer running them was not listed as using that machine either, which fed the diagnosis panel and the noisy neighbour warnings. Containers are now counted like every other workload.
• A functions customer is a real target. Because their containers were not counted, an attacker sizing up a functions-only customer found nothing there and always picked the smallest possible attack.
• The room left for functions counts every kind of work, not just virtual machines. The figure behind "this customer's function pool is full" was the fleet total minus what virtual machines had taken, and nothing else. A site packed with cluster workers, load balancer proxies, storage or CDN content looked completely empty to functions, so a customer could be told they had plenty of room with nowhere left to run.
• A functions customer with nowhere to run is no longer reported as served. Whether their contract counted as delivered was decided by asking if any machine anywhere on the site was switched on. Not their machines, not the ones they are allowed on. So a functions customer whose pool was completely full, or who was walled into a private segment with nothing left in it, read as perfectly served while every one of their requests queued and timed out. It now asks whether that customer can actually be served, which is the same question the warning on their card already asked.

Your fleet at a glance

• The fleet utilisation graph shows your fleet. It was showing the memory held by function containers, divided by the fleet minus what virtual machines had taken. If you had no functions customer, and most campaigns do not, it sat flat at zero however full your site was. If you did have one, it plotted their containers as though nothing else existed. It now reads the same load figures as the capacity view and the machine list, so the graph and the panels agree.
• Used rack space counts your gateways and demarcation boxes. The Capacity console's rack U figure added up servers, switches, patch panels and security appliances, and stopped there. Anything else you had bolted in occupied real slots you could see, and did not appear in the total, so the console told you that you had more room left than the rack did. Reported against an earlier build: switches and appliances had already been picked up by then, gateways had not.

Diagnosing a service that will not start

• "Every server is full" and "add a server this customer is allowed on" are told apart properly. When a customer confined to their own machines had nothing running yet, the game could not work out which of the two it was and defaulted to telling you the fleet was full. You bought a server, it landed outside their private segment because it had to, the warning did not move, and nothing you did helped. It now works out what one unit of their service would need even when none is running, so it names the right fix the first time. This affected clusters, CDNs, load balancers, storage and functions.

Incidents

• Two faults at once no longer blame each other's customers. A cut cable in one rack and a dead switch in another each reported everyone affected by both, so the money at risk was double-counted on each and the post-mortem named tenants who never touched the thing that broke. Each fault now reports only what is actually stranded behind it.
• A customer with a surviving copy is not having an existential outage. Any infrastructure fault touching one replicated or multi-zone customer was reported at the top severity, whether or not their other copy was serving perfectly. It now checks whether they actually lost everything.
• Diagnosis checks the cable is on their path. With two cables cut in different racks, both scored identically for every cut-off customer, so the ranking told you nothing. A cause now has to be on that customer's route to score for them.

Hardware failures

• Turning off the random failures now works on an existing save. The last release switched them off for new games and said loading a save would do the same. It only half did: the setting is stored twice, and only one copy was being cleared, so a sandbox save never lost them and any save got them back the moment you touched a difficulty or world slider. Both copies are cleared now. If you deliberately started a hard run, that still gets the failures it asked for.

Hardware you did not buy

• Setting a piece of gear down no longer leaves a second copy of it behind. Pulling something out of a rack stages a crate so you can put it straight back. Setting the gear on the floor instead ended the carry but left that crate sitting there, so you had the machine at your feet and an unopened box claiming the same machine. Opening the box handed you a second one, for free, and it survived saving and loading. Loading a save now clears any of these left over, and nothing you legitimately own is touched.

Notes

Existing saves load here with everything intact. Saves written by this version carry a little extra on growth requests, so if you go back to v0.1.31 afterwards, load one of your older files rather than the new one.

This release is harder. Congested network gear now costs you requests where it previously cost you nothing, so a site that was running at its limit and getting away with it will start showing failures. That is the intended behaviour and it is the mechanic the hardware ladder exists for, but if you have been running a switch permanently pegged, this is the update where you notice. Latency also climbs as links fill rather than staying flat, so a busy path will show worse response times before it shows failures.

Two products stop earning for nothing. A load balancer with no proxies placed, and a CDN with no points of presence placed, were both billing full rate while doing no work. If your income drops on loading, that is where it went. A load balancer or CDN with real hardware behind it bills exactly as before.

Machines running functions will look busier. Their containers were never counted against the machine holding them, so capacity and load readings on those servers were too low. Nothing moved and nothing was bought: you are seeing work that was always there.

Your utilisation graph will jump on loading, and the history behind it is wrong. The line was never measuring your fleet, so the minutes already recorded cannot be corrected: they will read low, usually zero, until they scroll off. From this release on it tracks the same figures the capacity view shows.

A functions customer may report a problem the moment you load, and a brand new one can now walk. If their pool has nothing left, or they are confined to a segment that is full, their contract now reads as not being served, where before it always read as served. Nothing about their situation changed, only whether the game admits it. Freeing up room on machines they are allowed on clears it.

The part to watch: a functions customer you have just signed, who never gets a single container running before their settling-in period ends, now leaves and takes the same doubled reputation hit any other customer would. Previously they stayed on the books forever, served nothing, and cost you nothing. Signing functions work onto a site with no headroom is a real risk now, the same way it always was for virtual machines. An established customer is not affected: this only applies while a new one is still coming up.

Loading an existing save clears the random hardware failures properly this time, including on a sandbox save and after you move a difficulty or world slider. The previous release claimed this and did not manage it.

Write traffic on replicated buckets goes up on loading, roughly in proportion to how many copies you keep. You will see it on the servers holding the bucket and the switches above them rather than on the customer's own figures. Nothing was bought and no bill changed, the write traffic was simply being counted wrongly.

Patch panels are new to the shop rather than changed, so nothing in your existing saves is touched by them. No save can contain one, because there was no way to buy one before this release.

Cable tidiness is still not part of this. It continues to report neatly routed cables as loose, and it is being reworked rather than patched around.

Multiplayer sessions need every player on the same version, as with v0.1.31.

If you read the API, this release renames fields. A run of numbers were named after virtual machines while actually counting every kind of workload, which meant anyone reading them got a wrong answer for a customer who does not run virtual machines. They now say what they count:

• On a customer: vm_count is unit_count, vm_distinct_hosts is distinct_hosts, vm_max_on_host is max_units_on_host, stranded_vm_count is stranded_unit_count.
• On a host: stranded_vm_count is stranded_unit_count. The separate vm_count on a host is removed: it counted only virtual machines and read zero for a machine full of cluster workers or storage. Use unit_count, which counts everything and was already there beside it.
• On a rack's customer impact: total_vms and healthy_vms are total_units and healthy_units.
• On capacity: unplaceable_vm_count is unplaceable_unit_count.
• On a growth request: additional_vms is additional_units, and a new class_tag says which service is being asked for. The amount is in that service's own unit, so it is a count of machines only when class_tag says virtual machines, and is gigabytes or requests per second otherwise. Read class_tag before interpreting the number.
• On the function pool: vm_reserved_mem_mb is non_function_reserved_mem_mb and vm_reserved_millivcpu is non_function_reserved_millivcpu. This one is a change of MEANING as well as name, so re-read it rather than remapping the field. It used to report what virtual machines had reserved; it now reports everything the fleet has committed to anything that is not a function, which is what actually stands between the function pool and the fleet total. ceiling_mem_mb and ceiling_millivcpu beside it change value for the same reason, without changing name.

These are the names the API reports, not what is stored in your save.