Preface
I thought it might be interesting to collect all of the sufficiently-specific suggestions made in the thread, and aggregate them into rough groupings, with references to the posts. So I went and did that, then thought I should go a bit further; prepare for giant wall of text.
Notes
Suggestions are numbered by appearance in the thread. If you see a post that wasn't included, it's because of one of the following reasons:
- I missed it
- It obviously wasn't intended as a suggestion in relation to the bot / belt discussion
- It wasn't specific enough to actually be implementable (e.g. 'you should focus on X instead of Y')
- It has blatant issues to the point where I don't think it's worth discussing. But I'm a random stranger on the internet, so feel free to ignore that judgement.
Notes on reading the list:
- 'bots' here refers to logistic bots, not construction. And possibly not applicable to logistic bots when they're supplying players, depending on the suggestion & the poster.
- References listed below a suggestion are links to comments in the thread where people have defined or expressed support for the idea. People may be listed more than once for a single suggestion if they later come back and add more details (or add a variation on the suggestion).
- I do not intend this list to imply that more popular suggestions should get implemented, so don't take it that way.
- If you feel I've misrepresented your suggestion in the process of aggregating it with similar ones, or otherwise misunderstood it, feel free to correct me with a post or PM and I'll get around to editing my post (at some point, probably). Or fite me IRL.
- You may note that simple 'reduce bot cargo size' and 'increase bot charging time' aren't on the list; as many commenters have pointed out, they would only result in building more bots and roboports, they don't deal with the underlying problems.
Suggestions List
- S1: Add belt un/loaders
Zeblote, psihius, Sigma1, Omarflyjoemacky, TheBrain0110, Tomik, aequitas, alefu, Avezo, purdueme91, Visione, vyktor, ssilk, warlordship, mcvey, Zool, PacifyerGrey, Gemoron, wlfbck
- S2: Limit amount of bots that can interact with a container simultaneously / explicit bot/container congestion / limited speed of bot un/loading (e.g. by explicit queing with un/loading speeds, or by a token bucket queuing system)
Zool, SeigneurAo, tarou00, Jarin, TheBrain0110, CremionisD, aelios, djtumolo, warlordship, Nick-Nack, ignatio, Antilope, Moin, Dranzer, vipm23, PacifyerGrey, Mestiff, Therax, vipm23 (again), kenken244, vorax, mavu, Iyallp, js1, Gendoh, Soloincognito, Reika, Optera, ttapada, Omez, PacifyerGrey, Brunel, Tomik, Drone, TheRaph
- S3: Add expandable splitters / balancer constructs (or at least some larger ones than 2-way)
Ubertwink, admo, Zeblote, Whirlin, CmdrKeen, Vader, Esja
- S4: Restore underground belt compression
Ubertwink
- S5: 'Belt stacking research' that makes all belts natively stack things
OrigamiGuru, TheBrain0110, Yinan, Lubricus, Killcreek2, WIZ4 (may actually be S23), Tomik, quickshot0,
- S6: Implement nested/recursive factories (ala Factorissimo) that deny use of bots within them
Ecu
- S7: Repeatable (possibly infinite) belt (and possibly inserter) speed research
3trip, Visione, SHADOW13, giustizieri25, Durentis, Esja
- S8: Stop beacon space requirements heavily favoring bot designs (e.g. Stop or limit multiple beacons from stacking while adding another mechanic to ensure they remain effective, add smaller beacons with smaller AOEs, make beacons work by transmitting effects point-to-point over power or circuit or logstics networks)
3trip, Tinyboss, 3trip, vipm23, stokan, PacifyerGrey
- S9: Make splitter behaviour even more configurable (e.g. per-lane controls, toggle for global vs. per-item alternation)
quyxkh, Dranzer, GotLag, mergele
- S10: Network-wide restriction(s) on bots (e.g. hard cap on number, decreasing speed, increasing power cost)
AgentPaper, Samlow, Inglonias, kingoftheinternet, Samlow (again), kenken244, hectar, Hakisak, TheRaph
- S11: Increase bot total power consumption (not charge rate)
Ractaros96
- S12: Make one or more faster belt tiers
Ractaros96, warlordship, yukkusu, Zool, Stevepunk
- S13: Nerf power production / power transmission / increase power consumption in general
EntroperZero, psihius, purdueme91, DragonMudd, purdueme91 (again), Tinyboss, blueblue, huhn
- S14: After nerfing bots, include a way to keep the original bots around (e.g. ultra-late-game research, alternate game mode, configuration option, appropiate modding API)
CremionisD, gerren, jodokus31 (except with nerfed bots as the alt. mode)
- S15: Implement 'covered belts' or similar (higher throughput, inserters can't interact with them, change over to normal belts via splitter or dedicated machine, may involve not visually rendering items on the belt)
<NO_NAME>, warlordship, motox, Yarri, hansinator, stokan, Sogrog, quickshot0, promaty
- S16: Add a fourth item transport mode
Samlow, warlordship, Mimos, sergey--05, tmx
- S17: Add side-inserters, or enable side-insertion functionality on existing inserters (possibly via research)
alefu, Sigma1, warlordship, briezee, Dranzer, Tomik
- S18: Explicit per-area restriction(s) on bots (e.g. hard cap on number, decreasing speed, increasing power cost)
Topher, ctrlaltdel02, Meister_Knobi, ssilk, Elecen
- S19: Split late-game recipe requirements into a couple of high-volume common resources plus a few low-volume rarer resources
Topher
- S20: Reduce the production cost of belts
Avezo, Redoneter
- S21: Nerf long-distance bot delivery times (e.g. by preventing bots from recharging before their delivery is done, by by increasing increasing charge costs for every roboport zone crossed, etc.)
Avezo, yekkusu, ssilk, Avezo (again)
- S22: Have belts carry power and supply it to devices in a 1-tile radius
aelios, scali
- S23: Make stack inserters natively un/stack items (possibly just on belts, possibly as a researched upgrade)
CmdrKeen, Lubricus, warlordship, tazdu29, madeof_tin, BluetoothThePirate, PacifyerGrey, ili, PacifyerGrey (again)
- S24: Implicit restrictions on number of bots traveling in an area (e.g. by adding bot collisions, repulsion/avoidance fields around them, throughput-limited pre-determined flight paths)
djtumolo, fallobst22, pleauser, vyktor, Meister_Knobi, Meister_Knobi (again), tmx, kisss256
- S25: Make inserter filtering functionality an option on all of them (possibly locked behind research or an insertable module
warlordship, tazdu29, Dranzer, Tomik
- S26: Add a train loader machine which can load/unload trains from/to belts at full compression and full speed (restricted version of S1)
warlordship
- S27: Remove request/provider/storage chests, add storage capacity to robo ports so all logistics movements are between roboports (and players)
jeriktelorian, Elok
- S28: Pairs of machines that effectively 'teleport' items around a base
Bertus, mOoEyThEcOw
- S29: Add an alternate bot charging mechanic that works by swapping their battery with a pre-charged replacement battery, if available in dock machine/roboport
pleegwat
- S30: Making bots have an ongoing maintenance cost (resource cost over time, e.g. by batteries burning out, or needing replacement parts)
Tekky, SilverWarrior, Mylon, mtilsted
- S31: Fix inconsistent inserter belt pickup behaviour
Mimos, hansinator
- S32: Add inserters with multiple input and/or output directions (or allow existing to be configured that way, potentially with optional balancing)
hansinator, Dranzer, devaking
- S33: Make bots explodey
golfmiketango, Elecen
- S34: Make bots ability to carry / effectiveness in carrying a given type of item be dependent on its production complexity, such that bots can carry more high-complexity items (e.g. rocket parts) and less (or no) low-complexity ones (e.g. ore, plates)
ssilk, scali, gerren, Llama (close enough)
- S35: Add more QoL de/construction tooling for belts
ssilk, <NO_NAME>
Underlying Conflict
Is there a 'problem' in the balance between the gameplay effects of belts and bots? Well, to answer that, let's look at two other, related, similar balance questions: belts & trains, and bots & trains.
- There don't seem to be many strong opinions that either trains or belts/bots should be used instead of the other -- no one suggests that trains should be a straight upgrade to belts (even early ones) because they're further along in the tech tree, or that bots should be a straight upgrade to trains because they're further along in turn.
- Few if any people appear to be deliberately restricting themselves from making full use of either trains or belts/bots instead of the other (because they believe that relative to the other option they over-simplify the game, or believe they make things less interesting or visually/aesthetically appealing, etc.).
- Trains and belts/bots each over their own clearly-defined uses within the game, which are mostly separate from one another, even though you might be able to manage using the "wrong" one to perform a given function.
From this, I get: each of the three transport technologies (belts, trains, and bots) has a conceptual 'niche' in terms of what kind of tasks it is
most suited for. The flaw lies in the fact that while the niche of trains does not have much overlap with that of belts and bots, the situation is different for the other two:
- I1: The niche of bots totally overlaps the niche of belts, and also covers extra things (that is, the bot niche is a superset of the belt niche)
- I2: Bots are better (more effective in terms of throughput, more convenient in terms of design and construction) at doing everything belts do (if you think this is a simplification, you're right, and I hopefully address your complaint later, so read on)
As a result, there's a tension between belts and bots that arises as a result of bots becoming progressively more of a replacement for (occupying more of the niche of) belts as they get upgraded and as your production facilities scale up. Meanwhile, trains with their mostly non-overlapping niche play very well with belts and bots.
The two issues immediately suggest a two-pronged approach: modify belts and/or bots to make their niches more distinct from one another, and mody belts and/or bots to make belts a (roughly) equally viable/'optimal' option in comparison to bots for the areas where their niches still overlap.
Additionally, part of "better at doing everything belts do" in I2 is that bots are significantly simpler and more convenient to use than belts are. Yes, they do get more complicated when you're building a megabase, but having built both a 'trains and bots' megabase and several 'trains and belts' megabases, I can confidently say that the latter is more complicated, and (to me) more interesting, engaging, rewarding, and aesthetically pleasing. I do think bots are a cool technology and I used them even in my 'trains and belts' megabases, but in a specific and limited fashion.
Caine proposed a similar model later in the thread, but I'd collapse space efficiency and flexibility together, personally. Space efficiency isn't really a direct concern; it only matters insofar as it impacts your ability to freely transport items within a factory module (a set of machines doing single task or set of related tasks and conceptually grouped together by the builder during design/construction), and freely place factory modules relative to one another.
Why should we care?
But, hey, why do we actually care about the options having different niches? Well, mostly because it means that more-optimal factory designs will tend to be the ones that leverage all three of the different transport options, to a large degree. This matters because the solutions that use more of the tools available tend to be the more interesting and fun ones. While it should generally be
possible to do things in a simpler way using a restricted subset of the tools, so people have an easier time starting off, it should also be
desirable to come up with more complicated designs in order to sustain players' interest and enjoyment over time.
There've been quite a few good arguments from people defending bots as-is, based on their experiences of the game. While they're no doubt enjoying how it is currently, I don't think that in itself is a great argument to keep things how they are, partly because they do not appear to be anywhere near a majority of current players (let alone future players), but
mostly because it encourages less diverse gameplay. Additionally, at least part of why they enjoy bots so very much is likely because of how awkward belts can be to work with at scale; improve that and I suspect they'd have a better time with belts than they may expect.
There have also been a few ideas around making bots and belts capable of explicitly supporting/enhancing the other. These are somewhat attractive, but ultimately I think they'd lead to less novel and interesting designs than having bots and belts each occupy their own well-defined niches -- because the other proposals would lead to greater homogeniety by encouraging you to use both types of transport simultaneously for everything.
Lastly, there were a couple of arguments that bots are cheaper than belts, based primarily on the cost of their associated research. This is missing the point on a few fronts, because it's making an apples to oranges comparison: current bots do a lot more than belts do, are significantly more convenient, and significantly more effective at what belts do (provide throughput of items across a given space) item for item. Making the comparison also implies that a single blue belt tile is comparable to a single logistic robot; but when you look at that explicitly instead of implicitly, it's obviously ridiculous.
Suggestions Analysis
Given the framework described, I went back and re-read all the suggestions, including all the new ones that occurred while I was writing stuff / making coffee (no, really, all of them ._.) to analyze them from this perspective and determine their impact on the two issues.
Before starting, and based on my first reading, I thought it would make the most sense to attempt to restrict the scope of bots niche to mostly focus on lower-throughput delivery of items across long distances, over complicated factory setups, or to/from especially tightly-packed factory areas.
I've annotated individual sentences of analysis with things like (I1) to denote which of the two underlying issues they have an impact on.
Of course, if you don't happen to (at least mostly) agree with my model, then probably the rest of my thinly-veiled rant won't interest you much. orz
- S1: Quite a lot of people like the idea of loaders. Frankly, I think this is just an inferior version of S26 (train loaders), because un/loading trains is really the only point at which they'd be necessary (for some value of necessary); everywhere else they're just pointless power creep. But if you disagree, they have the extra benefit (beyond S26's) of making belt setups more convenient (I2). If you have examples of other situations in which they'd be useful to core belt-based design aspects, and that aren't better improved by stack inserters or insterters that can compress belts, please do let me know. I'd be interested to hear them.
- S2: Variations on this idea are crazy popular, and I can see why: it doesn't nerf bot usage for all cases, but instead largely restricts bot usage to low- and medium-throughput scenarios (I1). You can also still work around it for high-throughput, but doing so requires increased complexity and space usage, making it more comparable in effectiveness to a belt-based setup (I2). Also, would be pretty easy to make this configurable by mods, letting people who like old bots ease into the changes (or never change).
- S3: Properly setting up belt balancers and main-bus-branches are a major pain point with belt systems, and this would go a long way to alleviating that (I2).
- S4: I guess this would maybe help a little with belt convenience (I2), but honestly underground belt compression is quite a bit of a hack, and very unintuitive. Just adding back belt sideloading compression would likely be plenty.
- S5: While I like the idea of stacks or pallets of items, I don't think this is the best way to go about it. A research that makes all belts (or even just blue belts) natively stack things would be overly powerful, and would also require improvements to train cargo sizes in order to not unbalance the train/belt niches. Would improve belt throughput (I2). Would potentially also mess with many circuit-controlled belt designs.
- S6: Would expand the niche of belts (I1), and building a belt-only recursive factory might be more powerful than a non-recursive bot factory for some cases (I2). This idea has the unique downside in that you would no longer be able to see your entire factory on a single plane, which is a really powerful thing for design, analysis, debugging, and comprehension. Making elements of factory design/functionality "invisible" to the player runs fairly counter to Factorio's existing design (the devs have gone out of their way to make things visible).
- S7: Would increase belt throughput (I2). Somewhat interesting, has some issues: increasing belt speeds would (currently) require increasing inserter speeds, or something like loaders, and there's a more fundamental but subtle issue where it would break the possibility of many circuit-controlled belt-based designs if belt speeds were variable over time.
- S8: Affects belt-based factory performance (I2), doesn't involve a bot nerf, would result in prettier factory designs... looks good to me.
- S9: Affects belt convenience (I2), a little. Mostly unrelated to the issues, honestly. More generally, I'm not sure if these changes would be a good thing... I'd need to spend some time figuring out how difficult various things would be with/without these options.
- S10: This is an interesting one. Would promote building smaller, more isolated networks with medium-throughput bot usage and/or large networks with low-throughput both usage, and as such would alter the bot niche (I1). As some have suggested, would likely need to be paired with a mechanic for maintaining separate logistics networks with overlapping physical spaces (e.g. "coloured" logistics networks).
- S11: Wouldn't do much on its own, in concert with S13 it would affect the viability of mass-scale bot usage, while leaving the rest intact, changing their niche (I1).
- S12: Would improve belt throughput significantly (S2), has only some of the issues S7. I don't think it's a great approach, though; do we really need yet more tiers of belt that are just higher-throughput...?
- S13: I'm kind of in two minds over this, and on its own it isn't really relevant to the issues, although it could be if combined with S11. I think coal is well-balanced right now, solar maybe could use some changes, and nuclear may be OP. On the other hand, I'm not actually sure it's a problem if nuclear is OP -- it frees you up from having to worry about the problem of power supply, which isn't necessarily all that interesting. On the other hand, maybe this should be changed, and mechanics should be added to make power supply more of an interesting challenge... either way, it's kind of out of the scope of belts & bots.
- S14: Doesn't affect either I1 or I2, but on the social level it's probably a good idea, as it'd give players who like old bots a softer transition (or no transition, if they want), resulting in less salt.
- S15: Would improve belt throughput (I2), and the restrictions basically mean it's largely only suitable for acting as a 'main bus', kind of implicitly promoting that style of design. Which could be a good or a bad thing, depending on your perspective -- either the devs would be making solid design choices more discoverable/intuitive, or they'd be forcing a certain gameplay style.
- S16: ...This isn't so much 'out of the box' thinking as 'build a new box' thinking. I mean, it doesn't affect either of the two issues, and instead introduces an entirely new niche to think about. Additionally, none of the suggestions thus far are specific enough to be able to directly implement and thus actually determine out what that new niche would look like.
- S17: Would allow for more compact belt-based designs (I1) and also potentially allow for more effective/performant belt-based designs I2), although to relatively small degrees for both. I still think it's a good move, even more generally.
- S18: This is a variant of S10, and similarly would likely restrict the niche of bots somewhat (I1), but I'm not sure it'd be as effective in doing so, or provoke as much in the way of interesting design decisions. I could be wrong though.
- S19: Probably a good idea in general; would help to promote a split between high-volume and low-volume transport mechanisms, so might impact the niches of both belts and bots (I1), although probably only in concert with other changes.
- S20: plz yes. Yellow belts are fine, red belts feel like a huge jump up, blue belts to a somewhat lesser degree (because you've scaled your systems more by then). Making faster belts cheaper would make them a lot more viable to use in general (I2).
- S21: Nerfing long-distance delivery times would only increase the latency of bot transport, not the througput.
- S22: This is a pretty neat idea, it would enable some more compact belt-based factory designs (I1) and generally make belts more powerful and convenient (I2). I'm not certain it fits the game overall, but it's an option that should be considered
- S23: Another try at stacks/pellets, improving belt throughput (I2). I suspect this one would work better than S5, depending on the specifics. More on this option later.
- S24: A suggestion in a similar vein to S10 and S18, with similar likely effects, but would probably be more computational intensive to implement, depending on the specific variation. It's also less explicitly manageable by the player, which I don't like.
- S25: Makes belt-based designs a little more convenient (I2) but probably isn't actually that relevant to the issue. But: generally seems like a good idea. Filtering inserters as a separate item is a little weird given how infrequently they're useful.
- S26: This is a good one. As mentioned, I think general-purpose container/belt loaders are just a worse (overly powerful) version of these. These actually solve a specific issue: even though there are 6 tiles adjacent to a cargo wagon per side, you can't actually unload from those six tiles to six blue belts at full compression using only inserters. Adding these would mean belts are actually viable for train un/loading (I2), which is a big issue.
- S27: This would restrict the niche of bots (I1), but it wouldn't actually reduce the main overlap with belts niche much (high-throughput transport within short/medium distances) and would remove bots from the part of the niche they uniquely occupied (transport of low-throughput items into/out of really compact, physically constrained builds).
- S28: This is kind of a fourth item transport (like S16), but detailed enough to be implementable. Problematic in that the niche of these devices would overlap with bots a lot, although not much (if at all) with belts. Intriguingly, you might be able to argue for replacing bots with an idea along these lines, and it would admittedly be endlessly entertaining to see items being shot out of cannons and flying through the air all around your base (and into your face)... And a long-range version could potentially be an interesting option for low-volume, irregular supply of materials to outposts (e.g. repair packs, replacement set of bots).
- S29: This doesn't really affect either issue, although it does make the really-late-game complexity of bot charging slightly more obvious. It is a definite buff to bots, but I actually think bot charging mechanics do need a buff, so this isn't a bad idea in general, once the bot/belt issues are resolved.
- S30: If expensive enough, could impact the ability to use bots at mass-scale (I1), but would also negatively impact the use of bots in general (civilian casualties D:), so I'm not sure it's a great idea. Also introduces the problem that you'd almost certainly want to use the bots themselves to transport the maintenance material into the roboports, which could get awkward...
- S31: Doesn't really have a major impact on the issues (very very slightly on belt-based factory performance, so I2), but definitely an issue that should be fixed in general. Current behaviour is surprising, confusing, and the cause of subtle and aggravating performance issues in belt-based factories.
- S32: This would enable more compact belt-based factories with complex inputs/outputs (I1), and would make belt-based factory design somewhat more convenient (I2).
- S33: Well... This could somewhat make bots less powerful (I2), I guess, but seems a little too nutty. Honestly, I've only left it on the list because it's hilarious.
- S34: An interesting one. Would directly shift the niche of bots towards transporting low-volume items that need to be moved across long distances or over inconveniently full parts of a factory, as well as simply for moving low-volume items that are only needed or produced in very small amounts (I1). Making bots unable to carry really low-complexity items would be restricting their flexibility too far, I think, but maybe reducing the bot carrying capacity of things like ores and plates to just 1 would work well.
- S35: QoL/convenience additions to belt de/construction would make them more convenient to use (I2), and all of the suggestions mentioned seem like solid ideas in general, to me.
Synthesis
Well, it looks like there's a lot of options for the devs to play with in regards to dealing with the two underlying issues. I'm sure they'll eventually end up choosing some good ones that make the game more interesting, engaging, and visually appealing, as they are wont to do.
But while I'm writing this ungodly monstrosity of a post, I might as well put down what I think a really good set of selections could be. Obviously, high on opinion and speculation.
Logistic bot/container concurrency limits (S2)
Because it would have relatively low impact on existing bot designs before fairly late-game (so, most of them), and it would clearly shift the niche of bots toward supplying low-volume items across long distances or in tight spaces. Bots would still need to not have limits on supplying the player, to not kill QoL.
Downsides: would be slightly odd if construction bots still had instant access, but we really
don't want them to be blocked by concurrency issues. Would also need to be able to supply the player without concurrency issues.
Might be able to deal with those issues by simply setting the concurrency limit high / un/loading time low enough. Possibly also suplementing with a limited version of S34 by making the cargo limit for ores, plates, and green circuits 1.
Overall, I think S2 is probably the best method of changing the niche of bots, and restricting their effectiveness where they still overlap with belts. It's also one of the most popular options, going by this thread, so implementing it would likely generate less salt.
Further Alter Belt & Bot Niches
I think a few further things should be done to more clearly define belts & bots separate niches. Specifically:
- S26: This is the most important one here. Trains have space for 6 belts on either side of them, but literally cannot be unloaded onto 6 express belts at full compression using only inserters, right now. Belts should at least be able to compete with bots in this regard, and given the way I've suggested their niches should be defined, belts should be the better option.
- S8: Change beacons to have roughly equivalent effects but without stacking mechanics, removing the space advantage of bots in beacon-enhanced factory modules. Also because the current setup is ugly as sin and has one obvious optimal configuration.
Ideally, I think it'd be cooler to instead have some kind of 'effect generators' that are connected by electrical network (or a new wire type run over it) to target machines.
Each would be able to affect several machines still, but with no stacking, and you'd be able to select which it affects from any connected the network. Would need some new interface mechanisms for easily (re)assigning groups of effect generators to groups of targets, and for identifying what affects what.
- S19: Designing high-tier input requirements like this generally seems like a minor but solid change to transport mechanism balance / niche separation.
Improve maximum belt throughput using item stacks
By making stack inserters inherently capable of creating stacks on belts (S23). Specific details:
- There should be a late-game research (around the same time you get the last few robot upgrades, or not long before) that enables all existing stack inserters to combine items into stacks (sized up to the stack size the stack inserter is currently set to).
- Stacks are formed of only 1 type of item
- Stacks can be placed onto all normal belts
- Stack inserters can place onto a stack that is smaller than the inserters set stack size to top it up, but cannot make it larger than their stack size
- Normal inserters cannot create stacks
- Normal inserters can skim items off the top of stacks (or pick up all the items in a stack, if it is small enough)
- Stacks don't exist anywhere but on belts
- Splitters can optionally break stacks into unstacked outputs on one or both of their outputs (or individual lanes, if per-lane controls become a thing)
- Stacks are created only by a stack inserter placing them onto a belt, or by a splitter (maybe an advanced/stacking splitter) set to output items as stacks
One of the consequences of this would be that train cargo sizes would need to be improved, as otherwise belts would be encroaching on more of their niche than ideal. Plus, they're kinda weeny as-is, I mean, they're 'physically' 6x2x2 chests in size at least, but don't carry anywhere near that amount of resources...
The main point of this is to enable belt throughput to be hugely increased without requiring ludicrously wide belt rows, nor the accompanying insane belt balancer and branch/feed arrangements. Main bus/tree design is a core element in belt-based systems, and this would enable that to scale much better than it currently does.
Expandable, flexible belt splitters (S3)
On one hand, I kind of quite like the giant belt balancer abominations we have right now; watching the items move through them is almost hypnotic. On the other hand, they're totally unintuitive, and the game doesn't mention them or otherwise expose the player to them at all, so learning about the issues behind and importance of belt balancing is non-trivial. Belt balancers and balanced extraction from a main bus are big pain points in build belt networks.
Given this, I think it would be a good idea to continue the splitter enhancements, and enable us to build much larger (but not arbitrarily) splitter constructs by placing down existing splitters. The simplest arrangement would probably be something like... any two or more splitters (up to some large maximum) physically adjacent and also connected via circuit wire (allow it to be run directly between them) form a single large splitter, which can be configured with all the same options that single splitters can.
Doing it this way allows for maximum flexibility in positioning/arrangement, at least, but doesn't preserve the aesthetic complexity of the older ones, sadly. I'd be interested in better suggestions for specific ways of implementing expandable splitters.
Minor belt-based factory improvements and QoL features
- S35: The QoL improvements from these two posts: 1, 2
- Make belt sideloading compression work again! This is basically the only one of the compression methods that is at all intuitive given the basic belt mechanics, and it also makes a lot of sense visually/physically. Watching side-loaded belts not compress just looks subtly wrong.
- S20: Make belts cheaper to construct. You need absolute shitloads of them.
- While you're at it, and on the same note, increase belt stack sizes, maybe? Say, double them?
- S17: Side-inserters, preferably not as separate items but a configurable option on them. With hotkeys. I'd say without even a research requirement; but if it has to have one, make it early.
- S25: Make inserter filtering an option on all inserters, instead of a dedicated item. Still locked behind the same research.
- S31: Fix the inconsistent behaviour re. inserters picking up items from belts in different orientations relative to them...
- I'd also suggest making it so that all inserters can pick up from belts of all speeds without issue. Conceptually, inserter 'claws' should really hover just above the line of moving products anyway, always ready to immediately grab one and jerk it back off the belt a bit before more slowly lifting it into place.
Possibly also:
- S32: Inserters with multiple, configurable input/output locations seems like an interesting option, although probably as a new inserter type? Might be a bit much.
- S9: Make splitter behaviour even more configurable, with ability to apply controls per-lane, and toggle between global and per-item alternation across lanes in an output
- S22: Have belts carry output and supply it to devices in a 1-tile radius. OK, so, totally unnecessary and I just want to see it happen because it'd be cool to play with it . I should probably just go mod this in, if possible.
Buff Bot Charging
Bot charging is gimped and awkward as hell right now. Slamming down a bunch of roboports looks shitty and is a boring way to solve the issue. There's no reason not to buff this once bots niche is more clearly defined. Some ideas on how to fix it up:
- S29: Add support for (nearly?) instantly recharging bots at a roboport by supplying them with pre-charged replacement batteries. Let the batteries be charged in the roboport, but also in dedicated machines for it (and then just belted/botted to the port).
- Add a kind of 'tesla tower' object that can wirelessly charge bots in range. Possibly with some loss in efficiency (maybe scaling with distance?), hopefully with some sort of awesome animation involving lightning, somehow. Bonus points if it can charge the modular armor gear of players in range of it.
TL;DR
It was Saturday and I was bored. Now it's like 4AM Sunday and I have a headache. This was a terrible idea.