Hey, I really love the concept of this mod, and so far it seems to technically do what it says it does. However, there's a few additions that would make it a lot easier for me to integrate into gameplay:

• It would be great to have a "strict mode" where only the beginning of group name is checked for planets, ignoring any %s whitespace or %p punctuation. Then a group name like [planet=nauvis] [virtual-signal=right-arrow] [planet=vulcanus] would be interpreted properly. I think this could be implemented for both modes fairly neatly just using gsub(), if my understanding of the differences between RegEx and Lua patterns is correct.
• Additionally or alternatively, having some signal that functions as an early exit point to the interpreter could achieve much the same effect, and also act to escape the whole group if it occurs at the front.
• It would be nice to be able to set the generated logistic name prefix from the settings menu. It looks like it is basically all set up for that except for one "__gen_" on control.lua:53:, unless there was some issue in testing.
• Being able to access the invert-selection string pattern from the settings menu would also be very useful, even if it required entering the pre-escaped string (though it seems at least a quick sanitization of something like %%?(%[%-%]) → %%%1 would capture 98% of needs). I can see that being too at-your-own-risk or error-prone to work for general release, just that when I saw that I immediately thought that signal-deny or signal-no-entry (red slashed circle or red X), or even signal-not-equal, would make more sense than signal-anything for that use.
• I haven't explored it fully, but I think if you just checked the import_from of the filters to the current planet and only added those that weren't already for the current planet, you could avoid the whole problem about active and inactive logistics groups altogether and respect their current status. I think that's what bugged me the most. Admittedly I don't fully grasp the intricacies of planet-platform logistics logic, but if the goal is just that there are requests for the current planet matching the sum total of all scanned filters, regardless of planet, I think that would do it.
• I'm not sure if there is a way to handle it performantly and safely while not messing with any in-progress shipments, but I wonder if it could also hook on_entity_logistic_slot_changed by a player, possibly comparing the tick as well. Not sure if you could do anything other than a full rebuild of the request, and not sure if that would cause problems.
• More of an actual bug, but I don't think duplicate items get handled correctly. From what I can tell, the proper way to do this is to check the return value of set_slot(), and if it's non-nil then then the individual filters need to be merged (I think just sums for count and non-nil max_count, then min non-nil minimum_delivery_count), since it just silently fails if there is a conflict.

Anyway, if that all sounds good, I've clearly already done some thinking and digging, so I'd be willing to work on some pull requests or Github issues if that helps. Cheers

Thanks for the feedback.

The "strict mode" idea is solid. RN any logistic group that has a [planet=*] in the name is considered to be managed by the mod and there is no way to disable that. Probably should've implemented more strict parsing from the start, but now is as good time as any.

I am not sure if generated_logistic_name_prefix should be configurable. I don't really see a use-case for that and if a user changes the setting mid-playthrough, then there would be no simple way to migrate old generated logistic groups.
Good catch on control.lua:53 though.

Regarding access to invert-selection - making the (currently) [virtual-signal=signal-anything] configurable can be a good idea. I don't want to expose users to Lua pattern matching though. I think it makes sense to add a dropdown with some common values.

The reason behind disabling groups is a bit more involved. For example:

Platform A (Nauvis)
Platform B (Vulcanus)
Shared group: [planet=vulcanus] Group1
Group1 has Iron Plates with import_from = Nauvis (default).

In this case Platform A should not request Iron Plates, but it will unless Group1 is disabled.

The mod could change Group1 items import_from to vulcanus in this case, but with enough import locations and enough platforms the situation becomes impossible to handle.
Furthermore Factorio requires import_from to be set to some value. Meaning that, as far as I can see there is no clean, simple solution to this.
One idea I considered was to create a dummy planet to act as a neutral import_from, but I did not get around to exploring that.

on_entity_logistic_slot_changed - yes, but logistic group can also be updated from the UI other than the Space Platform itself - e.g. the Cargo Pad. A perfect solution would probably require scanning all space platforms and triggering updates.
Still, just instantly updating/creating __gen_ group for the simple case is probably good enough.

I am not sure if it's a good idea to merge requests from multiple groups. Ignoring duplicate requests is kind of intentional, though I can see how that might feel unexpected.

If you’re interested in contributing, PRs are welcome! If not - I’ll probably get to this next week.

Re configuration, I agree that the setting should be normal/unescaped, but I think a freeform entry would be pretty easy to make safe and compatible for any normal text one can enter into the game's UI. Converting to escaped form inside the script would sanitize if it did contain anything looking like an escape sequence. If someone tries to force malformed Unicode in or something, I think they can take the blame for crashing their own game. generated_logistic_name_prefix being configurable might just be personal opinion about the current string, so not a big deal. Another random idea would just be to use a few zero-width spaces as an unconfigurable identifier prefix, then just have a decorative configurable name, which also fortunately pushes it even lower in the sort order.

Re merging, my thoughts were a scenario of wanting to get a few resources from anywhere to make it to the next stop, but also wanting a big shipment if it's from a producing planet. If it gets to that planet and the small request is read first, then it discards the big request, that seems like the wrong behavior. The current logistics UX is that requests in different groups combine (not sure how it handles mixed minimum_delivery_count though), which seems a pretty strong suggestion for how the mod should handle them. One could argue for taking the largest request instead, but just taking the first request per item doesn't seem ideal.

