#Source-Sink-Push-Pull

1 messages ยท Page 2 of 1

drifting salmon
#

Hmm how'd you manage that

storm adder
#

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?

drifting salmon
#

If you can manage to find out exactly how to reproduce the issue, a save file + instructions would be great

storm adder
#

very replicable

drifting salmon
#

Right, yeah a save would be much appreciated

storm adder
drifting salmon
#

I won't be able to look at it until tomorrow though

storm adder
#

i'll just..... leave that train up there alone and not touch it.....

#

and hope nothing else goes wrong

drifting salmon
#

Oh yeah I see what's happening

storm adder
#

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

drifting salmon
#

Yeah, the gui is just trying to close twice

#

It'll be a simple fix

storm adder
#

glad i could be of assistance, even when not knowing what im doing

drifting salmon
#

That makes it easier to find bugs haha

#

Apperently I've just never tried to deconstruct a train with robots with the gui open

storm adder
#

aw, this server wont let me post the DJ Khaled "another one" gif

drifting salmon
#

๐Ÿ˜ญ

storm adder
#

was in the process of checking up on a delivery of a fluid, making sure my station was actually picking it up like requested

drifting salmon
#

Hmm, yeah if you can give me a save that'd help

storm adder
#

any chance any of this could be related to me manually making those 3 lines into comments?

drifting salmon
#

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

storm adder
#

okay lemme go see about updating

#

and i presume that'll mean also going back in and making those lines into comments again

drifting salmon
#

Yeah

storm adder
#

for the sake of information conveyance; I'm having a great time. getting a peak behind the curtain a lil is very interesting

drifting salmon
#

Really glad to hear that ๐Ÿ˜„

storm adder
#

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

drifting salmon
#

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

drifting salmon
#

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

drifting salmon
#

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 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

drifting salmon
#

I think we're getting support for this in the API! wooooooo!

drifting salmon
#

love this game

drifting salmon
#

@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)

storm adder
storm adder
#

#1329785565863874610 message

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?

drifting salmon
#

yeah, I have 3

storm adder
#

Okay that makes sense.

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

the issue is the time it takes the trains to get there

#

assuming you have a reasonable train limit set

storm adder
#

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
drifting salmon
#

yeah exactly

#

on the topic of the limit of 10, I do hope to work around that eventually

storm adder
#

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

drifting salmon
#

For me I found that the main benifit was not having to run 15 pipes from my build to the actual station

storm adder
#

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

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

correct. I could add them though, though I'm curious what the use case would be

storm adder
#

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

drifting salmon
#

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

storm adder
#

Ye, i remember reading about that.

drifting salmon
#

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 ๐Ÿ˜„

storm adder
drifting salmon
#

since that means exposing per-item information, yeah?

#

and I can only fit one per-item signal

storm adder
#

Are they?
I could just read the chests/tanks that the station can "see" for determining "amount provided" and "deficits", no?

drifting salmon
#

I guess, if you wanted to duplicate a lot of the logic

#

I was more thinking about getting a ready-to-use value

storm adder
#

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"

drifting salmon
#

well, for example if we wanted to expose the number of trains for each item specifically

#

rather than just a total

storm adder
#

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)

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

the mod actually already does exactly that for dynamic item modes

#

which are inputs to the provide/request combs

storm adder
#

Is that why the limit of 10? Cos base-10 numbering only has 10 unique numeric characters?

drifting salmon
#

no, it just happened to line up ๐Ÿ˜„

storm adder
#

Ah, darn, I thought i was being smart

drifting salmon
#

the limit of 10 was after testing a station with all of the longest names in py

storm adder
#

Ahhh. Fair enough

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

I think 26 would be the absolute limit that would be worthwhile

storm adder
#

So 26 provision-entries, and 26 request-entries?

drifting salmon
#

idk, I don't think I want to add that many signals...

storm adder
#

It would be a lot of signals to add.

