@Pokeking: These fixes are for the base game, whether you have the Adventure Pack or not.

It's bugs that have been fixed in Fortress Craft Phoenix they are currently working on but implemented as a mod for Fortress Craft Evolved.

I noticed this mod and some more of Steman0's mods use Harmony V2 but the rest of the community use Harmony V1 still. The developer of Harmony V2 clearly states you should NOT mix those in the same environment.
What is the general though about that?

I'm asking because I get an Exception "Harmony exception: Could not load type 'Harmony.Patch[]'" from this mod when it tries to patch ItemBaseUtil.MoveItem().
Guessing it's because I also run Wariat117's Improved Mass Storage that does the same patch of that method, but uses Harmony V1.
My main problem is that this causes the rest of the patches this mod is supposed to apply not getting done since the try/catch statement exits after that exception.

So these fixes are for the mod, or the carts from the DLC?

im happy to see this is still being updated. just as i was hitting an issue with carts getting stuck at wait for full station, i see a patch fixing that. thank you =D

Okey well thank you for all your good answers, and a great mod :)

I'll note that some mods have been known to not play well with freight. It's entirely possible that one of the modded inventories was contributing to problems. They've been known to spontaneously stop working leading to apparently non-functioning stations. Not saying that is what happened here - I know specifically Tricky's Hoppers were prone to this issue - but I couldn't rule it out.

Multiple networks are provided exactly for this kind of precision of control. Sure, it's more effort than just adding more carts, but it guarantees a perfect balance. Unfortunately, timing being what it is, it's very hard for carts to predict which station will be occupied when it arrives several minutes later. As I said, they'll do their best to balance where they can, but you need enough carts on the system for that averaging effect to notably work. Otherwise you can end up with cases like you have where timing is just such that carts pick a station and it aligns the arrival with a time that another cart is already arriving or otherwise still finishing.

Networks should clean up after you remove all stations that use them. If they don't, they'll definitely disappear on a world restart.

And that station Supply/demand you described, every station on each elevator had almost identical cargo (+/- like max 5) since I use the big chests mod and have turned on sharing so it spread across all stations and the same on the dropoff side. Each lift had 2 stations each with connected inventories (To be clear im talking about the previous configuration not my new) and they still wanted to serve the lift closest, even if there was more ore in the other lift.

The problem seems to be that it's a pretty long distance, it takes a cart like 1.5 minutes boosted from pickup to dropoff and then if i have parallel offloading (which i need for the speed) and they all finish in that window they will all go to the closest loading bay, but I managed to fix it, I made 8 different networks with 2 carts on each, so I have 8 unloading stations in my base and 4 loading stations on each of the two elevator, but I have a feeling that this is not how it's supposed to work, or how you intended it to be used but it works better. It may have worked with the previous system I described earlier if I had 16 carts like I have now. I also didn't manage to find a way to delete a network, I read the manual and looked everywhere, is there a way?

There is some logic for that, but it can't be precise enough to capture every possible situation. Timing also makes it entirely impossible to cover all cases too. The carts diminish priority for stations that already have carts on the way, but this is a skewing factor and not a hard rule because otherwise it could lead to situations where stations are under served. This logic works much better for higher cart volumes than it does for individual carts. If you scale up cart volumes you'll notice it more clearly. Station supply/demand factors in as well, so you'll see the effect more prominently if you don't have a skew in supply to one station over another. If one station only ever gets a portion of the total, it is likely to see fewer carts to try to match the intrinsically lower supply. This is where appropriately balancing your cart assignments can help offset the imperfect nature of the auto-balancing logic.

Okey thank you, I thought there was some "cart intelligence" between them managed by the network they are on, like, they see that there are 4 stations with that material and cart 1 is already moving to station one so cart 2 goes to station 2 if there are material there. Problem is when there is like 1400 ore in a station and all 4 que up (has happened a few times), the first take 1000 and the second 400 and then the rest dont get any. That's a suggestion if you're still working on the mod, but thanks for the answer, I was going to add more carts, just need more of those alloy blocks =D. Otherwise, couldn't I make a network between just 2 stations on the same track as the others? but then I would need as many dropoffs as pickups.

To clarify the cart assignments selection logic, consider a cart assigned to a requesting station. This cart could go to either of the 2 supplying stations. Consider a cart assigned to a supplying station. It could go to either of the 2 requesting stations. Timing of their decisions could mean the supplying station's cart happens to go to the station that already has a cart assigned, if they both happen to get there at the same time, one cart will have to wait. The odds of this goes down as you have more carts in the system as it becomes more likely that the supplying station's cart will find a cart is already there and it will prioritize going to the other, unserved station. In other words, the logic for distributing carts works more efficiently as there is more traffic on the system. In the small scale case, you're more likely to see these kinds of one-off conflicts that impact the efficiency.

To best distribute carts, putting assignments on each is best. Carts will always serve the interests of their assigned station. Carts will also do their best to naturally balance by going to a station that doesn't have carts waiting. Sounds like you just happened to catch a time where a cart from another station entered a station that had its assigned cart arrive at just after. There's always a window of time where such a queuing of carts can happen - it can't be perfect since it can't predict the future. It will all even out roughly in the long run. If you have stations still under utilized, adding a few more carts will help fill in those gaps. 4 carts for 4 stations for moving ore is rather low considering load/unload times. I'd expect at least twice as many if you wanted to fully utilize the stations' capacities.

