Performing a small check enough times can still take a while. Meanwhile bots can easily be over 10000, so 600000 times a second those tests would need to be done. A megabase can easily still have under 100 trains. Trains are generally present in orders of magnitude less than robots, so they can afford to be more complicated. The FFFs have several stories of the devs optimizing things by shaving off a byte or two from what the game needs to access per tick, so it's quite likely health isn't stored along with the data needed for pathfinding. This would mean checking it every single tick for each robot in the air, and that means adding health to the chunk of memory that needs to be accessed for every bot on every tick. Health check doesn't exist every tick, it only gets used if the robot is damaged or repaired somehow, and those are reactive events - they only happen if something triggers it, or it happens to be on screen to draw the health bar, so the vast majority of the time a robot is out it's health is never checked. Shouldn't the player take care about stop selection, train limits, leaving conditions. Suggested robot retreat is a single-time trigger on health_<0.5 to switch for another mission (return to nearest roboport). Everything which increases the robot intelligence will not come, due to the plus of needed CPU performance for the checks. Tue 10:21 As already said, this will not come, because it increases the checks a bot has to make every tick. As mentioned removing the bots from roboports with circuit logic is fragile and leaves a bad taste. PS: It would be a challenge if there was a solution. Use the same mechanic for health and retreat to the nearest roboport for repairs. Bots already "retreat" when their charge runs low. Bots will often survive, retreat and try again and no second bot is scheduled for the same impossible task. But when it happens it slows down the thundering herd of lemmings. There is still danger to bots and you will still loose some and you have to take care how you design your flame turrets or your logistic networks. That's why I'm for the "retreat when getting too damaged" option. Each death forces the initial cause to send a bot to repeat. Bot after bot after bot will just jump of the cliff. The behavior that's annoying is the lemmings part. I'm totally fine with one bot throwing itself into fire or aliens and dying. But it is a challenge, which I think is justified. I have to admit, I think as well, that the bot behavior is annyoing. I say: "You got to invest resources to get resources (or to protect resources)." Needs personal attention, if not automated. Or maybe people, are annoyed by having to witness that part of their base isn't perfect. You know what? Maybe everyone is just annoyed by the alarm sounds when bots die again and again. Just trying to drill to the core of this. If one wants to solve that problem, why not go with invulnerability? The only real downside - as of my experience out of my personal games - is that one would be able to build concave log nets. Or not dieing at all, because it messes up the setup of their log net(s). What do people want? Bots not dieing like lemmings, as far as I understand. "Make bots not plunge themselfes into fire", But how far is it from what people are asking here?
0 Comments
Leave a Reply. |