Відео

I got there in the end. good video thanks for posting

didnt watch the newer video but i think it adresses some of the pain points im currently having with the system, well done

Hey, so a couple things: 1. You can change the 1 second window into a 2 tick window. This system will require at minimum 2 ticks between trains becoming active, so you can cycle through up to 30 depot stations every second. Check out my follow up video for more information! 2. There is a way to automate the depot station placement, but it is a pain to set up and debug. It requires a lot more combinators at each depot station. You'll want to have every newly placed depot station output a "Count" signal onto the global network, which keeps track of the number of total depot stations you have on the planet. Then, each time a new depot station is placed, it can: - Read the global count and save count+1 into a memory cell, which then gives the newly placed depot station it's own unique ID. Use this to set up the tick that the station will activate on. - Use the global count to set the actual clock's maximum amount of ticks it cycles before resetting. - This is the hard part: either plan ahead with your depot stations so that you ***never*** remove them after placement, because removing a depot station of ID X will now cause the next depot station you place to have the same ID as another depot station. Or... - Add combinator setups at every depot station that keep track of the global count. If the count ever decreases by any amount, you loop through every depot station (can be achieved by sending a pulse to the station and having the station send a pulse back when it receives it, use a clock to divide time between pulses). While looping, when you find a station that doesn't respond with a pulse back, you subtract 1 from the unique IDs of every single station after it. Rinse and repeat until all stations respond back with a pulse. As you can imagine, this will require way too many combinators to have a clean setup. It is definitely possible to do, it's just annoying to do, even if you only do it once and blueprint it. The amount of space needed for the combinators already makes it annoying... So yeah.. It's why I didn't go into it in the video, because the explanations would easily be another hour and honestly I'm not sure it's worth it

@@andreaagostinelli5310 You differentiate by naming fluid stations in a slightly different format (say, add the word "Fluid" in the name somewhere), and then use a separate but identical interrupt for them. Its identical except that the station names in the interrupt would work with the fluid station names. Give fluid trains the fluid interrupt, item trains the item interrupt, and it works out.

One thing I immediately realized is the potential risk of having overlapped train numbers, that is multiple trains having the same number, so they're activated at the same time in the system. To solve that, we still keep the parameter M here, but apply a different calculation, which is 2*(5*M-N)-1. The output is gonna be the same, but this time the numbers you get for each station in a depot are not gonna be the same if you type a different number any single time, and it can be called "depot number" or something like that. This prevents the overlapping problem if no "depot numbers" are the same. What you also need to modify for this is the calculation of L and K. Instead of the "maximum number of trains", it's now the "maximum number of depots", and K shouldn't be greater than 5*L. I know there's a lot of calculations here, but that's just the price you need to pay for this solution. Although if you really want to fancy out, you can do something like counting the number of O in the system, and only activate trains when there is exactly one O to prevent overlapping problems. Since the parameter is called "depot number" here, you can even make a digital display in each of the depot to show the number, so that users will be reminded of previous numbers they typed into for existing depot before placing down a new one.

Just to clarify: the second method will work ONLY jf you use the depots that have the exact same amount of spots, but the first method works for multiple sizes

Just read the comments of the others and seems like it's already solved haha😂

@@jasonsalwaysburnt O1 is being output by the decider combinators at each depot station. It's the way to cycle through each depot such that only one is ever active on a given tick. It prevents multiple trains from being dispatched for one request.

Problem with this is, that if your logistics network always requests a resource more than the other, it will starve out the one which is further away from the stations. e.g. So all your trains are busy supplying iron to your stations, but 1 station is requesting copper. But the only copper provider which you have in the system is farther away than the iron providers. This will only happen if you have less trains than stations, meaning 10 trains -> 8 iron, 2 copper providers will work, when full capacity is required But if you have only 5 trains, and 8 iron stations, 2 copper stations, the resource that will be starved off its trains will be the one which is further away. Hope this makes sense lol

@@CasualBoomtown Can you elaborate a bit more? I don't fully understand what you're saying here 😅

@farazsth98 one train station as the depot, and have th rest of the trains waiting in line waiting there turn.

@@CasualBoomtown hes talking about setting up a queue system where trains cannot accept new orders until they wait at a depot, and theres only 1 depot.

@@ender5670 Hey, so on the provider side, this can be pretty easily implemented, you don't have to do multiple deciders. Just connect all the chests together and input them into a decider, and ensure that whatever they store is greater than or equal to the maximum train capacity for that item. If this is true, output an L=1 and use that to set the train limit on the train stop. This will close the provider if there isnt enough resources. On the requester side, this is already indirectly done. In the video, IIRC I use a <2000 threshold to send a new request. This leaves more than enough space in the chests for a full train cargo to unload.