drifting salmon
#

oh wait

#

stations can't provide and request the same item anyway

storm adder
#

Shrug
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.

drifting salmon
#

idk, I have the py recipe signals turned off because of how they clutter the gui, even though they would be useful sometimes

storm adder
#

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

drifting salmon
#

I think that really, deliveries is probably the only thing the station really needs to output per item right?

storm adder
#

Uhhhh.... maybe?
You mean to suggest that it's only relevant to know how many trains are on the way to deliver items/fluids?

drifting salmon
#

I think so

storm adder
#

And it's not relevant to know how many trains are on the way to pickup stuff.

#

Hmmmm

drifting salmon
#

nono

#

deliveries means provide or request

storm adder
#

Ohh....

drifting salmon
#

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

storm adder
#

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]
?

drifting salmon
#

yeah

storm adder
#

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.

drifting salmon
#

yeah

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

no but I mean, that isn't a problem

storm adder
#

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"

drifting salmon
#

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

storm adder
#

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"

drifting salmon
#

oh wow, new factorio version already out!

storm adder
#

Ooh! The one with filters for fuel slots???

drifting salmon
#

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?

storm adder
#

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.

drifting salmon
#

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

storm adder
#

From 2.0.45 notes

Added PumpPrototype::flow_scaling.

#

Under the "modding" section

drifting salmon
#

that was meeeeeee (by way of annoying the devs)

storm adder
#

Wild to see such a quick response.
Wube is great. I wish other games I liked had this sort of responsiveness.

Anyways, SSPP stuff.

storm adder
drifting salmon
#

it's just the existing network item tab

storm adder
#

Ah, it's for entries in that list... I c.

drifting salmon
#

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

storm adder
#

Aaaahhhhhh.
I see.

#

So neither number is "good" when it's a large number.

drifting salmon
#

yeah, if everything is working correctly, they should all be zero

#

like ash in this screenshot is doing ash things

storm adder
#

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?

drifting salmon
#

yes exactly

#

(also this is from my editor world, if you were wondering why there are such weird items there)

storm adder
#

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)

drifting salmon
#

mostly, except when stations are at the train limit

#

or if you have not enough trains

storm adder
#

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?

drifting salmon
#

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)

storm adder
#

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.

drifting salmon
#

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

storm adder
#

"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.

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

yeah it was also very magicky lol

storm adder
#

I think the most "proper" way would be to have short, concise, arguably incomplete information in tooltips.

With long form explanations found elsewhere.

drifting salmon
#

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

storm adder
#

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)

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

almost perfect

#

the only reason it's off by 100 is because the pipe segment has an odd number of pipes

storm adder
#

Oh right I was gonna get that pump side project thingy

drifting salmon
#

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

storm adder
#

Are they 3x2 footprint?

drifting salmon
#

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

storm adder
#

(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. )

drifting salmon
#

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

storm adder
#

I like the lil "hazard" striping outlining the actual footprint. Very good.

drifting salmon
#

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

#

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

storm adder
#

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?

drifting salmon
#

yep

#

it means that there's never going to be a variable amount stuck in that input pipe after the wagon target is met

storm adder
#

Hmmm.
It still has the potential to have that residue get sucked into the pump to fill the pump's internal buffer?

drifting salmon
#

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

storm adder
#

Hmmmmm.
ConfusedMathLady
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?

drifting salmon
#

a 1 second inactivity condition

storm adder
#

Ah. I see.
Has that always been present and I just haven't noticed?

drifting salmon
#

yeah that's always been there for fluids

storm adder
drifting salmon
#

I will need to make it usable for items as well to properly support loaders

storm adder
#

Classic me, not noticing.

drifting salmon
#

classic me for not documenting it anywhere lol

drifting salmon
#

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

storm adder
#

Shrug
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

drifting salmon
#

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

storm adder
#

Translation/localization of content at any scale, developer or mod creator, sounds like a lot of work

