#Source-Sink-Push-Pull
1 messages ยท Page 2 of 1

idk, i was doing stuff with old trains not even part of the SSPP station system
deconstructing one of those old trains, to void the fluid it was carrying, before reconstructing it
opening the UI element for the locomotive so i could manually remove the fuel, is when the error occured
you want the save?
If you can manage to find out exactly how to reproduce the issue, a save file + instructions would be great
Right, yeah a save would be much appreciated
I won't be able to look at it until tomorrow though
i'll just..... leave that train up there alone and not touch it.....
and hope nothing else goes wrong
Oh yeah I see what's happening
actually i lied, i messed.
if i go up to the train and just deconstruct it piece by piece, instead of with a planner, that goes as expected
That makes it easier to find bugs haha
Apperently I've just never tried to deconstruct a train with robots with the gui open
๐ญ
was in the process of checking up on a delivery of a fluid, making sure my station was actually picking it up like requested
Hmm, yeah if you can give me a save that'd help
any chance any of this could be related to me manually making those 3 lines into comments?
I don't think so? That check for extra cargo isn't actually required for SSPP to function (in fact it was only added recently), it was just to make the user aware of broken stations ASAP
Most likely its just some edge case I missed with cleaning up old jobs
Actually
Why are you on 0.4.1?
There is a small chance this issue was fixed in 0.4.2

okay lemme go see about updating
and i presume that'll mean also going back in and making those lines into comments again
Yeah

for the sake of information conveyance; I'm having a great time. getting a peak behind the curtain a lil is very interesting
Really glad to hear that ๐
seems the button that caused the most recent crash is no longer causing crash, but also things have changed about the current situation in the save
Oh, it may have caused a reboot...
Which means that something was in fact not cleaned up properly and then the update just detected that and forced a reboot
Oh well, I have the save from before the update so I can verify that tomorrow and hopefully figure out what happened
yeah this works pretty well!
am now able to load an EXACT amount of fluid as long as it is a multiple of the pump speed per tick
so with py pumps that move 200 units/tick, it's possible to load 25000 fluid exactly with nothing ever getting stuck
I think this does actually look promising enough to release as it's own mod
well hit a roadblock with this little side project anyway
the modding API is as annoying and incomplete for pumps/fluids as the in game functionality is, compared to all the options inserters/items have
If I manually set a filter on a pump, then pump.insert_fluid(some_fluid) will check that filter before inserting the fluid, and not insert anything if the flโฆ
if anyone wanted to +1 that thread that would help
I'm calling this thing a "perfect pump" - basically a pump that ALWAYS pumps at it's maximum speed, regardless of how full the input fluid segment is. It's super convenient for multi fluid stations, makes them as reliable as item stations. The only thing I can't seem to get working is filters, because the way the filter is implemented for pumps is WEIRD.
Although I think I might clean it up and do a beta version of it anyway, since for the thing I actually want to use it for (loading fluid wagons at shared-pipe multi-providers), the filter doesn't matter
@storm adder made a demo of the big fancy pump! this one is a bit jank because it doesn't use that new setting (have to wait for the next factorio update), but I'd love to hear your thoughts on it!
(don't save over your main saves with this version, I make no guarentee it won't explode)

