Robot Attrition Suggestions

[Alpha-Prime-01]

Robot Attrition:

Many people seriously dislike Robot attrition, BUT, we get its role in SE, that being said, because the lack of actual choice in the effectiveness of robot attrition, most people end up simply editing the code to make it not function at all; thus defeating the entire purpose of it in the first place being dependency.

Many suggestions have been made to attempt to balance it further to be player choice.

-The first 1 I want to address is the mod option in place already: Robot Attrition Setting at 1000 is 500x higher than at 1 while 1 setting is 2x higher than .001 both are the same power away from each other, yet below a whole integer the change is insignificant https://discordapp.com/channels/419526714721566720/419527276875481111/741418466715762709 This makes the value irrelevant for decreasing actual attrition worthwhile and only leads to players disabling the mod in the code.

The first Suggestion being reverse the powers so that .001 is significantly less attrition value and 1000 is only a few fold harder, or make them equal in strength to the same power from 1 at least. Or if possible make it a slider as well as equal in strength from the starting default value.

-Second thing I wanted to address is that one of SE's strengths is gating things behind research level., As a general rule all factors of micro management in SE get easier with more tech. Except attrition. A scaling tech level would slide nicely into SE’s arsenal of strengths.

The second suggestion being exactly that, a simple solution of a tech research to reduce the probability of a crash per level. Similar to rocket safety in concept. i would suggest 10-11 ish levels with 9% reduction each level for an end goal of 90%-99% reduction at DSS level.

-Third concern would be If adding tech research would be 'too easy' and you want players to do something more to get robots to die less, then add another type of shielded armor logic bot, make them slower if you would like, larger charge time, anything to make them more resistant to dying so players can choose speed/cost/power/etc. over bot death if they want. Although this would have to be a significant change in deaths if they were extremely costly. This also seems like the most amount of work on your part tbh so dont know how inclined you are to feel about it.

-Last Concern/Suggestion would be: at the end of the day, theres still going to be some players that simply want to turn it off. They are going to go into the code and stop the mod from working, theres no stop to them doing this; and for those that cant figure out how to disable robot attrition by altering the code; may end up not finishing SE altogether simply because their playstyle isnt functional without dumping millions of resources into the build just for 1 mod they dont actually want anyhow. So please add a "disable robot attrition" option to the mod settings for this.

I would like to further suggest that if possible make the on/off checkbox also say "this cannot be reversed once saved into an active game" Meaning, if its even possible to do, that once its disabled and saved in that condition, even if they turn it back on, every time the game loads with that saved mod setting of disabled it overwrites the checkbox in options. Maybe make a secondary checkbox next to the first with "are your sure" if it is possible to do that. This would incline some players to at least keep it on even at minimal settings. And for those that would edit the code, or stop playing either way, would continue playing without editing the code.

This would give a 'hardmode' mentality to having it on, and once removed, cant be put back in that condition. Also, removing the mod to attempt to erase the saved condition would disable SE, making it impossible harder to cheat it back on without console commands, if at all as far as i can fathom.

[AartBluestoke]

perhaps robot safety research, where x% of the time the failing robot doesn't explode, but get changed to a 'damaged logistics robot 3' The challenge at high levels would then be to pick these bots up and refurbish them back to working condition in an assembler rather than a resource sink?

Has anyone done an analysis on the material drain from robots exploding?

The pain point probably isn't the material sink of the bots, as bots are not that expensive, but the effect of the explosion.

[AvengerStar]

The pain point probably isn't the material sink of the bots, as bots are not that expensive, but the effect of the explosion.

The explosion effect can be mitigated with an already existing research. I doubt that is the point of this ticket.

The idea for bot servicing is an old one proposed by one of our contributors with his own mod. Potentially, it could be integrated with robot attrition mechanics. However, that does not fully address the issues brought up in the original post. The robots still crash, a situation that players may want to avoid more often one way or another.

[eoraptor666]

I was going through the available mod for a new single-player playthrough and stumbled upon the "Limited logistic bots" mod. This mod makes the bots use more power the more logi-bots are active per network.

Trading extra power for more bots could be a viable trade-off for bots getting killed. It is not a resource sink as no logi-bots are destroyed, but it does required extra power.

The extra power use for the bots could probably be easily be linked to the current attrition factor - a higher attirion factor for more power use.

[teanders]

This issue is about how Robot Attrition (RA) works together with Space Exploration(SE).

RA is fine by itself, since people who install it want the extra challange it gives. People who installs SE isnt nessessary into RA, but it is a dependecy since SE balance revolves around RA. The core problem of this issue is that the goal of the two scenarios are different from eachother.

• RA by itself gives the player extra logistic challange by giving intensives to building with belts and trains instead of robots.
• SE with RA challanges the player to build further away from the sun, thus trading power for robot safety.

Having such dependencys makes balancing difficult.

---

But if we ignore that, and accept that RA is a part of SE. In my opinion, RA shouldn't itself be balanced around power usage, since power is the intensive for higher RA factor in SE.

The change here should be with SE and not RA.

There is also frequently brought up that RA has a large UPS inpact when lots of robots die.

I think the feedback and suggestions from Alpha is on point. An "infinite" research behind material science 1 or something simlear to cargo rocket survival, where it starts of cheap and doubles each time, would be coherant to how SE works elsewhere.

[AartBluestoke]

I don't think we understand the issue the OP is raising.

There are several potential issues: 1) resource sink, building bots is annoying 2) damage hits - they don't like the alerts/potential for other random problems outside their control 3) ups hits 4) no way to "improve" this situation 5) inability for perfectionists to be perfect because of random bot loss.