Re group disabling, I think you're right that if a logistics group is "managed" by the mod, the planets in the name should take precedence over any import_from, though there might theoretically be some control pattern that would be disabled by that. I've selected shattered-planet as the import before to disable individual slots, so I think one could also select a different space-location as the dummy, perhaps even space-location-unknown, rather than just a planet. It is also possible to use a request with negative values to cancel out another request. I'd have to do some more testing and thinking to make sure every situation of minimum, maximums, import_froms, and group names would get canceled and behave as expected, though it might not be possible to cancel an infinite/nil maximum. I guess I could just remove the groups I don't want from the platform. There's some tradeoff between respecting the enable settings, not editing the existing group's import_from, and having the same functionality as if you had manually added the requests for each planet. A solution that does all of that perfectly might not exist and you'd have to pick something to sacrifice.

Re triggering, I might just have to play with it some more, I think the goal was to get it to feel as much like a native feature as possible, where if the underlying groups change, it also affects ships that are already docked. Overall though, pretty low impact on this one too.

I still don't want to implement escaping for invert-selection setting. Even though it might be possible to make it not crush the game - having a drop down with a few options (like deny signal, no entry, output) would make code behavior more predictable and UX would be better IMO. There might not be a reason to having such setting at all - if strict parsing is implemented, the mod could force invert-selection to be in front of the [planet=*]. I also want to force users to use an icon for invert-selection to keep it in the spirit of the mod.

There might be a way to use w/e invisible unicode symbols in the group name and the mod could identify space platforms by the count of symbols, but I'd leave such hacks for now.

Merging requests makes sense - since that's how base Factorio does it. For some reason I though request with highest item count takes priority. But I tested it and it seems that Factorio actually increases request amount. The mod should do the same.

Okay, I completely forgot that you could set Shattered planet/Solar system edge as the import_from. Since player can't import anything from Solar system edge - it makes sense to use it as neutral import_from. Haven't tested space-location-unknown so don't know how that works, but it also makes sense. I'd just set each Group1 item import-from to something like Shattered planet/Solar system edge, stop disabling groups and leave the rest of the mod behavior unchanged. But if you'd rather implement some sophisticated request merging - that's also fine.

Re-triggering updates when on_entity_logistic_slot_changed for docked space stations should be safe and easy to do. Too bad there is no way to subscribe to group renaming. Though the mod could subscribe to closing space platform ui and trigger updates at that time.

Published a new version where most of things discussed here were implemented.

Noteworthy changes: Requests merging, Removed group disabling, Strict search setting, "inverse-group" icon selection setting, handling of on_entity_logistic_slot_changed for simple case.

For compatibility with OSHA Launch Control and Improved Cargo, it would be nice if the mod also worked for space locations - the OSHA mod adds a special space location which in the "import from" slot makes platforms request cargo from other platforms (if they are set up to share), so any requests with the "other space platforms" location in the name should be active at every planet/location.

I'm not sure if there is a convenient way to implement a "filter" for that as well - eg. "only import from stations when in these locations". Interpreting everything after "other space platforms" as the filter would work, but might be counter intuitive since then [nauvis][other-space-platforms] means something different than [other-space-platforms][nauvis] (ie. order would, in some cases, matter)

I haven't tried "OSHA Launch Control and Improved Cargo". If I understand correctly, the main use-case is to allow each item from a given section to also be requested from other space platforms.
Implementing that would require adding another temporary section to correctly manage requests, since Factorio does not support having multiple "import_from" conditions on a single item request. I don't think I would like to work on that for now.
Though a simple change would be to make neutral_import_location configurable. That way all items' "import_from" from user logistic sections could be set to orbital-connection (which I think OSHA mod uses) instead of solar-system-edge. Would that work for your use-case?

I don't think so. I mean, it would be a way to automatically set the default of a certain group to "other stations", but a) that would also happen as a side effect when making a group for another planet, and b) the "other stations" request would always be active for planet-specific groups, no matter your location.

A simple solution to the "simple" default import selection problem would be making the "neutral location" depend on whether or not there is a "other space stations" signal in the group name: if there is, set the neutral location for that group to "other stations", otherwise set it to eg. "shattered planet".

I'll think about making a PR, or even another mod, that implements a selection syntax to control above which planets a certain logistics group should request from other platforms.

edit: "orbital-location" is the type of the location (rather than "planet"), so it's full name is [orbital-location=other-space-platforms]. changing all the filters from exclusively [planet=*] symbols to also consider orbital-location is probably the largest part of the required change for the "simple" problem

Another thought - if a group has only a single planet(/space-location) in the name, why don't you just set the default location of that group to that planet, and then ignore it when computing the temporary sections? All that temporary LG logic is only necessary for inverse or multi planet selections ...

A simple solution to the "simple" default import selection problem would be making the "neutral location" depend on whether or not there is a "other space stations" signal in the group name: if there is, set the neutral location for that group to "other stations", otherwise set it to eg. "shattered planet".

I see. It's not that hard to implement. Seems like a niche use-case, but I don't see why not. Basically I'd implement handling for some special icons that, when used in a group name - will define neutral_import_location. If no planets are matched by existing logic or no special icon found in a group - the default (solar-system-edge) will be applied. Otherwise - the planet requests in a temporary section will still be generated, but user sections would be set to "other stations". Would you be willing to test those changes on your save file? Or maybe PM me your save, so that I have easier time setting up OSHA mod.

Another thought - if a group has only a single planet(/space-location) in the name, why don't you just set the default location of that group to that planet, and then ignore it when computing the temporary sections? All that temporary LG logic is only necessary for inverse or multi planet selections ...

True, but temporary section would be required if any of the sections in a given space platform have 2 or more planets defined. Seems like mod behavior would be less predictable when half of the sections use simple logic and half need generated section. It also makes harder to see resulting sum of requests in case request merging happens, but I can see how it mostly comes down to preference.