drifting salmon
#

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

drifting salmon
#

@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

storm adder
#

The cargo check when? The waiting condition for waiting at a stop?

drifting salmon
#

no, the one that locks the train if it detects that the wrong thing has been loaded

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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)

drifting salmon
#

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

storm adder
#

Mod-level option works

#

Per-station sounds hard to implement, but ofc i don't actually have any reason for thinking that

drifting salmon
#

mostly it's just a matter of not wanting to add setting to the gui that I don't think anyone should ever use ๐Ÿ™‚

storm adder
drifting salmon
#

loaders should now be properly supported for multi providers without needing any extra combinators \o/

storm adder
#

Good icon

storm adder
#

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)

drifting salmon
#

I mean I wasn't entirely confident about adding the train counts like that at all yet

storm adder
#

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.)

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

not that there's a problem with aesthetics, I just worry that I will really want to use those outputs for something else later

storm adder
#

Cos that won't require I/O combinatoes at all

drifting salmon
#

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

storm adder
#

Oh duh

#

That'll work.

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

omigosh I know

#

THAT was the thing that killed my combinator based train system

#

I ranted about it a lot lmao

storm adder
#

Ohhhhhh, that's very unfortunate

drifting salmon
#

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...

storm adder
#

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?

drifting salmon
#

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

storm adder
drifting salmon
#

sorry those two points were not really related I think ๐Ÿ˜„

#

basically, the delivery time is purely used for calculating buffers

storm adder
#

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?

drifting salmon
#

yes, exactly

storm adder
#

Perfect.

drifting salmon
#

BUT, only from push stations

storm adder
#

Yes.

drifting salmon
#

wait no I got that backwards

storm adder
#

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.

drifting salmon
#

you will also notice that they have different storage needed values

storm adder
#

Oh hmmm. So not identically

drifting salmon
#

because pull stations have two different thresholds

storm adder
drifting salmon
#

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

storm adder
#

How are those 2 different thresholds determined?

drifting salmon
#

the lower threshold is just throughput * latency

storm adder
drifting salmon
#

the upper threshold is just double that

storm adder
#

Yeah, I should problt just pick through the code to answer my own questions

drifting salmon
#

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!

storm adder
#

๐ŸŽ‰

#

Latency is... including max train time listed as part of train class?
Or is it separate?
Are they the same thing?

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

yeah but they aren't actually the delivery thresholds directly

#

gimme a sec I'm trying to translate the code into english

storm adder
#

Delivery_time is similar. And I'm seeing
m_max(Delivery_size, throughout * Delivery_time)

Which makes sense.

drifting salmon
#

yeah, basically the delivery size provides a floor

storm adder
#

That's good to know.

drifting salmon
#

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

storm adder
drifting salmon
#

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

storm adder
#

No worries. I'll keep picking through and seeing what insights I can glean

drifting salmon
drifting salmon
#

how come you have a bunch of your trains running on cellulose?

#

(I may be having a stickybeak in your world)

storm adder
#

Cos I hate ash

drifting salmon
#

but why not just use the wood

storm adder
#

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.....

drifting salmon
#

hahaha

storm adder
#

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

drifting salmon
#

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"

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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

#

To be more free form

drifting salmon
#

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

storm adder
#

Anyways.

My old stations have two somewhat separate systems for indicator lights.

  1. Is there a train at the station or on the way?
  2. 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

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

but the thing is, the stations already show all of that info

#

you just have to click on them

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

re a central display, I could definitely add a dedicated "network info" entity just for that

storm adder
#

There's currently a history tab listed.
Could even just have it be another "summary" tab, where things are listed

drifting salmon
#

how would that differ from the existing items tab (once searching/sorting is added)?

storm adder
#

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 iron_plate , 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 iron_plates, 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.

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

well yeah I know about that one ๐Ÿ˜„

storm adder
#

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"

drifting salmon
#

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

