When I select fully configured combinator with copy tool and then paste over different (not configured) combinator the UI of another combinator doesn't show the copied config.

To be clear the config is pasted correctly (shown in tooltip), the UI is just not showing it.

This was discovered and reported on GitHub: https://github.com/Sharparam/cybersyn-combinator/issues/47

In short: There are no events in the game that allows for mods to make this work properly. But the not-yet-released logistic section support update will remedy this in other ways to make it behave more as expected.

Until the update is out, you should be able to make signals work in a given combinator by hovering it with the mouse so it gets the yellow selection rectangle and then run /cc_sort. This will forcefully run the signal sort for the combinator, which is what doesn't trigger when doing a copy-paste with the copy (or blueprint) tool.

Why do you need any event at all? I guess there is something stored in "storage" which keeps track of something for the UI. But couldn't you read the combinator config everytime its UI is opened by player?

The "network" and "Cybersyn signals" are stored in logistic sections, and the combinator needs to keep track of which sections are used for them so it can display them properly (and before the logistic section support, the same is true for the section containing the regular output signals). This configuration is indeed stored in storage. They can't be read on open because unless there are already some signals configured in them it's impossible to know which section is used for what. (And even then, you can put virtual or Cybersyn signals in the regular output signals area, which complicates that matter, especially if copying signals from a normal constant combinator.)

When you paste settings/signals from a different combinator, those exist at different indexes from what the current settings are configured to. Normally this can be detected and a sort function run to update the configuration to use the new indexes, but such an event doesn't exist specifically for when you do a blueprint paste (which is what the normal Ctrl+C + Ctrl+V paste is). So it ends up copying those sections in, then when you open the combinator it thinks "none of the needed sections exist, so they must be created", and it creates the three necessary sections on top of the ones that were copied. The copied sections end up hidden in the UI while still producing their signals as output.

With the logistic sections update, this is mitigated since the combinator can now show all sections, just like the vanilla constant combinators, and there is also some updated logic for detecting network and Cybersyn signal sections, to reduce the risk of a bunch of empty sections being added on paste. So even if some sections do end up in the wrong place, you can fix it in the UI by deleting/modifying them, just like the regular constant combinators.

I understand that you want to have request and control signals in different sections. That is very nice to have. Are you planning to somehow not show sections which contain control signals in the new version or are you going to show all sections?

Unless someone specificaly asked for having proper sections being configurable in the UI I don't really understand why you would implement it. To me it seems that it is treating symptoms instead of fixing root cause of the problem.

IMO the requirement that you need to have specific sections in specific order and requirement that control signals also have to be in specific order (this one is VERY confusing...why the hell would you rely on order of signals instead of their type+name?!) is the root cause. If you would stop relying on this you wouldn't have to store anything in "storage" and you would support copying from whatever source out of the box. It would be constant combinator with new UI and no extra logic.

Instead of relying on "storage" being up to date you could read all sections from the combinator when UI is opened, sum up all signals and show them in the UI. Then if user modifies something you could:

• either separate request and control signals to separate sections
• or just don't care and put everything in one section (since it will be read by same logic once it is open again and all signals will be summed up again)

I know there are some limitations when using just one logistic section, so you might NEED to have more of them, but my point is that you shouldn't have to keep anything in storage.

There is no way to uniquely identify logistic sections, so you have to rely on indexes ("names" (groups) don't work since they introduce special behaviour and are also visible to the player). So you can't create a section and say "this is the network section" with something like an ID that you can later query (that would've been ideal). You have to create the section, note down its index, and store "the network section for the combinator with unit number x is at index i. It is a bit jank but works out well enough. This is required to know which sections to use for network and Cybersyn signals, and which sections to show in the output signals area.

Unless someone specificaly asked for having proper sections being configurable in the UI I don't really understand why you would implement it. To me it seems that it is treating symptoms instead of fixing root cause of the problem.

Having sections support is quite crucial, so that you can do what you can with the new vanilla constant combinators: Set up requests that you can share between multiple stations (like having multiple stations that request iron ore). Then you can update the iron ore request in one place without having to update each station (for example).

But perhaps more importantly, it removes the need to have all the sorting code which is currently necessary to handle the fact that multiple sections can exist (when copied or upgraded from a constant combinator) while the old design relied on there not being any sections at all (in 1.1, where the different types of signals were stored at different offsets in the signal table).

control signals also have to be in specific order

(Cybersyn) control signals are all stored at fixed indices in their signal section but are managed completely internally by the combinator. It would make no sense to have multiple threshold signals for example. They all get merged to a single value by the game anyway and which signal would you show and update in the text field?

or just don't care and put everything in one section (since it will be read by same logic once it is open again and all signals will be summed up again)

This would break fantastically if the player wants to organize their requests in a certain way, maybe have some sections be shared while others are specific to the station for example. It's basically what the current version does (for cargo signals) and it's not great now that sections exist. I've seen some people use the vanilla combinators instead since this one lacks section support (understandably, I would do the same depending on my needs for a particular station).

With the sections support, combinators on placement/copy/upgrade will instead:

• Move any network (virtual) signals to the network signal section (merging if any of the same name+quality exist). (If it's a grouped section, they are copied instead to not have unintentional effects elsewhere in the circuit network.) (It might be desirable to be able to have multiple network signal sections, but I would need to find a way to make the UI be able to display and let the player manage them without being a mess.)
• Move any Cybersyn control signals to the Cybersyn signal section (likewise, also merged if there are multiple, and grouped sections are once again left intact).
• Any non-grouped sections left empty after the above two steps are pruned.
• Meaning any remaining sections are output signal sections and display similar to a regular constant combinator (with the caveat that due to lacking API support, not all features are available).

It could make sense to have the network signals be dynamically read from all sections, but the issue becomes that it's then unclear what section they belong to, and the output signal area will be confusing to look at when the sections don't display what they actually contain (assuming the network signals would be filtered out of that display), that latter part may be a minor thing though.

It would mean that the only section with special handling would be the Cybersyn signal section, and I might approach this route if I manage to figure out a way to allow multiple network signal groups to work in the UI. You could then have the same section appear in both lists, with the network side filtered to show network signals of that section, and the output signals side showing cargo signals. That would make it work mostly the way you describe, with the exception of control signals.

Edit: Created an issue for tracking multiple section support for network signals, although such a feature is probably far off from being realised.

I was about to write even longer text, but I guess my bottom line is: Is there going to be something stored in storage after the update which adds support for logistic sections?

If answer to that would be no, we are done here. Otherwise we could continue to discuss if it is really necessary (also maybe on some IM instead of this forum-like form, if you are interested hit me up on Discord).

The logistic section update which I just released does still use storage to keep track of the network and Cybersyn sections. But the cargo signals no longer require it and are handled "automatically" by virtue of any non-special sections just being shown in the regular output area.

I would be open to further discussion, especially so if you have ideas for the network signals (username sharparam on Discord).

With v2.4.0, the original issue in this thread should now be fixed.