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.