Can we please make constructions bots avoid fire?

[quyxkh]

It seems we're back at the old split, between those who regard design challenges, any possibility of failure at all, as the point of play, and those who regard them as impediments.

[mrvn]

If you are using mods, then you can as well use one, that makes the bots invulnerable.

No, invulnerable bots are something completely different and a huge change of the game play.

[Impatient]

Ok, I agree it is different. But how far is it from what people are asking here?

"Make bots not plunge themselfes into fire",
"Make bots avoid enemies"

What do people want? Bots not dieing like lemmings, as far as I understand. Or not dieing at all, because it messes up the setup of their log net(s). 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. Which feels cheat-ish.

I personally don't want any of this. I am fine with how it is at the moment. Just trying to drill to the core of this.

You know what? Maybe everyone is just annoyed by the alarm sounds when bots die again and again. Or maybe people, are annoyed by having to witness that part of their base isn't perfect. Can not be perfect. Needs personal attention, if not automated. Constantly drains resources. I say: "You got to invest resources to get resources (or to protect resources)."

I have to admit, I think as well, that the bot behavior is annyoing. But it is a challenge, which I think is justified.

[Impatient]

It seems we're back at the old split, between those who regard design challenges, any possibility of failure at all, as the point of play, and those who regard them as impediments.

Very much so.

[Kyralessa]

It seems we're back at the old split, between those who regard design challenges, any possibility of failure at all, as the point of play, and those who regard them as impediments.

Very much so.

Agreed. I wonder if it's possible to make a mod that doesn't make bots completely invulnerable, but simply makes them invulnerable to fire. Is burning damage a distinct thing in Factorio? Could someone write a mod to make bots immune to burning damage?

By the way, while searching for something along those lines, I found this old related thread:

viewtopic.php?t=47441

It's worth a reminder here that the trouble with a change to the base game is that it changes it for everyone.

Not everyone will want their bots to be fire-immune. A mod lets you make a change to the game if you want. A change to the base game forces it on everyone.

[Silari]

It seems we're back at the old split, between those who regard design challenges, any possibility of failure at all, as the point of play, and those who regard them as impediments.

Very much so.

Agreed. I wonder if it's possible to make a mod that doesn't make bots completely invulnerable, but simply makes them invulnerable to fire. Is burning damage a distinct thing in Factorio? Could someone write a mod to make bots immune to burning damage?

They're actually already 85% fire resistant in the base game.

Code: Select all

data.raw["construction-robot"]["construction-robot"].resistances = {{percent = 100, type = "fire"}}

in a mod's data.lua should make it 100. Do the same but with ["logistic-robot"]["logistic-robot"] to make logistic bots also immune (again, normally 85%).

[mrvn]

Ok, I agree it is different. But how far is it from what people are asking here?

"Make bots not plunge themselfes into fire",
"Make bots avoid enemies"

What do people want? Bots not dieing like lemmings, as far as I understand. Or not dieing at all, because it messes up the setup of their log net(s). 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. Which feels cheat-ish.

I personally don't want any of this. I am fine with how it is at the moment. Just trying to drill to the core of this.

You know what? Maybe everyone is just annoyed by the alarm sounds when bots die again and again. Or maybe people, are annoyed by having to witness that part of their base isn't perfect. Can not be perfect. Needs personal attention, if not automated. Constantly drains resources. I say: "You got to invest resources to get resources (or to protect resources)."

I have to admit, I think as well, that the bot behavior is annyoing. But it is a challenge, which I think is justified.

I'm totally fine with one bot throwing itself into fire or aliens and dying. That's game play. The behavior that's annoying is the lemmings part. Bot after bot after bot will just jump of the cliff. Each death forces the initial cause to send a bot to repeat.

That's why I'm for the "retreat when getting too damaged" option. 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. But when it happens it slows down the thundering herd of lemmings. Bots will often survive, retreat and try again and no second bot is scheduled for the same impossible task. Think of it as recharging their health. Bots already "retreat" when their charge runs low. Use the same mechanic for health and retreat to the nearest roboport for repairs.