storm adder
#

(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.)

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

I think that's kind of backwards

#

like, the station should just buffer enough to support it's maximum it can produce, right?

storm adder
#

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? "

drifting salmon
#

or else why did you build that much production if you didn't want it to run

drifting salmon
storm adder
#

Like, per slot? How wagons work?

drifting salmon
#

yeah

storm adder
#

No, I did not know that

drifting salmon
#

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

storm adder
#

So, maybe a niche situation;

  • I've got a nearby station that provides iron_plate and copper_plate
  • 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.

drifting salmon
#

like how you can paste assembling machines on to requester chests

storm adder
#

That's why I limit by disabling inserters.
I like having the headroom to put spare items

drifting salmon
#

hmm

#

idk what to do in that case

storm adder
#

Not strictly necessary, but it's a situation i find myself in fairly often where some IO off the station would be convenient.

drifting salmon
#

other than just dump the items in a random empty train instead

#

and let sspp liquidate them automatically

storm adder
#

Oh yeah, I was gonna ask.
What's the whole "liquidate" thing about?

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

but then what happens with those items

storm adder
#

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.....

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

ok but for something like stone, you can just build a sink

storm adder
#

(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)

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

I mean that's exactly how the mod is intended to be used

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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?)

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

fwiw you gain nothing from spreading out depots

#

trains aren't picked based on distance

storm adder
#

frog_sus

Yeah... you're right.....

#

Ig ill just setup unloading at the depots then

#

For any liquidation

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

Hahaha

#

That was very much not intended usage but I kinda dig it

storm adder
#

ChillBar_tired I've spent the past 4 hours in the lab trying to get combinator magic to work

drifting salmon
#

uh oh

storm adder
#

it's fine, i'll figure it out.
it's for automall stuff, not trains

drifting salmon
#

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?

storm adder
#

i made it from scratch

drifting salmon
#

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

storm adder
#

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
drifting salmon
#

I'd be super terrified I'd make a mistake and accidentally craft 2000 tailings ponds or something

storm adder
#

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

drifting salmon
#

can it handle different crafting machines? like can some recipes use assembling machines and other recipes use some other machine

storm adder
#

yep, just make space for it where the assembler would be

#

thats for a foundry footprint, but ofc pY doesnt have the foundry model

drifting salmon
#

does the CC just have a list of the things this machine should craft?

storm adder
#

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. .

drifting salmon
#

ngl the giant sushi belt was my favourite part

storm adder
#

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.

drifting salmon
#

oh interesting, you have to input the counts

#

couldn't you use the selecter combinator to figure out the counts?

storm adder
#

the intermediary thing is another part im trying to address

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

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

storm adder
#

yeah, at py1 where im at, it's definitely a worse solution than just handcrafting

#

way more finicky, and far slower

drifting salmon
#

but, rule of cool

#

plus should be more useful later

storm adder
#

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.

drifting salmon
#

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

storm adder
#

i plan to keep the logistics area very small, but have large construction area via construction range extenders

drifting salmon
#

I hacked my zone extenders to have a really small connection distance

storm adder
#

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.

storm adder
#

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.

drifting salmon
#

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 ๐Ÿ˜„

storm adder
#

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.

drifting salmon
#

have you checked the history tab to see how long deliveries are taking?

storm adder
#

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

drifting salmon
#

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

storm adder
#

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 ๐Ÿ˜…

drifting salmon
#

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

storm adder
#

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.

peak sluice
#

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?

storm adder
#

I wouldn't expect total blueprint size to be the problem..... but maybe?

peak sluice
#

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 ๐Ÿ˜‰

drifting salmon
#

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

drifting salmon
#

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

peak sluice
#

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?

drifting salmon
#

Or rather the other way around

#

oh wait no you mean there was a depot here before?

peak sluice
#

Yes

drifting salmon
#

hmmm I didn't think that was possible

#

but yeah that would mess things up bad

