We’ve fixed a nasty HVC Monorail bug for 0.1.2!

v0.1.2 settings changes (1)

This week, we’re pulling out the big guns, because we’ve fixed a big bug. The nastiest HVC (High Voltage Cable) and Monorail bug has been fixed for 0.1.2! 

As we continue to improve and fix bugs for QoL update 0.1.2, we’re posting more info about the bugs we’ve squashed and improvements we’ve made. Reminder, this update will launch sometime around the end of October or early November. 

In case you missed last week’s update with Joey, we’ve worked on a slew of Machine Streaming improvements for 0.1.2 that we’re really excited about. This week is all about tackling a big, big bug.

I (Lauren) spoke with Sharat, Lead Engineer for Techtonica, about what caused the HVC and Monorail to fight each other and how they fixed it.

What bug are you talking about? 

In case you never encountered this bug, it appeared to be pretty simple. If you tried to attach the HVC to the monorail, you would get no power. Y’all flagged this as a really frustrating error to encounter, so our team pushed hard to get it fixed. 

And, we totally understand that it was frustrating! But it was a complicated bug across systems, which meant it took some time on our end to solve. 

So, what caused it? 

The bug with monorails using power over HVC’s had to do with the way our power networks are set up. Simple power networks are created for contiguous sets of power floors. They get updated whenever you build and erase floors. Voltage Steppers allow you to connect multiple of these simple power networks together via HVC cables and splitters. 

We have a separate HVC network concept that we use to check if two Voltage Steppers are connected to each other by a chain of HVC’s. The way we track those connections is by linking together any simple power networks that have Voltage Steppers on matching HVC networks. 

When we connect the networks this way, we’re marking one of the simple power networks as a “child network” and another one as the “parent network”. For normal power usage, we run everything through the parent network, checking the power needs, power supplied, and accumulators across all of the child networks. And that system all worked fine for our initial 0.1 launch.

So what’s special about monorails? Well, monorails require power in two different ways. First, in the same way as assemblers, they consume some small amount of power every tick in order to run baseline operations such as unloading and packing batches of resources. However, monorail depots require an instantaneous burst of stored accumulator energy in order to send out a new cart of resources. We use accumulator energy directly in a few other cases, such as when upgrading a production terminal or activating late game techs. When the monorail wants to send out a new batch, it sends a request to its associated power network to find energy to use. 

The bug came up when that power network was a child network. The bug caused the child network to not properly forward that request to its parent network, which would result in the energy request never being granted to the depot. In 0.1.2, we’ve fixed it so that the parent network now handles all the requests in all of its child networks now. Editor’s Note: I did suggest trying a therapist, too, to resolve their issues. But it turns out it was actually tech related.  

But wait, didn’t I say that there were other cases using the accumulator energy? Why weren’t they broken in the same way? Well, it turns out that all the other cases were already special cases. When using energy to activate a tech, we currently just draw from all build accumulators directly, ignoring connectivity.  For upgrading the production terminal, we’re checking directly for networks connected to specific HVC ports on the terminal. It’s using a different flow since it’s searching for parent power networks from the HVC connection instead of from the floor connection. So in the end the monorails were the only case where the bug would show up.

Does the monorail still have other bugs?

Yes, this only fixes the power issue – which was the biggest one. We’ve noted that there seems to be some complicated cases for monorail bugs with save/load. We’ve added a few more safety measures in 0.1.2 to help avoid those issues from breaking the save completely. However, we still haven’t solved the root problem, so there may be some issues with some mid-transit monorail batches getting lost or duplicated when loading a save. That’s a larger code refactor than could fit into this update.

As always, you can join our Discord to hang out with our community and chat with our team. Find us at https://discord.gg/techtonica.

We’re also streaming on Twitch twice a week at https://twitch.tv/firehosegames

Until next week! 

More Recent News