PS: It would be a challenge if there was a solution. As mentioned removing the bots from roboports with circuit logic is fragile and leaves a bad taste. It's certainly isn't a good solution.

[Impatient]

That's why I'm for the "retreat when getting too damaged" option. 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. But when it happens it slows down the thundering herd of lemmings. Bots will often survive, retreat and try again and no second bot is scheduled for the same impossible task. Think of it as recharging their health. Bots already "retreat" when their charge runs low. Use the same mechanic for health and retreat to the nearest roboport for repairs.

I like that idea very much, actually.

[ssilk]

@kyralessa: Thanks for the link. I've already searched for it.

@impatient: As already said, this will not come, because it increases the checks a bot has to make every tick. Everything which increases the robot intelligence will not come, due to the plus of needed CPU performance for the checks.

Sere also viewtopic.php?f=5&t=99001 We need more control over bots

Robots are and will be quite stupid. The player has to care about them, has to understand their behavior and needs to build so, that it supports the way they work. Not vice versa.

[coppercoil]

@impatient: As already said, this will not come, because it increases the checks a bot has to make every tick. Everything which increases the robot intelligence will not come, due to the plus of needed CPU performance for the checks.

I think health check is very cheap. Health check already exists. Yes, robots can die after the check. Suggested robot retreat is a single-time trigger on health_<0.5 to switch for another mission (return to nearest roboport). This return is implemented too. No need to modify pathfinding.

Robots are stupid. Though trains are pretty smart. Why. Shouldn't the player take care about stop selection, train limits, leaving conditions... Yes, there are circuits for that

[Silari]

@impatient: As already said, this will not come, because it increases the checks a bot has to make every tick. Everything which increases the robot intelligence will not come, due to the plus of needed CPU performance for the checks.

I think health check is very cheap. Health check already exists. Yes, robots can die after the check. Suggested robot retreat is a single-time trigger on health_<0.5 to switch for another mission (return to nearest roboport). This return is implemented too. No need to modify pathfinding.

Robots are stupid. Though trains are pretty smart. Why. Shouldn't the player take care about stop selection, train limits, leaving conditions... Yes, there are circuits for that

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. 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. 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.

Trains are generally present in orders of magnitude less than robots, so they can afford to be more complicated. A megabase can easily still have under 100 trains. Meanwhile bots can easily be over 10000, so 600000 times a second those tests would need to be done. Performing a small check enough times can still take a while.

[coppercoil]

Health check doesn't exist every tick, it only gets used if the robot is damaged or repaired somehow

That's great. The retirement check I mentioned earlier would work exactly as intended.

Trains are generally present in orders of magnitude less than robots, so they can afford to be more complicated. A megabase can easily still have under 100 trains. Meanwhile bots can easily be over 10000, so 600000 times a second those tests would need to be done. Performing a small check enough times can still take a while.

Yes, trains and robots are quite different. My question was not about the performance, it's about the philosophy: dumb or smart?
If trains can be smart, so robots can also be smart.

[torne]

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. 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. 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.

It would not have to check the health every tick; as you mention the health gets updated in reaction to an event, so that event could also check if it had crossed the threshold and update the robot's state. Whether that would require storing/reading more data or not per tick depends on how the current logic for determining the robot's movement works.

They already change their pathfinding target when they need to recharge, but there's a number of ways I can think of for that to work and probably more I can't, and I dunno if it's been discussed by the devs anywhere. For some plausible ways that could work (e.g. if they just have a "need to go back to roboport" flag that's set when their charge gets too low) then the same logic could just be triggered by the "robot damaged" event without really changing the per-tick behaviour at all; it'd probably just go back to the nearest roboport when it was too badly damaged, and then carry on with whatever it was doing afterward. But maybe it works some other way.

