You should search for each specific crash message or misbehavior description, and report them if they haven't been previously reported. Even if two mods aren't compatible with each other, they shouldn't cause the game to crash.

I encountered this bug playing Pyanodon's mods, but based on discussion there I don't think this is a bug in the mod. It may be impossible to trigger this bug in vanilla Factorio due to a lack of vanilla entities with the necessary combination of features, but supposedly the features themselves are ...

This makes base planning difficult from the start, especially when you're aware that in a dozen or so hours, you'll need to rebuild everything because you'll gain easy access to legendary quality. This might come as a surprise to you, but most players don't unlock legendary quality in a dozen hours ...

Synchronizing those checkboxes would reduce the functionality of the combinator. There is no obvious/simple way to "fix" this without eliminating other ways the combinator could be used intentionally.

Are the two words also distinct in all the translations?

I wrote https://mods.factorio.com/mod/combinator-codify so that I could copy and paste parts of combinator settings. It's not perfect, but it made setting up space platform logic a lot easier for me. If more folks were giving feedback on it, I'd probably work on it more. One of the things I'd like ...

Unfortunately the API does not do any sort of search. You can request specific mod(s) or all mods and nothing in between yet. Search functionality that matches the official mod portal and in-game mod browser search functions would be a good request to make!

Suggest merge with viewtopic.php?t=118674

Are you aware of https://mods.factorio.com/mod/RibbonMaze20 ? Mazes are great!

This is a terrible idea that only might work and would almost certainly cause more problems than it fixes:

instead of creating a wire, build_from_cursor a blueprint that contains the entities and the wire

How about allowing any lua expression that uses any pure (no side effects) function from the existing library?

Is the amount to be pulled or the size of the buffer exposed anywhere in the UI or API?

What book?

I have also noticed this in my attempt at pymods, where doing prioritization without splitters is important in the early game. I was surprised to need to add belts and do side loading, not being able to rely on inserters to be lower priority than items already on a full belt.

Here's a variation of yours that doesn't require mirroring. One can take 1 belt of each of 2 items off a 4 belt sushi bus. Two copies of it in the same orientation, offset by one tile vertically, can take 2 belts of each of 2 items off an 8 belt sushi bus. I wasn't able to come up with a compact way ...

Tertius wrote: Sun Jun 15, 2025 7:46 pmI propose a different approach. Very simple and very direct.

FYI, this subforum is for no-circuits no-bots designs. This is where we come to show what can be accomplished with just belts, inserters, etc. There's a "Forum rules" dropdown at the top of each post with a summary.

Your last version can be made one column narrower on the left if you move the outputs farther down so the leftmost lane can cross under down by the other outputs. I failed to get a screenshot when I did it, though.

Good job continuing to optimize this! Makes me want to go back and try a sushi setup ...

I started concentrating on just 4 belts, with the expectation that there's plenty of space to get the outputs from the other side across the bus if you mirror this.

This was the best I could do for two items, which is simpler but I think one tile longer than your version. I like your version that ...

I might call this a N-M Filter Splitter, where N is the number of belts of input and M is the number of belts of the target item(s?) you extract. So the vanilla splitter entity would be a 2-1 Filter Splitter and your original post is a 8-2 Filter Splitter.

This would pretty closely match the ...

This doesn't quite work, but it's as close as I could get to compacting two copies to overlap. I might revisit this. Thanks for the inspiration!

06-14-2025, 23-14-26.png

0eNrNXO1u20YQfBf+poP7/hDQJymCgFYYl6hEqhRV1DD07qViIHJjXj07RCD9MmJLc7Nzdzt7e2ReqsfdqT2MXT9Vm5eq2w79sdr8/lIdu6e+2V1 ...