I put together a simple circuit in Zhtszhsobvt drawings, but it doesn't work...

The train just goes around in circles but doesn't let the lubricant fill up.

Here is a BP: https://factoriobin.com/post/brdjasuhahbt-EXPIRES

if needed I can send you a save

That BP seems to require a lot of mods I don't have, would you be able to send a save instead (so that the game can download those mods automatically)

Also that does remind me that I need to add import/export buttons for networks, since network settings aren't part of blueprints.

That BP seems to require a lot of mods I don't have, would you be able to send a save instead (so that the game can download those mods automatically)

hmmm... in my current game about 350 mods :))) be careful :))))
here: https://dropmefiles.com/JT834

Mods are still downloading but there are definitely some in there that are gonna cause problems. I know because I recognise them from when I had to add compatibility with them to cybersyn. Hopefully SSPP should be a bit better at complaining when some other mod does something unexpected than cybersyn is, but we'll see... :D

I think your issue was just that you hadn't set delivery size on the network item, so it was trying to collect 1 fluid unit, minus granularity which defaults to 1, which resulted in the condition being "wait until the train has at least zero fluid". Setting granularity doesn't matter at single item stations, but you must set the delivery size.

Maybe I should have the delivery size default to the class capacity, but I chose to default it to 1 so that it's obvious when you forget to set it. The reason it isn't always just the full capacity, is that for certain items, especially modded ones, you absolutely don't want to be transporting a full train at a time as some items take hours to produce. It's not uncommon in mods like pyanodons to have items where you are delivering a single stack at a time.

It's a bit non-obvious :) So far, it turns out that it's a bit much to prescribe with your hands. But maybe it's just out of habit.

Sorry, not sure I follow. Unsure if it's what you were talking about, but with those 200k fluid wagons you're using, you're going to need a LOT more than 2 storage tanks to hold even a single full load of fluid from those 4 wagon trains. This is no different to cybersyn, or any other pull based train system: you need enough storage to fully load or unload a train, or things won't work as intended, if at all.

I am planning to make a video going over setting up a basic system, hopefully some time in the next week, as it is a bit much to explain in the readme.

Sorry, not sure I follow. Unsure if it's what you were talking about, but with those 200k fluid wagons you're using, you're going to need a LOT more than 2 storage tanks to hold even a single full load of fluid from those 4 wagon trains. This is no different to cybersyn, or any other pull based train system: you need enough storage to fully load or unload a train, or things won't work as intended, if at all.

Not at all, the requesting station requests exactly as much as its reservoirs lack to reach the amount set in the combinator. And the train controlled by Cybersyn leaves immediately after loading the specified amount, without waiting for the full load. This is clearly visible if you open the train GUI at the time of loading. Well, the train really does travel half empty :)) I installed this mod because I like unhurried trains :))

The equivalent to the SSPP's "delivery size" parameter in cybersyn is the request threshold signal. CS will only send "exactly as much as its reservoirs lack" if that amount is greater than the request threshold. If you aren't setting the request threshold, then most likely it is using some default value that just happens to be less than the tanks can hold. The fact that CS will exceed that limit in some cases doesn't actually matter when you have enough trains, and is only visible in your simplified test setup.

Basically, the fact that CS is working somewhat like you expect in your test case is just a fluke. I think the fact that I default delivery size to 1 is probably a good thing as I don't think having things seemingly work by coincidence without actually being set correctly is a good thing :P

Also, I'm not quite sure what you mean by "unhurried trains"?

The equivalent to the SSPP's "delivery size" parameter in cybersyn is the request threshold signal. CS will only send "exactly as much as its reservoirs lack" if that amount is greater than the request threshold. If you aren't setting the request threshold, then most likely it is using some default value that just happens to be less than the tanks can hold. The fact that CS will exceed that limit in some cases doesn't actually matter when you have enough trains, and is only visible in your simplified test setup.

