[Mod 0.16] Signal Splitter Combinator

[Cadde]

https://mods.factorio.com/mod/signalsplittercombinator

Signal Splitter Combinator

A simple decider combinator that takes one input, the signal index to output.
Indices range from 1 to 2^31, though at that point i bet you have WAY too many signals in your network anyways.

The order of signals is determined by their load order or something similar. As such, a burner inserter will ALWAYS come before a regular inserter. And so on. With this in mind, don't rely on a particular signal to be in the same indexed slot all the time. It really depends on whether a signal comes before or after another in the games internal library.

The point of this combinator is that you can select A signal, whichever you want from the currently active signals by it's index.
The use case would be if you want to split up signals into separate channels. For instance, easy splitting of belt contents onto separate belts.

Or whatever else you may need a signal splitter combinator for.

Known issues

Performance - Due to it being an initial release, i haven't done any optimizations. As such, do note that the internal mechanics on this mod may be heavy on performance. It's constantly updating a decider combinator (which this essentially is, controlled by code) on every single tick. It is entirely possible to avoid this constant updating by checking if the signal has changed. And only updating when it actually has changed.

Let me hear your thoughts on improvements.
For example, in the next version i could always add a specific signal to listen for that sets the index via circuit network? I don't need it but you might?

[eradicator]

Just from reading the description:

"If you want to reset the index, just save and load the world."

If your code behaves differently after a save/load cycle it is guaranteed to desync in multiplayer.

[Cadde]

Thank you for the heads up, i will change this behavior in the next release then.

That being said, you don't happen to know for sure that this will cause a desync? After all, it's just a local variable in script that sets up a newly placed combinator with a higher index.
Will one machine assume an index of X and the other an index of 1 (for a fresh join) and this would be the desync in question? Or would it sync based on whomever sets the index on the object in question?
Why wouldn't it desync whenever someone sets the index via the GUI? It's the same thing happening.

Finally, this mod was made for personal reasons in SP. I am releasing it because i've seen a need for it when i looked for a solution to my own problem.

EDIT: No matter. I've updated it because i never did get around to test it with construction robots... And it crashed whenever a construction robot would place or destroy an entity due to left over development code.
In the same sweep, i've removed the auto-incrementing indexes.

[eradicator]

Will one machine assume an index of X and the other an index of 1 (for a fresh join) and this would be the desync in question?

Exactly.

That being said, you don't happen to know for sure that this will cause a desync? After all, it's just a local variable in script that sets up a newly placed combinator

If it behaved like you described the desync is guaranteed 100% as stated above. Factorio is a synchronous simulation, which means that all players must have the exact same game-state at all times. But your assigning an index K on player1's computer and index J on player2's computer, etcpp. Mods are generally not allowed to behave differently after a save/load cycle for this reason. It's not something you (or any other modder) can "do right" - it's simply not allowed because it breaks the synchronicity of the simulation.

Well, "allowed" is realative ofc. The engine doesn't care about it in SP because you can't desync with yourself. Just telling you so you can keep it in mind for whatever you mod next ;). If you actually wanted to keep the behaviour you could simply store the variable in global (i.e. the global table litterally named "global").

As a general tip you can put all dev code in an "if DEBUG then dostuff() end" clause, so it can simply be disabled by removing the global "constant" DEBUG or changing it to false.

[Cadde]

If it behaved like you described the desync is guaranteed 100% as stated above. Factorio is a synchronous simulation, which means that all players must have the exact same game-state at all times. But your assigning an index K on player1's computer and index J on player2's computer, etcpp. Mods are generally not allowed to behave differently after a save/load cycle for this reason. It's not something you (or any other modder) can "do right" - it's simply not allowed because it breaks the synchronicity of the simulation.

So both clients run the exact same code path whenever an event is fired? It's not a per object sync?
Good to know. Thank you.

With that in mind, since neither of my friends play MP and if anyone wants me to fix MP issues i would need the error reports for such cases so i can make it MP compatible.

Well, "allowed" is realative ofc. The engine doesn't care about it in SP because you can't desync with yourself. Just telling you so you can keep it in mind for whatever you mod next . If you actually wanted to keep the behaviour you could simply store the variable in global (i.e. the global table litterally named "global").

Whatever i mod next would likely be some functionality i would need myself, in SP.
I can't keep MP in mind when developing without also testing MP related issues myself.
This due to the simple nature that i'm not running MP.

As a general tip you can put all dev code in an "if DEBUG then dostuff() end" clause, so it can simply be disabled by removing the global "constant" DEBUG or changing it to false.