answering them all: 1) as pointed out by @teanders above, attrition exists to help differentiate locations in a meaningful way. I don't think this should change. This can also be automated with logistics signals - "of logistics free = 0, put another bot into the roboport" 2) mitigated by an infinite research, 500 bot networks/hit. 3) Should be investigated, if this is a concern. 4) potential agree, other than explosion damage which is mitigated by research. perhaps we could have an infinite research that increases the time between bot explosions by increasing the time between bot damage tick calcs? - that way ups cost goes down proportionally also? 5) SE doesn't pander to perfectionists - random rocket crashes, probabilistic meteor interception with variable timing and strike sizes. Some random losses are currently an expected part of SE gameplay. Perhaps the expectations of this last point can be managed better?

Could we conduct a poll about which of these issues are what matters to people? could @Alpha-Prime-01 or others chime in with some clarification of the exact game mechanic that annoys them? the op says "Many people seriously dislike Robot attrition" but doesn't say the specific problem, other than a lack of control over

[nicolas-lang]

I think there should be:

• a settings-configurable safe-zone which disables crashing completely ( defaults to something like 50, mainly to enable ammo and fuel supply for small off-planet bases) ( this could get either a code based hard-cap or be left open to allow users to disable the mod) ( i would only enable 1-2 researches to improve this to like 2-5x the base value)

• a settings-configurable upper bound below that a crash is % based and the % can be researched (like rocket crashing)

• above the upper bound the crash rate become exponentially worse depending on the robot count

• an infinite research with a slightly diminishing return that pushes the upper bound

[EarendelGames]

There will be a separate branch at some point with a bot repair recipes. I'm also considering having some techs so that you can reduce crash chances of certain zone types, but this will be when there are more district environmental challenges, such as lightning worlds vs radiation worlds vs windworlds.

[CoffeeCecil]

I'm seeing construction robots crashing and the setting generally and needlessly makes my life miserable. So this is my fix:

https://www.reddit.com/r/factorio/comments/wal9ar/space_exploration_fixing_robot_attrition_for_good/

I would infinitely prefer an off switch programmed in. In the context of SE, if I have infinite resources to throw at a project I can simply out build robot attrition's intended use case (iirc it was using 10K robots to build a dead simple factory). I can't outbuild robots breaking due to a logistics request, and busting the drills or whatever they are carrying. Or construction robots running into each other - I've read that's not intended but I've still seen them crash and enough of them recently that it's pissing me off.

And finally, a suggestion of what you could do to make life miserable for robot users but still rewarding if you put effort in:

Belts don't use power.

Robot ports do. That power is fixed right now. But, if you made it variable like the umbrella power is in Space Exploration? You might not be able to run a 2500K robot port network if each robot port takes 30MW instead of the normal value due to radiation or wind.

Personal robot ports would have to be exempted from this so you could use them for construction. Or not without special robot ports. Or not at all if sadism is your thing.

The idea is you can overcome the problem if you engineer a fusion reactor in somewhere in the mix - but that's only as easy as finding some nuclear fusion, clearing out the space for everything, ect. Or you could just throw 1K belts at it. And in the context of "a radioactive outpost sending material into space" that works.

[Wiwiweb]

Construction bots aren't affected by robot attrition so something else is destroying your construction bots here.

You won't lose what's being carried by a robot as it crashes. The item gets dropped in a package that gets automatically picked up by construction robots.

Hope that helps assuage some fears.

[CoffeeCecil]

There's a wiki saying it doesn't happen and then there's me seeing one explode. I'll take a screen shot the next time it happens though.

The fact that it doesn't pop an item does make it a lot less stressful though. Life is easy when you can unpack a cargo rocket into a warehouse - especially if it is the first one on a planet.

Not that I'm complaining that it doesn't break things (I might just be crazy or my computer might be). But again. It's not really doing much of anything other than being annoying. But if possible (and I'm not saying it is) and feasible (and I'm not saying it is) it'd be nice if there was an off switch or an alternative.

[CoffeeCecil]

Yeah. I decided to have a look at that code. There's something going on with it that isn't right and I watched it happen today. So at one base I have 520 odd robots and a giant roboport network. And this base has six assemblers anchored to 1 logistics chest. Some of the input is handled by belts, some by logistics robots. In particular pipes are iirc. Which is relevant because it was building cargo rocket silos in batches of 50.

High volume, huge project. Also feeding my tier 2 logistics and was constructing 130 core drills because I need them.

Other base is an artillery construction base with a pollution problem. Since I have K2 installed I go "pollution filters but this time instead of circuits, I use logistics robots". On a whim I tossed 100 in instead of 50. Was down to 56 robots in 2 hours.

The logistics base lost none.

I have no explanation for why this is. The code I looked at was subtracting one value from another to find which robot networks should crash. The logic seems correct, to be frank, it doesn't seem like I should see that behavior.

There's only 8 logistics end points at the artillery base because 1 logistics warehouse was feeding 12 pollution filters. There's no reason why it should have interpreted n_robots to be more than 50 when they were flying 1 pollution filter to a cleanup station at a time.

I've never really liked watching a logistic robots explode when they come to clear my trash slots. And the rest of SE/K2 is really. Really cool. If someone says "oh, you're sad because a skill reason" then sorry, the game encourages you to solve tedious tasks with automation. Walking across a factory for belts, and then several blocks for rails, in a facility that is nearly impossible to scale out because everything is connected to something else is like... no man. I have better things to do than walk like that in a game. I'm going to make a big ol bus and have robots handle output so it all lands in one sane place.

So I deleted the entire event hook in the mod's control file. And it does exactly what it should do now. I'm just going to back up the mods folder in case my fix gets patched in any way because... yeah, no. Not interested in walking unless I'm building a giant factory. And I love building big factories.