Factorio Forums

Either by having their path finding logic avoid fire, or make items ineligible for automated repair, while they are in proximity to a fire.

This is the only part of the game that I really don't like. Flamethrower turrets are truly awesome, but having all your bots commit suicide by trying to patch up the flaming wall in front of them breaks it.

And/or have them fly back when they have a bit over half their health. Fire can start with bots on the way so the flying back thing would be useful on it's own.

PS: And don't have bots flying through fire call in other bots to repair them either.

Also related to the same overall issue (stop construction bots from committing suicide by immolation) :

viewtopic.php?f=6&t=88505
viewtopic.php?f=6&t=47441

I won't merge all these older threads, because each time, the suggestion uses a different approach to tackle the issue.

I must say, that I never had this issue so strong, that I want to change it. When thinking about why, I think one reason might be, that I try to have a big distance from my roboports to the walls. I found that the bots taking longer to repair is good in many cases. Maybe that’s it?

And yes, flamethrower are super, but that’s their problem. No weapon is perfect. And (IMHO) that’s part of the game

The suggested rules:

- avoid path to fire: will never be implemented, because too CPU intense
- ineligible if entity near/on fire: hm. It would mean that any entity needs to calculate health in two ways; one is the “true” health, one is the health seen for robots. Would make things much more complex .vs. more than questionable gameplay improvement.
- go home, if health lower than 50%: as a general rule I’m against it, because I think it is much more important to repair things. Robots are replaceable. If it would be a switchable option, I would go for it. Thinking to some kind of complex research, but I don’t know how this could be switched then. E.g. an icon on top of screen.
Maybe this last one could be implemented as mod.

Everything is replacabel. It's a question of cost. A stone wall is far cheaper to replace than a bot. And trying to safe that one wall might cost you 20 bots. A artillery turret with 20 shells might be different. Might be well worth 20 bots. Or when you have to hold the line at all cost or the biters get inside your base where there is no opposition.

If bots retreat when approaching half health that would mean another repair bot gets send. So this wouldn't stop repairs, just shorten the amount of repair each bot does at a time. On the plus side the damaged bots would get repaired and return quickly instead of having to wait for a new bot to be produced, delivered and get a new repair pack.

You say your roboports are far away. That would mean a bot takes a long time before it starts repairing and retreating at half health would mean a large gap till the next bot arrives. On the other hand isn't the fight over by then and it's not repairing while under attack where you have to hold the line at all cost?

Maybe this could be a roboport setting. You configure the roboport weather bots should return for repairs or not and when a bot leaves a roboport it remembers that setting and acts accordingly.

mrvn wrote: ↑Wed Sep 08, 2021 11:25 am Maybe this could be a roboport setting. You configure the roboport weather bots should return for repairs or not and when a bot leaves a roboport it remembers that setting and acts accordingly.

That sounds like a ‘we really want to not change the bot pathfinder; any small seeming change will drastically reduce UPS on most bases.’

Whatever the suggestion, I think it should not change the bot pathfinding if it is to be implemented.

On the other hand, suggestions like these create Overton window for other crazy ideas like bots pathfinding within logistic area, so concave networks are possible. Even biters don't pathfind around fire and they at least actually have some pathfinding

ssilk wrote: ↑Wed Sep 08, 2021 7:22 am - avoid path to fire: will never be implemented, because too CPU intense

I'm not suggesting adding fire-avoiding path finding to bots. Bots fly in a straight line to the target. If moving forward means moving into fire, bots could hang back until fire is out. To expand: Bots are moved forward some increment each tick. If a tick causes the bot to be on fire, it is moved back to the position at the previous tick.

- ineligible if entity near/on fire: hm. It would mean that any entity needs to calculate health in two ways; one is the “true” health, one is the health seen for robots.

Not exactly what I was suggesting. I'll expand: Whenever a damaged friendly entity or construction ghost appears within range of a roboport, it is added to a todo-list for construction bots, right? If the entity in question is on fire, it is instead moved to a pending todo-list, which after a timeout is added to the ordinary one.

Would make things much more complex .vs. more than questionable gameplay improvement.

Since this has been posted many times before, it appears that many players do consider this a significant improvement.

Can we please make constructions bots avoid fire danger?

Although fire is one of the ways this problem is demonstrated, I have more problems with bots running into biters. They should be able to see danger then just run back like it needs a recharge... or maybe if its actively taking damage to run back.

@posilla: I’m not sure what you want to tell us.

kaspar42 wrote: ↑Wed Sep 08, 2021 6:25 pm If moving forward means moving into fire, bots could hang back until fire is out. To expand: Bots are moved forward some increment each tick. If a tick causes the bot to be on fire, it is moved back to the position at the previous tick.