peak sluice
#

I'll try it, now

drifting salmon
#

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

peak sluice
#

I'm lazy, so I tend to force it without because of the trees and things.

drifting salmon
#

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...

peak sluice
#

wait a sec for me to check it. I'm running across the map at the moment ...

drifting salmon
#

don't worry I just checked it haha

#

problem solved with one line of code lol

peak sluice
#

I love it when that happens!

drifting salmon
#

I'll still have to go over your other issue with built stations sometimes still acting like ghosts

peak sluice
#

The "crash when clicking on it" one?

drifting salmon
#

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

peak sluice
#

ok

#

I've lost track (ahem.) of where we are, now ๐Ÿ™‚

drifting salmon
#

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

peak sluice
#

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.

drifting salmon
#

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

peak sluice
#

Isn't there a standard framework for building mods?

drifting salmon
#

I mean there's the modding API, but I'm not aware of any libraries for managing multi-entity constructs like SSPP stations

peak sluice
#

Oh, wow. You like a challenge, then!

drifting salmon
#

of course, I'm a factorio player

storm adder
#

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?? )

drifting salmon
#

hmmmmmmmmmmmmmmmmmm

storm adder
#

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

drifting salmon
#

can you easily put another station right above that one?

storm adder
#

yeah, im just gonna squeeze anothe one in

drifting salmon
#

as in on the same track, just dump a second stop (with combs) right above

storm adder
#

ohhhhhhhhhhhhhhhh, uh

#

seems like it should work?

drifting salmon
#

if it's only for requests yeah

storm adder
#

and it is

drifting salmon
#

(I know it's cursed, but I feel it fits in with the rest of that station :D)

storm adder
#

very cursed

#

im rushing cDNA and im excited to have it over with

drifting salmon
#

man I haven't gotten to actually play the game in nearly a month

storm adder
drifting salmon
#

I was in the middle of rebuilding my mall/random bio junk like cdna

storm adder
#

yet another 10+ requester station

#

so, sequential stations again

drifting salmon
#

man when I finally finish this table rework/filtering stuff I'm gonna have to look into working around the limit aren't I

storm adder
#

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

drifting salmon
#

why so many chain signals?

storm adder
#

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

storm adder
#

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....

drifting salmon
#

classic py gameplay

storm adder
#

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

storm adder
#

Ooh, sushi

tired shale
#

Sushi in 2.0 is glorious.

storm adder
#

I use it all over

#

Its so good.

peak sluice
#

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?

storm adder
#

Are all of your depots at (roughly) the same place?

peak sluice
#

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?

storm adder
#

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.

peak sluice
#

My depots are all over the base, but the demand stations that are being fed from the mines are the nearest

storm adder
#

You got a screenshot? Even zoomed out would help make sure we're talking about the same thing.

peak sluice
#

sure, just a sec

storm adder
#

(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))

peak sluice
#

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.

storm adder
#

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.

peak sluice
#

agreed

storm adder
#

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."

peak sluice
#

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?

storm adder
#

Are A and B not set to the same priority level for their pulled item?

peak sluice
#

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

storm adder
#

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)

peak sluice
#

Hang on a sec. I misread your comment, let me run back and check the priorities

storm adder
#

If A is set to "pull high priority" and B is set to just "pull", then that'd explain the observed behavior for sure.

peak sluice
#

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.

storm adder
#

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.

peak sluice
#

It's finally filled B, after nearly an hour

storm adder
#

And i presume that A is too full to have possibly accepted the shipment?

peak sluice
#

and all the priorities are the same

#

It (A) might have been full. It's making copper cable. so it empties fast

storm adder
#

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.

peak sluice
#

I haven't ever looked at dynamic priority. Would I need to implement my own round-robin thing?

storm adder
#

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.

peak sluice
#

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! ๐Ÿ™‚

storm adder
#

You won't be able to order each of the 30 stations.

#

Not directly