I think you are mistaken. When a request for resource delivery occurs, CS adds the expression "Cargo >= X" to the train schedule in the waiting condition at the sending station. Therefore, as soon as the amount of cargo reaches the threshold value X, the train immediately leaves the station. By the way (!), the fact that the schedule is clearly visible is very convenient for debugging. However, for some reason, CS adds a lot of intermediate points to the route, which, as it seems to me, prevent the game engine from finding the path...

If "delivery size" == "treshold", then it's probably worth either naming this parameter that way, or describing it in the documentation in more detail. Intuitively (to me) it seems that "delivery size" implies the "=" sign, not ">=". Perhaps this is a peculiarity of my personal perception :). I think I'm not the only one who will try your mod after CS, so it would be worth clarifying.

Basically, the fact that CS is working somewhat like you expect in your test case is just a fluke.

I don't think so, this is not the first game I used CS in and it always worked the same. I wrote why just above.

Also, I'm not quite sure what you mean by "unhurried trains"?

"Slow and Steady" mod https://mods.factorio.com/mod/slow_and_steady

I do feel there is some communication issue here, sorry about that haha. Anyway, in SSPP, delivery size is actually an upper limit, not a threshold. Trains will not be filled more than that. The thing is that in cybersyn, overfilling like that only ever happens if your polling rate is too low (you have thousands of stations), or if you've just switched the system on. Once running, and ignoring polling delay, CS will dispatch just as many trains as SSPP will.

As for schedules, SSPP doesn't actually care which requester it is going to at the time of dispatch. It thinks in terms of deliveries, rather than individual items. This is one of the fundamental differences between SSPP and cybersyn, and is part of why the conditions only get added the schedule as the train arrives at stations. It should also be noted that using different request thresholds in cybersyn completely breaks any kind of complex prioritisation you try to do. To me, making sure items actually go where they should (and don't get voided when they don't need to) is more important than sending a tiny bit fewer trains. I'm not sure if you've done byproduct/void heavy modded runs before, but SSPP is designed to support those cases just as well as simple pull cases. Cybersyn simply does not handle those cases well.

Also, the reason that CS adds those intermediate stops is because that's how it tells trains to go to that specific station (the station stops after the coordinate stops), even if stations have different names. SSPP instead manually tells trains to leave stations when it wants them to, and just makes sure that the target is the only station available, so doesn't need those intermediate stops.

I do feel there is some communication issue here, sorry about that haha.

Oh yes, quite possible :))

Anyway, in SSPP, delivery size is actually an upper limit, not a threshold. Trains will not be filled more than that. The thing is that in cybersyn, overfilling like that only ever happens if your polling rate is too low (you have thousands of stations), or if you've just switched the system on. Once running, and ignoring polling delay, CS will dispatch just as many trains as SSPP will.

As for schedules, SSPP doesn't actually care which requester it is going to at the time of dispatch. It thinks in terms of deliveries, rather than individual items. This is one of the fundamental differences between SSPP and cybersyn, and is part of why the conditions only get added the schedule as the train arrives at stations. It should also be noted that using different request thresholds in cybersyn completely breaks any kind of complex prioritisation you try to do. To me, making sure items actually go where they should (and don't get voided when they don't need to) is more important than sending a tiny bit fewer trains. I'm not sure if you've done byproduct/void heavy modded runs before, but SSPP is designed to support those cases just as well as simple pull cases. Cybersyn simply does not handle those cases well.

You are right, I have never worked with scenarios that include many by-products, and I also have no experience in building megabases. You understand me, I am not criticizing your development, on the contrary - I am trying to understand it. And for this I need to understand the principle of operation. Just "press the button - get the result" does not suit me :)))))))

Also, the reason that CS adds those intermediate stops is because that's how it tells trains to go to that specific station (the station stops after the coordinate stops), even if stations have different names. SSPP instead manually tells trains to leave stations when it wants them to, and just makes sure that the target is the only station available, so doesn't need those intermediate stops.

Yes! Now I understand, somewhere in the CS description it was that it doesn't matter at all what the stations are called and whether their names are unique, thanks for the clarification :)