This mod was written from pretty much scratch for the first time. While i've done LUA scripting in the past on many other games. This one was literally me figuring out how to make things happen in factorio.
The one problem i have with anything LUA is debugging. There's no compile time catches such as "you cannot assign string to a number field" etc. A.k.a, type safe.
And i can't easily watch the results of some operation in data or the contents of some structure. For that, i used serpent a lot coupled with abusing the GUI to print contents of data structures and results of operations. Hence why there was a lot of testing code remaining.

If i were to do what you propose and use "if debug", i wouldn't be able to gain any benefits using that system. It would be a boon and i would be better off doing things right first try. At which point, i wouldn't bother releasing the mod as i then wouldn't need to take such measures.

"oops, i forgot to remove that" - fixing right now, i can still hot-load controls.lua by a save/load.

That being said, i release because it can be useful for others. And i would be happy to fix any issues that arose for others when they happen.

[eradicator]

So both clients run the exact same code path whenever an event is fired? It's not a per object sync?
Good to know. Thank you.

The only thing synced are so called "input actions", which includes keystrokes, console command, and a few special cases like resolution changes. Everything else must be simulated synchronously.

I can't keep MP in mind when developing without also testing MP related issues myself.

Apart from desyncs from using local variables instead of storing to global there's not really any MP issues that need to be cared about at all. Not that i can't realate to the problem of insufficient MP lab rats testing environments...

Yea, debugging includes a heap of guesswork. The "if debug" method was more meant as a way to quickly check if it runs fine when it's turned off. For static logging things, not for the quick print() bits used for situational debugging. Also i didn't know if you had any programming experience :p.

I think most modders originated from a "i want this for myself" pov. And then slowy drift towards..."but hey, this might be fun to implement" :p.

[Cadde]

Indeed, i usually make something for myself and end up coding "for fun" for others as time permits.
You could look up Mods Studio for Euro Truck Simulator if you wanna see my "experience levels". And that's just the tip of the iceberg, because as i said, i mainly code for myself whenever i need something or i simply feel like making something cool.

As this project is a first for factorio and i kinda love-to-hate LUA, it's messy.

[Nightinggale]

I have an idea for optimization. You should add a selector in the GUI for input. You should be able to select red, green or both wires. Avoiding using both wires means you can avoid spending time merging the red and green wires and even not reading one of them at all.

For example, in the next version i could always add a specific signal to listen for that sets the index via circuit network? I don't need it but you might?

I could really use that. I'm trying to use crafting combinators to switch production according to changing needs. It works, but it's getting complex and can stall on something like trying to produce green wires before green circuit boards even when out of circuit boards. I plan on making some loop like system where it tries to produce item 1. If it fails, then item 2 etc. Looks like Signal Splitter Combinators could assist quite a lot when trying to build something like that.

You could add a red/green/both selector for control signal as well, meaning you can set it to control on green and data to pass through on red if you like, preventing mixing the two signals.

Factorio is a synchronous simulation, which means that all players must have the exact same game-state at all times.

This is a fairly common setup for network games because it makes them less prone to suck if ping times get too big. It makes sense when you think about it. Imagine a ping time of 10 ms. On a 3 GHz CPU, that's 30 million CPU cycles. If the CPU can calculate the data in 50k cycles or less, why wait for the network? The game will run faster, more smooth and use less bandwidth if it can pull off doing all calculations in parallel on all computers.

It's also common to use the savegame code to make a savegame and send to a joining player. This means if you save and load, if anything is changed, then you will cause desyncs.

While I haven't released any mods for Factorio, I have worked with setups like this for other games and I can tell you that trying to figure out what is causing desyncs can really be a pain, particularly if it's some background activity like circuit networks. It's much better to make sure you get it right from the start.

Another thing you should be aware of would be blueprints. Make sure you can make a blueprint where your settings and wire connections work as intended. It quickly gets annoying to use some awesome entity from a mod only to discover it's a micromanagement pain because you can't use bots to build it, meaning you have to build, connect and set up each manually.

Copying settings between controllers is also something to watch out for. I think it calls a certain LUA function in one of them with the other one as argument, but I can't remember the details. It looked fairly easy to do when I looked through the documentation at some point, but even the simplest task is a bug if you forget to implement it at all.

[Cadde]

I have an idea for optimization. You should add a selector in the GUI for input. You should be able to select red, green or both wires. Avoiding using both wires means you can avoid spending time merging the red and green wires and even not reading one of them at all.

While that's possible on pure "select index" from either red or green. It will still merge the signals from red and green.

Example...

Green: 56 x copper plate, 48 x iron plate, 77 x coal,
Red: 3 x engine unit, 156 x rail, 54 x red science, 45 x coal

