I've tried to avoid getting into this as an argument, as you said, its not very helpful, what we really need is a word from the devs on this suggestion, as it is much more viable than most others - I'd love to see at least an attempt, even if it turns out to be too problematic in ways I can't see.
ssilk wrote: ↑
Wed Sep 21, 2022 8:46 pm
In the current system this changes with growing traffic. When more bots charge at one roboport a bot will suddenly take a different roboport. The same is it with this suggestion, with the difference, that it is much more unpredictable, because the bots can spread much more over the ports, because once a bot took a new path it can end completely unpredictable in nirwana (dead end, no path out). This unpredictable dead ends cannot happen in this way with the current system.
How can the bots spread out more than currently? I don't see how that applies. I can see how they'd spread out more quickly than currently, as they'd be taking shortcuts, but that doesn't change the extend to which the bots spread out amongst roboports. Also, them spreading out is pretty much a good thing. The only situation where it would spread out more is when robots are 'stuck', and then spreading out is the only way to get to the target anyway.
But there is a simple rule: Avoid concave networks, if you want to use bots safely. But that's not my opinion. My opinion is that the current system works very well for how less CPU-cycles are used to make it more or less intelligent. But it has some quirks and we don't need to fix the whole system to fix these 2 or 3 sometimes annoying problems.
The point of the suggestion is that it doesn't alter that much, it doesn't cost any more CPU cycles (in theory), and produces better behaviour in most cases it applies in. I don't see how this criticism applies.
In other words: This suggestion will make the system not simpler (see down why). This suggestion makes it even more complex to handle.
For who, and in what way? You are using the 'complexity' of the system as a cover-all criticism for improving it. Nobody ever said it would be simpler to analyse, it was only pointed out that it was easier for the player to use, producing fewer obscure problems.
We already had arguments (*) in older suggestion threads, that one just needs to avoid convex networks (bases). This is in most cases relatively simple. In some not. Then it can be seen as a kind of puzzle. Sometimes I like it, sometimes not.
The point is: is can be predicted.
But this system can be predicted. I mean a wiki page would suffice for anyone who wants the details, but in most cases it would just work, and do so with far fewer players wondering "why did all my drones just die?"
As far as I can tell it isn't a fun puzzle, its just an annoying limitation of your primary late game building system.
As you say "We need to try it out".
But still not giving up, eh?
Its a really good change, it makes sense, and I think it has a decent chance to be implemented - at least more than most robot routing improvements.
I will still support this, as I don't see any really meaningful objections to the changes.
Now take all points where the robot runs out of fuel and instead of going zig-zag take the third side of the triangle and go directly. For me removing those out-of-fuel points on the path is a no-brainer
But you're looking again only to this one aspect of their behaviour: Bots do stupid things, because they go straight and need to refuel in zigzag.
This is the only aspect of behaviour being looked at because this is the only aspect of behaviour that is relevant. Its like the whole point of the change...
And yeah, "Bots do stupid things" is a bad thing, and what the suggestion is trying to change.
Did you think for example about what will happen when the bots are upgraded by research and suddenly go faster, so that they now can fly longer. With that the this system of "make a path for your bots via roboports" changes from one moment to the other to bullshit. Bots will suddenly make completely new paths.
Yeah, the path isn't pre-planned, only instantaneous - no bot would have a route, only a roboport its trying to recharge at. Upgrading the bots would result in the current recharges being a little wasteful, but would still work perfectly well.
Do you think this is another "path finding for bots" suggestion, because its really not. It is basically doing nothing more than corner cutting. Those corners remain just as cut at higher speeds.
And suddenly your formerly well designed path around of your "convex edge" is useless, just because you researched an upgrade for robots.
... and complexity means, there might be much more of those cases; we cannot know what they are and how many.
There isn't a path around the edge. Only a roboport to recharge at...
And complexity doesn't mean that - it makes a system hard to analyse, and may require approximations, but we can certainly constrain potential problems.
BTW: The current system will also change with more bot-speed, but not in a way, that is so unpredictable. AFAIK nobody has ever complained about it. But I can guarantee you, with this proposed system they will.
No, no it will not. It will not need any special handlers for bot-speed that I can think of. The pre-calculated stuff is still just as calculated.
[... That is a no-brainer ...] both to calculate and to predict.
No, not even close.
I keep on it unless you explain me the opposite: This suggestion replaces an already complex system, with one that is one or two categories more complex. You might not see that yet. But you can trust me; seeing such things is part of my daily job as developer. Most times I just ask then simple questions like: what will happen when you do this and that at the same time
And then they see this ain't gonna work.
I do plenty of dev stuff as well, and this is not noticeably more complex. The system looks ahead, and sets a flag and a pointer, and leaves. Then, if anything changes further down the line, it does whatever it would do now. That is all.
The prediction is only done when a bot finishes charging, or when it first sets off.
I challenge you to think of any single situation where the result isn't pretty much obvious - or if it isn't, the result is just as non-obvious right now.
Reducing complexity to see how a system works is a super important part of such a design process, and wube's developer, especially Kovarex, is a master in this. Also the reason why I still like to be kind of "main moderator" for ideas&suggestions. Because people tend to make complex things, because they think doing many things at once is simpler. But that is only true, if look for one aspect and often they forget to look at the whole story.
Yeah, it is important, but it isn't the only thing that is important, and again, this system doesn't add anything which isn't already there.
I really don't understand your position on this, so to make sure we are on the same page, could you explain what the proposed system does which is so complex, and a situation where the game wouldn't fall back to the current entity handling?
I can see concerns around testing it thoroughly, but it is certainly doable.
My understanding is:
The only change this suggestion involves is that when and only when a bot leaves a roboport or finishes charging, it will find the direction and distance to the target, if the distance is within 80% of range, then nothing special happens. Otherwise, it will ask the roboport network for the best roboport from 80% charge dist in that direction, set the bot.isRecharging = true, bot.chargingRoboport = roboport, and that is it.
From that point onwards, everything happens as it does in base-game.
When considering the mass action of drones, I believe this change will do almost nothing, except for making the drones waste less time.
The obvious edge case is when a drone finds its departure roboport as the closest, but this issue has been addressed multiple times, and any of those solutions is fine.