I have 2 cargo lifts with 2 freight stations on each totalling 4 stations and titanium ore is set to 0 so freight carts should always try to keep these empty, I have dedicated 1 freight cart to each station but they still que up many on one station, The dropoff station in my base (2 of them) have cargo set to 5000 and 2 dedicated cart to each of them totalling 4, on the whole network there is 4 freight carts, how can I make it so they distribute more evenly? Do I Only set dedicated in the dropoff or only on pickup?

Courtesy of steveman0, copied here for others in future, possibly not exhaustive.

Freight Fixes mod bug fixes:
-Fixes an issue with transferring items between cart inventories that would sometimes leave an item unable to offload.
-Fixes corner track to prevent carts from getting stuck on them on world load
-Fixes carts no longer exclude stations for demand balancing when there's only one option.
-Freighters now reject going to stations for assigned station needs they can't serve.

Would love to install this but I also want to have the achivements :(. Havin problems with loaded carts idling due to no accessible destination station, demand is clearly above the freight in transit.

Holobase revisions are already in the plans for FCP. I think DJ even did some things on the carts and track. If not, I'll likely have a look at some point. Holobase support isn't too hard to do.

FCP is going to be pushing players further away from carrying everything around in their inventory. The hardcore inventory mode and hardcore crafting will be standard which will substantially incentivize automating lines. You'll have less of a need to sort and search your inventory that way.

Handbook and tool tip stuff is dependent on feedback. If there's anything wrong, drop it in Discord. Zebra has been collecting and making corrections when they are reported. If no one reports the error, it doesn't get fixed!

Not sure what more is needed performance-wise. FCE is already blazingly optimized. FCP is only going to get better with the addition of newer, more efficient tech. Not many known issues for a game that can push millions of verticies regularly.

Not sure I can do much to improve wait-for-full. The underlying infrastructure doesn't have the information necessary to make substantial changes to the functionality.

UI changes aren't out of the question if they're reasonably productive. The problem is that UI work is especially time consuming when factoring in it must also by MP compatible. If there's a particularly good idea, I note it, but generally core functionality occupies all of what little time I have to devote to it any more. After all, I still have a full time job. This is hobby work for me.

Tracks aren't entities FYI. They can't count carts as they have no logic unlike belts.

I'm sure someone would suggest a map, complete with rails shown as red when congested. Probably would be a performance hog though. If done, it would have to be a holo display and should probably display horizontally on the ground ... and would need a large area. Personally, probably not worth the effort though.

The freight system really doesn't need improvement though. There are a lot of areas of FCE that could take some attention first.

First, is a dang search button on the inventory! And, sort-by-type is ... odd. In addition to sort-by-alpha, by-quantity, and by-type, I'd suggest "unsorted" or rather, "custom". The custom mode would remember the players ordering if they switched to another mode and back. Perhaps shift-custom would save a current by-alpha or by-type into the custom's order.

Second - accurate handbook and tool-tip info.

Third, performance improvements. :-(

Fourth, letters and symbols on blocks, ala Empyrion. Make it possible to have large signs as a series of plain blocks, each with a single letter.

Nothing earth shattering, but here's a few ideas for improvements.

I want the wait-for-full, but reading through the forums, it seems to be the #1 thing that people get bogged down over. If it's not removed for FCP, then I suggest adding a mode or toggle for wait-for-full-unless-another-cart-from-a-*different*-consumer-station is blocked and waiting.

I will program just for the fun of it, but hate UI work. That said, most of the improvements that I think you might make are UI:

A filter or sorting button on the transport grid to show only stations for a selected network. Or maybe for a selected freight item.

Clicking on a freight item in network status could show a list of stations using that good, sorted by network.

Station info in the monitor could show everything that's shown in the station interface?

Tracks could count traffic, ala conveyor belts?

I use one way tracks everywhere more or less. There's only the rarest case that it's safe to allow 2-way travel on a track line and these are virtually always cases where only one cart will use the line. If you're not seeing any conflicts though, you're probably fine.

Glad you like freight and my other mods!

If you do find any issues that are reproducible I'm always looking to improve the system. It's likely to be even more central to progression in FCP so every fix will make it that much better for release.

Re "carts withdrawing from stations". I have all my stations fronted with a one-way track piece to prevent any carts from going the wrong way (and a turbo rail coming out). Is that a bad idea? If so, it's easy enough to provide a way for a cart to back out to a junction that goes in an appropriate direction.

Thanks for this and all your mods!

Your freight additions to the base game make the game so much better. The freight monitor is my favorite tool for accessing the health and status of my base. Your blueprint builder relieves tedium in a non-cheating way. Your access port is a great QOL addition for my "warehouse". Your MS manufacturer is great for setting up small stations to manufacture large handfuls of selected finished products in a more compact layout.

The network only had three carts and the monitor showed the other two as empty. At any rate, it sounds like this isn't a common or reproducible bug, so maybe it was a unique glitch. I reported it in case it was something that might affect others; since that seems unlikely, please don't spend any more time on it.

What was the in transit quantity? With only 9 loaded and 103 needed, it should fill to full no problem. If something like this happens again, the log file might help. But really, verifying the network stats is the best way to identify an issue. If you had a mysterious amount in transit either in other carts or from an unexpected source, then it'd explain the issue. Otherwise there's no known cause that would prevent a cart from withdrawing from the station. I suspect you somehow ended up with additional carts with items in transit.

I think I solved it - but the solution was unexpected.

Here's what I saw:

A network named "Fuel-Relay". Two stations.
Station "provider" had 500 fuel. It had one assigned cart that was waiting to get into station provider.
Station "consumer" wanted 103 fuel. It had two assigned carts. One was waiting to get into station "provider". The other was loading at station provider, but sat for ages with only 9 of 25 cargo loaded.

After typing this, I removed the consumer carts and assigned a second cart to the provider station. Seems to be working as expected now.

Whatever is happening, it is possible to debug with the system monitor. The rules are straightforward, if offers > 0 and in transit < needs, a cart will collect an item. With wait for full, they won't leave until full. The only way this system fails is if you have your system setup in such a wait that offers can't exceed 0 or that you let the in transit value equal or exceed destination needs. The reason why wait for full is not recommended is in part that it's inherently more efficient in the vast majority of use cases. If you don't have any more to collect, it's almost always better to transport what you have and come back later once it has restocked.

I'll switch back to wait-for-full and try to debug. I do have two carts, but the network only has two stations (producer and consumer) and the second cart was waiting empty behind the first cart. The consumer had drained its 300 can storage; the cart in the station had maybe 11 cans in it and the station wasn't adding any more even though there was plenty available at the providing station.

Wait-for-full is working for my empties and for a couple of bar production setups. Those bar production setups have three stations. Smelters feed a station with a tiny mass storage. That tiny station is on a dedicated network with one other nearby station having a huge mass storage and a single cart. That huge mass storage has a third station to feed bars to a general network. The huge mass storage has no stockers or output ports, so the size has no impact on performance or speed.

If it's stuck half full, either you don't have any more at the station to provide (this would be rather obvious though) or you have another cart on the system that is loading up to fill with the system demand. Did you check the network demand to confirm that the registered in transit is less than the network needs? If you accidentally let another cart in the system somewhere it might be filling up as well locking the other one out from filling - carts may not under any circumstance fill with more if doing so will push the in transit quantity over what is necessary to meet network needs.

P.S. (to the prior comment)

Yeah, I imagine that forcing carts to only carry full loads of fuel is more efficiency than I need, but I liked the idea/puzzle of making it happen.

P.P.S
This comment brought to you by the 1000 character limit on comments. :-/

I can't get "wait for full" to work reliably. I know it doesn't make sense to use this mode most of the time, but I though I had a good use-case. I created a network with only two stations on it. One provided fuel canisters. The other consumed them with a desire for 100 of them. The provider station was set for wait-for-full. Most of the time it seems to work - the carts carry 25 fuel at a time instead of only one or two fuel canisters. Every now and then though, I'll see that the consumer has run dry and a cart is stuck in the provider station half filled.

Oddly enough, a similar setup with one or two consumers of empties and multiple providers of empty fuel cans has never glitched.

What am I doing wrong? I see that the consumer will send a cart when it only needs one or two canisters. That should be OK; it seems that the station *usually* does notice that the consumer now wants more than it originally wanted.

Sounds like you have a routing issue most likely a one-way track is turned around. That's usually the cause whwn a cart launches from a depot and then fails to route to the station. I'd advise reviewing your grid and try simplifying parts until you narrow in the the problem.

okay, thank you. i doing all of the above

The game only loads into RAM what it needs to. You can't arbitrarily ask it to use more RAM, nor would that improve performance in any way. RAM is unlikely to be a significant factor in FPS performance anyway. If you can't get 60+ FPS typically with that computer I can only assume you've turned your settings up too high or aren't using enough rooms on a very late game fortress.

hello, steveman0, this post is not related to the mod, but more about the game, i was chatting with Wariat117, on many mods ideas, but one thing that came up was, How does the game decide its ram usage? (gamer logic, more Ram, faster game) but he could not find what code or line, in the files, (cause it might be worded differently), now you are thinking, why would you need to know that? i got 64 GB worth of ram and the game only use 5 (at best) with 30 fps :/ piss poor fps for a machine like mine, and i don't know why, and so. the simple point, i would like faster game, possible improvements to my fps (at fab settings, i cant even get my 256 chunk loaded) i9-9900k at 5Ghz stable, and 2080ti

Shouldn't be any overlap with other mods. I'd have to review the source to recall what specifically was added here.

Any way we could get a list of those fixes so we understand what to look out for ie what was broken and no longer should be.
It would also also be good to know so we can be wary about compatibility with other mods which may have similar features / fixes.

Could you fix the filename of "mod.config"? It is case sensitive on Linux, seems to work fine with that change.