On the green channel, coal has index 3. So selecting green and index 3 would set up the underlying decider combinator for coal. It would output 122 x coal, not 77 as you might expect.
Can anything be done about this? OF COURSE! but i would have to make hidden constant combinators instead and control the output manually rather than abusing a decider combinator like i am doing now. I wanted to keep things simple so i went with that.

For example, in the next version i could always add a specific signal to listen for that sets the index via circuit network? I don't need it but you might?

I could really use that. I'm trying to use crafting combinators to switch production according to changing needs. It works, but it's getting complex and can stall on something like trying to produce green wires before green circuit boards even when out of circuit boards. I plan on making some loop like system where it tries to produce item 1. If it fails, then item 2 etc. Looks like Signal Splitter Combinators could assist quite a lot when trying to build something like that.

You could add a red/green/both selector for control signal as well, meaning you can set it to control on green and data to pass through on red if you like, preventing mixing the two signals.

I will consider it. But be mindful that indices still change. I had this idea (for some reason) that all would work out well as far as indices goes. That for example copper wire would stay at index 1 in recipes. But sometimes, some recipes have some items that come before copper wire in the list. All of a sudden, copper wire could have index 2 or higher.

So can you explain in more depth just exactly how changing the index on the fly helps? The reason i made this little combinator was because there was no simple way of splitting any assortment of signals up into single outputs. And the only reason i would need that is because of miniloaders and per-item belts. As in, i am feeding an assembler each ingredient on separate belts and it's set up to accept any recipe with up to 10 ingredients.

Example:



Whatever i set the recipe to in the assembler, each belt will be filtered to one of the ten indexed signals. And because specific items indices change on different recipes, i've even set it up so items will move around to the appropriate side that will feed items into the assembler.

But if you can explain in detail just how an index selector signal will help you then i would be happy to add it if it's necessary.

EDIT: On a side note, i really miss Minecrafts modded redstone where each wire color really has meaning. That is, i wish factorio had 16 colors to pick from and that they were truly separated in every circuit network machine.
And of course that one could perform such tasks as select a signal, max, min and other common logic without needing to make a jumbled mess in vanilla.

To be frank, they should have included a circuit network computer.

[Nightinggale]

Can anything be done about this? OF COURSE! but i would have to make hidden constant combinators instead and control the output manually rather than abusing a decider combinator like i am doing now. I wanted to keep things simple so i went with that.

In that case forget the proposal. Instead I need to take a look at your code because I tried to hijack the decider combinator like that and couldn't get it to work. Maybe I just didn't get it right and maybe it's easier in 0.16 (I think I played around with 0.15, not sure)

I will consider it. But be mindful that indices still change. I had this idea (for some reason) that all would work out well as far as indices goes. That for example copper wire would stay at index 1 in recipes. But sometimes, some recipes have some items that come before copper wire in the list. All of a sudden, copper wire could have index 2 or higher.

Through my experimentation, the list of signals is predictable. It sorts the signals according to value (high to low) and for signals of the same value, the order of signals in the crafting menu is used.

This can be used if you want to control the order of signals. If you don't want the values, just signal types (like filters for inserters, loaders etc), use a decider combinator and output each as 1. After that if you want to give something come first, set up a row of decider combinators in parallel, all inputs connected by red wire and all output connected by whatever wire you want (or both). First is pass through (needs a tick delay, each + 0 works too). The next is a decider combinator, which is true for each > 1 and outputs value of each. Next is true for each > 2 and outputs value of each etc.
Now for each decider combinator, attach a constant combinator with a green wire and set the high priority stuff there.

Example: you want iron plates to go first nomatter what.
You set icon plates to 1 in the constant combinator. The decider combinator triggers on iron plates > 1, in which case it will output 2 iron plates. If there is iron plates in the input, it will be 1 (remember the first decider combinator sets everything to 1). This gives a total of 2 and iron plates passes through the decider combinator. This means out is 3 iron plates (1 from pass through and 2 from the combination with the constant combinator), meaning iron plates will always be before anything, which is just in the pass through.

Knowledge of this is quite important when using the crafting combinator because it only looks at the first signal. This means if you want to make yellow belts, you need gears. If both are 1, it will make belts before gears (signal order). Setting it up that requested gears have the value 2 while belts have the value 1, gears takes priority and your production line will not stall in lack of input.

So can you explain in more depth just exactly how changing the index on the fly helps?

I have set up a Memory Module. The address controller is a decider combinator and a constant combinator, which is set to count ticks. It resets at A == 500. The result is that the memory reads input once every 500 ticks. This means the index of each signal is stable for 500 ticks. Since the input is the items in storage, I then have 500 ticks to iterate though them to decide which item is the most important one to produce. Since this is quite literally an iteration, having a memory, which adds one every time I want to move on to the next item seems like a clean solution.

