Upgrade Queue Mechanics needs tweaking


One suggestion I’d like to make is around the way Upgrades works / dont works…

When I have a Planet with say 10 Small Beron mines in total, and I place all of the 10 in an Upgrade queue, Beron Production Completely stops.

This is the same for Power, Science, Entertainment Centres, Civ Centres ETC. Basically any building you might want to upgrade.

The issue is, that all 10 in the Upgrade / Construction queue, Immediately goes offline. Early game this is not so much of an issue, but late game, If I have 20 T1 Science centres on a single planet, which I want to Upgrade to T2, it means I will lose 20 Science points (on a sliding scale as the upgrades complelete), for 80 Hours.

This does not make sense.

It’s like whilst the first science centre upgrades, the other 19 in the Queue waiting for Upgrades stop functioning. AND THEY SHOULD NOT. They still count towards Employment numbers, they still consume power, etc. Does these “employees” go to work and sit there doing nothing?

The only way around this, is to upgrade 1 building at a time, waiting for it to complete, and then doing the next…making it an excessive tedious process.

Can the devs not change this mechanic, so that the only building affected in an Upgrade queue is the actual building being upgraded at that point in time??? Should not be that difficult, and makes alot more sense than having the building consume power, employment and not doing anything whilst in the Queue.

Or at least then reduce the amount of time it takes for subsequent upgrades in an Upgrade queue, based on the amount of structures being upgraded. For example if I have 10 Beron Mines Being Upgraded to 10 Deep Beron Mines, in Stead of the Usual 4 Hours per mine upgrade time, make it 20 Hours for the lot. Then at least we could justify that even though the other 9 mines in the construction queue are not producing, they are “preparing” for upgrades, which makes the upgrade process go quicker when it’s their turn in the queue…

Something like that… hope what I’m trying to convey makes sense?


I like the suggestion. But let’s please not say things like “Should not be that difficult.” That trivializes the work involved and doesn’t add to the discussion.

And probably it IS difficult.

Right now building on/off function is tied to production queue. When it goes in, whether passed as a batch or added to an existing queue it’s deactivated. When each one comes out it’s activated.

Now imagine that each of those deactivated buildings instead doesn’t deactivate. And imagine each of those deactivated buildings is an object. Now instead of changing object state on receiving queue increment command and when an object finishes production queue, which has very distinct triggering conditions, imagine there are ten buildings in queue and one finishes. What happens?

The newly produced object has an active state (as usual), but also another object changes state from active to inactive. And the triggering condition on that is a bit weird. It’s not passed at the time the user inputs, nor is it triggered at the same time the newly produced object changes state. If it’s handled via multithreading, depending on how the thing is written, the intended next in queue deactivation might take effect before the newly produced activation - which is to say you could have two things deactivated. So you’d have to make sure it’s sequential, which means maybe writing the whole thing differently, except maybe it can’t be changed because it’s tied to other behaviors that are continuously evaluated (like deactivation on invasion or unhappiness or whatever) and though those could be rewritten too that might change the performance - which in turn would act out differently on different systems.

Could be anything, something different to that. When deactivation is not linked to user input, it depends on in-game passage of time and evaluation of those arguments, and that’s a whole different ball game. And if multiple buildings end up being deactivated at the same time because of the handler, maybe the whole planet shuts down and doesn’t start back up again, especially since maybe that system wasn’t designed with this sort of behavior in mind. So it’s not just whether the system acts correctly on its own or not, it’s also how other systems that interact with the system change, and what the requirements of those are and what those affect &c.

I do think buildings should only deactivate one at a time. I just don’t think it’s necessarily going to be a simple and easy fix.

I have only limited knowledge about programming mostly from friends who do it for a living and based on what they told me, the reason could be as simple as “It was easier this way”.

My guess is that the system checks how many of each structures is in the building queue and flags them as offline. Or semi-offline, because they still need labor and power but they stop producing resources and have no effect on happiness.

Correct, However Same mechanics is in use for when example resources are taken when building lots of items in a queue… So Same mechanic, just needs to tweak it

Following is all speculative. I don’t know how Outscape is programmed. I can guess, but they’re just guesses. Still -

@NinjaOtter: Looks to me like resources are removed from inventory when the user passes the request. If multiple buildings are queued at the same time all resources required to construct all buildings in the queue are removed at once - at least that’s how it works for me. And if an additional building is added to an existing queue, resources are removed then. As I see it that’s the same trigger - user input - as what’s used for deactivation.

My guess is changes to variables are triggered 1) on player input, 2) on queue completion, not on continual checks on what’s in a player’s queues. Then the program makes increments or decrements to gold, resources, and happiness based on those variables.

If the program instead has to check multiple planet building queues at any given moment there’s more calculations involved - rather than only updating variables on user input and queue completion, the variables are recalculated almost constantly. The process is more complicated in terms of execution, so more things can go wrong; it’s just easier to do it with variable updates.

Sure, conceptually there’s not much difference, and conceptually it’s better to do the latter as there’s more freedom to change things up. But in practical terms, in programming it’s usually best to minimize calculations and checks as a matter of course to lower system requirements and lower the number of things that need to be checked when debugging.

