* Improved ItemModule::take() behavior
The original take() behavior spams items in whatever order they appear in the items list until each index is depleted, which is problematic when non-specific unloaders are competing against dedicated unloaders for a low-index resources.
My modification makes the take() loop persistent so take() will do complete laps around the item list starting from wherever the previous call returned from, never repeating the same item twice in a row unless there is nothing else to return. A significant improvement IMO.
How is this an improvement? With the original behavior, if you converge a bunch of belts on a storage block or launcher, want to unload a few belts of specific resources (ex.: copper, lead, silicon and titanium for surge alloy) and pass everything else including overflows along using non-specific unloaders, you are out of luck when the resources you want are at the top of the list since most of those will get swept away by non-specific unloaders. With the rotating take(), non-specific unloaders are equal-opportunity across all available resources, which gives single-resource unloaders that many more chances to unload more of their resources before non-specific unloaders get to them. It also reduces the rate at which items further down the list that may hardly ever get touched by the existing implementation will race toward the storage block's cap. The even drain across all items will help prevent things like mass driver stalls due to receivers filling up with an excess resource that isn't getting cleared.
It would be even nicer if dedicated unloaders had priority over non-specific ones (non-specific unloaders don't touch resources with dedicated unloaders unless the dedicated unloaders are overflowing), though that would require a rework beyond my current "getting the stupid IDE and tool chains to work" level of familiarity with Java development.
To sum it up: trivial change, big impact for people who like mixing belts and sorting them out with unloaders.
* Update core/src/mindustry/world/modules/ItemModule.java
Co-Authored-By: Patrick 'Quezler' Mounier <Quezler@me.com>
* Update core/src/mindustry/world/modules/ItemModule.java
Co-Authored-By: Patrick 'Quezler' Mounier <Quezler@me.com>
* Formatting
* Anuken's take() rotator.
Co-authored-by: Patrick 'Quezler' Mounier <Quezler@me.com>
- huge community (~1.5k members)
- anti-grief measures (discord bot <-> in-game moderation)
- huge map pool (50+)
- stable, powerful server based in europe
* Steam Rich Presence support. I opted to put this code inside of
DesktopLauncher.java instead of SNet.java because it heavily overlaps
with the work the DiscordRPC code was already doing.
Testing wasn't easy because I had to figure out how the Steam version
actually runs normally, but it was straightforward once I figured out
what version information to slam into the JAR and fixed 'desktop:steamtest' to work locally with my paths.
Because of how Steam currently expects SetRichPresence to be used, I had
to upload to the Steam partner site a trivial Rich Presence loc token
called 'steam_status_raw' that just gets entirely substituted for the
'steam_status' RP token string. I didn't expect that I'd need to do
anything for localization support (and instead just let it use English
for everyone like Discord) but apparently Steam isn't happy if you
directly set 'steam_display' to a raw string (but I'm going to look at
that when I'm back at work because I don't know that we need that
requirement.)
* Whoops, left this in there from debugging the Steam connection.
* Fixing coding style, and also triggering another CI build
