0 of 0
A simple mod in theory, and mildly limited in isolation, but quickly powerful with other mods. One new item, the storage transfer controller, that allows you to set various storage containers to transfer items between each other. It works with a very basic system where each container has a channel, and it either sends or receives items on that channel. Maybe some day I'll implement multi-channel support but that would likely require a dedicated UI which I don't feel like making.
As an example of what this mod does, you can set a locker in your cyclops to channel A and set it to send items, then set a locker in your base to channel A and set it to receive items. On it's own, doesn't help much. It would let you transfer items to your main base from a distance, but that's about it. But if you combine it with some other mods that's when you get to the fun things. Set your autosorter to receive items on a channel and use Grav Trap Storage to send items on that same channel. Now when you collect items they get auto transported to your autosorter to be sorted. Make a locker filled with decoys/torpedoes/beacons and have it send them to the cyclops's decoy bay. Use it alongside my mod Equivalent Exchange and have items get automatically sent to the research table, or use the Auto Item Converter to effectively autocraft items to pull out as needed (like autocrafting torpedoes for my cyclops torpedo mod). Or when FCS gets updated, use it to send items from external storages to your main autosorters so your drills automatically feed into your main storage. There's a lot of potential when combined with other mods
If you are asking about or reporting delayed transfers, read the Performance Configuration section
What Can It Do
The mod tries its best to automatically detect any storage containers, including modded ones. It's not foolproof, and especially if the modded item has a weird object hierarchy or interacts with a container from another object, but these cases should be rare so it should work with the majority of things. It also has configuration options in the case of performance impact. You can likely set these to ignore performance in most cases, but be aware that if you do then the mod will try to go through every item in a locker set to "send", so if you have large backups of items it can get slow, more on that down below
What Can't It Do
Work with everything, unfortunately. Some things in the game are just not handled in a way that this mod alone can handle. Some examples of that include:
Performance Configuration
The mod should have minimal performance impact under general usage, however it does have the capability of slowing a save game to a halt under specific conditions. These configuration options are designed as a failsafe to make sure your save doesn't become excessively unplayable if those conditions arise.
To fully explain how the configuration options work, I have to give a slight bit of detail on how the mod as a whole works. When a container is set to transfer, the mod will go through every item in the container one by one and, for each item, look for a suitable container that will accept that item. It has to do this because we don't know the criteria on what kinds of items the receiving container can accept, or how many. In normal cases, this is not an issue. The container will be checked, items will be deposited, and that's that. However, this becomes an issue when the transferring container has a large number of items (30+) that are unable to be sent anywhere else. The mod will try to go through all of those items, every frame, which obviously gets very slow, and only gets slower as more items are in the transferring locker.
To act as a failsafe in case this occurs, the mod has two options: "itemChecksBeforeBreak" and "thoroughSortCooldown"
Item Checks Before Break handles how many items in a locker the mod will look through before deciding to ignore all other items and assume they can't be transferred either. For example, if you have a locker with 15 titanium that's set to send on channel "abcd" but there's no available receiving containers, the mod will only check the first 10 and will just assume that the other 5 also can't be sorted. Normally, this isn't an issue either. The issue comes in when mixing items and sending to lockers that can only accept certain types of items. For example, if you have that same locker with 15 titanium, but you also have one creature decoy inside of it, and you have a cyclops decoy tube set to receive on channel "abcd", nothing will happen. Theoretically, the mod should be able to transfer that creature decoy to the decoy tube, but because it first checks the 10 items, which are all titanium, the mod assumes that the other 6 items also can not be sorted even though one theoretically could be. This is a niche use case, so in most cases this setting shouldn't matter.
Thorough Sort Cooldown is the setting more likely to affect your gameplay. Whenever the mod fails to transfer an item, it adds that item to a dictionary and keeps track of how many times it has failed to transfer that item. On a "normal" sort (not-thorough), the mod will skip any item that has 5 or more failed transfer attempts. This is to avoid wasting processing on trying to transfer an item that we know is not likely to be transferable. Every so often the mod will perform a "thorough sort" which is where it will ignore these failed attempts, and try to transfer the item once again regardless. What this means is that if the receiving locker is full for a large period of time, the items in the transferring locker will be marked to be skipped on non-thorough sorts due to many failed transfer attempts in a row, so once the receiving locker empties up, there will be a slight "delay" before the transfer will reengage. That delay depends on the cooldown you set in the configuration, as well as where in the cycle it happens to be when the opening is created. It might happen almost instantly, it may not happen until the entire cooldown has passed. If you don't believe that you will ever have conditions that would cause performance issues in a save, you're free to set this cooldown extremely low or even to zero, and that will remove any "delayed" transfers. I'm sure the majority of people likely can do that with minimal consequences, but the option is here nevertheless as I have seen saves become borderline unplayable because someone had several lockers full of several hundred items that were all being failed to transfer
Mod page made by me this time, cause I got off my ass finally
As an example of what this mod does, you can set a locker in your cyclops to channel A and set it to send items, then set a locker in your base to channel A and set it to receive items. On it's own, doesn't help much. It would let you transfer items to your main base from a distance, but that's about it. But if you combine it with some other mods that's when you get to the fun things. Set your autosorter to receive items on a channel and use Grav Trap Storage to send items on that same channel. Now when you collect items they get auto transported to your autosorter to be sorted. Make a locker filled with decoys/torpedoes/beacons and have it send them to the cyclops's decoy bay. Use it alongside my mod Equivalent Exchange and have items get automatically sent to the research table, or use the Auto Item Converter to effectively autocraft items to pull out as needed (like autocrafting torpedoes for my cyclops torpedo mod). Or when FCS gets updated, use it to send items from external storages to your main autosorters so your drills automatically feed into your main storage. There's a lot of potential when combined with other mods
If you are asking about or reporting delayed transfers, read the Performance Configuration section
What Can It Do
The mod tries its best to automatically detect any storage containers, including modded ones. It's not foolproof, and especially if the modded item has a weird object hierarchy or interacts with a container from another object, but these cases should be rare so it should work with the majority of things. It also has configuration options in the case of performance impact. You can likely set these to ignore performance in most cases, but be aware that if you do then the mod will try to go through every item in a locker set to "send", so if you have large backups of items it can get slow, more on that down below
What Can't It Do
Work with everything, unfortunately. Some things in the game are just not handled in a way that this mod alone can handle. Some examples of that include:
- Interior base pieces such as bio/nuke reactors (these unfortunately separate the container from the mesh in a way that this mod alone simply isn't equipped to recognize and account for
- Some small submarines, due to how their collision objects and storage containers are handled, it's very difficult for this mod to get the proper containers. As such, it's inconsistent which ones you may get. The Prawn suit handles this much better, and it should work with the main storage compartment on the back, but the seamoth (and likely small modded submarines that may have storage containers) does not
- The player itself, although that's more because I didn't feel like implementing anything to do with that than because of a logical limitation
Performance Configuration
The mod should have minimal performance impact under general usage, however it does have the capability of slowing a save game to a halt under specific conditions. These configuration options are designed as a failsafe to make sure your save doesn't become excessively unplayable if those conditions arise.
To fully explain how the configuration options work, I have to give a slight bit of detail on how the mod as a whole works. When a container is set to transfer, the mod will go through every item in the container one by one and, for each item, look for a suitable container that will accept that item. It has to do this because we don't know the criteria on what kinds of items the receiving container can accept, or how many. In normal cases, this is not an issue. The container will be checked, items will be deposited, and that's that. However, this becomes an issue when the transferring container has a large number of items (30+) that are unable to be sent anywhere else. The mod will try to go through all of those items, every frame, which obviously gets very slow, and only gets slower as more items are in the transferring locker.
To act as a failsafe in case this occurs, the mod has two options: "itemChecksBeforeBreak" and "thoroughSortCooldown"
Item Checks Before Break handles how many items in a locker the mod will look through before deciding to ignore all other items and assume they can't be transferred either. For example, if you have a locker with 15 titanium that's set to send on channel "abcd" but there's no available receiving containers, the mod will only check the first 10 and will just assume that the other 5 also can't be sorted. Normally, this isn't an issue either. The issue comes in when mixing items and sending to lockers that can only accept certain types of items. For example, if you have that same locker with 15 titanium, but you also have one creature decoy inside of it, and you have a cyclops decoy tube set to receive on channel "abcd", nothing will happen. Theoretically, the mod should be able to transfer that creature decoy to the decoy tube, but because it first checks the 10 items, which are all titanium, the mod assumes that the other 6 items also can not be sorted even though one theoretically could be. This is a niche use case, so in most cases this setting shouldn't matter.
Thorough Sort Cooldown is the setting more likely to affect your gameplay. Whenever the mod fails to transfer an item, it adds that item to a dictionary and keeps track of how many times it has failed to transfer that item. On a "normal" sort (not-thorough), the mod will skip any item that has 5 or more failed transfer attempts. This is to avoid wasting processing on trying to transfer an item that we know is not likely to be transferable. Every so often the mod will perform a "thorough sort" which is where it will ignore these failed attempts, and try to transfer the item once again regardless. What this means is that if the receiving locker is full for a large period of time, the items in the transferring locker will be marked to be skipped on non-thorough sorts due to many failed transfer attempts in a row, so once the receiving locker empties up, there will be a slight "delay" before the transfer will reengage. That delay depends on the cooldown you set in the configuration, as well as where in the cycle it happens to be when the opening is created. It might happen almost instantly, it may not happen until the entire cooldown has passed. If you don't believe that you will ever have conditions that would cause performance issues in a save, you're free to set this cooldown extremely low or even to zero, and that will remove any "delayed" transfers. I'm sure the majority of people likely can do that with minimal consequences, but the option is here nevertheless as I have seen saves become borderline unplayable because someone had several lockers full of several hundred items that were all being failed to transfer
Mod page made by me this time, cause I got off my ass finally