houkime wrote:I actually don't like an approach of burner universal assemblers and inserters.
Both actually suggest some sensorics and programmability involved which actually cannot be true on this stage. Also they introduce balance issues.
Instead I personally would suggest reducing early recipe count to minimum and introducing a special non-universal machine for each type of operation. This way you need not really to balance things - they become obsolete naturally because they are purpose-built and cannot be used for anything else other than old ineffective recipes. They can even be quite fast and propel early game in a realistic way.
Because they are individual they also can have custom special behavior (not always pleasant) and variable sizes.
And for early inserters I actually have a realistic way to implement them without sensorics and whatsoever involved.
Imagine two spinning rotor like in helicopter but with sticks instead of blades. They overlap and are slightly out of phase.
To load and unload things they just spin)
You can have an example of this kind of a loader in this video.
https://www.youtube.com/watch?v=m029tGxeDR4
Just as fast as inserter would be BUT!
They spin no matter what and consume fuel constantly.
When they are set to grab things from belt they will grab till they clog and even clogged they prevent passing by things to bypass them.
So in order this to work you need a crude random beltsplitter - It can be done simple as pie. Imagine a car's windowcleaner thing that just goes right-left And pushes things to two separate belts as they go in.
Works constantly without any electronics and sensors whatsoever.
Consumes fuel no matter what
Cannot balance between lines And either pushes everything to the outer lines or just messes around randomly.
I just want to illustrate that early game disadvantages need not to be about SPEED, things can just have behavioral or geometrical drawbacks because of their crude nature. Inconvenient, sometimes funny and sometimes even useful - engineering is always about objects and their behaviour.
You know, belts that can spill over, lathes that require water cooling and produce tons of garbage metal chips that fly everywhere...
Wow, quite a good idea drop there! I appreciate your creativity and effort here, and I applaud your dedication to realism!

I especially like the idea of making very varied and interesting advantages and disadvantages, how you mentioned flying chips and belts/inserters that are too dumb to turn themselves off. It is much more realistic and limited, rather than items somehow backing up like fluid on a constantly moving belt... Also I totally agree that the inserters imply some sort of fancy sensors, which would be impossible until the advanced circuit in the base game. I explain the assembling machine as basically just a bunch of inserters putting things together, and that seems to solve the realism problem of assemblers, but doesn't really - it actually just consolidates the assembler issues with the question of how inserters work. Although you can put a fair bit of mechanical programming into non-electric machines, which is why I personally don't have a problem with the burner machine tool or chemical reactor. Switching recipes is like re-tooling and exchanging parts, which is just stuff the Factorio character does off camera and skips ahead to

Any real scenario would have TONS of grinding and stuff, this is why it has taken humanity so long to progress!
Unfortunately, while I would love to add a lot of what you said to Factorio, the reality is.. most of it is beyond my ability!

I don't actually know any of the game's API, so I don't know what variable names to use to reference anything. This *really* limits my ability. However I feel that it would take quite a bit of effort to learn, and would result in lots of bugs, so it's low on my priority list. Also, many of these hardcore realism features would make even basic automation quite impractical. As you noticed, you would have to run everything at a locked constant throughput, or face tons of jams that you have to clear manually. This is kind of a problem with science for one thing, because some techs take more or less time, and sometimes a miner runs out resulting in decreased throughput.
Also about keeping the recipe count to a minimum, this kind of contradicts the realism of uniquely limited machinery because then everything would have to be made of the same simple. unrealistic parts. Like how most everything in base is just circuits, gears, and iron plates. For example, my brother's 3 meter metal lathe from 1920 has hundreds of parts, and it could itself make probably a quarter of them. Many of them are made with other processes like casting, flat milling, slot shaping, etc. The result is that one needs an entire smeltery, foundry, and machine shop to completely re-produce the parts for all the machines used - and that's not even counting assembly, which is actually the much more intelligence-heavy process. Ultimately, if I made the part/recipe/machine count really high and had each machine do a super specific job, then it would be way too much work to add and maintain, and make progression even more slow & complicated. I've tried to go for a large handful of machines & parts, each of which represents a superposition of many similar pieces or jobs. For example the iron castings in XM, one of them could be a leg for a lathe, or the headstock (holds the spinning bit), or the apron (holds the work), or the ways (track for sliding back and forth), etc. This applies to size too, where if a machine really needs one giant cast piece, I would just put like 5 of them in the reciepe, or if a machine needs a few medium sized cast parts and a great many small ones I would just put 2 castings in. Again, I'm limited by the practicality of maintaining a mod within a reasonable size, and the goal of he game to be fun automated production. It feels like I'm pushing the edge as is.
As for the sort of overpowered universality of burner machines, I also think this is a problem, which was part of why the burner era was so difficult for me to work out. However I managed to largely nullify the problem by indeed making the burner machines become obsolete, like you suggested. I did this through using different recipe categories to limit burner machines to making only burner-level and electric-1-level things. This alone is enough to make them obsolete, because you literally can't finish the game on them, and adding their slow speed & awkward fuel requirement gives even more reason to upgrade as soon as possible. Overall I'm happy with the current set of burner machines.
In the end, I think these issues come from the structure of the Factorio game itself, just like I remember you mentioning a week or so ago. Ultimately, while I would also like to vastly improve this stuff, it would require completely re-inventing a new game (also like you said). If I was going to do that (or was even capable of it), at that point I would almost certainly make a new game instead of changing any existing one.