Again - I don’t know how Outscape is programmed. But instead of just “tweaking” existing programming, I think they’d have to write an entirely new handler for queue completion events that would interact with loads of different variables in entirely new ways. Or they would have to make changes to how queue completion events are handled, which would introduce a load of other issues from performance to newly introduced bugs.

Again - I think it’s a good idea to have single buildings deactivate rather than multiple buildings; it’s more intuitive to players that way. But I really do not think it is a “simple” thing.

Probably that doesn’t mean much because you can’t relate, so I’ll use an analogy. Say you want ice cream, just get in car, drive to grocery store, buy some. The hardest part is choosing a flavor. “Simple”.

On the other hand, if you’re starting with no grocery stores, no car, no dairy industry, no shipping infrastructure - you raise a cow from a calf which you got from somewhere, you raise fields of sugar cane that you refine into sugar, you build a refrigeration unit out of metal you smelt - you get the picture. It’s a major process.

That’s how programming is. If you have infrastructure that supports specifically what you’re working on that’s great. So if you’re trying to build a number of different variations of spreadsheet, say, we already have a computing infrastructure that supports spreadsheets and doing various things with spreadsheets.

But if you don’t have something that supports what you’re doing, you have to build it. Or maybe you source code or third-party it out, which means it’s hard to understand and work with - think you have a Phillips-head screwdriver but all you can buy is slot screws and one-way screws or Phillips-head screws in the wrong size &c.

Is that the case for Outscape? I am not aware of any existing easy to use interface with negligible cost that lets you create a program like Outscape that implements easily modifiable variables all at low system requirements. So the product has to be built from the ground up.

To extend the ice cream analogy, if you want ice cream, and there’s no grocery stores &c, maybe you do raise the calf and grow then process the sugar beets &c. But you are only trying to make ice cream for one person. You won’t necessarily want to go to the trouble of raising multiple cows, or giant fields of sugar beets, you won’t be founding a dairy industry, an agricultural industry, and a transportation industry to get ice cream to others. You’re just going to do what it takes to get the ice cream you want, and no more.

So in programming terms, sure, you could build a system that could handle variable inputs in very easy to modify ways. But making a system that can handle that sort of thing is going above and beyond requirements, like raising hundreds of cows or sugar beets stretching as far as the eye can see. Sure, you can build a system that can handle all sorts of changes, but it has more overhead.

So it probably isn’t simple, or a tweak. That isn’t what you want to hear, so it isn’t easy to accept. But I’m saying even if it is simple conceptually (which I’d agree with), I’d say it probably isn’t simple in terms of actual execution.

Again - I think it’s a good idea that ought to be done. I’m just saying I don’t think it’s going to be all that easy to do.

Are you saying all they need to do is find a way to make a different choice? Because they already have the cow and store and everything in place. (queue, construction checks, resource removal, offline mode for structures… ) And the only thing needs to be modified is the tag on offline buildings, from “everything in the queue” to “the one thing under construction”?

So, it is something that could be much easier to implement than sectors (for spawning) for example.


I ought to have contextualized the ice cream analogy re: the suggested feature.

I’m saying even if there’s cows and a store, there may be no sugar to make the ice cream with.

There just may be no infrastructure to handle the specific suggested change. Doesn’t mean there won’t be changes, or that the suggested change can’t be done. Just means if there isn’t infrastructure, that getting it done might not be a simple “tweak”.

The way I understand programming, when a computer processes instructions, ideally you don’t want to tell it “first you must do this, then you must do that.” Humans think that way, but computers often try to do a load of different things at about the same time, and forcing the computer to do otherwise is inefficient and costly in terms of processing.

To use an analogy, imagine you want to move a heap of sand from here to there, but instead of using a bucket, you have to move each grain of sand one by one. If a computer wants to do things easily, it doesn’t care if sand gets mixed around some so can be allowed to use a bucket. If precise ordering is important, though, grains of sand must be moved one by one so the precise order isn’t disturbed.

Consider the current implementation of building queues. Buildings go offline at user input time when they’re added to the queue. An alert is sent if stuff would go offline; if the player pushes it then okay, stuff goes offline, if not then it doesn’t. The player is entirely prepared to handle any consequences, or can avoid them altogether. As to buildings going online, there are no negative effects to a building going online that I know of.

So the current implementation uses buckets. If building “A” is finishing a production queue and somehow a command is processed that states building “A” is offline before building “A” is online, that sort of thing only is a problem if the program is constantly decrementing production queues (another reason I think it possible but unlikely). If it’s only incrementing there are zero problems, A didn’t even exist, A was offline, in either state A is not contributing anything, then A goes online, then there’s only good things happening. And if A went online before A went offline, it’s a single building, for a hundredth of a second or even half a second, perhaps there’s a momentary undeserved boost in farso production or happiness or whatever, but it’s not a disaster, the player might not notice, there might not even be any perceivable effect in terms of information reflected to the player. The takeaway here is under the current implementation, if stuff gets a little mixed up, it is not a problem in terms of things crashing or blowing up or major exploits. There is an issue with micromanagement I’d say, but it’s not going off the rails.

