Things that should be taken into account when running multiple ASF instances:
*LimiterDelay ASF.json properties should be shared.The shared resource at the start could be simply OS-wide, but the better solution would be to somehow take into account the default network interface.
Apart from network interface it would be also nice to take into account used WebProxy.
WebProxy doesn't affect Steam connections.
First of all, there are web limiters too, and there is no reason to limit them system-wide if we are using different proxies.
And on top of that - we have
SteamKitProxyInjection, plugin for ASF allowing proxifying WebSocket connections.
ASF is not coded with the assumption of user using any kind of plugins, and web limiters indeed should take webproxy into account, perhaps even override default selection based on it. I'll see what can be done in regards to that.
LoginLimiterDelay for sure won't take web proxy into account, only the interface.
Then maybe think of the way to allow plugins to change this behavior. Because plugins like SteamKitProxyInjection will be pretty useless with system-wide limiters.
Nothing stops the plugin from changing ASF semaphore into its own implementation, plugins are not limtied to what I "allow", they can always do whatever they want through reflection.
But ASF will not provide such functionality as definining proxy for Steam connections is not supported by SK2.
Calculation of defined bot instances
This one is not worth the effort, there is no easy way to share memory across different ASF instances, and doing all of the effort with files, pipes or memory mapping just for displaying warning is not worth the effort, skipping that one.
Wiki part done in https://github.com/JustArchiNET/ArchiSteamFarm/wiki/Compatibility#multiple-instances
I consider this issue fully implemented to the planned scope.
can cross-process limiter be optional ?
Every instance still uses its own delay properties if i undestood that right. If you completely want to ignore that you can change the values to 0. This might lead to other problems tho.
It doesn't make any sense to resign from it. If you want to disregard the cross-process limiter then set limiters to 0, since you're not using any proper limiters to begin with. If you're using ASFs with different WebProxy settings then limiters across different web proxies do not overlap.
Otherwise present your valid use case. I don't know about any.
i have 250 asf instance on my server running in different netns and macvlan(local ip 10.0.2.1-250)
and my router has 250 public ipv4 ip and route local ip(eg. 10.0.2.1) to adsl1

every instance has separate network.
Fair enough, I'm not able to guess all the different conditions upon which cross-process sharing should be enabled, so I'll likely introduce another command-line argument such as --limiters-group=<name>.
And done in V4.2.1.6+. For your use case, it should be enough to specify the groups same as the number in your config path, but of course you can use any strings you like.
thanks