Which means you need to find a new path.

Not exactly what I was suggesting. I'll explain: Whenever a damaged friendly entity or construction ghost appears within range of a roboport, it is added to a todo-list for construction bots, right? If the entity in question is on fire, it is instead moved to a pending todo-list, which after a timeout is added to the ordinary one.

So if you write a mod, that makes fire-proof robots, you need to look into both lists, if something needs repair. And things which are just been put out of the no-repair-list and get immediately on fire again will constantly moved from one list to the other, making funny things with robots, which wants to repair it. And many more strange and over-complicated things will happen.

I still don’t know, it’s... It’s so much clearer, easier to understand as it is yet. And the gameplay value is really low. Yes, it removes a bit of frustration, but - objectively seen - it doesn’t bring any new gameplay in, I go nearly so far and would say, it removes some gameplay.

Would make things much more complex .vs. more than questionable gameplay improvement.

Since this has been posted many times before, it appears that many players do consider this a significant improvement.

Many do that, but it doesn’t mean they are right/correct/know it better. It’s more likely, that they are frustrated, too. I can’t help. Bots getting lost, when involved in fights. Things gets destroyed, when enemies shoot. When bots should not be killed in a fight, walls should be, too. And turrets! I find it mean, that the turrets are always attacked first, they should be attacked last.

You see: it’s not so simple.

TBH , from the start, I wished the construction bots were totally immune to any kind of damage. Them being destroyed by anything stronger than a sneeze doesn't add much to gameplay value, just some annoyance for the player who regularly needs to monitor if the bots left for defence reparation aren't doing something stupid like throw themselves into fire, acid, or whatever. It's not a regular resource sink like defending against the biters may be, just an annoyance.

In the end the player who wants to automate, either has to set up a white elephant to ensure there are always enough bots but not too many all around the defensive perimeter, or just lay down a mega logistic network so that things just sort themselves alone. The alternative being when structures are destroyed somewhere, manually monitor if there are construction bots left at that place.

Would be a super simple solution, and can be easily modded (think so).

ssilk wrote: ↑Wed Sep 08, 2021 10:28 pm Would be a super simple solution, and can be easily modded (think so).

https://mods.factorio.com/mod/invincibl ... ction-bots

ssilk wrote: ↑Wed Sep 08, 2021 10:03 pm @posilla: I’m not sure what you want to tell us.

kaspar42 wrote: ↑Wed Sep 08, 2021 6:25 pm If moving forward means moving into fire, bots could hang back until fire is out. To expand: Bots are moved forward some increment each tick. If a tick causes the bot to be on fire, it is moved back to the position at the previous tick.

Which means you need to find a new path.

No, they would turn to hovering in place just outside the range of the fire with that suggestion. Not sure if that is better performance wise. Now every tick the bot has to check if the next step takes it into fire.

Game play wise bots would no longer repair anything inside a fire of a certain size because they can't get near enough.

I like my suggestion better where bots retreat when they've slightly less than half health. They would still fly into the fire and try to repair stuff. But often they should be able to retreat before being destroyed. If that means they do less repair work then that is fine by me. As suggested it could be an option. Either in the prototype (mods could have brave and not brave bots), global or as part of the roboport.

ssilk wrote: ↑Wed Sep 08, 2021 10:03 pm

Not exactly what I was suggesting. I'll explain: Whenever a damaged friendly entity or construction ghost appears within range of a roboport, it is added to a todo-list for construction bots, right? If the entity in question is on fire, it is instead moved to a pending todo-list, which after a timeout is added to the ordinary one.

So if you write a mod, that makes fire-proof robots, you need to look into both lists, if something needs repair. And things which are just been put out of the no-repair-list and get immediately on fire again will constantly moved from one list to the other, making funny things with robots, which wants to repair it. And many more strange and over-complicated things will happen.

I still don’t know, it’s... It’s so much clearer, easier to understand as it is yet. And the gameplay value is really low. Yes, it removes a bit of frustration, but - objectively seen - it doesn’t bring any new gameplay in, I go nearly so far and would say, it removes some gameplay.

Would make things much more complex .vs. more than questionable gameplay improvement.

Since this has been posted many times before, it appears that many players do consider this a significant improvement.

Many do that, but it doesn’t mean they are right/correct/know it better. It’s more likely, that they are frustrated, too. I can’t help. Bots getting lost, when involved in fights. Things gets destroyed, when enemies shoot. When bots should not be killed in a fight, walls should be, too. And turrets! I find it mean, that the turrets are always attacked first, they should be attacked last.