And yeah this would work with the system in the next video as well.

​@@farazsth98 ah ok, that makes sense. however, wouldn't using the signal from all the chests combined have a chance of dispatching a train when there's enough items in some chests combined for the whole train but not enough in others, leaving wagons unfilled and making the train wait? i'm going to use a balancer to equally fill the chests but i'm curious if that would be an issue if they were unevenly filled. i know it's kinda nitpicky though, i really appreciate you making this video and replying to comments cause i've been trying to figure this out for a few days and experimenting to no avail, so thanks a bunch!

@ender5670 Yep, it would be an issue if you're not loading / unloading your trains evenly, but that's a separate issue. You shouldn't try to solve it with circuits (because even if you had a single groups of chest per decider, if you're not unloading / loading evenly, chests within that group can become uneven), but rather by setting up your loaders and unloaders correctly.

@@dacheson007 Hey, yep, the sandbox mode is a scenario that's part of the Editor Extensions mod

@@skoovee Haha it does look similar! But nah I just looked up some random cursors and used one of those, not running Factorio on Linux

Although it would make a problem with liquid cargo, since trains cannot know which cargo type they support

Oh, you can solve it by naming liquid logistics stations differently

@@chrismauck2710 Ah I might have forgotten to show that, oops. The interrupt is essentially just "Fuel < X AND Refuel station is not full", you can set Fuel to coal, solid guel, etc, and X to whatever threshold you'd like!

@@shermanxie4905 Hey thanks! 1. It requires a lot more circuit logic essentially. If you increase the limit at requesters, you have to make sure that providers don't just output a +1 signal, they have to output a +C signal where C is the number of incoming trains. Additionally, the problem you mentioned should not happen if you increase the requester limit correctly. Why? If the first provider train can come in and fill up the buffer chests way over the amount the train station requested, then why do you need to set the limit to 2 at all? Sounds like limit 1 would have been the correct choice, so that would just be an error in the setup, and you'd want to ensure that a limit of 2 is only used when you actually need 2 trains to come and fully unload. 2. Yeah so the method I explained here actually does require all trains to have the exact same number of wagons, and all stations to load / unload that number of wagons. It would just be that certain stations load less on (but this less amount is evenly distributed amongst the wagons, so loading and unloading is faster). Your suggested solution of using different groups and provider/requester names is great too, and would actually allow you to have different sized trains. I think in this case both solutions work and you kind of just pick whichever one you want to go with! Thanks again for the kind words! 😄

Additionally, I find it useful, especially for raw ore providers, to set the station priority based on how full the station is. What works for me is to dividing chest contents by 1 train worth of items and set that as priority. This makes it so that all providers are being used more or less equally, which may or may not be something that you want.

just wanted to say that the train ID condition works perfectly as an alternative to the solution the video has provided. Great for stamping down without manual adjustment, thanks! Side note, it seems that the train ID is updated everytime a wagon/locomotive is attached to the "main" locomotive, so you can typically get away with setting the clock value to equal the ID since most of the time scheduled trains will have more than just 1 locomotive (itself) and thus will have unique ID difference greater than 1

@@SinkDustinSink Thank you! Yes it does work with fluid wagons, you have to have a separate interrupt for fluids that only work with fluid stations (which are also named differently). For example, copper plate provider would be named "<copper-plate-icon> Provider", while a water provider would be named "<water-icon> Fluid Provider". Note the extra "Fluid" in the name, that's how you differentiate between the two station types. Fluid wagon trains would only get interrupts that then work with stations named "<icon> Fluid Provider". This way, fluid trains never show up to the item stations, and item trains never show up to fluid stations. Btw, the follow up video generalizes the interrupts even further, so would recommend that if you haven't watched it yet!

@ thanks so much for the reply

@@farazsth98 Just fyi (maybe a lil boost to the algorithm w/ more comments too lol) I figured out my issue: Had my fluid provider deciders set to less than instead of greater than from a silly copy/paste mistake (as well as other small things). Thanks again for the great video :)

@@Ziiklz The decider that connects to the train stop has to be the only one connecting to that train stop. It sounds like you've wired it up in a way where one decider is connecting to multiple train stops, even if you didn't intend to (this can happen indirectly if you choose a wire colour that the train stops are using to connect to the rest of the network). If you watch the first video closely, you can see that the wire i use to connect the depot to the decider is unique, and does not connect anywhere else. Broadcasting the clock to the network doesn't cause this, but broadcasting the O signal to the network would.