peak sluice
#

agreed

#

Maybe I should learn LUA and submit a pull request

storm adder
#

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.

peak sluice
#

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.

storm adder
#

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

peak sluice
#

That's interesting; I had assumed that the destination was being chosen by SSPP, not by the game.

storm adder
#

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 .

peak sluice
#

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!

drifting salmon
#

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

drifting salmon
storm adder
#

ah, well, my bad then PB_hide

#

also, this

drifting salmon
#

Push graphite?

storm adder
#

ah

#

that's why

#

i copied a previous entry at the station, and didnt change it's operation mode

drifting salmon
#

The copy button, a double edged sword

storm adder
#

good thing i didnt set up storage for graphite heheh

drifting salmon
#

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

drifting salmon
#

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

peak sluice
#

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.

drifting salmon
#

That sounds like a seperate issue

#

The main thing is the lack of waiting areas

peak sluice
drifting salmon
#

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

peak sluice
#

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?

drifting salmon
#

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

peak sluice
#

That time appears to be a few hours, based on what I saw last night. It needs a minimum probability, not a simple value

drifting salmon
#

So that train limit can be set to 2

peak sluice
#

They have a train imit of 2

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

I think that A is actually several stations

peak sluice
#

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.

drifting salmon
#

That'd be really hard to do in a way that would suit everyone

peak sluice
#

OK

drifting salmon
#

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

peak sluice
#

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?

drifting salmon
#

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

peak sluice
#

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.

drifting salmon
#

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)

peak sluice
#

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 ๐Ÿ™‚

drifting salmon
#

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 ๐Ÿ˜„

peak sluice
#

๐Ÿ˜„

storm adder
#

Yay bug reports

peak sluice
#

I love detail!

#

and edge cases; they're the interesting ones

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

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

peak sluice
#

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 ๐Ÿ™‚

storm adder
#

pepeseth
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

drifting salmon
#

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

peak sluice
#

I am testing the limits ๐Ÿ™‚

drifting salmon
#

it is much appreciated, a large scale vanilla-ish base looks VERY different to a py base

peak sluice
#

what's a py base?

drifting salmon
#

pyanodon's

peak sluice
#

OK

drifting salmon
#

lots more individual items, but most items only have one or two sources

peak sluice
#

I haven't tried that, yet

drifting salmon
#

and the total throughput of most items is a lot lower

peak sluice
#

I'm going to start a new game and experiment with the latch and clock -> dynamic priority thing

drifting salmon
#

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

peak sluice
#

A wiki would be really helpful

drifting salmon
#

I just need to get important feature work done so I can finally focus on documentation (and a tutorial video)

peak sluice
#

Is there any chance of an update to SSPP with those other problems fixed?

drifting salmon
#

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

peak sluice
#

OK

drifting salmon
#

oh

#

look in the top right

#

this station is disabled

peak sluice
#

Yes, I froze it last night

drifting salmon
#

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

peak sluice
#

OK

drifting salmon
#

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

peak sluice
#

Yes. The stations at the top-left making copper cable were hogging all of the supply

drifting salmon
#

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

peak sluice
#

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?

drifting salmon
#

as high as you can set it without having ups problems

peak sluice
#

ok

drifting salmon
#

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

peak sluice
#

I know that fear ๐Ÿ™‚

drifting salmon
#

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

peak sluice
#

Let's put it down to user-ignorance, which will hopefully be solved by the wiki.

drifting salmon
#

bugfix release is up

#

that'll come when the table rework is done (hopefully it'll make things more robust in general)

noble furnace
#

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

drifting salmon
#

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)

storm adder
#

Wow so many new people

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

you're also missing that trains in SSPP don't have to go back to the depot at all

storm adder
#

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?

drifting salmon
#

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

storm adder
#

nod 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.

drifting salmon
#

mostly that option is for people with bad double headed networks

storm adder
drifting salmon
#

