Here is inctruction how change cargo ship capacity from 500 to etc. 50000:
1) FIRST save game manually.
2) You have to use the command tcl and get through the closed off landing ramp of the freighter. After that, you need to click on the boarding door with the console open, make sure the string says "DOOR (XXXXXXXX) PP T" or something similar, then use the command unlock.
3) Board the ship and in ship you use console and write tcl again (without tcl you may fall through ship), DO NOT ENTER THE PILOT SEAT, WAIT FOR IT TO TAKE OFF ITSELF AND TAKE YOU INTO A LOADING SCREEN.
4) Once you are in space, then you want to enter the pilot seat. Zoom out until you can see the entire ship and open the console, and click on the back of the ship. A string such as GBFM " (FFXXXXXX) should appear, and note that number down. Go load back into the save you just made (in step 1)) and use the command "FFXXXXXX.setav carryweight 50000". And you see in terminal cargo ship capacity changed to 50000.
Last advice: make cargo ship capacity equal or less than cargo link capacity, because if cargo link capacity will be etc 40 000 and cargo ship capacity 50 000, then 10 000 resources will be returned back.
Or just use the Darkstar Maufacturing mod that provides 100k Inbound/Outbound Cargo Link storage capacity and a 10k Cargo Ship along with other great stuff. Darkstar Astrodynamics offers 100k regular storage containers and a 100 k Transfer Container
Started to play again after the new vehicle update. Noticed that this mod no longer works. Cargo ship capacity wont increase anymore. Tried to sleep 24hr on venus and came back still the same. Checked plugin.txt and this mod is there on the list. In game creation also says that the mod is active. Anyone else noticed this?
Same, mod dont work. 500 ship capacity is too low and it seem bethesda testers dont test it because it is nonsense. I have mod with more cargo capacity and with 500 ship capacity are cargo full and ship carries the first type of materials from cargo (or two resources and other resources are stuck in cargo and never leave planet), maybe with 1000 ship capacity wil be better.
I just got word that CK2 has been released...I was beginning to think it would never happen.
I'll have to go back and review the tests I've done with the capaicty...but it's been a minute or two since I've played SF and now there's tons of work to do going through my mods with CK2...not just the ones I've published, but the other WIP mods as well. I'll get to each one as time and opportunity allows.
Just know that I'm still around and will be working on my mods....I've also got HUGE treats for my very cool mod-users that'll be released as soon as they're ready, but I know you'll all LOVE them!
So I built a huge outpost production chain for exp and money. At first it made my game so laggy that it became unplayable. I started to look for mods to get rid of this. The best one, https://www.nexusmods.com/starfield/mods/7418, make a single storage hold alot. So lag fixed. Your mod works as advertised. Now if the cargo link storage was increased ALL my outpost issues would be gone. It seems that the cargo ships all hold inventory even after drop off. Like I said, great mod.
You might get better throughput if you also include a file that changes the cargo link output storage as the ship seems to deliver goods until the first output container attached fills up (which then the operation to move those items down a cargo storage link chain begins; you might just catch the split second it is in the first output container in a quick-loot menu if you're lucky [even I have a hard time reproducing this], but it's classic lazy Bethesda coding - probably imported directly from FO4 outpost links that had similar issues; outputs should just check the end container of a chain first and fill it up but I digress). Someday maybe Bethesda won't make a literal ship instance deliver goods and instead do the delivery system under the hood and just have the cargo ship arrival and departure as a "representation" of delivery happening and working. (that ship is legit taking your cargo from one place to another and it's insane.)
Cargo links and storage links are a buggy mess and I hope someone gives them a complete overhaul at some point. Probably need a whole under-the-hood style rework.
Thank you for even considering trying to tackle any part of this system. You're the real G out here.
I don't disagree with your logic here. The "conveyor chains" are buggy at best and just non-responsive at worst. Many of the scripts seem to hang at times...like if the player changes the inventory data anywhere in the chain. It seems that the script gets confused and takes a long time to update the new data and correct itself. It seems to me that adding larger capacity doesn't seem to help that hanging issue directly, per se. No matter how much buffer I tried to give it, the issue remained. After all...it's kinda like the relationship between voltage, current, and power. The capacity (voltage) is there...but not moving (current)...therefore, no work (watts) is being done. It will, eventually, straighten out...but it seems to take a player action...usually like reloading the cell. (going to another system for a little while then coming back or logging in and out). The other problem is that this issue is frequent, but not 100% consistent. It's what we engineers call an "intermittent defect"...and we hate those more than anything since they are the most irritating type of issue to diagnose. LOL
The reason I made the mod this way was for large production chains where the player might experience a bottleneck where not enough items are delivered per trip and can't keep up with the next stage in the production chain. Theoretically, the cargo ship, itself, functions as a buffer...delivering as much as the incoming container (and attached storage) can handle...storing the rest for the next round trip. But you hit the bullseye with the underlying issue. If the items aren't moving through the storage output links as fast as they should, you'll see a bottleneck or even a stoppage...that could happen at any point in the chain...incomming or outgoing...between the pad and the storage buffer....or the storage buffers and the manufacturing module...or the manufacturing module and the warehouse storage...
I'm working on the pad storage now (both incoming and outgoing) and testing it. If it seems to help, I'll publish the changes in the next update.
Absolutely - I have a genuine feeling that the closer that the cargo outputs match with the cargo ship's weight limit, the easier it will be for a cargo ship to properly empty all of its goods - meaning there will be theoretically no bottleneck anymore - or if there is one, it would be caused by the logic of conveyor chains which would be its own thing to tackle probably. But that mismatch between output size and cargo ship size is likely what is really slowing things down - there's no bigger mismatch in the code than that right there. (The output being a base 300kg, where the cargo ship can hold 7000kg vanilla??? That's such a huge mismatch - it's insane...)
I might go as far to say the cargo delivery system was intentionally designed to be slow, but by utilizing an inherent mismatch as "design" instead of using an external timer or other external system to properly balance the cargo system, they created one helluva buggy mess. I look forward to the results of the output container tests! We will hopefully get a bit of a better understanding of the underlying mechanics Bethesda has put in here along the way.
I just puzzled out how I would see cargo links re-written in an ideal world. I'm autistic as all hell and this problem wouldn't leave my brain. You don't have to use this info at all, but it may come in handy if you ever decide you wanna tackle the big big...
The on-site conveyor chains just need to use different logic on creation. Here's the logic: Instead of "linking" two containers, it's going to take the destination container you set up and make it the new destination for the source that is filling up the chain. Then the code will designate the newly "linked" container as a new destination container when the destination container you specified is full. Making a link between a new container and a container that already has a link just adds that new container to possible new destination containers when the sources fill up the end-of-the-chain container. Instead of being a top-down fill method that starts with objects at the top of the chain and moves them down the chain to the bottom of the chain, its a bottom-up fill, since the objects will immediately go to the bottom of the chain. Also this code logic has a weird caveat that actually makes it work a bit smoother than its top-down counterpart: since the code wouldn't check where the destination is until either the current destination is full or when a new link is made, it will just continue filling up its chosen container in the link until it is full 100% of the time, and then do a logic check of the chain to find destination again. For one, this means that if you were to empty a container at the end of the chain, it would still fill up the container it has been filling instead of changing destinations immediately. More importantly, this means that you could change around items all day long while the conveyor logic is happening and as long as you aren't editing links or filling up the destination container the game has worked out, it should just keep working away with no hangs or mess-ups.
As for the cargo links themselves... Here's the logic for that: We're going to set a new precedent, both by altering how the game does background resource generation and by using time-based delivery: deliveries would now come and leave every 3 local hours for each individual cargo link. Let's say for this example you are receiving goods on Bessel III-B (with a 1:50 ratio of hours of sleep to UT passed - 50 UT hours per hour) from Jemison in Alpha Centauri (with about a 1:2 ratio - 50 UT hours per day). So for every 3 Bessel III-B hours that pass, 3 days pass in Jemison. If Jemison had been sending deliveries at the same rate - 1 delivery every 3 local hours, 24 deliveries will have been made from Jemison during that time. So, sleeping on Bessel III-B for 3 hours will now result in 24 deliveries being made from Jemison. You could even use this logic to create a rate table between every planet and every other planet, so every rate will be available to the game and wouldn't need to be calculated every single time; instead the game could just use the table as an index lookup. Now with this logic, every 3 local hours you will get a (cgf.debug)message saying "X amount of deliveries from LOCATION have been processed." along with a cargo ship dropping down and landing on its pad for visual effect and confirmation only. (These cgf messages would only show if you are at a relevant outpost for those deliveries; these messages would be insane and crazy if you had a massive cargo system and they popped every time a calculation had been made regardless of where you were.) Now, it's easier to justify a small 300kg delivery if you get 24 deliveries at once, making the need to change the cargo ship capacity needless - you'd just need to increase the destination storage to be a very-large container. It also gives a very-justifiable reason to set up an outpost on a planet with a good timescale. It also makes much more sense for a space game.
12 comments
1) FIRST save game manually.
2) You have to use the command tcl and get through the closed off landing ramp of the freighter. After that, you need to click on the boarding door with the console open, make sure the string says "DOOR (XXXXXXXX) PP T" or something similar, then use the command unlock.
3) Board the ship and in ship you use console and write tcl again (without tcl you may fall through ship), DO NOT ENTER THE PILOT SEAT, WAIT FOR IT TO TAKE OFF ITSELF AND TAKE YOU INTO A LOADING SCREEN.
4) Once you are in space, then you want to enter the pilot seat. Zoom out until you can see the entire ship and open the console, and click on the back of the ship. A string such as GBFM " (FFXXXXXX) should appear, and note that number down. Go load back into the save you just made (in step 1)) and use the command "FFXXXXXX.setav carryweight 50000". And you see in terminal cargo ship capacity changed to 50000.
Last advice: make cargo ship capacity equal or less than cargo link capacity, because if cargo link capacity will be etc 40 000 and cargo ship capacity 50 000, then 10 000 resources will be returned back.
I'll have to go back and review the tests I've done with the capaicty...but it's been a minute or two since I've played SF and now there's tons of work to do going through my mods with CK2...not just the ones I've published, but the other WIP mods as well. I'll get to each one as time and opportunity allows.
Just know that I'm still around and will be working on my mods....I've also got HUGE treats for my very cool mod-users that'll be released as soon as they're ready, but I know you'll all LOVE them!
Time to get this train rollin' !
Cargo links and storage links are a buggy mess and I hope someone gives them a complete overhaul at some point. Probably need a whole under-the-hood style rework.
Thank you for even considering trying to tackle any part of this system. You're the real G out here.
The reason I made the mod this way was for large production chains where the player might experience a bottleneck where not enough items are delivered per trip and can't keep up with the next stage in the production chain. Theoretically, the cargo ship, itself, functions as a buffer...delivering as much as the incoming container (and attached storage) can handle...storing the rest for the next round trip. But you hit the bullseye with the underlying issue. If the items aren't moving through the storage output links as fast as they should, you'll see a bottleneck or even a stoppage...that could happen at any point in the chain...incomming or outgoing...between the pad and the storage buffer....or the storage buffers and the manufacturing module...or the manufacturing module and the warehouse storage...
I'm working on the pad storage now (both incoming and outgoing) and testing it. If it seems to help, I'll publish the changes in the next update.
Thanks for the comment!
I might go as far to say the cargo delivery system was intentionally designed to be slow, but by utilizing an inherent mismatch as "design" instead of using an external timer or other external system to properly balance the cargo system, they created one helluva buggy mess. I look forward to the results of the output container tests! We will hopefully get a bit of a better understanding of the underlying mechanics Bethesda has put in here along the way.
The on-site conveyor chains just need to use different logic on creation. Here's the logic: Instead of "linking" two containers, it's going to take the destination container you set up and make it the new destination for the source that is filling up the chain. Then the code will designate the newly "linked" container as a new destination container when the destination container you specified is full. Making a link between a new container and a container that already has a link just adds that new container to possible new destination containers when the sources fill up the end-of-the-chain container. Instead of being a top-down fill method that starts with objects at the top of the chain and moves them down the chain to the bottom of the chain, its a bottom-up fill, since the objects will immediately go to the bottom of the chain. Also this code logic has a weird caveat that actually makes it work a bit smoother than its top-down counterpart: since the code wouldn't check where the destination is until either the current destination is full or when a new link is made, it will just continue filling up its chosen container in the link until it is full 100% of the time, and then do a logic check of the chain to find destination again. For one, this means that if you were to empty a container at the end of the chain, it would still fill up the container it has been filling instead of changing destinations immediately. More importantly, this means that you could change around items all day long while the conveyor logic is happening and as long as you aren't editing links or filling up the destination container the game has worked out, it should just keep working away with no hangs or mess-ups.
As for the cargo links themselves... Here's the logic for that: We're going to set a new precedent, both by altering how the game does background resource generation and by using time-based delivery: deliveries would now come and leave every 3 local hours for each individual cargo link. Let's say for this example you are receiving goods on Bessel III-B (with a 1:50 ratio of hours of sleep to UT passed - 50 UT hours per hour) from Jemison in Alpha Centauri (with about a 1:2 ratio - 50 UT hours per day). So for every 3 Bessel III-B hours that pass, 3 days pass in Jemison. If Jemison had been sending deliveries at the same rate - 1 delivery every 3 local hours, 24 deliveries will have been made from Jemison during that time. So, sleeping on Bessel III-B for 3 hours will now result in 24 deliveries being made from Jemison. You could even use this logic to create a rate table between every planet and every other planet, so every rate will be available to the game and wouldn't need to be calculated every single time; instead the game could just use the table as an index lookup. Now with this logic, every 3 local hours you will get a (cgf.debug)message saying "X amount of deliveries from LOCATION have been processed." along with a cargo ship dropping down and landing on its pad for visual effect and confirmation only. (These cgf messages would only show if you are at a relevant outpost for those deliveries; these messages would be insane and crazy if you had a massive cargo system and they popped every time a calculation had been made regardless of where you were.) Now, it's easier to justify a small 300kg delivery if you get 24 deliveries at once, making the need to change the cargo ship capacity needless - you'd just need to increase the destination storage to be a very-large container. It also gives a very-justifiable reason to set up an outpost on a planet with a good timescale. It also makes much more sense for a space game.
Someday maybe lol...