This does look good, and is a clear improvement, although I'd love to see the kind of orthogonal tracing stuff you see on PCB layout software, where setting a corner sets the position of the previous corner, and locks that axis, then waiting for you to place the next corner before deciding this one....

+1

That sounds great, but it doesn't appear in the documentation for TriggerEffect (https://wiki.factorio.com/Types/TriggerEffect), so I'm not sure what TriggerEffect types this works for... The hit-effects.lua file seems to use it for "create-entity" type effects. I'm also curious why that f...

Another factor is that the game simulates the particles even if they aren't rendered, and I've seen True-Nukes produce particle updates in excess of 20ms/tick for several minutes straight - and that is with substantial anti-particle measures in place (in fact a huge amount of T-N is anti-particle co...

Simple reason IMHO: if you want to cancel crafting, then what will change, if you are asked, before the game begins to spill? You need to cancel it, so do it. NOW! Don’t bother me with questions, I need to go fast, because every second might count (crafting will produce useless items in the meantim...

Adding a reserved-queue will increase CPU cost (one queue per roboport). Strictly this could all be done with a counter - every bot knows which roboport it is going to, and increments the counter for that roboport, and decrements it if it changes target. I'd still say it would increase the difficul...

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

... Like the differentiation you made between intuitive and complex. Yeah, this is more complex and might be eventually more intuitive. Which is - when it is really like so - a good thing, because that improves the gameplay in a way, that Factorio likes to go. But - as you might know - intuition is...

... Yeah, what you are saying makes a lot of sense, my only objection is that I don't tend to plan my bot routes out, I just expect them to work, which they mostly do, with a few exceptions, all of which are due to me assuming that they'll follow the trail of roboports rather than bee-lining it. I ...

Well, I've made it work - at least kinda. It oscilates massively, overfills its output belt, etc. But it is a belt only self adjusting sushi-belt system. Note that it only uses yellow belts, with some reds for length purposes. I have a huge number of improvements I'd want to make, but this is kinda ...

Note: The proposed algorithm should actually save bots in a lot of cases. I would say it's more likely to save bots than harm them with the new paths. Assume the blue area in the OP is alien infested territory. Currently the bots will venture into the alien territory and get shot down. With the pro...

That is not quite true. One thing I use from time to time early in the game is the following: Pick up a bunch of copper wire from an assembler, click on circuit boards to build all, cancel all copper wires intermediates. That will let me build as many circuit boards as I have copper wires picked up...

Since this forum is about circuit-free solutions this would have to be something you turn on/off manually. I'm not so sure about that. Using a feedback measuring system, and clever belt jamming techniques, you could conceivably vary the levels of potions until the number received was proportional t...

I've built a version which divides the belts using splitter-logic, so that they naturally give 1/3 or 1/4 as relevant. This means it doesn't suffer from items missing. It can have issues if the sushi output is disconnected, but with about 3 looparounds installed, I haven't been able to create any br...

Yeah, the mod works pretty much entirely with script triggers, which are caught on line 340-416 here: https://github.com/More-Wrong/Factorio-True-Nukes/blob/master/True-Nukes_0.3.4/control.lua and are generated from here: https://github.com/More-Wrong/Factorio-True-Nukes/blob/master/True-Nukes_0.3.4...

All of these are good suggestions, and any of them would be an improvement - particularly the freeze position of mouseover, and the hide intermediates beyond first craft. I'd also say that when you have the queue expanded, it should form a window, so you can't click things behind it when manipulatin...

Yes, this would be amazing.
I'd say the game should give a message like: "Cancelling craft will overflow inventory, are you sure?"
Then clicking again would cancel anyway.

I can easily pick up another vanilla playthrough. The problem is not that I need more content, but that I don't want to be fresh after another 1k hrs playthrough when the DLC is released. I think the intent is that with a broad range of mods, the vanilla playthough can be sort of fresh - although t...

as you say a roboport must be in range of the target so you could always set that as recharge target Ah, in almost all cases - there is the potential for a mod to create a really inefficient robot going from a super wide-range roboport to a very remote target. Then the bot literally cannot reach th...

Please lets concentrate of the simplest fix first. Yes absolutely - the originally proposed change would be a really big improvement, and the rest is just dealing with edge cases on that. As for the case of the bot picking its source as recharging target: As a first iteration this should raise an a...