if they aren't signalled properly trains can get stuck turning around

storm adder
#

Heh, that's funny

drifting salmon
#

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

storm adder
#
  • 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"

drifting salmon
#

actually my goal is more along the lines of "make things work reliably regardless of where depots are"

storm adder
#

For sure. Makes sense

drifting salmon
#

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

drifting salmon
#

storing big arrays of data like that in lua is not great

#

and you have to rebuild it whenever the rail network changes

storm adder
drifting salmon
#

that's a lot of new concepts to introduce for what most likely amounts to not actually improving worst case delivery time

storm adder
#

ducknotes fair enough, I suppose

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

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

drifting salmon
#

the stations actually making the items is

storm adder
#

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.

#

Hmmge which might be me worrying about small peanuts.

Just cos i feel like it's a problem, doesn't mean it is.

drifting salmon
#

I don't think train fuel usage should ever be a concern, congestion yes but not fuel

storm adder
#

Perhaps....

drifting salmon
#

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

storm adder
#

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?

storm adder
#

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

storm adder
#

i could see how you could use that, in conjunction with radars for broadcasting counts, to make a strict priority list of stations.

drifting salmon
#

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.

peak sluice
#

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.

drifting salmon
#

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

peak sluice
#

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.

drifting salmon
#

Yeah that makes sense. Think I'm just too used to how it works internally haha.

peak sluice
# drifting salmon try upping the latency to 600 here

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.

drifting salmon
#

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

peak sluice
#

lol. That was because I forgot to connect the storage circuit, so it just kept going ๐Ÿ™‚

peak sluice
#

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.

drifting salmon
#

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]

peak sluice
#

That might work, as all the stations tend to follow the same pattern

drifting salmon
#

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

peak sluice
#

I haven't tried cranes, yet

drifting salmon
#

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

peak sluice
#

thank you!

drifting salmon
#

one caveat, this won't update ghosts

peak sluice
#

OK

drifting salmon
#

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.

peak sluice
#

That's not a problem. I updated the blueprint, so I'm only interested in existing stops

drifting salmon
#

Yeah I was gonna say that also for updating ghosts it still wouldn't update blueprints

peak sluice
#

I wouldn't expect it to

drifting salmon
#

I think logically it should still update in-world ghosts though, since from the player's perspective those are still "stations"

peak sluice
#

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.

agile ruin
#

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?

drifting salmon
#

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

agile ruin
#

Yeah something like that could work, thanks

#

I'll do the same for supply stations

drifting salmon
#

I assume the reason you are doing multiple stations like this is because you're bottlenecked by the pumps?

agile ruin
#

Nah, I just like the look of them

#

No practical reason for doing something like this

drifting salmon
#

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 ๐Ÿ™‚

agile ruin
#

I'll just leave it like this, not too big of a deal to have one train waiting to get unloaded there

peak sluice
drifting salmon
#

took the time to reply to the exact message lol

peak sluice
#

Yeah, Discord is annoying about that, when there are successive messages

drifting salmon
#

glad it works anyway! now to make some more multi providers ๐Ÿ™‚

peak sluice
#

I can't remember which one it was, though I do remember trying it out to see if it works

storm adder
#

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.

drifting salmon
#

that is exactly what it is for, though it isn't implemented internally as just adding to delivery time, formula wise

storm adder
drifting salmon
#

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

storm adder
#

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"

drifting salmon
#

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"

storm adder
#

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.

drifting salmon
#

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

storm adder
#

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

drifting salmon
#

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

storm adder
#

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.

drifting salmon
#

it'd be impossible

#

there's no api for dragable elements

#

mod guis just aren't allowed to do that

storm adder
#

"Just get good and deal with it".
Good to know.

drifting salmon
#

I could add a way to move items by clicking on a button in the item row then clicking another button in the place where you want to move it to

#

but the gui already takes a long time to open because of how many elements it has when there are a lot of items/jobs