EDIT: On a side note, i really miss Minecrafts modded redstone where each wire color really has meaning. That is, i wish factorio had 16 colors to pick from and that they were truly separated in every circuit network machine.
And of course that one could perform such tasks as select a signal, max, min and other common logic without needing to make a jumbled mess in vanilla.

To be frank, they should have included a circuit network computer.

I completely agree. Circuit networks is essential to Factorio, particularly when adding mods. However the implementation seems to be less than perfect and have a tendency to make mods UPS heavy. Even if the mods does the right things, simply being LUA makes it less efficient than the same tasks in C++, meaning it would be better to have some standard calls in the API for the potential performance intensive tasks, which are often required, like easy access to circuit networks. However this isn't the place for 0.17 requests.

[Cadde]

Through my experimentation, the list of signals is predictable. It sorts the signals according to value (high to low) and for signals of the same value, the order of signals in the crafting menu is used.

Not in my testing, have you actually tested it?
Signals are sorted by value in the GUI but not in the circuit network itself. I actually tested this case when i made the mod, changing the "strength" of signals didn't alter their index. Nor did changing the order they appear in a constant combinator.
In fact, here's proof:


The combinators have indices 1, 2, 3, 4, 5, 6 from the top. The order of signals is almost the same as in the combinator. For some reason, the turbo and ultimate inserters are swapped. Possibly because the mod creates them in that order.

Now, let's change the values of the signals...

Notice how the splitter combinators hasn't changed? I've also connected the network to a pole to show how the GUI handles it.

And just for good measure, here's the signals "in order" (note that the turbo and ultimate are still swapped behind the scenes) and showing how the GUI changes the order, but not the simulation.

Knowledge of this is quite important when using the crafting combinator because it only looks at the first signal. This means if you want to make yellow belts, you need gears. If both are 1, it will make belts before gears (signal order). Setting it up that requested gears have the value 2 while belts have the value 1, gears takes priority and your production line will not stall in lack of input.

Crafting combinator works differently to my mod, it will take the strongest signal before the first signal as far as i know. I don't mix signals to my crafting combinators anyways because it doesn't work with miniloaders (one item per belt) feeding a machine. If the signal swaps mid crafting, it will get items stuck on the belt that won't be used. I have to clear the belts between each batch. In my previous shot, i clear them manually because i hadn't set it up for auto-clearing yet. But in another game, i simply toggled the last recipe on and off until the belts were clear of items before setting a new recipe.

So with that said, signal order as far as which recipe is being used does not matter. The crafting combinator doesn't clear belts, only inserter hands.

I have set up a Memory Module. The address controller is a decider combinator and a constant combinator, which is set to count ticks. It resets at A == 500. The result is that the memory reads input once every 500 ticks. This means the index of each signal is stable for 500 ticks. Since the input is the items in storage, I then have 500 ticks to iterate though them to decide which item is the most important one to produce. Since this is quite literally an iteration, having a memory, which adds one every time I want to move on to the next item seems like a clean solution.

Alright, i will do some research on how to create a virtual signal and use that if present in the circuit network.

[Nightinggale]

Through my experimentation, the list of signals is predictable. It sorts the signals according to value (high to low) and for signals of the same value, the order of signals in the crafting menu is used.

Not in my testing, have you actually tested it?
Signals are sorted by value in the GUI but not in the circuit network itself. I actually tested this case when i made the mod, changing the "strength" of signals didn't alter their index. Nor did changing the order they appear in a constant combinator.

Interesting. I had made a brief test where your mod did use the same indexes as what the crafting combinator use. However now I made a bigger test setup and while it does give the same most of the time, there are cases where it differs. This is something, which needs further investigation.

However if I can't control a priority order this way, then I might not be able to use the signal splitter like I planned to. I need to rethink my plan

[eradicator]

I'm pretty sure signals never change their order internally. That's how all other parts of the API work. Things don't randomly shuffle. So the order should be item subgroup + order string.

[Cadde]

I could techincally make a database of all items in existence and then force certain signals to be assigned a certain "index" behind the scenes.
I say i could, doesn't mean i would because can you imagine the amount of work that would go into doing that?

It's also possible that the API has some kind of function to determine what group a certain item (signal) belongs to and thus instead of indexing i could simply say "signal group:belts" and "signal group:inserters" etc.

But i digress, the mod here is meant to split signals regardless of what those signals are. It's possible to split signals in vanilla but it's a PITA to do with the components and functionality we have. Especially when you consider the fact that it has to be entirely dynamic in nature, meaning any signal of any kind.