@@MainCoreNightcoreAMV Hey, this shouldn't be possible if you have the system set up correctly. The requesters and providers are paired in the sense that when there is a plastic request, the train handling it will only ever go to the plastic provider first before going to the requester

​@@farazsth98 I'm having this same problem. I've checked and double checked that I have it set up properly, but once every couple days a train will try to drop at the wrong station.

I'm having the same problem. Let me know if you figure out what's wrong.

@MrArineon Hey sorry, I'm not sure how to help without some more information. I've used this setup for over 30 hours and haven't run into this specific issue at all

​@@farazsth98I'm going to import your blueprint tonight and go through it with a fine tooth comb. The only thing that I'm doing differently is that I'm using radars to send the signals to the depot (At least I think, I'll know for sure once I import the blueprint)

@@pahtriac Haha my apologies, I actually tried to go slow 😅 in fact some people have commented about me going too slow! But thankfully those comments are not the majority so hopefully even though I wasn't slow enough for some people, I hope it's still useful to you all!

@@farazsth98 it got me uptosnuff in absence of LTN..

@@Fp401-s4c Yeah it could work, you just have to make sure two trains dont become "active" within a single tick of each other, as that'll lead to both being sent out for a single request. It's doable with some logic and might even be a better solution than having to set up the depots manually

@@RadicalCrab It's difficult to fix this because it looks like an intended game mechanic, the provider station does not consider itself "empty" until the train has completely cleared the station, while the requester sees it as incoming instantly. I guess one way around it is to read the incoming train contents and use that as the "check" for when to start and stop providing the positive signal. I'll try play around with it and see if I can solve it in a nice way!

@@a.m.7307 It works fine, are you getting "Destination is full" for the loaders? If so, that's normal, you have a train limit of 1 on your loaders and you're trying to feed 9 unloaders, which means 2 trains will go to the loaders while 7 will wait with "Destination is full" until the loaders are open. The solution is to add more loaders, or increase the train limit at the loaders (which requires a bit more circuitry to achieve).

Interrupts are shared globally between trains and platforms. I guess one just cant use different interrupts for different trains

@@dadillegaming1563 You have to add additional logic to the circuits in order to account for higher train limits. If you look at the pinned comment in my most recent video, I have some blueprints in there where the provider stations can accept higher train limits (I haven't implemented this for requesters yet, because I haven't needed it). Essentially, instead of sending a +1 signal when the train heads to the provider, you send a +C signal, where C is the number of incoming trains to the provider. That's the high level quick explanation but there's a bit more to it than that.

@@dalastjedi1768 Ah I thought I showed all the depots haha, they're all different, so 0:60, 61:120, 121:180, etc. However, in reality a whole second of cycling between trains is not ideal, so what you can instead do is just have a "K == 2", "K == 4", "K == 6", etc, essentially cycling between trains every 2 ticks. It works the same, but is just much faster. I can do up a blueprint, let me know if you really need one after reading this comment!

@@farazsth98 Please do. I can reverse engineer just about anything but putting 2 brain cells together to try to create a circuit just ends up in failure. lol

@@dalastjedi1768 Here you go, this contains all the blueprints that I'm currently using in my save. The only thing it doesn't contain is the train interrupt, which is not blueprintable, so you kind of have to just copy it over from the video. Please also see the comment in the gist as well! gist.github.com/farazsth98/2c2f378e429696b2c91313bdd9e24e4f

@@permanent8387 It works with more than 1 train in provider stations, I've already got that set up (it's just a bit more circuitry to make that work). It'll also work for requesters, but I haven't needed to set that up, the buffers have been good enough for now!

@@G1MP3R4T0R You mean activate X number of provider stations only when there's X number of requests in the network? There's no clean way to do that when you have multiple provider stations unless I'm missing something. You have to differentiate between different provider stations in order to get one to open up, while others stay closed. The other issue is an obvious one: if every train is interrupted at the same time, the train limit of the provider doesn't matter. Even with a limit of 1, every train will have a new temporary stop to the provider as soon as the interrupt fires. Sure, only one train will leave, but the other trains will be waiting in line to leave for the provider after the first train is done, meaning they won't be available to deal with any other requests in the meantime. Try it out and see for yourself, if you can find an elegant solution to deal with the whole "every train leaves at the same time when a request comes through" problem without the global clock, I'm all ears. It would simplify the design a lot, but yeah I haven't been able to come up with one that works yet.