You see: it’s not so simple.

It's frustrating because you can not change the stupidity of the bots. Bots not calculating that they don't have enough fuel to reach their goal and aiming for the next recharging spot right away is another of those stupidities. No advanced civilization would program their bots that way. Hell, us stupid humans would not program their bots that way except for factorio devs it seems.

There are mods where the aliens throw flames (spiter with fire damage). Try playing against them with repair bots.

NotRexButCaesar wrote: ↑Wed Sep 08, 2021 11:13 pm

ssilk wrote: ↑Wed Sep 08, 2021 10:28 pm Would be a super simple solution, and can be easily modded (think so).

https://mods.factorio.com/mod/invincibl ... ction-bots

Exactly. My personal opinion is that bots should be like that in vanilla : it doesn't give an overwhelming advantage while removing nuisances, and the most important : doesn't alter significantly the core of the game, which revolves around the factory itself.

Koub wrote: ↑Thu Sep 09, 2021 6:23 am Exactly. My personal opinion is that bots should be like that in vanilla : it doesn't give an overwhelming advantage while removing nuisances, and the most important : doesn't alter significantly the core of the game, which revolves around the factory itself.

If we can if developers can make bots to be more adequate with very little developing efforts, so lets do it regardless of low importance to the general gameplay. This just makes the game smoother, and this is good. Mrvn's suggestion about returning to a roboport at half health sounds like three lines of the code. I understand, there will be slightly more code, but anyway this is very simple solution. Polishing the game is not a bad thing.

coppercoil wrote: ↑Thu Sep 09, 2021 7:31 am [...]Mrvn's suggestion about returning to a roboport at half health sounds like three lines of the code. I understand, there will be slightly more code, but anyway this is very simple solution.

I have learnt over the years to never ever assume the simplicity of a change in the code (and yes, there is a form of PTSD from work where I'm considered an expert at my job, and people often wrongly assume "that's just a few clicks") . I have to admit I don't have the slightest idea of what it would be, and I'm convinced most people who post in these forums don't know enough either, even those who are developers themselves.

So I just try to forget the impression of "it should be a quick change", and focus on the "I think the change should make the game overall better". It's the devs' job to know how hard it is implement a suggestion, if it fits their vision of the game, and finally if it's worth the hassle.

In this case, I'd be fine with whatever would be implemented to remove the hassle of the construction bots being "stupid" from the player's perspective in combat situation. Either bots who don't get themselves into damage, or even just totally immune bots (because they would have advanced danger avoidance embedded software of course ).

Koub wrote: ↑Thu Sep 09, 2021 9:59 am

coppercoil wrote: ↑Thu Sep 09, 2021 7:31 am [...]Mrvn's suggestion about returning to a roboport at half health sounds like three lines of the code. I understand, there will be slightly more code, but anyway this is very simple solution.

I have learnt over the years to never ever assume the simplicity of a change in the code (and yes, there is a form of PTSD from work where I'm considered an expert at my job, and people often wrongly assume "that's just a few clicks") . I have to admit I don't have the slightest idea of what it would be, and I'm convinced most people who post in these forums don't know enough either, even those who are developers themselves.

Wasn't there just a few days ago a post by a dev saying something along the lines of "The moment you start making assumptions about the difficulty of my work I lose all interest in your idea."? I would be careful with that kind of presumptuousness if I was interested in changes actually happening.

Personally I just "solve" the issue by flagging bots unrepairable. That way they at least don't cascade-suidice by trying to repair each other while hovering over a fire. And building a new wall even if inside a fire might actually be a better defensive strategy than waiting for the biters to break through.

Koub wrote: ↑Thu Sep 09, 2021 9:59 am I have learnt over the years to never ever assume the simplicity of a change in the code (and yes, there is a form of PTSD from work where I'm considered an expert at my job, and people often wrongly assume "that's just a few clicks") . I have to admit I don't have the slightest idea of what it would be, and I'm convinced most people who post in these forums don't know enough either, even those who are developers themselves.

Yes, I know. Been there, done that. Nevertheles, players can think that one solution is very likely simplier that another. "Tree lines of code" was a kind of metaphor that reflected my personal opinion about the complexity. Of course, I may be wrong

Why should bots be immune to damage when no other factory thing is immune to damage? What is so special about bots that, outside of a mod, they should be impervious to biter and spitter attacks?

It's simple enough to use an invincible-bots mod.

It's simple enough to turn the aliens off completely, or set them in peaceful mode, if desired.

If burning bots is the problem, there are plenty of other defensive options without using flamethrowers and flamethrower turrets.

It doesn't make sense to change the game for this.