To clarify;
You say your tar block exports 14 fluids.
And also, 1 station can only be set to provide 10 different entries, due to character limits on combinator descriptions.
So that must mean you have at least 2 stations at your target block, correct?
yeah, I have 3
Okay that makes sense.
having too many per station is bad anyway since if they all get requested at once that would take really long time to service everything
Well, depends on "service time",
which for pY having 12k/s pumps and fluid wagons with only 25k of storage; service time with only 1 pump per wagon, is only 2.08 seconds.
For vanilla pump speeds and wagon capacities, and single pump has service times upwards of 40 seconds.
the issue is the time it takes the trains to get there
assuming you have a reasonable train limit set
Hmmm ye...
Well I suppose then it's just a balancing act between those competing considerations.
- condensing more fluid types to a single station means lower footprints, but also more trains needing to file through that single station.
- more stacker capacity means easier time having trains que for stations, but also larger footprint
- more stations to split fluids between means a division of trains needed, but it also means larger footprint
yeah exactly
on the topic of the limit of 10, I do hope to work around that eventually
Ah, I see.
That changes things then.
Cos I was considering scrapping my approach, in favor of having dedicated pumps per fluid.
Since only the 1 pump for a given fluid needs to connect to the wagon at a time, and that can be controlled by filter.
If the SSPP station limits to 10, might as well just uae dedicated pumps.
Even if it was 12, same deal.
Its when limit is 13 or higher that things can get spicy
For me I found that the main benifit was not having to run 15 pipes from my build to the actual station
Ohhhhh..... yeah that makes sense....
I was staging my "storage tanks" that the stations can "see" as close to the station as possible.
Such that the total fluid that can fit in the "shared pipe" is small.
So there's less "spare residue fluid" left in the shared pipe after a train leaves.
But ye, absolutely could have the shared pipe be long
Interesting
yeah, I've basically been treating the storage tanks as machines to shove into the actual build
then I just have a pair of circuit wires running from the stations to the tanks in the build (one for the filters, one for the contents)
and multiple stations can share wires without issue
Fair enough.
Doesn't matter if station-2 can see there's creosote available if station 2 isn't set to allow provision of creosote.
yep
also on the topic of the pipe length, the pump thingy I posted makes that moot
so granularity can just be a flat 500 everywhere
I can see why my solution would be inefficient for a large Shared Pipe.
Cos I'd have to make my evac pump run longer to ensure clearance of residue.
And thus, and solution where exact dispensing of fluid amounts is used becomes far more appealing.
I just generally dislike reliance on exact precision.... don't trust it. But I'll give the "Perfect Pump" thing a go, and see if I run into the "off by 1" errors fear when considering reliance on precision.
Basically as long as the shared pipe has a capacity that is less than delivery size, it guarentees that loading will be within 200 units of the target
and, if the storage tank is > ~75% full, the amount is EXACT
most of the time my trains have been loading exactly 25000 with nothing getting stuck
plus, this has the advantage over the suck it out method that it doesn't require delivery size to be a full wagon
so for expensive fluids you can use 10000 or less
Hmmmm, yeah eventually I'll want to have partial wagon deliveries......
All assuming that I'll ever have a situation where I want to have 13 or more unique fluids provided, and to have some subset of those fluids be partial-wagon.
(Well.... if i wanna have the station deal with items as well, then that'll take up space at the station.....
A small crane for input to wagon and a small crane for output from wagon will eat 1 entire side of the station, so I'd be then limited to 6 pumps at the station...)
Oh also,
Train IDs and Train Counts, from stations;
Iirc, wiring to the SSPP station directly has the wire recieve the cargo counts for a train at the station, but not those other 2 statistics.
correct. I could add them though, though I'm curious what the use case would be
I like having fun indicator lights at my stations.
So i can tell at a glance what the status of the station is.
Different color lamps for
- if a train is on the way
- if a train is in the station
- if it's set to provide something and not enough is in local inventory to allow a pickup.
- if it's got local inventory for pickup, and it's just waiting for a train to route to it
That sort of things.
Bullet points 3 and 4 there won't need to know train-ID or train count, but 1 and 2 would.
Its not necessary by any means, I just like it
mostly the reason that those aren't exposed currently is because the output of the general comb is where all of the random stats are planned to be output
since it's not used for anything currently
Ye, i remember reading about that.
but since that isn't just re-using the existing outputs, they don't have to just be the same set of things (train id, count, etc)
so I've been waiting till there was some specific piece of info I've wanted before adding it
plus, as soon as I add something, people will start relying on it, so I have to make sure I expose the right things ๐

3 and 4 here are the most difficult things imo
since that means exposing per-item information, yeah?
and I can only fit one per-item signal
Are they?
I could just read the chests/tanks that the station can "see" for determining "amount provided" and "deficits", no?
I guess, if you wanted to duplicate a lot of the logic
I was more thinking about getting a ready-to-use value
It would be possible without I/O from the station itself, even if not easy
I'm lost on what you're seeing as difficulties regarding "per-item information"
well, for example if we wanted to expose the number of trains for each item specifically
rather than just a total
Ah, yes.
It'd be hard to have both (1) "trains on the way to pickup coke" and (2) "amount of coke provided to the network by this station"
Cos you'd "need" signals for those different values. And they're both related to 1 item, so which value gets the native signal?
(It could technically be bitwise encoded to the same singular "coke" signal..... but, I don't expect that would be something worth actually implementing. Lots of problems)
I think also important is that I generally don't want to expose things in a way that needs a lot of external combinator logic to do anything useful
so I generally prefer to start from the point of "what is the end goal", and then work out the simplest information required to achieve that goal
so I'm thinking that here, the goal is to be able to see more information about the station in the world, rather than in the gui
Hmmm...
One argument in favor of retaining the limit of 10 provisioned entries and 10 requested entries, would be indexing provision entries as "0 through 9" and request entries as "A through J"
Then using the " 2๏ธโฃ " signal to give the count of trains on the way for whatever is the 2nd entry in the list of provisions
And using " ๐จ " to give the count of trains on the way for whatever is the 3rd entry in the list of requests.
The limit of 10 is relevant because there's only 10 numeric signals.
(I'm just tossing out ideas, may or may not be useful)
Using alpha-numeric signals to give train counts would ease competition for what gets put over any specific item signal.
the mod actually already does exactly that for dynamic item modes
which are inputs to the provide/request combs
Is that why the limit of 10? Cos base-10 numbering only has 10 unique numeric characters?
no, it just happened to line up ๐
Ah, darn, I thought i was being smart
the limit of 10 was after testing a station with all of the longest names in py
Ahhh. Fair enough
well it was actually just over 11, but I left some extra room in case I add extra options
I think I would be quite happy using numbered outputs like that
Even if the limit were increased, I don't think I really care to make it truly unlimited
16 would be another nice breakpoint, then hexadecimal can be used
The game comes baseline with 26 alphabetical virtual signals.
And 10 numeric virtual signals.
And... technically 12 punctuation signals, and 14 math operator/syntax signals....
As well as a variety of other icon signals.
Idk how hard it would be to add in extra signals as part of the SSPP mod.
I know it's already got the 10 signals for dynamic "pushi-ness", the orange looking ones.
I think 26 would be the absolute limit that would be worthwhile
So 26 provision-entries, and 26 request-entries?
idk, I don't think I want to add that many signals...
It would be a lot of signals to add.

But also, anyone who's gonna be finding "real" use cases for SSPP is gonna be playing a mod like pY.
And if that's already the case, there's already gonna be a lot of different signals.
The ship of "are there too many signals" likely will have already sailed by the time someone reaches for SSPP.
idk, I have the py recipe signals turned off because of how they clutter the gui, even though they would be useful sometimes
Even without the extra recipe signals, just the baseline amount of signals added for each item/fluid in pY already increases the signal count over the base game by like 10x
I think that really, deliveries is probably the only thing the station really needs to output per item right?
Uhhhh.... maybe?
You mean to suggest that it's only relevant to know how many trains are on the way to deliver items/fluids?
I think so
And it's not relevant to know how many trains are on the way to pickup stuff.
Hmmmm

Ohh....
probably not the best word to use
basically, the general comb would just output the number of active trains at or going to the station for each item
and if I can say with certainty that I won't want to later use the signal for something else, that could just be the item signals directly
Hmmm...
So if there's 1 train on the way to pickup Source Coke,
And 1 train on the way to pickup Push Iron Oxide
Then the General I/O combinator will output [ 1 on coke] and [ 1 on Iron oxide]
?
yeah
And then if I wanted to instead have values for "how much coke is being provided to the network", I'd just wire up to the same chests the station uses for determining the same value.
yeah
Ye, fair enough.
I have felt myself feeling a bit lost on how the system determines when to dispatch a train to replenish a requesting station that's falling short on local inventory.
It seems to be related to various parameters the user inputs, like (1) max train route time, and (2) throughput for the item at the pulling station.
But if I were trying to set a light to indicate if the station is "short on supply" or "good on supply", idk where I'd set the threshold for that.
Well, the main issue with that is that requesters don't actually know for certain that they have items incoming until those items leave the provider
Ye.
And if that's the case, I want my requesting/pull stations to have the lamps for that item to show "red" so I can know at a glance there's a problem.
no but I mean, that isn't a problem
And if possible, have a different color for "we're low on this item, but it's fine cos there's a train on the way"
there are trains out getting items from providers, but at that point the items are for any requester, not a specific one
so even if the requester doesn't have any trains coming to it yet, there might still be trains going to providers
Oh, that's fine.
The situation i want to be able to diagnose is more about a pulled item at a station being low, because the station(s) that are supposed to be acting as source for that item aren't producing.
Because I oftentimes find myself not necessarily checking in on my source stations often enough, and noticing there's something wrong.
If that's the case, I want the source station to indicate "alert, we've got a problem, I'm not getting items to provide to the network.
And also have the pull station indicate "alert, I'm not receiving items from the train network. Pls address that"
oh wow, new factorio version already out!
Ooh! The one with filters for fuel slots???
uhhh, maybe
I just know it has that thing I wanted for my pump that I only brought up on discord like 6 hours ago
and it got immediately added which was cool
also wait fuel slot filters!!???
no more assembling machines eating my cellulose?
Filters for burner entities fuel slots is from 2.0.44
The version released today is 2.0.55
Neither have been marked as stable.
But yes; no more assemblers eating your cellulose.
awesome
anyway the reason I opened the game back up was for screenshotting this
I think that what the mod really needs is a way to filter this
this is basically the unmet demand of your network overall
what is needed is the ability to filter the item list so that it only shows items with unmet demand
that was meeeeeee (by way of annoying the devs)
Wild to see such a quick response.
Wube is great. I wish other games I liked had this sort of responsiveness.
Anyways, SSPP stuff.
That's a list where each row is a station.
And the green numbers are.... "trains-worth of items provided"?
And the red numbers are.... "trains-worth of requested items not provided"?
it's just the existing network item tab
Ah, it's for entries in that list... I c.
green is push demand, meaning the number of deliveries waiting to pushed (they have no request stations that the items can go to)
red is the same but for pull demand
yeah, if everything is working correctly, they should all be zero
like ash in this screenshot is doing ash things
Classic ash things.
And the numbers are in units of... "train-trips" of the given item?
Like, you've told the system that ash gets moved in bundles of 20k, and the 17 is indicating that there's 17 of those 20k bundles that are still waiting for a pull/sink to send them to.
Right?
yes exactly
(also this is from my editor world, if you were wondering why there are such weird items there)
Theoretically, it should be impossible for a given entry on that list to have non-zero values for both numbers, right?
If you were to have 1 unmet pull of ash alongside the 17 unmet push of ash, that would very quickly resolve itself to 16 unmet push of ash (and 0 unmet pull)
mostly, except when stations are at the train limit
or if you have not enough trains
Ah. Yes, train limit.
So displaying both is still useful.
What you're looking for is a way to have the list only show entries for which one or both numbers is non-zero.
Cos that's where there's work to be done.
Can the columns be made to be sort-able?
yep, and yeah that's the plan
but I'm going to do searching, sorting, etc all at once, and that's gonna be a big update
searching items is particularly complicated because of localisation (users can search in different languages)
That'd be sufficient functionality i would think.
I don't need the dual-0 entries to be hidden entirely. Just sorting so the non-0s are at the top would be fine.
Searching would be nice... cos eventually that list is gonna get very large.... and being able to see if I've already got an entry for a given item/fluid has already been a thing I've wanted.
So I wanna add an option for granularity to let you choose what exactly it does
currently, for items, what it does is round down the load target to a multiple of granularity
and for fluids, it just subtracts granularity from the load target
but for people using loaders instead of inserters or cranes, it'd be better for items to just use the subtraction behaviour as well
but I don't know if I like the term granularity
I'm wondering if it'd be reasonable to make subtract the only mode, since that's a lot easier to explain
and it works for inserters, too, you just have to set it to the existing granularity - 1
so if your inserters load 12 items at a time, you would set subtract to 11
alternatively, we could leave the name as granularity, and do that -1 automatically
"Granularity" as a term makes sense, once it's function is understood. Initially, it wasn't intuitive what it meant.
Maybe tucking that message you just typed up with the explanation somewhere the player can read would be a good idea? Like how pY has that lil menu in the top left with explanations on a bunch of pY mechanics.
hmm that's a good idea
honestly, I could just make the tooltip longer
I've been trying to keep tooltips short and concise, but maybe it's better to just have a full explanation in there
Longer tooltip also works.
As far as the different operating modes, and making a toggle/option for it for those using loaders; i didn't even know that was how it worked tbh.
yeah it was also very magicky lol
I think the most "proper" way would be to have short, concise, arguably incomplete information in tooltips.
With long form explanations found elsewhere.
that's kind of the case already (although the readme isn't really that much better...)
I want to set up a wiki I think
The Readme also isn't available in game.
Which... idk, it's not hard to figure out where it's at, and it is useful info.
But someone just browsing for mods via the in-game search bar on the mods page, likely won't automatically assume there's an online resource that answers all their questions
(Unless the Readme is available in game... and I'm just blind)
oh huh, didn't even think of that
I always use the website to find mods
Maybe it wouldn't be too hard to just add a little help button in the top right of the network window?
the help window wouldn't need to be as fancy as the py codex, basically just the readme would probably be enough to start with
but at that point I should probably just use tips and tricks
Definitely a good start.
Idk what text formatting is available for mods to add long form explanations of mod mechanics, but it definitely doesn't need to be anything fancy
Actually, I think I would prefer to just have the help button give you a link to the readme/wiki
maintaining in game help would be a lot of extra work to maintain
That also works.
Also might help them find this thread, which would mean more access to info and ability to ask clarifying questions if any arise.
almost perfect
the only reason it's off by 100 is because the pipe segment has an odd number of pipes
Oh right I was gonna get that pump side project thingy
and, thanks to the base game update, these pumps have zero ups overhead compared to normal pumps
in fact they should even be a little bit cheaper
Are they 3x2 footprint?
yep, but I added a mod setting to make them smaller if anyone wants that
they also have a more expensive recipe similar to the one for cranes
(The crane mod also allows for the cranes to be 1x6 or 1x3, instead of the default 2x6 and 2x3.
The 1x setting causes the power demand to double. )
yeah I know, but adding a 1-tall pump would be weird
also it'd mess up the connection graphics
honestly for my stations, having the pumps be 3x2 instead of 1x2 is actually more convenient
since I can power them without having to offset my power poles
I like the lil "hazard" striping outlining the actual footprint. Very good.
yeah I originally used the one from the cranes but after looking at it close it was kinda yucky, so I made a new one
updated version of the pump, requires 2.0.45
this should be the version I put on the mod portal once I'm sure I haven't forgotten anything
also I'd be open to suggestions for a more interesting py recipe
So...
Fancy pump uses "flow scaling"
Where, flow scaling allows the pump to always pump at a known constant rate, even if the pip it's pulling from varies in "fullness"
Which makes it more reliable for the purposes of exact dispensing of fluid?
yep
it means that there's never going to be a variable amount stuck in that input pipe after the wagon target is met
Hmmm.
It still has the potential to have that residue get sucked into the pump to fill the pump's internal buffer?
that is also always going to be the same amount (exactly equal to what's in the pipe)
for a setup where you have one normal pump pumping into the shared pipe (200 per tick in py), the pump will have 200, the shared pipe will have 200, and the perfect pump will have 200
add one extra 200 for 1 tick of combinator delay, and 800 is ALWAYS the correct value for granularity
Hmmmmm.

So if granularity of 800 is just causing the train to wait until 24,200 instead of the nominal 25,000.....
Why does the train just leave on the tick where it hits that number? What's making the train wait for the residue?
a 1 second inactivity condition
Ah. I see.
Has that always been present and I just haven't noticed?
yeah that's always been there for fluids

I will need to make it usable for items as well to properly support loaders
Classic me, not noticing.
classic me for not documenting it anywhere lol
Now, how should I expose the option for the inactivity condition...
I think it only makes sense for providers, and I don't think it needs to be set per item

I only really see it as being useful for fluids and loaders situations, where there might be spare items in a shared conveyance system, where the inactivity condition is used to detect when the residue is all taken care of.
But for items shared through a belt via loader, the lag time it takes for the shared belt to clear will be far longer than the lag time for a shared fluid pipe
Ig either way, inactivity covers it
I can't think of any use cases where I'd want to change the duration of the inactivity condition......
But maybe that's just not something my playstyle would bring up
yeah, I think I'll just make the duration a mod setting
it really doesn't need to be configurable per station I think (other than being turned on or off)
oh right I have to check over the new chinese translation as well
so many things to do, I was only away for a few days
Translation/localization of content at any scale, developer or mod creator, sounds like a lot of work
oh nice, the output from google translate is actually completely correct
when the russian translation was added, there were a lot of words that google translated to completely the wrong thing
even though in russian those words did have other meanings that were mostly correct
nice, don't even have to break out the chinese thesaurus
and everything fits perfectly, russian also had the problem of a lot of the text taking up way more space than there was room for
@storm adder do you think there's still a reason to add the option to skip the cargo check?
I'm thinking no, but if it were added, it could probably just be a mod setting rather than per station
The cargo check when? The waiting condition for waiting at a stop?
no, the one that locks the train if it detects that the wrong thing has been loaded
Ohhhh, uh.
The rest of the system isn't really set up to allow multi-item train trips. But if that was ever to be something the system allows, the check would very much get in the way.
nah multi item trips are explicitly not planned
I very much don't want to think about making sure that certain items are at the same station for the very small chance that occasionally the stars might align and a couple of train trips can be saved
Fair enough.
Outside of that.... there might be some people who might dislike the need of a separate mod for perfect pump, and still want to go with a setup more like what I've got now that relies on temporarily loading the wrong fluid?

If mod-A is gonna have a function, but that function only makes sense if you also have Mod-B, seems sorta odd for Mod-A to not have a workaround for if the player only has A.
Or, just make them the same mod (or make B part of the dependency chain for A)
the thing is the mod is still usable even without the other mod, or a suck it out pipe (that's how I was using it for a long time, just accepting that sometimes trains would be a bit underloaded)
I suppose I most likely will add it as a mod level option, but I don't think I want to make it a per station setting
Mod-level option works
Per-station sounds hard to implement, but ofc i don't actually have any reason for thinking that
mostly it's just a matter of not wanting to add setting to the gui that I don't think anyone should ever use ๐

loaders should now be properly supported for multi providers without needing any extra combinators \o/
Great.
So.
- make indicator setups and sign-posts on a per item/fluid basis
- make a train arrival chime based on signal color
- make skeleton of station status indicators based on train present/en-route (then wait for I/O signals to be available to hook it up)
Nice.
Actually,
Is the implementation of "count of trains en route" gonna include a signal for train in the station?
(The way I'd do this with a normal station is to read train ID, then just look for [ID > 0] to determine if a train is in the station at all)
I mean I wasn't entirely confident about adding the train counts like that at all yet
Oh, totally fine.
(As a blanket statement; I don't want any of my discussion input or suggestions to be construed as expectations. But also, I can't give a disclaimer about that every time. So.)
haha yeah that's fine, don't worry
I'm just not entirely comfortable using up the outputs for what is mostly an aesthetic use case
If I was super pressed for having any given functionality, I could always make my own mod.
Anyways.
Train counts are some ways off, potentially forever away.
So for now, I focus on making indicators of station inventory
not that there's a problem with aesthetics, I just worry that I will really want to use those outputs for something else later
Cos that won't require I/O combinatoes at all
also, for "train in the station", if you aren't worried about the train id, then you could also just check if there is any output of the provide/request comb
it won't count the case where the train is finished and about to leave, but I think that is logically close enough to there being no train
Oh, so very interestingly, in 2.0 they made trains retain their "reservation" in a given stop after they leave, until the train clears the signaling block the station is in.
And while that's happening, the train ID is 0, but the count of trains stays above 0.
So my previous system would show yellow while the train was on the way, green while it's in station, then yellow again for just a little bit while the train left, before going back to other colors
omigosh I know
THAT was the thing that killed my combinator based train system
I ranted about it a lot lmao
Ohhhhhh, that's very unfortunate
it's also completely impossible to keep an accurate sum of trains because of it
since you can't add up train counts from multiple stations
since trains can be at multiple stations at once
of course, if that "feature" wasn't added, SSPP wouldn't exist...
I'm trying to make sure I understand the underlying logic behind train dispatching.
Clearly, the system accounts for a time component, as you have to input max travel time and throughput.
I'd expect that a Pulled item will determine the throughput โข max_telivery_time = T , and start pestering the network for a delivery once it's local inventory is below T.
... do the source stations stations account for time in the other direction? Telling the network they have more than they really do, anticipating the listed throughput will be produced while the train is on the way?
no, they don't
as far as the time component is concerned, provide stations act as though they take up the entire delivery time
so technically the "storage needed" value shown is a bit of an overestimation

sorry those two points were not really related I think ๐
basically, the delivery time is purely used for calculating buffers
Ye. Mostly relevant at the pull stations.
If they're told that:
- shipments bring 20 units, and take 5 seconds
- the station uses 1 item per second
Then the station will start pestering the network for a shipment when local inventory is at or below 5
Right?
yes, exactly
Perfect.
BUT, only from push stations
Yes.
wait no I got that backwards
Sink stations and pull stations function identically, aside from the 1 very important distinction of which provider station type (source or push) they can accept from.
you will also notice that they have different storage needed values
Oh hmmm. So not identically
because pull stations have two different thresholds

at the lower threshold (station needs fewer items) they will only request from push stations
once they cross the higher threshold (station needs more items) they will also request from source stations
How are those 2 different thresholds determined?
the lower threshold is just throughput * latency

the upper threshold is just double that
Yeah, I should problt just pick through the code to answer my own questions
I don't mind answering haha
also push stations work exactly the same but in reverse, they also have two thresholds
ok, train gui crash is fixed!
๐
Latency is... including max train time listed as part of train class?
Or is it separate?
Are they the same thing?
latency is separate from the delivery time
I kinda wanna draw up a graph
or not a graph a diagram
latency is like a fixed extra buffer
Latency is in units of seconds.
Which is used in conjunction with throughput (in units of item/second) to get a value in "items" to use for buffer thresholds.
yeah but they aren't actually the delivery thresholds directly
gimme a sec I'm trying to translate the code into english
Delivery_time is similar. And I'm seeing
m_max(Delivery_size, throughout * Delivery_time)
Which makes sense.
yeah, basically the delivery size provides a floor
That's good to know.
then buffer is always at least stack size
which is why for low throughput stations the storage needed value usually ends up as just delivery_size / stack_size + 2

I think I'm too tired to do numbers right now lol
but I think you have a good idea how it works now, it's not super complicated
No worries. I'll keep picking through and seeing what insights I can glean
apart from compute_storage_needed and compute_buffer, the part where those actually get used is https://github.com/jagoly/SourceSinkPushPull/blob/main/SourceSinkPushPull/scripts/tick.lua#L265 and https://github.com/jagoly/SourceSinkPushPull/blob/main/SourceSinkPushPull/scripts/tick.lua#L328, though those bits of code are a lot less readable
how come you have a bunch of your trains running on cellulose?
(I may be having a stickybeak in your world)
but why not just use the wood
Don't worry about it. It's fiiine

Also, you can see the remnants of my old train system
Man I wish i could have stuck with it.... its so pretty with the lights and the chimes.....
hahaha
The only reason I still have some trains on coke is cos I was too lazy to actually round all the trains up and check their fuel
You may notice, at my exchange stations between old and new system, the refuel station for the SSPP trains is still cellulose
seeing the cellulose everywhere is just really weird to me ๐
because with spoilage on it last five minutes
so every time I see cellulose I think "ugggh, here we go again"
Ohhhhhhhh. With spoilage yeah
I didn't even know it spoiled
Man, I spent so long picking the chime sounds, and they're different per station type so I can easily tell whats going on just by hearing.....

Its fine.
Sadness session over.
New trains. New is better.
I mean, I can add some more stuff!
as long as they aren't needed to be per item
but like, a general status signal would be easy to do
I was also jealous of your small rail blocks
ah yeah, going the opposite direction to me ๐
although I kinda went from "totally uniform main bus" to "totally uniform city blocks" so maybe not quite
my blocks are so big that it's quite a pain when I want to do small builds
I feel compelled to often put unrelated stuff together just to fill the space
Anyways.
My old stations have two somewhat separate systems for indicator lights.
- Is there a train at the station or on the way?
- If no station here or on the way, what's going on with the local inventory?
Where a status to be indicated from point-1 there would inherently override any possible status from point-2
Since SSPP stations are somewhat inherently multi-item, I was planning to more explicitly split those two systems.
By having 1 lamp indicate train scheduling,
And 1 lamp per item/fluid the station deals with, indicating the inventory status of that item.
If "count of trains en-route" ends up being split per item, then I'd also indicate that by having 2 lamps per item/fluid: 1 for inventory status, and 1 for train scheduling status
I guess the main issue is that from a mod design point of view, I think it makes more sense to have all of the status information just part of the station/network guis
It certainly would make my life easier.
And this is a part of my old system i ran into; there's so many different values i want to track and convey per item being dealt with.
And my solution was to encode counts of trains on the way to a station, to the signal for the item, separated by the type of station.
Which is why all my old stations have radars next to them
So if you want a station to display
- count of trains en route for coke
- local inventory of coke
- local surplus/deficit of coke
You quickly run out of ways to convey that without the signal count getting waaaaaaaay out of hand.
but the thing is, the stations already show all of that info
you just have to click on them
Which.... is, sorta fine?
The system surrounding the station can't be made to automatically act upon that information, but it's readable to the player.
I guess the my question is what actions would you want to take with that information if it were available
other than just repeating the same info on nixie tubes or similar
Currently, its mostly just non-function use cases, like repeating the information to a central nixie tube display like you mentioned.....so I'll spare the long description of my past setup that did just that.
That function, which is don't think is purely aesthetic, is something that doesn't need to be facilitated through the I/O combinators.
Lemme brainstorm and do a think on what use cases would need actionable information that would "need" to be facilitated through the I/O at each station
re a central display, I could definitely add a dedicated "network info" entity just for that
There's currently a history tab listed.
Could even just have it be another "summary" tab, where things are listed
how would that differ from the existing items tab (once searching/sorting is added)?
Ngl, the info might already be present in the "items" tab, I'm just not familiar enough with reading it to be able to see it.
I have been thinking about "net throughput" being something I can't really see.
Like, if I have 3 pull stations all set to a throughput of 10 for
, that's a total pull of 30 items/s.
And I'd have to go track down each of those station, note down the throughput i specified, and sum them all to get the total pull throughput.
Then, go do the same for every source for
s, and sum those to get the total source throughput
Then subtract pull from source to get net throughput.
Net throughput specified to/from the network, per item, would be real handy to have on a summary, somewhere. Even if the throughput specifications are only used for calculating buffer size.
yeah that could definitely be useful
I do wonder if that could instead be integrated into the grid view for items
like, a way to have the minimaps for each station show their throughput setting, and a way to have them sort by that
Anyways, actionable IO at stations...
One already implemented example is "what signal and what value is the currently docked train managing?"
The prime use case for which is setting filters on pumps/inserters
well yeah I know about that one ๐
Hmmmmm....
Could any potential I/O be used for recipe setting.........
I'm imagining an un-buffered station, where the station tells the network; I've got [A] and I also have [B]
When, in fact it has neither on hand, but has the ingredients for both.
Its just waiting for the train to show up, so the signal from the train can be used to set recipes to craft whichever between [A] and [B] the train ends up requesting.
Ig that's already possible with the aforementioned "filter signal"

I think that's probably out of scope
but a dedicated network interface could maybe be useful for that, to just read unmet pull demand
although I do have a feeling that if you have items that are so expensive that you need to craft them on demand like that, you probably don't want to put them on trains anyway
(To clarify my stance; I think there aren't any good use cases for IO at each station that would be worth bothering with.
But as an exercise, and to make sure no opportunity gets missed just cos it wasn't thought of, I'm trying to think through possibilities.)
ah yeah, no worries
I am fully open to there being some good use cases I haven't thought of, which is why I was asking
Hmmmm.....
So.
My multi-fluid source station.
Based on the variety inputs, it has an estimated "storage for acetylene required"
That value is ~25k.
I use 30k tanks, and tell the pumps to target exactly 25k, to leave 5k headroom for evac pump system.
For acetylene, "overproducing" isn't really an applicable term.
But I can see fluids further down the road where being able to tell my on-site buffering system "idk how much to buffer here, just put however much into the tank that the station thinks we need" would be highly convenient.
And for that, the provider_I/O would need to constantly be outputting storage estimates per entry.
And then if I get later down the road, and my ability to produce increases, so I increase the listed throughput for that entry at that station, the amount the system will buffer will increase accordingly.
I think that's kind of backwards
like, the station should just buffer enough to support it's maximum it can produce, right?
I've been needing to tell my item inserters how many items to put in the chest.... and it's lowkey kinda annoying to have to mentally think through "well the trains gonna pickup 20 stacks.... and this item stacks to 100... so i should have the inserters stop at like... idk 2.5k? "
or else why did you build that much production if you didn't want it to run
you know you can filter the big py chests?
yeah
No, I did not know that
I actually want to add an option to put the filters into the clipboard at a station and then apply it to a chest
because I get tired of setting the chest filters
if I had to do that with inserters I'd go insane ๐
actually I wonder if I could just use the normal shift click settings copy paste behaviour
So, maybe a niche situation;
- I've got a nearby station that provides
and 
- the chest has been filled with each item until the system has told it to stop, either by disabling the inserters or by only allowing so many valid item slots that are filtered by type.
If I wanna dump off extra items I have in my inventory, I can't easily do that if the chest is hard limited by available slots, cos the inserters just fill them all up and leave no room.
like how you can paste assembling machines on to requester chests
That's why I limit by disabling inserters.
I like having the headroom to put spare items
Not strictly necessary, but it's a situation i find myself in fairly often where some IO off the station would be convenient.
other than just dump the items in a random empty train instead
and let sspp liquidate them automatically
Oh yeah, I was gonna ask.
What's the whole "liquidate" thing about?
basically if a train ends up with items in it unexpectedly, it goes into liquidate mode
where its basically a maximum priority push provider
so if things break, instead of needing you to go and empty the train, it will just sort itself out
the only way to get into liquidate mode is if the train already has items in it when you switch it to automatic
so it won't happen if a station loads the wrong thing
I feel like you already know what my thoughts are......
Sure would be nice to have a general "storage" station..... that acts as a lowest priority sink for any items that either find themselves in trains for liquidation, or to allow push stations to not require a sink station requesting the specific item.
but then what happens with those items
They just get sent to storage.
And if you've setup some re-routing or sorting or processing at the storage site, that works. But, worst case it just get stashed into chests.
Eventually, I'll have logi-bots, and I'd have the storage site unload the trains into purple chests.
So if I'm out, and I find myself with too many belts in my inventory, I can just throw the extra belts into a train, the train will take them back to storage, they'll get put back into the logistics network, and the bots will now have them for whatever down the road.
But I'm not gonna set up sink entries in a station for every possible item I could end up with too many of.....
I suppose technically every depot is that kind of station for dump items at least
it won't accept items from push stations but I strongly think that they shouldn't have storage sinks
since you can just store the items at the place they are created
Eh, fair enough.
You'd rather your plate production back up on byproduct stone and stop producing plates, compared to having a trash heap of garbage somewhere.
I'd rather kick the can down the road, make sure my plates never stop, and deal with the mass storage site of byproduct at some other time (a time when I'm hopefully more equipped to deal with it)
Neither are "incorrect" approaches, but they are mutually exclusive.
ok but for something like stone, you can just build a sink
(You can probly find my trash pile in my save if you looked. I wonder how bad it is, I cleaned it out not too long ago)
you don't need an omni sink
an omni sink only makes sense if you want it store random junk
there are probably less than 10 byproducts total that are produced in quantities that will be that kind of issue
My old train system that has an explicit yellow station for mass storage has some very basic sorting just for stone.
It gets rerouted to a passive provider station, so i can in turn disable my stone mine unless the storage-reroute stone is empty.
And i also have a sink station setup to make bricks out of the stone, to sink them.
I mean that's exactly how the mod is intended to be used
I set up the mass storage so that if I end up with more stone than my sink can handle, or if I just don't feel like setting up a sink at that time, I don't have to stop what im doing just to go deal with a process that backed up because of insufficient sink-capacity.
If I'm in the middle of setting up one process, getting derailed from that to have to go deal with something else right then, is.... unappealing to me, and the sort of player i am.
but surely you just add massive storage to your stone sink
all of the work to route that back to somewhere else later just seems so much more complicated to me
I'm just coming around to moving my moss production to the recipe that uses stone in the recipe.
And I'm very glad to have stone sorted to source stations at storage, rather than having it all sent to the sink where it would be relatively hard to get out (I'd have to go set up sorting to a provider station there, which, I guess I could do?)
ok but again, like, what do you gain from an omni sink here
just to be clear I'm not saying that just stashing in chests isn't a valid thing to do a sinks
I'm just saying that they don't need to be omni sinks
there aren't that many byproducts like that
If i have a general sink for every item at a central location, i can have bots do the sorting once i get them.
And i can then send non-sink things like belts/inserters/assemblers i just happen to have excess of to be sorted back into the logistics system
End goal is to have my storage and my mall be very close to each other.
If a liquidate item without a sink setup explicitly for it will get taken to a depot, then I have to put all my depots centrally instead, which means i can't spread them out for even coverage.
fwiw you gain nothing from spreading out depots
trains aren't picked based on distance

Yeah... you're right.....
Ig ill just setup unloading at the depots then
For any liquidation
there is one issue still
liquidation doesn't trigger for items that aren't on the network at all
it will just re-lock the train
Oh. So, I can't just toss spare belts into a train to banish them back to my mall for redistribution later.
So, I'll just have to setup an array of stations and reserve the lowest prio sink mode to be for storage, and setup an entry for various items in the network as the need arises.
SSPP is flexible enough that it implicitly allows for my use case of an omni-storage site, even if not explicitly enabling a station to be check-boxed as "send any extra items here"
Also frees me up to place depots all around the factory to act as trash cans.
I've spent the past 4 hours in the lab trying to get combinator magic to work
uh oh
it's fine, i'll figure it out.
it's for automall stuff, not trains
ah yeah I saw that crazy thing
is that one you made from scratch or is it based on that one in the py discord?
i made it from scratch
daaaang
I kinda wanna see it in action
I've never made an automall
in fact I'm pretty terrible at bothering to make malls at all lmao
I've only just started setting up a mall at all and it's just a standard bot mall
this is what it looks like when i can use bots
it's really not too bad.
- make a list of things you want
- compare that list to things you have
- pick the thing you're most deficient in
- put that in memory, and dont change memory until the clock loops
- set requests at the blue chests for the ingredients of the set recipe, which can be read from the assembler
I'd be super terrified I'd make a mistake and accidentally craft 2000 tailings ponds or something
im addressing the problem where it changes recipe on a timer, which is very bad, cos it often vastly overshoots the targets,
especially for things with small ingredients lists and short craft times. which thankfully, tend to be things that arent a problem if you overproduce
but i just know pY is gonna thow me a curveball, and it's gonna be a problem
can it handle different crafting machines? like can some recipes use assembling machines and other recipes use some other machine
yep, just make space for it where the assembler would be
thats for a foundry footprint, but ofc pY doesnt have the foundry model
does the CC just have a list of the things this machine should craft?
this is technically the same machine.
it's just 3 of the amalgamated onto a central hub where the ingredients are, instead of getting ingredients from a blue chests.
and the outputs have to be put onto belts to be re-routed into the storage, instead of purple chests for the bots to handle. .
ngl the giant sushi belt was my favourite part
the CC holds the list of things to craft.
it does require that any intermediaries be requested in amounts HIGHER than the amounts of the items the intermediaries are used in
like, i have to request more iron sticks than bolts, and i have to request more bolts than small parts.
oh interesting, you have to input the counts
couldn't you use the selecter combinator to figure out the counts?
the intermediary thing is another part im trying to address
or would that be a crapload of extra logic
I do have to ask though, is the footprint of all of this actually less than just having 5 assemblers ๐
I suppose it's more useful for things like machines where you can have like 30 different machines on the same crafter
current plan is to not change much.
- i just want the recipe to be made to change from counting crafting cycles, instead of counting ticks on a looping clock.
- with a catch for ingredient inserter inactivity, to allow recipe changing when i dont have ingredients for something anyways
- i want to set the ingredient inserters to be limited earlier than the auto-insertion limit the game generates
- i want to pass the ingredients for the top-level assembler down to the next level down, so those ingredients can be added to the list for the next level down
and yes, i think this sort of setup is WELL worth. it's generally not just replacing 5 assemblers, it's replacing an entire mall.
even in vanilla, the count of assemblers to actually make every item you could want with assemblers that have static recipes, it's a lot of assemblers. for pY, it's even more worthwhile
I think I'm weird in that I actually like handcrafting shitloads of machines haha
I have a routine where I just count up all of the ingredients for a whole build, collect them and then craft them all at once
yeah, at py1 where im at, it's definitely a worse solution than just handcrafting
way more finicky, and far slower
the real use case is once i get decent construction bots and coverage, and i can just.... "here's a list, craft the things on the list, then build this blueprint"
without any further input from me.
yeah I hope to have something like that at some point, though I'm probably not going to share crafting machines
do you do a global logistics network?
I've opted to do global construction this time but not logistics
so I can have little per-block logistics networks
i plan to keep the logistics area very small, but have large construction area via construction range extenders
I hacked my zone extenders to have a really small connection distance
small logistics areas are great, so your logi-bots dont try and follow you (a moving target) around all day.
but construction bots going to build stationary targets, they can fly as far as they want. they'll build it eventually.
Train system has been working unbelievably well.
I did end up forgoing the "sushi pipe" for the 1 multi-fluid provider station i have set up. And never got around to figuring out the fancy pump mod.
I'm also running into a situation where I keep running through items at a pull station, before a resupply deliver can get in, and thus the site stalls due to lack of ingredients.
Its Native Flora.
Arguably I shouldn't be trying to ship it via trains, and yet....
I upped the "deliver time" system wide, and I keep upping the latency, and that seemed to help up to a point.
Any idea why? Assuming SSPP is working properly, the only ways that should happen are if:
- the station consumes items significantly faster than the specified throughput
- there's a lack of provider throughput
- deliveries take a lot longer than the specified time
so, you should be able to narrow down exactly which one of those is the case and then adjust that
upping latency is usually not a good solution, except if the issue is that your demand or supply is very spiky
also flora is definitely worth shipping on trains
I have spoiling flora and I still ship it on trains ๐
Stack size of 50, and multiple sites pulling full yellow belts of flora..... its.... a lot.
I've got 4 belts off the flora patch, loaded with like 72 red inserters into warehouses, and then 2 sided loading into wagons from those warehouses..... so i don't think the issue is the source station having issues being a source.
have you checked the history tab to see how long deliveries are taking?
Oh right, that's a thing.
I'll take a look when I get home today
Is it cos I don't have enough trains in the system? That's something I wasn't paying a ton of attention to....
Could be the culprit
yeah that too, you can check that in the classes tab
if the available trains ever drops to zero you probably want to add more
have you been having any issues like this one https://mods.factorio.com/mod/SourceSinkPushPull/discussion/6808c0e76436488ec8dadf75 ?
I should setup an alarm to notify me if I have no trains in depots for too long of a time
Nope, never had any issues with copied/blueprinted stations not pasting properly.
If anything, it's "too good" at remembering its settings, and I can't remove items from the ghost-station configuration before the station gets built and dispatches a train for the wrong item ๐
lmao yeah making the stations configurable as ghosts at all was a lot of work
but because 99% of my actual play of the mod so far has been in the editor bugs keep sneaking in without me noticing
I haven't noticed any anomalous or "buggy" behavior in my time, since that one time I crashed a few times cos I was on an old version.
Hi. I just joined the channel.
re: the blueprint problem (that's my report), I'm wondering if I'm stressing it out by the size of the blueprint that I'm pasting.
My FPS/UPS is still up near 60, but the blueprints often cover more than a screenful at a time. Is that a problem?
I wouldn't expect total blueprint size to be the problem..... but maybe?
I think it's only ghosted a station four or five times since I started playing six months ago, so it's rare. It could be something weird that I did, that someone who is more familiar with the game wouldn't do in the same way.
Not a game-breaker. The benefits far outweigh any confusion that it causes, though I still don't understand the way that the demand and supply calculations work ๐
Hello, glad you finally joined the discord ๐
I'll have a look into that issue today. I did a quick test before I went to bed in my world and everything seemed to work fine, so I'll have to try your world
Though I did just have a thought that maybe its related to pasting a BP with more than one station in it
Why is the name of this train stop "depot"?
@peak sluice
the one that is crashing
did you name it that or is the game being weird with names again
That's my name but it is an interesting point. All my SSPP depots are scattered across the map (to reduce the bottlenecks).
The problem might be because I tried to paste an SSPP train stop over the top of an existing vanilla one?
Or rather the other way around
oh wait no you mean there was a depot here before?
Yes
I'll try it, now
it looks like it is
won't let you normal paste, but if you force build, it will
but instead of destroying the vanilla stop ghost and then making an SSPP stop ghost, it just "converts" it
I'm lazy, so I tend to force it without because of the trees and things.
which ends up not giving me the events I need to set things up
well at least I know what caused the problem, now to see how I can work around it...
wait a sec for me to check it. I'm running across the map at the moment ...
I love it when that happens!
I'll still have to go over your other issue with built stations sometimes still acting like ghosts
The "crash when clicking on it" one?
I'm glad you were here to ask about that depot lol, I would have wasted at least half an hour looking in the wrong place otherwise
no that's fixed
the one where you had a station just not doing anything
oh, found the issue, was a dumb refactoring mistake
I changed a function from being called twice to having a loop inside of it
but that function was early outing with returns.... so the second iteration wasn't running
so if your bots decided to build the rail next to the stop after all of the other parts, then no station would be created 50% of the time
OK, great. It's nice when it's something deterministic. I was afraid it might be a timing thing. I usually play when my machine is busy running test cycles and stuff, so my CPU is spiking a lot.
thankfully, factorio is by design fully deterministic for multiplayer reasons
I'm glad that my build logic does seem like it's actually sound (sans silly mistakes), I really don't want to rewrite it again
Isn't there a standard framework for building mods?
I mean there's the modding API, but I'm not aware of any libraries for managing multi-entity constructs like SSPP stations
Oh, wow. You like a challenge, then!
of course, I'm a factorio player

i've hit the 10 entry limit for requesting
(also, yikes, what is that station layout? i allowed myself to screengrab that and share it on the internet?? )
hmmmmmmmmmmmmmmmmmm
at one point i had the station taking in Tin plates as well, you can see the inserters set to that filter
must've changed the request entry
can you easily put another station right above that one?
yeah, im just gonna squeeze anothe one in
as in on the same track, just dump a second stop (with combs) right above
if it's only for requests yeah
and it is
(I know it's cursed, but I feel it fits in with the rest of that station :D)
man I haven't gotten to actually play the game in nearly a month

I was in the middle of rebuilding my mall/random bio junk like cdna
man when I finally finish this table rework/filtering stuff I'm gonna have to look into working around the limit aren't I
eh, this is only because I'm trying to shove everything into the same station, which is only reasonable because I'm building unreasoably small
like this setup for automation science, the footprint just ends up larger and more expansive, so there's more perimeter along which to place stations
why so many chain signals?
cos stacker is that 3-lane parallel before the u turn, and i want any waiting trains to not block the through line between the 4 stations
so, make everything chains, and they'll wait in the stacker
Oh! I never looked at my flora problem. I did double my train count and now have a ton waiting in depots, but also wasn't paying any attention to if that solved the issue
And now it's 04:40....

classic py gameplay
I don't even have a use case for properly automating cDNA.
I just know it's used in initializing a lot of the AL animals, and so I'm getting a stockpile rolling
my cdna is still semi handfed
Ooh, sushi
Sushi in 2.0 is glorious.
Hi.
I'm still getting confused by the way that it selects the stations that it will feed. I have about 30 stations that want copper sheets and about 20 resource fields that are creating them (i.e. mine + smelt).
SSPP always seems to pick the same two or three demanding stations and ignores the other ~27 of them.
Why is that?
Are all of your depots at (roughly) the same place?
No. There are a few groups. Top left of my base is being fed and bottom right is not. The rails from the mines tend to come in near the top-left.
Does it pick the nearest one, then?
I believe that if you have multiple trains that could potentially fill an order , the system just picks a random train from the ones that are available.
And then, after that, the train will route to the closest destination that has the item, relative to its departure point.
I'd bet that the 1 or 2 source sites that are getting hit over and over, also are the closest to your depots.
My depots are all over the base, but the demand stations that are being fed from the mines are the nearest
You got a screenshot? Even zoomed out would help make sure we're talking about the same thing.
sure, just a sec
(Also, "closest" is whatever the pathfinding algorithm determines, which takes into account more than only length directly along track. It also accounts for if signals are closed along a path, or if stations are present on a path, and other things as well (this pathfinding algorithm is a baseline part of the game, not a part of sspp))
The base is a big grid of tracks, I'm playing this game without a bot mall - only using logistic bots to fill the personal bag. Depots are spread all over the base in places where I don't need it for a resource station.
This helps me minimise the bottlenecks when you have 100-odd trains all trying to do the job of a logistics bot.
most of the copper is coming in from the top because I've mined the southern copper out at the moment.
So first let's make a distinction;
As far as the pathfinind is concerned, comparing [1->A] vs [1->B] is functionally identical to comparing [X->A] vs [X->B]
Since anything coming from up north must go through X, that means the entire north branch can be simply represented by X.
agreed
This is why I mentioned the nuance of the pathfinding algorithm.
When a train gets dispatched from the depot to the source, that's fine it'll just pick whatever source.
Then when pathfinding looks at [X->A], it's reliably determining that is a shorter path than [X->B]
Even tho B might literally be spatially closer, I'd imagine you probly have a bunch of trains active in that grid there. That traffic is gonna mean red lights between X and B, which the pathfinding interprets as extra "distance"
And by the time the route to B is sent around all that extra distance, the train figures "wait a minute, A is actually closer, so I'll just go to A."
Is there a reason why it doesn't choose a round-robin to decide which station has priority and only then pick the best route to that one?
Are A and B not set to the same priority level for their pulled item?
Yes, but that won't help, because there are only two or three priorities. I need more than 30 ๐
In my mind, I expected it to service them all using some sort of priority based on the requested throughput
Also to clarify;
You've got production at 1 through 4
And consumption at A and B.
And the total production at 1-4 is less than the total consumption capacity of A + B
(Might be an obvious question, just double checking)
Hang on a sec. I misread your comment, let me run back and check the priorities
If A is set to "pull high priority" and B is set to just "pull", then that'd explain the observed behavior for sure.
My production and consumption are more-or-less equal at P=186k/m and C=183k/m. They move around a bit but they are around the same amount all the time. I've been trying to keep things in balance.
You also can set how "pull-ey" A and B are dynamically, using that setting for the operation modes at A and B.
I haven't done much with the dynamic mode, I just know there's button for it, and signals present for it.
Jagoly would know more about the details, or if it even is a fully functioning feature at all.
It's finally filled B, after nearly an hour
And i presume that A is too full to have possibly accepted the shipment?
and all the priorities are the same
It (A) might have been full. It's making copper cable. so it empties fast
With static priorities, and all of your Sources being located how they are relative to the Pulls (the whole "through X thing), you're gonna have A get "first dibs" on shipments, and only overflow will make it to B.
Dynamic prio will solve it, I think.
Like, don't let A get entirely full before you overflow.
Once A gets to half, set it's priority low
And if B is empty, set it's priority High.
I haven't ever looked at dynamic priority. Would I need to implement my own round-robin thing?
The orange-looking symbols shaped like the parameters signals: those are the signals you feed back into the I/O combinators at the station to dynamically set the operating mode.
OK, but that is going to get very tangled. There are nearly 30 stations that I will need to manage.
I think I may have reached the limit of what is possible! ๐
The type of player i am, I generally don't approach this problem in the way you do, so it's unfamiliar territory for me.
My gut reaction is to just say... let A get first dibs, that's fine.
As long as I don't have product waiting at 1-4 that's preventing more product from being mined and smelted, then we're good to go.
Production limited vs consumption limited.
Every factory is gonna be one of those 2. And I generally prefer to be Production limited.
The resource limits (production or consumption) are part of the game - that's fine. I wonder, though, if it might be a good idea to change things so that it has a priority queue that serves all stations and rations them according to their requested throughput.
Like an overloaded PC - it slows down when you run too many demanding tasks, but makes sure that they all get an appropriate share of the available resource. Sending everything to the nearest one feels odd to me.
For vanilla, it's priority (set between 0 and 255) then distance.
Which is incredibly simple and computational inexpensive, compared to keeping a list of all the stations, and what order they should be serviced in.
That's my bet on why it's set up that way
That's interesting; I had assumed that the destination was being chosen by SSPP, not by the game.
It might be?
I didn't write the code, so idk for sure.
Who knows, maybe jagoly will pop in and say it'd be easy to change how SSPP picks stations .

Yes.
I'd be surprised if it was a significant workload, as the destination probably doesn't change on every update cycle (like the route can). But, it's getting late, so I'm going to bed. I need to be up in five hours!
Many thanks for the chat!
So uh
Distance between things is NEVER considered at all
Even distribution is always prioritised, both for providers and requesters
If your providers all provide at the same rate, they should all get chosen roughly equaly
Same for requesters
That should be exactly how it works
Push graphite?
ah
that's why
i copied a previous entry at the station, and didnt change it's operation mode
The copy button, a double edged sword
good thing i didnt set up storage for graphite 
It is, the only time SSPP lets the game pick destinations is when sending to a depot or fueler
I'll have to have another look at your save. The mod SHOULD behave exactly as you seem to want it to, so either something is configured wrong or there is a bug
Basically, stations are picked with weighted random sampling
If requester A has a deficit of 1 shipment of copper, and requester B has a deficit of 2 shipments, and they both have the same mode (priority), then when a shipment becomes available, it has a 33% chance of going to A, and a 66% chance of going to B
This has the advantage over true round robin of statisticly better distribution that accounts for stations real usage, at the cost of being a bit random
But the randomness becomes less of an issue the more deliveries are made
OK, thank you for clarifying that. I think that it explains what I see, but I am not sure if it's going to work well when the factory gets large.
Some of my stations (e.g. copper cable) will exhaust their inputs much faster than others (e.g. low density structure). So the incoming copper plate will always go to the copper cable assemblers, and the low density will be starved. This wasn't a problem in the early game, because all of my stations were slow and the trains could fill them with a single delivery, keeping the deficit below the delivery size for long enough for the next delivery to bypass the cable station.
Now that the base is large, and the cable assemblers are much faster (6.7k/s), this tactic won't work. The trains cannot feed it fast enough when they are supplying from so far away.
Are you sure? I think it explains why all of the copper goes to the fast consumers.
Here's the latest save:
https://drive.google.com/file/d/1sVSk6rZCCFRuu1Fv5-RVma6q-05ISAJ8/view?usp=sharing
I would think the copper mostly going to fast consumers would be desirable
If the issue is train throughput, you really just want to add waiting areas
If the bottleneck is train travel, then adding a waiting space can double throughput
A fast consumer needs a lot of the input but it should not be allowed to starve the others completely. They need to get serviced at a minimum rate.
Can you explain what you mean by a waiting space?
They should get serviced at a minimum rate, given enough time for probability to do its thing
A waiting space would be room at your stations for a second train behind the first one
That time appears to be a few hours, based on what I saw last night. It needs a minimum probability, not a simple value
So that train limit can be set to 2
They have a train imit of 2
I guess, do you actually have enough copper
Is the issue that you just don't have enough providers, or that deliveries are too slow
If copper production is low, enough that both A and B are functionally empty every time a new shipment becomes available, then wouldn't they get split evenly? Very odd that the observed behavior is that A gets it all.
I think that A is actually several stations
Not at the moment, because I've recently doubled the map size.
A is several stations
I don't expect B to get serviced at the same rate as A. But I think there should be a minimum supply in the algorithm.
That'd be really hard to do in a way that would suit everyone
OK
Can the priority of the lds just be increased until you fix supply issues?
Because all of this amounts to how the mod should behave when there is an imbalance in providers and requesters, so it is going to be arbitary
I'm sure that I can sort it out manually, but I felt that the mod could benefit from an "end stop" for when the map gets out of balance?
If you really wanted some kind of "minimum supply" for a particular station, that seems like a good use case for dynamic mode. If the station hasn't gotten a delivery in some time, increase the priority until it gets one
A latch and a clock
Just to be clear I still don't quite see why you'd do that over just building more supply
I definitely need to build more supply, but I'd like my base to be better behaved when it hits the edge cases. I'll play with dynamic priority.
actually another option, just increase the buffer size at the LDS by increasing latency
that way it will request a bigger stockpile and thus get a bigger share of limited supply
that's kind of what latency is for, making weird little adjustments without affect the system as a whole
also to be clear I am open to changing the way that low supply situations are handled, the way SSPP does things in this regard is different to other mods (IMO better, but different)
in CS for example, the system uses a very simple round robin system, meaning in low supply all requesters are serviced equally (even if one station needs 10x as many items)
I still don't really understand what each of the parameters actually controls and what happens when I change them. ๐ฆ
Also, to be clear, I do like SSPP a lot. I never got this far with other mods. They would fail before my base got anywhere near 6000x6000. So, this is interesting to me, I'm not complaining ๐
oh don't worry, complain away, you've done more good for the mod with all of your bug reporting than anyone other than me at this point ๐
๐
Yay bug reports
seeing your base does make me want to figure out a way to have trains gets picked based on distance though
I feel kinda bad seeing you distribute your depots all around but knowing that actually trains are just picked randomly
it just gets really expensive really fast having to calculate and sort the distance of 100+ different trains
It's a super tough problem to solve.
Especially if you try and account for round trip distances, not just the closest train for the 1st leg of the trip
nah it'd only ever be the first bit that matters
I don't want distance between stations to ever be accounted for
because I want the system to work correctly without having to think about that (I like just putting blocks wherever, without having to worry about distance)
so I want things to work correctly even if I randomly put my blocks in the worst possible spots
I don't think you need to worry about distance. You can't solve all of the problems all of the time. I think a simple minimum supply would be fine. Just make it quicker than a few hours ๐

From just a math standpoint, I wonder if there's proper math works done on variance between trip lengths, given spatial distribution of points in the network, and possible routes between, for different "strategies" of dispatches.
I'll look into that
For my own sake and curiosity
a great deal of work has been done in that regard for real life logistics actually
though not all of it translates to factorio
haha, this save has gone from like 70mb to 400mb
I am testing the limits ๐
it is much appreciated, a large scale vanilla-ish base looks VERY different to a py base
what's a py base?
pyanodon's
OK
lots more individual items, but most items only have one or two sources
I haven't tried that, yet
and the total throughput of most items is a lot lower
I'm going to start a new game and experiment with the latch and clock -> dynamic priority thing
lemme know how it goes! it's definitely not the first thing I'd try (I think just increasing the stockpile at LDS would be best), but factorio is all about trying different solutions to problems
plus any use of dynamic mode is cool, so far the only thing I've actually used it for is shutting off requests for spoilable items completely
I also really need to set up a wiki
A wiki would be really helpful
I just need to get important feature work done so I can finally focus on documentation (and a tutorial video)
Is there any chance of an update to SSPP with those other problems fixed?
yeah I should probably do one
I'm in the middle of a pretty big rewrite of the gui tables but that's taking a long time, should do a bugfix release in the mean time
try upping the latency to 600 here
that's basically telling SSPP to keep 10 minutes worth of items in stockpile
it also means that the deficit of this station is now trippled, so it should get 3x as much of the limited supply
OK
Yes, I froze it last night
ah cool yeah I figured it was just for troubleshooting
oh yeah
there is also one other reason that distribution might not be even
if a station is at it's train limit, it won't get it's share of items
it will block lower priority stations from getting items until it does, but not same priority stations
OK
so what was th problem item again? it was copper plates right?
because as far as I can tell there's no issue with copper plates
Yes. The stations at the top-left making copper cable were hogging all of the supply
it seems like you have plenty of spare copper
also I don't know if you have framerate issues, but you might want to increase this setting
it'll make SSPP generally more responsive
The base you're now looking at is my reaction to a problem I thought I saw before. You have to disable the suppliers to see the problem that I encountered.
I keep my FPS/UPS near 60
What's a good setting for the stations per tick on a base that large? 20?
as high as you can set it without having ups problems
ok
the UPS cost of the mod should be mostly constant regardless of the size of the base, but the more stations you have the more ticks it will take to process everything
apparently I put a cap of 8 on the setting for some reason...
I guess I must have been worried people would set it to 100 and then complain their game was lagging
I know that fear ๐
anyway I think I'm just gonna assume that there wasn't any kind of actionable bug with item low supply distribution, just a mismatch with expected vs actual behaviour
I THINK the mod should already provide the tools to deal with the problem, they're just not quite obvious
Let's put it down to user-ignorance, which will hopefully be solved by the wiki.
bugfix release is up
should fix all of the current bugs except for jobs not getting cleaned up for items assigned to the wrong class (https://mods.factorio.com/mod/SourceSinkPushPull/discussion/6804f3e825f2185e0c75e57c)
that'll come when the table rework is done (hopefully it'll make things more robust in general)
Hello everyone,
can you help me understand how to configure a network to transport objects? My train stays at the depot and does not leave. Below I have put some screenshots of what I did. Thank you very much
no worries! firstly, change the mode at the requester to mode 5 (pull)
for deliveries to be made, either the provider needs to be set to "push", or the requester needs to be set to "pull"
It's similar to how logistics chests work in the base game. "source" modes are like passive provider chests, "push" modes are like active provider chests, "sink" modes are like storage chests, and "pull" modes are like requester chests
let me know of if that got a delivery going, then I can explain some of the other settings if you want (the numbers you've put in are a bit odd, but that might be because you were just trying to get things working at all)
Wow so many new people
Okay, grapgh theory and distance based dispatch.
- trips have 3 stations and 2 legs, 3 if you require return to depot after delivery
- depot -> source, source -> pull, pull -> depot
- the only leg/stations to be considered is the initial depot, and the source; when a job is to be assigned, assign it to the train that's closest to the source.
I'm picking through the mod code to try and figure out how it works currently.
currently it just picks a random train, the only prioritisation it does is it prefers trains that have made it back to the depot, before picking a train still on it's way
the only optimisation that can be done there is like you said, preferring closer trains
that's pretty much it
Ye. Close trains, only for the 1st leg of the job.
So, when I was trying to get my vanilla system to do this, I was thinking along the lines of storing a list of measured travel times.
- have a "pace train" who's only job is to loop around between all pairs of Sources (S) and Depots (D), On repeat, with detection set up to measure travel times.
- keep a list of travel times, where old travel times for a given D->S pair are overwritten as the pace train
- use that list of travel times for dispatch purposes.
It seemed appealing because of the lack of needing to do all the processing for "how far are things?" At the time_step when a train is to be assigned a job.
Instead, the list is already pre-fabricated; when S(i) is picked as the source for a job, the system would already know, in order, which D's are closest.
you're also missing that trains in SSPP don't have to go back to the depot at all
And SSPP already has a feature where practical travel times are recorded, for the "history" tab to see past jobs and how long they took.
Maybe this is a useful line of thought?
if you wanted to pick the closest one, most of the time that's not going to be at a depot at all
if I just needed to match depots to providers, that'd be easy
since that can be cached
ye. I'm aware.
I'm doing the problem solving strategy of first considering an easy version of the problem, to see where that leads me.
So.
If trains were reliably at depots, it'd be easy to find closest train to source. That's good to know.
And SSPP does have a toggle for "force return to depot", for instances where you have refueling done at depots, and no fueling stops.
mostly that option is for people with bad double headed networks

if they aren't signalled properly trains can get stuck turning around
Heh, that's funny
the game does actually have an api for getting the rail pathfinding distance from one point to another
the same value the game uses to determine closest, better than just using length(a - b)
but it's too slow to call 100 times a tick
- Forcing-depot would make distance-dispatch easy, but it also forces the final leg of every job.
- best use case would be for factories where all depots are spread evenly throughout the factory. So those "last legs" of jobs get short and less of a problem.
- Not forcing-depot eliminates a lot of last-legs from jobs, but makes distance accounting very complicated.
- best use case is for factories where depots are centralized, and last-legs are potentially very costly. Centralized depots also make the gains of distance-dispatch less appealing.
Hmm.
I wouldn't imagine you'd want your mod, on purpose or accident, to heavily nudge people towards either strategy of "spread out depots" or "centralized depots"
actually my goal is more along the lines of "make things work reliably regardless of where depots are"
For sure. Makes sense
that's why delivery time exists as a setting - if you set all of the station settings right, and you keep deliveries under that time, it doesn't matter if a delivery has to use a train on the opposite side of the base
though this is more relevent for matching providers with requesters, because there it actually matters
for more than just how long the delivery takes
the fact that it makes picking the closest train also not really matter is just a nice side effect
on this note, even just caching distance between stations is a lot of memory use
storing big arrays of data like that in lua is not great
and you have to rebuild it whenever the rail network changes
For my vanilla system, the goal was to take sections of the factory, for example a clump of 4 city blocks that have 12 stations between them, and represent those 12 stations with a single "waypoint" station.
The 12 stations aren't techincally at the same exact location, but practically speaking they're all close enough.
Which would cut down on the array size by a lot.
that's a lot of new concepts to introduce for what most likely amounts to not actually improving worst case delivery time
fair enough, I suppose
I could probably add simple sorting of trains with as the crow flies distance
that's still not great to calculate for every delivery, but it's not infeasable
the issue is I don't think it's good to rely on anyway
since sometimes there won't be a train nearby
so your settings should be set to handle that case nicely anyway
having things be handled reliably is definitely the primary goal.
Where, "reliably" means that if you have sufficient supply of items to sources, and sufficient trains in the network to handle jobs, your pull stations can ALWAYS dispense their stated throughput of items.
also, the mod has bufferless mode for providers which eliminates the travel time entirely
which should be used for items that are so high throughput where that matters anyway
also on this note, the train travel time is rarely ever going to be the actual bottleneck
the stations actually making the items is
Beyond reliably functioning, I'm seeing the possibility of potentially very long first-legs of jobs, which just feels wasteful from a fuel perspective.
It also creates more train traffic, which means higher max-delivery-time settings to ensure reliability.
which might be me worrying about small peanuts.
Just cos i feel like it's a problem, doesn't mean it is.
I don't think train fuel usage should ever be a concern, congestion yes but not fuel
Perhaps....
but most of the time congestion happens AT stations anyway, unless you are using really bad intersections or something
so the distance doesn't really matter
that's kinda what I meant about a lot of the real life stuff not translating to factorio
in real life fuel and moving trains is expensive
in factorio you can have as many trains as you want as long as you don't have congestion issues
I've spent the last like 3 hours at work, making a spreadsheet to simulate the distance stuff we'd been talking about.
Mostly cos it's good practice for spreadsheets. I'll spare the results cos I doubt they're relevant, but if anyone is interested feel free to ask.
If only we could nest threads. Maybe someday.
Anyways, I should figure out dynamic mode switching, in case that becomes relevant. Omw home to take a look into that.
You just... pass the relevant IO combinator the signal type for the operating mode?
oh!
the icons for the signals are representing the index of what entry in the station it is.
then, the value of the signal is the mode.
i was thinking the signal itself was representing the operating mode, like "SSPP signal 2" was for setting an operating mode of 2.
okay cool, 10 signals lines up with the limit of 10 entries per station
i could see how you could use that, in conjunction with radars for broadcasting counts, to make a strict priority list of stations.
should changing the name of a class with trains assigned to it automatically change the class for all assigned trains?
the current behaviour is to just shut down every train in the class (they all keep the old name)
actually nevermind, not as simple to do as I was thinking. maybe later.
Even though it's an deprecated question, my answer is "yes" - the trains should stay in the class, even if the name changes. Using the name to effect a "hidden" change in behaviour might be confusing.
Using the name to group equivalent trains is OK, but I don't like the idea of using it to control what cargo it carries, for example.
the potentially confusing thing is that changing all of the trains IS a hidden change
I think I should be able to make it work though
Odd. I don't see it that way. I think that the name identifies the train group but the class controls the group's behaviour. Changing the name should not change the class, it should only give it a different label. Like renaming a product doesn't change what that product is and how it works.
Yeah that makes sense. Think I'm just too used to how it works internally haha.
I've been thinking about the help text for latency, because I didn't understand what it did until your comment that I should set it to 600. I think pretty slowly sometimes, so I apologise for the delay, but what do you think about changing the help text to say this:
"Keep enough in storage to provide items/fluid for this many seconds between deliveries"
?
I'm trying to approach it from the point of view of the player, rather than the mod.
Yeah the description for latency is pretty bad
That suggested description isn't quite accurate though
latency is more like extra time before a delivery is even started
if everything is able to run at full speed (no issues with supply or whatever) then latency doesn't matter, but it adds extra "wiggle room"
mostly the reason the description is still bad is I can't come up with a better one that isn't a whole paragraph ๐
@peak sluice I've still been using one of your saves for testing because it stresses the gui code well, but I accidentally loaded it up with no mods
why did you have like 10000 modules in your inventory XD
lol. That was because I forgot to connect the storage circuit, so it just kept going ๐
I can't think of a good way to explain the latency, either. But your comment here gave me a much more helpful way of grokking it.
Is it possible to read the granularity from the hand size of the inserter that is connected to the receive I/O? It's quite a lot of work to go through and update them all, every time I do new research.
technically possible yeah, but not sure if its a good idea. I kind of would like avoid the rabit hole that is actually tracking the layout of stations
I was thinking about adding some utility commands for making network-wide changes though
something like /sspp-update-granularity [old_value] [new_value]
That might work, as all the stations tend to follow the same pattern
it hasn't been an issue for me yet though since I use cranes, which I just limit them to 250 because I don't care if research makes them go from 250 to 251
but it is a problem for regular inserters definitely
I haven't tried cranes, yet
@peak sluice made that command
I don't know how long it'll be till I do a new release, but if you replace scripts/cmds.lua in SSPP's mod zip with that file, you can use it now if it'll save you some time
thank you!
one caveat, this won't update ghosts
OK
I'll probably add a flag to the command to have it do so for the actual release though. Or maybe just have it also affect ghosts.
That's not a problem. I updated the blueprint, so I'm only interested in existing stops
Yeah I was gonna say that also for updating ghosts it still wouldn't update blueprints
I wouldn't expect it to
I think logically it should still update in-world ghosts though, since from the player's perspective those are still "stations"
That makes sense
It's unusual in my case for a station to stay as a ghost if we're talking about the time-scales of doing new research.
How do I set up the settings for dual stations like this one? As in, will for example 2 trains get sent here to deposit things even though only one would be enough to fullfill request?
And for supply stations that are like this, will the available resources be counted twice if they are connected to the same storage tanks?
there isn't any built in support for sharing storage between stations like that
well you can share storage, but if both stations request the same resource like this then indeed demand will be double counted
the easiest solution for this case specifically is to just split the tanks into two groups
I assume the reason you are doing multiple stations like this is because you're bottlenecked by the pumps?
another solution if you really do want to share storage would be adding a constant combinator with 1 delivery's worth of oil fed into only one of the stations
so that only one of the stations can request the "last bit"
but yeah if you aren't actually bottlenecked by the pumps then just doing seperate stations is simpler ๐
I'll just leave it like this, not too big of a deal to have one train waiting to get unloaded there
That's much better ๐
took the time to reply to the exact message lol
Yeah, Discord is annoying about that, when there are successive messages
glad it works anyway! now to make some more multi providers ๐
I can't remember which one it was, though I do remember trying it out to see if it works
Re: latency tooltip
"Max delivery time" when declaring items in the network, makes a lot of sense to me.
Then, in turn, I considered "latency" to be a local ammendment to "delivery time" for a specific item at a specific station. If you need to tune buffer targets locally, you can use latency. If you need to globally adjust buffer targets, you change delivery time.
that is exactly what it is for, though it isn't implemented internally as just adding to delivery time, formula wise

I suppose it is mostly just an addition to delivery time
only difference is it also scales the gap between push/pull and source/sink deliveries, wheras delivery size doesn't
I do know I encountered a "problem" where I determined i wanted to increase delivery time for all items, as my network was growing quite quickly.
But when I did that, I found that I also needed to go around and put more tanks down for fluids, cos the trains were trying to keep a 50k unit buffer at stations that only had 30k of tank capacity.
Going around and fixing every station was rough, specifically because there was no way for the stations to "know" how much storage capacity they had, so they couldn't kick back an error for "insufficient storage for buffer target"
Wasn't too big a deal to just manually check every station. But i did find myself wanting for a field to enter "how much storage space does this station have for this item"
I kind of have an idea in my head of a kind of "wizard" you can run through when you want to make changes to a whole bunch of stations
like you would say "I want to check all stations for item X"
Would be nice.
I have like... 50 or so entries in my "items/fluids" tab, and it didn't take too long to just tab through all their delivery times to change 60 to 120.
then you could go through each one, make changes if needed, then mark it as done
this would be more about making changes to the stations themselves
like adding more storage or changing filters/inserter conditions
That would be nice.
Ofc the system can't place more tanks/chests and wire them up, but getting a list of "here's the stations that are gonna need more hardware" would be vastly better than having to go through and manually check every station
yeah exactly
honestly, just making the network gui remember some state when you close it would help a lot
like if you had the stations list for an item open last time, when you open it again it'll still be open
then you still have to remember which square you looked at last, but still saves having to expand the item again
also I tried to add arrows to the edges of the screen when you hover over a square
like the ones the game uses for alerts
but there's no way to draw things pointing at world entities, in screen space ๐ฆ
every mod that adds arrows has them around the character, not the edges of the screen
Would it be difficult to add "dragging" for re-ordering of entries in the "items/fluids" tab for the network window?
Mine are.... all sorts of out of order, and i find the buttons for "move down" and "move up" to be a pain to use. So, I've just left my list all jumbled.


I'm tearing them all down, for the most part.