I don't think this is particularly necessary, regardless; robots have a bunch of limitations that you have to design around and this is just one of them, and having them actually plan non-straight-line paths has already been rejected many times. But, I also don't think that triggering damaged robots to give up on the current path and just fly directly back to a roboport temporarily is necessarily going to have any performance impact per-tick, unless there's more detail about how the implementation actually works somewhere that I haven't seen.

[eradicator]

Even if an on-damaged-return-to-port behavior was computationally feasible, is that actually a good solution to the problem at hand? That seems to me the more interesting question. A fleeing robot might already be surrounded by flames, or the "nearest port" might be positioned in such a way that the original path would've had less fire in it. For this to be a viable solution the fleeing-path would have to be guarenteed to be better than the original path on average. Otherwise robots would just end up doing a different sort of suicide than they do now. And then you also have to prevent that walls of fire don't turn into another infinite loop like robots trying to cross concave networks.

[Silari]

It would not have to check the health every tick; as you mention the health gets updated in reaction to an event, so that event could also check if it had crossed the threshold and update the robot's state. Whether that would require storing/reading more data or not per tick depends on how the current logic for determining the robot's movement works.

Right, I think I was conflating it with the suggestion from earlier that they should avoid fires, which would need per tick checks.

I suppose you could get a similar effect with a mod - check the on_entity_damaged events for robots, and if their health is below <whatever percent>, set their energy to just below the threshold to trigger a recharge, so they change course. No API commands to control bots directly that I know of though.

[mrvn]

Even if an on-damaged-return-to-port behavior was computationally feasible, is that actually a good solution to the problem at hand? That seems to me the more interesting question. A fleeing robot might already be surrounded by flames, or the "nearest port" might be positioned in such a way that the original path would've had less fire in it. For this to be a viable solution the fleeing-path would have to be guarenteed to be better than the original path on average. Otherwise robots would just end up doing a different sort of suicide than they do now. And then you also have to prevent that walls of fire don't turn into another infinite loop like robots trying to cross concave networks.

Nothing is guaranteed. If the bot flies into the fire from one side and the nearest roboport is on the other side then it will die. Same with alien nests in a concave network. While possible that is actually an unlikely situation unless you already have a concave network. But lets look at it. The bot was flying towards the fire. It flies some way inside till the damage triggers a retreat. The retreat is to a roboport on the further side, where the bot was going anyway. So have you really lost anything? It didn't save the bot but it also didn't kill it anymore than it already was.

And before you say it, yes you can construct cases where the retreat kills the bot while flying on wouldn't. But those will be few and far between. The most common case is repair bots at the wall with roboports very near. With fire the bots run like lemmings into the fire. A retreat would naturally turn them 180° around.


A solution to the above would be simple and even save CPU cycles (at the cost of 8 bytes per bot): Return from where you came from. Don't search the nearest roboport but remember where you came from. On bot damaged: if health < 0.6: self.set_destination(self.source_port)

[posila]

I think aborting robot's job when its healt gets bellow certain threshold would not be problem for performance.

[Koub]

I think aborting robot's job when its healt gets bellow certain threshold would not be problem for performance.

Good news Are you considering doing ... "something" about the issues that are discussed in this thread (whatever the solution, and even if it's just thinking about it), or the current design is exactly what you devs want (in that case I could as well move the whole thread to "won't implement") ?

[ssilk]

@coppercoil hm. You’re right. Health needs to be checked only, if the health changes. Needs not to be checked every tick. Stupid, that I didn’t get that earlier. But that’s how it sometimes is.

Silari already explained why the trains can be much more clever than bots: because there are not so much of them.

[posila]

Good news Are you considering doing ... "something" about the issues that are discussed in this thread (whatever the solution, and even if it's just thinking about it), or the current design is exactly what you devs want (in that case I could as well move the whole thread to "won't implement") ?

Me, personally, I don't consider doing anything about behaviour of bots described in this thread, and I can't speak for others, especially not for game designers