Now imagine the suggested implementation with only a single building going offline at a time. Imagine if building “A” were offline and just finishing being produced. When it’s finished, building “A” goes online and another building “B” goes offline. Imagine if you dump all those commands in a bucket. When the bucket is emptied, maybe the grains got jumbled a bit. So instead of “A” going offline then “A” coming online then “B” going offline in that specific sequence, maybe “A” is offline and “B” goes offline then “A” goes online. Now instead of something that maybe affects the game for a hundredth of a second or half a second whatever in an imperceptible way, maybe an entire planet goes bonkers as it has no power supply. If safeguards are written in so planets don’t go bonkers, depending on the implementation that may introduce an exploit that lets a player get infinite positive effects &c. by canceling building production queues with split second timing. Think “item duplication glitch”.

It is vital those things are in sequence, and if they go out of order, if “A” and “B” are both off before “A” turns on - which happens, again, when you’re using a bucket, then perhaps the planet has no power, meaning everything shuts off, which can trigger weird things. The player has no opportunity to intervene as this is handled by the computer, and not at a time when the player is making an input. It is a total disaster.

Various error checks could be put in but that requires additional processing power. And also there’s the possibility of unforeseen behaviors as so many different variables may be affected and so many consequent behaviors interact in so many ways. What happens if - for example - there’s some sort of programmed behavior so negative consequences around a building finishing production are halted, and suppose under certain circumstances users can affect that behavior? Maybe by canceling production at a particular moment, say? Then you can get really weird stuff happening, like maybe a player can eternally build and cancel buildings if timing it carefully, so they can effectively get infinite buildings on a planet as they get all the good stuff (happiness or resource gain) but none of the negatives (power or colonist consumption). Or maybe you get lag in servers processing user inputs, or users deliberately disconnect at certain times to try to trigger stuff that might break the game open.

So you get emergent behaviors that range to everything from planets going bonkers and shutting down to players glitching the game for exploits to out of memory errors and game crashes - and that’s just a few things out of a long list.

If the bucket is so problematic, what about grain by grain? What if the computer’s forced to process things sequentially? That avoids some issues but runs into others - like bottlenecks that impact performance. And for that sort of thing it’s not enough for the program to pass muster on a particular computer. Different computers with different operating systems and different hardware may find they are no longer able to handle the program without it crashing. Or maybe the handling on events is programmed to expect only up to a certain delay and changing how building queues operate means that entire thing has to be rewritten as well.

So if the feature is changed in one way, it can break the game in any number of ways, if the feature is changed in another way it can break in yet another way. The program’s being asked to do things it wasn’t doing at all to that point, and a whole new set of behaviors can emerge in terms of interaction with other programmed behavior, in terms of software working with hardware, in terms of players possibly exploiting unforeseen or untested circumstances &c. Just wildly weird stuff, stuff you probably wouldn’t even imagine.

For all I know, maybe the program is already set up so it can easily handle such a change without any of that stuff being any sort of a problem. It’s possible. Then all the developers would need to do is make the change, and maybe all the possible problematic issues could already be addressed. But that assumes the infrastructure exists.

If the infrastructure doesn’t exist, if it has to be built, then it’s potentially quite a task - and not one I would care to characterize as trivial.

Conceptually, to a human, it’s quite simple. But in programming terms, it’s a question of getting software to execute, software which interacts with any number of other things simultaneously going on in the software, designed to run on different operating systems and different hardware setups, on computers that just doesn’t understand English or human concepts.

It can be quite simple if there’s infrastructure to handle things, like ordering your automated assistant to order some ice cream. But four hundred years ago, if you told your non-electric toaster to order you some ice cream, well, it just wouldn’t work out too well.

If there’s no inexpensive automated option to create something like Outscape with simple easily modifiable inputs and outputs that’s where we’re at. We just don’t have the infrastructure. And if Outscape does have that sort of infrastructure, within its own design, that would be great, but it isn’t necessarily the case - because all that is a good deal more complicated to process.

I’m not saying it’s impossible or even impractical. Only that I don’t expect it would necessarily be a trivial thing to address. Though I would agree that it should be looked at and changed as suggested - as one of any number of automation features like waypoints. Hint hint.

1 Like

If it would help, think of it as “they built an industry for ice cream”.
But now, you want roast chicken. :stuck_out_tongue:

1 Like

I am a Programmer By the way.

And conceptually, it would be alot less complicated than what you’re stating.
There would be some sort of an IF Statement, handling the construction queues.

For example, IF Building = Upgrade, then {a whole bunch of logic, that would set the building as offline, deduct resources for construction etc…}

My Suggestion is a tweak of this logic, to something like IF Building = Upgrade AND “No Other Buildings are Upgrading” then {standard logic applied}, ELSE IF Building = Upgrade AND “Other Similar buildings are being upgraded” then {Modified logic applies}

Modified logic can be as simple as {Current Logic - Set number of buildings offline n-1}

Not really difficult to do…

1 Like


I’m assuming it’s multi-threaded.