The ability to select what index to output would be more in line with "give me the first n signals", now give me the next set n*s signals". But i personally don't see what that would be used for. And considering the unstable nature of signals (I.E, they can change order depending on what items are being signaled) it would be unstable at best.
But likewise, i could just as well do a "min index", "max index" in the gui and use constant combinators instead for input and output.
But the question remains, why?

There are options options options but as i said before, i tend to do modding for myself. If there's something that can be easily implemented without me necessarily using it myself i can do that. But so can any other modder.
I don't even care what license i've used for this mod. But to be clear, i would be glad if anyone used it to build something better. I've always been that way, it's free to use as you see fit.
In Minecraft i made the "Ore Veins" mod. That then grew into another mod, which in turn grew into an even bigger/better mod by other authors. And which in turn i used when i returned to Minecraft at one time.

So in short, if you want some functionality do motivate me enough to implement it or be my guest and give it a try yourself.

[loonybin0]

Okay, so what follows is a little story about a problem I was having and the solution I came up with. I know it's bad form to necro an old thread but I'm putting it here because it is relevant to this discussion as will eventually become clear (tl;dr at bottom):

My problem: make it so that three inserters pulling items from the same chest always pull out different items (no two inserters pulling the same item out at the same time). I thought that, while perhaps a little more complicated than my usual use of very simple circuit logic, it still shouldn't be that difficult to achieve, as it seemed like a common enough use case that people might have. I was wrong.

After trying to figure it out on my own for quite a while (such having all the inserters read and filter out the hand contents of all the others, or reading the contents of the chest and send one item's signal to each inserter) I realized I was stuck. I thought, oh well, I would just have to do a quick search for a solution online. The first result was not helpful, and the second result was the thread that originally was the inspiration for this mod. I tried to look through and figure out any of the the linked videos the OP listed as the "solution" to no avail (the one comment on one of the vids being quite accurate). I then saw at the bottom of the thread the link to this mod. Yay! I started up Factorio and looked through the available mods but I didn't see it. I went back to the mod's webpage and saw to my disappointment that it was made for 0.16 and so incompatible with 1.0.

I went back in game and tried to figure it out on my own again. Failure. I tried deciphering those videos again. Failure. I tried to be creative with Google to see if I could find another solution. Failure.

If only the mod worked! Here it is nearly two years later, and this problem that had a solution no longer does.

Then I thought, well maybe I could just kinda cheat and alter the version number in the mod to trick Factorio into thinking it's compatible.
And, well, it actually worked - mostly anyway. Here's how I made the mod work in 1.0 (obvious apologies to Cadde for my crude adulteration of his mod):

1. Download the zip from the mod's webpage and extract the contents.
2. Go to wherever that is, e.g. C:\Users\[User]\Downloads\signalsplittercombinator_0.0.2\signalsplittercombinator_0.0.2\ and open info.json in a text editor (personally a fan of NP++).
3. Change 0.16 in

   Code: Select all

    "factorio_version": "0.16",

   to 1.0 and save.
4. Now go to \signalsplittercombinator_0.0.2\prototypes and open entities.lua.
5. After the line with p.icon add a new line

   Code: Select all

   p.icon_size = 32

   and save.
6. In that same directory, open items.lua and remove or comment out one line so it looks like

   Code: Select all

       -- flags = {"goes-to-quickbar"},

   and save.
7. Now go back to wherever you unzipped (e.g. \Downloads), r-click the mod directory and send to -> compressed (zipped) folder (or whatever zip utility you use).
8. Make sure that the new zip's file structure matches the original's.
9. Now copy the new zip and place it in your Factorio mods directory, e.g. C:\Users\[User]\AppData\Roaming\Factorio\mods.
10. Start up Factorio, go to Mods, and make sure the checkbox beside this mod is checked and confirm. That's it, you're done!

So in short, if you want some functionality do motivate me enough to implement it or be my guest and give it a try yourself.

So... close enough?

I may not check this thread again soon, so if you need to reach me, shoot me a message on Discord or Steam (better). Loonybin0

tl;dr - Had a problem that needed separate signals. Fixed by altering mod so it works in 1.0.

[eradicator]

it is relevant to this discussion

Welcome to the forum and congratulations on solving your problem. I won't pretend that i remember any of this after two years :p.

[loonybin0]

Quick update:

My quick fix was, of course, too good to be true... When I try to open up my armor inventory, I get this

----

moderror.png (29.37 KiB) Viewed 3628 times

----

Any ideas or help would be appreciated. Thanks.