Local named logistic groups

[commanderguy3001]

Logistic groups are a great feature, but they have a few specific problems.

One of the main usages for logistic groups in a normal playthrough is for enabling/disabling sets of logistic requests for the player.
This works perfectly fine in singleplayer, where having all logistic groups being global doesn't hurt.

On multiplayer servers however, this quickly becomes annoying, as every player can edit the logistic requests of every other player.
Currently, the only "solution" to this problem is using unnamed logistic groups, but those being unnamed are often significantly harder to make sense of, especially if you have requests in multiple groups.

One relatively common example would be to have one group for outposts, one for train stations and one for smelting.
Every one of those will have belts, all might have roboports, two of them might have train stations, rails and signals. the same goes for power poles etc.
But them all having so much in common means that there's often relatively little visual difference between them, making it harder to quickly discern them.

My proposed solution:

• add a toggle switch next to the name of each group, which makes said group local to the entity.
• groups added in the inventory are local by default, while defaulting to global for things like constant combinators.
• If one adds a global logistic group, and then switches it to local, it just keeps the contents.
• When a local and a global group have the same name, but different content, gray out the switch, so you can't make it global. this is just a simple solution to accidentally overwriting either group.

[Arxos]

This is one of the things that has annoyed me the most since this feature got added. I frequently want to use this feature so that I can name constant combinators, to remember what exactly the values it outputs represent. However, the global nature of this is more often a problem than a benefit.

If I make a generic blueprint that can be used for various things, I can't just give it a logistic group, since the values on the combinator may need to differ for every placement of said blueprint. At best I can add a disabled/empty backing group that at least represents the name, but that's rather convoluted.
Even if the values are expected to always be the same for every blueprint, I may want it to still not be shared/clog up the list of logistic groups when all I want is a name for clarity.
To that end, it may be good to separate logistic groups for things like inventories, combinators and chests entirely, or better yet, allow for some sort of grouping (logistic group grouping...) by default, as they have very different use cases. You're pretty unlikely to ever want something that a constant combinator is outputting as an inventory request (though admittedly not impossible, e.g. to synchronize logistic mall requests, but I can't think of anything else).

OP's proposals for the local group handling are exactly what I'd like, though I'd personally suggest to make every logistic group local by default. Make it so that raising it to a global group requires an explicit action, to minimize accidental cluttering of the global groups. At least personally, I've wanted to *not* share things far more often than the other way around.