#Seth's Pull System description.

1 messages · Page 1 of 1 (latest)

mild wraith
#

Let's see if I'm allowed to make threads.

#

Nice. Seems that it will.

#

So, there's 6 (sorta 7) types of stations.

  • 🟥 passive providers.
  • 🟧 byproduct management
  • 🟨 mass storage
  • 🟩 waiting bay stations
  • 🟦 requesters
  • 🟪 active providers
#

Also, ⬛ stations, for refueling.

high arrow
#

More of a true vanilla LTN, actual logi stops on rails

mild wraith
#

The trains are set up with variety of interrupts, and the only static schedule is "go to 🟩 , no wait condition"

high arrow
#

I'm not sure if I'd call it a pull system, seems like a hybrid as it's using both styles?

mild wraith
high arrow
#

Seems very much like a logistics mirror

#

Cool stuff!

mild wraith
#

At each station, there's variety of combinators that encode if the station is available to the signal for that item type.

Counts of available 🟥, 🟦 , 🟪 , and 🟧 are encoded on the red wire.
Counts of trains on the way to 🟥 , 🟪 , or 🟦 stations, as well as trains at 🟥, 🟪 or 🟦 stations are encoded on the green wire.

#

At the green stations, a list of "valid targets" is composed.

The list of valid targets is the list of available 🟦 stations, minus an adjustment value.
The adjustment value is the count of trains at or on the way to 🟥 🟦 or 🟪

For example.

  • If i have 1 " 🟦 iron_ore " station available, the list of valid targets will include " iron_ore "

  • If a train leaves for " 🟥 iron_ore ", the adjustment value will then negate the " 🟦 iron_ore " in the valid targets list, and thus another train won't leave for for any other available "🟥 iron_ore " stations.

#

At the array of green stations, the list of valid targets is pulsed down the line of stations every 3 seconds
With each station only "forwarding" the pulse to the next station if that specific station has no train at it.

#

This is the list of interrupts for the train.
Absent any interrupts, it defaults back to 🟩

image-99.png
#

First on the list is refuel. Fairly straightforward.

image-123.png
#

Next up is dealing with pushes from 🟪

#

I lied earlier. List of valid targets also includes the count of available 🟪 stations.

So if my " 🟪 stone " becomes available, then stone will be added to the list of valid targets, and a train can see that signal for the wildcard in the interrupt condition.

#

No other station type needs to be available in order for a train to leave for purple. And the train will end up full of an item after the interrupt is done.

At which point, those items will be "spares" left on a train with no drop point specified.

#

The order of the "spare" interrupts is important.
First is "deliver spares"

image-184.png
#

This one requires being at green, to avoid situations where a train from 🟪 undercuts a train already dispatched to a 🟥 station (which I'll get to later)

#

Next is "manage spares"
Where the train takes the items from purple, and brings them to an 🟧 station.
🟧 stations function similar to 🟦s, in that they take deliveries of items.

image-108.png
#

The difference is that this "manage spares" is the only way for 🟧 stations to recieve items; they can't "actively request" deliveries, only recieve spare items for the purpose of managing items from 🟪

#

If neither 🟧 nor 🟦 stations are available, then the last resort is 🟨

image-149.png
#

At 🟨 stations, any item can be recieved, and they're mostly just stored in a massive array of chests.
Some items are sorted, and given to 🟥 stations for that specific item.

#

So that's dealing with active pushes.
Next is how the system deals with dispatches for requests.

#

This requires signal from the clock pulsing the list of valid targets.

And again, the list is adjusted based on trains being en-route or at various stations, to avoid multiple trains being dispatched for the same singular slot at a 🟦 station.

#

The aim of the "adjustments value" to the list of valid targets is to avoid situations where a train gets "stood up" at a red stations.

Its very bad for a train to pickup a load at red, then for it to no longer have a spot at a 🟦 , because some other train swooped in and took the spot.

#

Additionally,
Stops all enable/disable on 2 conditions.

  1. Local inventory
  • for pickup stations, have enough to fill a specified % of a full train
  • for drop stations, have below a specified % of a full train.
  1. Relative to the count of available stations for that item. This is for times when I have some stations i want to recieve service before others like some 🟦 stations being more important than others.
#

So my question in the main channel was in regards to the "deliver spare" interrupt.

#

I'm unhappy with that interrupt requiring a trip from 🟪 to 🟩 , before potentially going to 🟦.

I'd much prefer that the train be able to go directly from 🟪 to 🟦 .

However, I'll need to add a check for if a train has already been dispatched to 🟥 to fill the request from 🟦. This check will mean checking the adjustment value at the 🟪 stations.
.

Its incredibly unlikely that this situation will arise... but still.

#

#train-help message

As mentioned here; the system has a "distance inefficiency" problem, that gets worse the longer any potential trip gets.

#

I don't currently have plans to address this distance inefficiency...

#

Oh!
Fluid trains and item trains are separated to different groups.

The know which stations to go to because of the names. Item stations have cargo_wagon in the name. Fluid stations have fluid_wagon in the name.

#

" 🟪 cargo_wagon stone "
And the item trains have interrupts that target station names with the wagon type in the middle there.

While " 🟥 fluid_wagon heavy_oil " is only targetable via interrupts that are on trains with fluid wagons.

#

@serene pivot a ping, just cos you were the one that asked.

mild wraith
#

Additional fun things I have at the stations;

  • Arrival speakers; they play a fun arrival sound locally when a train shows up. The instrument used is based on the station color.

Indicator lights; all stations have indicator lights that show the current status of the station. (The color scheme here breaks with the usual "logistics chests equivalent" color code)

  • all stations indicate green if a train is in the station.
  • all stations indicate yellow if a train is on the way.
  • all stations indicate purple if the station would otherwise be enabled based on local inventory, but has been told to disable based on the global count of available stations
  • stations indicate red if there's a "problem" which means different things for different station types;
    • 🟥 stations indicate there's a problem if they don't have enough available for pickup (usually, that amount is 1 train full)
    • 🟦 stations indicate a problem if their local inventory is below a specified amount (usually, that amount is 110% of 1 train full)
    • 🟪 stations indicate a problem if their local inventory is above the specific amount (usually, 1 train full)
    • 🟨 stations indicate a problem if their local buffer has any items in it, meaning they haven't yet gotten everything into the downstream major storage array.
  • all stations indicate blue if there's not a train on the way, but they don't trigger their relevant "problem condition".
  • 🟧 stations have the unique indicator color of orange, which shows when they don't have enough items in local inventory, but that's fine because the item in question is just byproduct from other processes.

THIS MARKS THE END OF THE DESCRIPTION OF THE SYSTEM. EVERYTHING AFTER THIS POINT IS ME AND OTHERS TRYING TO SORT OUT HOW TO FACTOR IN ROUTE DISTANCE INTO WHICH TRAINS GET DISPATCHED.

high arrow
mild wraith
#

Hmmm....

#

Those coordinates on temp stops only show for temp stops that are added manually by the player, for locations that aren't stations?

high arrow
#

Yeah

#

I'd love an automated GPS, this is the only player facing GPS I know of lol

mild wraith
#

Yeah... automated coordinates would be very nice.

#

I've seen a very small amount of the AAI vehicles mod stuff.
I know that whole system adds signals for XY coordinates....

high arrow
#

Yeah, you can bitpack stuff too if you want, X is the first 16 bits, Y is the second 16, then XY is a single signal

#

Pythagorean to get straight line distance and call it good enough 😛

mild wraith
#

Yeaaaahhhh.....
Sounds very complicated.....

I am somewhat planning on having easier access to trains by the time my network is so sprawling that the "distance inefficiency" gets to problem levels.

And then I can just put dedicated trains down and do a more standard "all push" system .

high arrow
#

Ah darn, I was wondering how far this would actually go XD

mild wraith
#

I might try and bother with accounting for distance... I'll have to do a think about it.

#

My green stations currently exist in banks of 5 of each type;
A cityblock in the grid is dedicated to having 5 🟩 fluid_wagon and 5 🟩 cargo_wagon stops.

#

They each have their own dispatch clock....... and they don't communicate with each other......

And I sorta just.... hope that their clocks are desync'd enough from each other that it doesn't cause problems.....

#

I'm sure it's fine.

#

So i could find the coordinates of the center of the arrays.

high arrow
mild wraith
#

All 32 bits on the red radar wires are taken.
And 8 bits of the green wire are accounted for in carrying my "adjustment value"
So, I've got 24 bits left on green....

#

12 bits for X and Y.

high arrow
#

Oh good you're already doing that

mild wraith
#

4096, 2^12, is not a ton of space for max values....

high arrow
#

I found TDMX to be a necessary component of systems over a certain complexity

#

Time division multiplex

mild wraith
#

Huh

high arrow
#

Each station of each type gets its own tick to use that signal

mild wraith
#

Ah.
That's very different than how my dispatch clock currently works.

#

Rather than having a list of valid targets, and adjusting that list based on trains already being dispatched....
Then flashing that list past trains at waiting bays.....

Instead;
Have each station be able to recieve the list at a specificied timestamp in the looping clock.....

high arrow
#

Sure, that'd solve the stampede

#

Does each resource have it's own clock, or do they all have a slot on the master clock? The TDMX I rolled allows sharing, 10 copper and 10 steel and 10 gC stations would each get ticks 1-10 on their own resources

mild wraith
#

Hmmge

I think the way I ingest "requests" is just incompatible with also taking in XY coordinates alongside the requests.

Currently, I'm just counting number of 🟦s that are enabled, to use as the foundation of my list of valid targets.

So if I have 1 blue stone and 1 blue iron ore station available, the "valid targets" list will have both stone and iron ore.

That entire list gets pulsed to the green stations, and then the interrupts at the stations can trigger based on that.

So, all items share the clock.

#

I could have a constant combinator at each blue station denote the coordinates for that station, and then broadcast that on the remaining green radar bits.

But then.... if I ever have 2 blue stations available, even if they're different items, the coordinates would get jumbled.

#

Okay, I'm reading more about the concept of "time division multiplex"

#

And it seems like something I'll need to understand further before proceeding.

#

It'll require that I broadcast my clock signal on radar.
Probly a good idea regardless, tbh. I can just send it over the new "clock" signal.

#

Then, I can tell each of my blue stations that they get to broadcast their coordinates over the radar from "time" to "time"
Probly just 1 tick....

#

Timing is gonna become important.

high arrow
#

Yeah, will have to transition between a lot of constant state and pulse signal stuff

mild wraith
#

If my clock is 3 seconds, 180 ticks, per loop, that's enough "space" for 180 different blue stations.

#

But.... I don't go from green to blue....

I go from green to red to blue......

#

So I'll need coordinates for all of them?

#

Okay.

high arrow
#

Which red activates is a different question than which green activates

#

Closest red to blue, closest green to that red

mild wraith
#

That seems less intensive than calculating all total distances of possible routes.

high arrow
#

Yeah, just a simple pair of subtractions, square em, add and sqrt

#

Sqrt's not the easiest in factorio but I think we have a shortcut

mild wraith
#

Either way, I'll need to broadcast coords for... basically all stations.... might as make my system able to track coords for all stations.

high arrow
#

Coords or distance, to know how far the others are and shut off if they're not the nearest

mild wraith
#

Okay.
A scenario where no blue stations are available.
Silence on the 2 "blue station coords" channels.

One blue station becomes available.
Now, for 1 out of every 180 ticks, I get the coords for that station.

I can then calculate the distance between it, and all available reds..... but I'll need to take care about which item this is for......

high arrow
#

Yeah the blue/red/green variables are important for how you're doing your setup, to be sure, but so are which items they have

mild wraith
#

Then... in the event I had more than 2 blue stations available, for different items....
Determining which coords belong to which item is gonna be a nightmare....
I'd have to hard-code in which time-stamps in my clock correspond to which items.

high arrow
#

Yeah having the stations decide based on global information is probably easier than centralizing

#

The TDMX just allows you to put a ton more information on the signals that exist

#

So you can use the real signals too

mild wraith
#

Using the "real" signal to encode counts of stations was the entire reason I dipped into binary encoding to begin with.

high arrow
#

I mean, if they all pulse their presence on the 0 tick or the max tick of your clock, that's that information. The rest of the clock they can use that signal for other things

mild wraith
#

I'd still need to tell the system;

" hey if you see coords for a blue station on tick 4, that's coords of a stone station.
And if you see coords of a blue station on tick 5, that's coords for an iron plate station"

And so on... and so on....

#

Which seems.... like a lot.

high arrow
#

It's the combination of clock(12) and information on the copper signal that gets paid attention to

#

Oh, probably lead four bits color, then 14+14 X+Y

mild wraith
#

Currently, my clock isn't broadcast over radar.

Each of my 3 arrays of green stations has their own clock PB_clown

high arrow
#

Global signal is so 🪙

#

💲

#

jeez discord's awful lol

mild wraith
#

I'm fine dedicating an entire signal to the global clock.

I want the count of " 🟦 cargo_wagon stone " stations to be encoded to the 8th through 15th bits of the stone signal over radar, so the count of red stone can be on the 1st through 7th bits of the stone channel.

But for the clock? The clock can have the entire " 🕐 " signal. That's fine.

high arrow
#

That's fine, you can do that. But it doesn't need to be a constantly present signal, does it?

#

You can transmit that information once per clock cycle

mild wraith
#

That's currently how I'm flashing my "list of valid targets" to the trains at 🟩 stations.

The list only gets sent when the clock signal = 1.

high arrow
#

Okay, memory cells are a thing

mild wraith
#

I'm not currently implementing much in the way of memory cells.

high arrow
#

This is a memory cell that resets once per clock cycle 😛

image.png
#

actually it's a latch

#

Which is a fancy memory cell with an off switch

mild wraith
#

Hmmmm....

#

I will have to do a think on how I could implement latches/memory into the system in a way that is useful....

high arrow
mild wraith
#

I'm staring at the prospect of having to redo my blueprints for stations again...
Because I'll need to have each station contain it's coordinates on a CC, and for those coordinates to be given via parameter prompt.....

And that's gonna mean another combinator of footprint. And my footprint is already getting a little out of control....

And I'll also need to go back around and retrofit all my stations with the new blueprint.... and I'll need to get coordinates via manual temp stop for each station.....

high arrow
#

lol I'mma be real with you; This is actually one of the more well engineered systems I've seen, but pull is like difficulty 12/10

mild wraith
#

Oh ye, the "is this easier?" Ship has looooong since sailed.

#

At this point, I'm running 60% on principle of wanting to prove to myself I can do it, and 40% on the intrigue of learning about tangential disciplines like binary encoding and TDMX

#

I've already got a decider at all stations determining if the station is enabled.
And also, and combinator carrying "global count of stations" and "cargo % target" values.

I can fairly easily add coordinates to the CC, on channels relevant to the station color.
And 1 more DC for determining station-enable status, and an AC for writing coordinates to the radar, is do-able.

But I'll want the coordinate signals to be "written" to the radar on the global clock cycle..... which means I'll need to read the clock at each station....

However, most of the time I have stations in banks of a few in a row.
Like, for my wood production site, I need to request in water and moss, and output wood. That's three stations in a row, and they can share a "clock reader"

#

Also, if I'm gonna be hard coding in station coordinates, I don't need to be super precise.

I could easily take coordinates of [2372, 4612] and just code them in as [23, 46]. Essentially rounding both coords to the nearest "100 tiles"

#

Which makes the amount of bits available basically a non-issue.

high arrow
#

Sure, might have to include another tiebreak method at that point

#

But it does save you some bits for damn sure

#

More stations might end up at similar distance with a larger rounding bubble

mild wraith
#

True......

#

To be really robust, I'd need a tiebreak either way.

While less likely if I calc distance down to the 1 tile, it's still possible to have a tie.

high arrow
#

True, though I suppose you could probably do some sort of check to see if there's a collision and adjust one of them

#

Not sure which would be easier, prolly tiebreak

#

Oh or just have them sound an alarm during the 'acknowledge' phase, if two stations acknowledge, BEEPBEEP

#

kinda late collision detection LOL

indigo crater
#

Assuming these are 2 stations with trains the train ID can be used to tie break. If they are two receiving stations the train pathfinder can be used to tiebreak.

mild wraith
mild wraith
#

I keep getting stuck on having to track which stations specifically belong to which coordinates. And ensuring that a train dispatched on a given short_path actually follows the path.

I can track coordinates, and have a "short path finder" system find the shortest path for a delivery... but once I have that short_path_01, I'll need to disable every otherwise available 🟥 except the one on short_path_01

And then, I'll have to somehow determine when that train is done at 🟥 , and disable all otherwise available 🟦 stations except the one on short_path_01....

But while the train on short_path_01 is waiting at red, the "short path finder" will need to be working on the next thing; finding short_path_02.

#

I think my conception of the approach is... bad.

high arrow
#

The trains will be good about sticking to short paths if you give them the short paths. If they switch(they won't) it's for your own good lol

high arrow
mild wraith
#

I have a given item at 🟦 being requested.

Under current function, there's a number of things that could go wrong in regards to distance. Let's explore some of those.
One would be; if multiple trains at 🟩 , and only 1 🟥 available for the item, the system could send a train from a very far away 🟩, instead of a 🟩 that's already close to a 🟥

#

That'd just be down to which 🟩 station array has a local clock that is running "ahead" of the other 🟩 station arrays.

indigo crater
#

Priority likely can be used to fix some of that. As a train at a higher priority station takes precedence over a train at a lower priority station.

high arrow
#

Hmm, it'd be hard to distance sort via priority b/c it has to adjust based on which requester is calling

mild wraith
#

If i have multiple 🟥 available, when a train gets the go-ahead from its 🟩 , it'll already go to whatever 🟥 is closest to that 🟩 station.....

Which could mean moving away from the 🟦 station......

indigo crater
#

In this case they just want red to move over green and priority can do that. Though the problem there is green lighting red trains you don't want green lighted yet.

high arrow
#

Hmmm... with some directional structure that could work

indigo crater
#

The clock mismatch is also why you want a global clock timing is critical for this

mild wraith
#

So perhaps before considering accounting for distance, I should tie my 🟩s all together with a global clock.

high arrow
#

Well I mean, you know which red you want, because that red is closest to the blue station. You can find the closest green to that red to pick that train

mild wraith
#

Currently, there's 15 total " 🟩 cargo_wagon " stations.
They're all clumped in groups of 5.

Each group of 5 has a local clock, and those 3 local clocks are all desync'd from each other

high arrow
#

Oh hey so I have a circuit that may be of some interest to you then

mild wraith
#

Each clump passes the composed and adjusted "valid targets" list down the chain of stations, only "forwarding" the list to the next station if the current station has no train.

high arrow
#

It's bit nonsense again

#

So each station gets a bit in B, I xor against 2^(stations+1) -1, and the most significant bit of that is the northernmost station without a train

image.png
#

N<=X<M is an MSB test

mild wraith
high arrow
#

this one, always

image.png
indigo crater
#

The advantages having a synced clock gives you for these stations is that all trains see the same signals at the same time. This then lets you use built in factorio features where the train that moves is the train closest to the one opened slot by strait line distance.

high arrow
#

Unless it has a train, then the next

mild wraith
#

Which would cause problems in the event that 2 🟥 were available at the time that a singular 🟦 became available.

2 trains would leave, 1 to each red, but then only the one that could get to red and load faster would be able to reserve the 1 allowed train at the 🟦

#

And then the faster train would often unload enough at 🟦 to disable that station.

Leaving the slower train stuck at its 🟥, taking up space in the station and meaning a whole train was sitting around not able to take new dispatches.

high arrow
#

Stampedes are hard

mild wraith
#

Hence, now I only dispatch 1 train from a given array of 🟩 every 3 seconds.

The time between dispatches allows the system to account for "trains already at or on the way" to the 🟥 station, and adjust the list of valid targets accordingly

#

The problem being, the gates letting trains out at 🟩 are very dumb regarding distance.

high arrow
#

lmao there have been probably a dozen or two people who've come in with pull systems they liked. Exactly zero have had distance handled

indigo crater
#

What about starting from blue you open one red that does not yet already have a train at the red or on the way to the red. Then you use the synced signal on greens to dispatch the closest green. This does require working out the blue/red distances to only open the closest red not already in use.

mild wraith
#

That... could work?

high arrow
mild wraith
#

Listen, I'm thinking about a lot

indigo crater
#

Some times having learned more lets you hear something you didn't before or a slightly different phraseing when in a some what difference head space lets it sink in.

high arrow
mild wraith
#

So reds enable not just on "has sufficient local inventory" AND "fewer than threshold other red stations available",

But also on "blue for this item has enabled"

high arrow
#

Well maybe, idk

mild wraith
#

(I do already also have "count of waiting trains" encoded to the " locomotive " signal on the radars)

indigo crater
#

Another option is to use the distance between green and blue to only add the given blue signal to the green rotation when that green is the closest green to the blue.

#

The problem there is when several blues are open at once.

#

This is why by the way I tend to say you just about have to make and program a full fat computer to make pull systems work well.

high arrow
#

Or a situation like this

image.png
#

You'd vastly prefer the first green, but closest green to blue would select the 2nd

indigo crater
#

it would be simpler to manage just the green blue distances as apposed to blue red distances and just eat the edge case.

high arrow
#

Yeah, it's a two step process to do it 'right' I think. Determine which red, then determine which green based on which red

mild wraith
#

Agreed.
🟩 to 🟦 distance.
And then if the 🟥 it goes to means backtracking or a circuitious route, that's... fine.

#

(For context, I work IRL in civil engineering)
My engineering brain is fighting hard to force me to consider the "do nothing" option.

Being; what are the ups and downs of just.... leaving it as is?

#

And honestly..... the distance inefficiency problem is seeming increasingly like it's not that bad, considering the alternatives.

high arrow
#

It has a limiting effect on the upper end of your system, you'll reach the limit somewhat sooner. You can engineer around it to be somewhat smart even ignoring it

indigo crater
#

If the system you have works for what you are doing and isn't causing signifigant problems the worst you have to deal with is longer delays between deliveries which so long as the rate of delivery is enough and the buffers can hold the delay doesn't really matter.

high arrow
#

If you're at like 30% of track throughput it's just a few more trains

mild wraith
#

Yeah, I think I've been aiming for "perfect, regarding distance considerations"

I should instead see if there's any low hanging fruit i can pick, regarding distance things.

indigo crater
#

While we might like the better solution we also know that things like roudabouts and bidirectional rail have there place.

high arrow
#

There's some trick with 20 for sqrt by hand, lemme see if I can find it

indigo crater
#

You don't need sqrt for distance.

mild wraith
#

Without considering distance at all, I've already got my 2 main goals down;

  • minimal individual trains, I've currently got just 20 total trains servicing like 164 total stations.
  • management of stations pushing byproducts, and specific stations for managing or storing those byproducts.
indigo crater
#

as x^2 + y^2 will have the same sorting as SQRT(x^2 + y^2)

mild wraith
#

You'd need to sqrt to find the actual distance in the units of the grid system.
But just for comparing distances, you can compare the magnitudes of the pre-sqrt values.

high arrow
#

sqrt not necessary here, you right

indigo crater
#

We don't need the real distance here just things sorted from closest to farthest

mild wraith
#

I love "distances" being conveyed in units of "area". Very fun.

indigo crater
#

On the subject of distance I have debated making a flood fill combinator set for rails where each power pole distance you have repeater combinators that add one to a given signal and pass it on. build it right and this could resolve some of the fiddely problems.

high arrow
mild wraith
indigo crater
#

THe point was to propogate along the main so the distance was rail distance.

#

THis also lets you add more to some things if you want to discurage some paths.

#

Yes this is reinventing A* why do you ask.

high arrow
#

So with a dual wire multiplexer, you can have requests on red, and provision stuff on green. Each station can encode its type on either, and each station can have it's own type ID, so a stone provider/requester could have a different ID for the two clocks, that's fine.

When a blue station is ready to request, it waits for its slot, and then broadcasts [blue+X+Y]. All of the providers of both types see this.

They now will broadcast their distance to the requester on THEIR tick, with their ID, which all the other providers see. So if a higher priority request comes through, a station will know that it doesn't get to go. If a station sees another broadcast of same priority, shorter distance, it also knows it doesn't get to go. If it makes it all the way around to its clock again, it's shortest and gets to go

#

Providers will broadcast [red+X+Y] or [yellow+x+y], w/e

#

You can do a not-so-fancy trick there and just have higher priority on the lead bits be a lower number and do a clean <

#

That way it's always less than any distance of a lower priority provide

#

"Anyone else < me? I sleep"

#

That covers the 2 step process too

#

Since both are request-provide pairings

mild wraith
#

That would work.
It'd require me to scrap my "only enable this station based on global of the count of other similar stations being low enough", as that system requires the counts of stations to be encoded on the radar broadcast (as it currently is)

I definitely could scrap that system... and free up the red radar wire to hold other encoded data. its one of the first things I implemented to the system, but it's since become fairly redundant with other features..... I do still very much like my ability to turn off my stone mine until my "stone byproduct from other processes" stream runs dry enough.

The other issue i see, if I'm reading things correctly, is that it would cause my 🟪 stations to have to wait for a corresponding 🟦 to be available...... which sorta defeats the whole reason to have 🟪 stations in the first place?

high arrow
#

I mean, that's one of the reasons why a combo push-pull is even harder lol, I think you ahve to handle their behavior differently

#

You could probably try to do some pairing with that still

#

Have them be Greenlit, wait around for 20-30s or something for a request, and if not then take it to the central storage

indigo crater
#

Do you really need the active providers though or are they just passive providers with a higher priority.

mild wraith
#

The red stations get pulled from only if a blue station is available;

image-130.png
#

The purple stations get pulled from regardless of if there's a dedicated drop point available for the items;

image-195.png
high arrow
#

I mean I get the principle, if the purple output is less than total consumption, this makes sense

#

It is fancy priority but it's logistics on rails lol

#

You'd also bone yourself if you overprovided into purples in logi chests, but be fine if it wasn't overprod

mild wraith
#

In pY, there's enough processes that kick off byproducts that I do in fact need to be confident that the byproduct won't back up and clog the process.

#

Like, every ore processing chain kicks off stone/gravel/sand/soil, in varrying amounts.

high arrow
#

Py is a good excuse for pull

indigo crater
#

Just making purple high-priority red should work so that they get used before other red sources it is basically the same thing. All making them active does is add a bit more buffer in the form of storing in trains.

high arrow
#

lol I'm completely sold on rule of cool here

#

Is it good? No lol

#

Sticking to the spec is wicked cool here tho

mild wraith
#

Making the purples hust high priority reds would mean I'd need a blue pulling the items.
Which would mean eventually that pull would run out of items from the "purples", and start pulling them from actual reds.

high arrow
#

Only when rates demanded it, IE the system functioning >.>

indigo crater
#

When I did space exploration I made a priority system that applied only to producers, all consumers where considered the same. It does work assuming the factory ratios can deal with all the byproduct

mild wraith
#

I'm not confident in pY having ratios or consumption rates that are that convenient.

They might turn out to be? But... id rather set up my system to be able to handle if they aren't.

Hence, Orange stations to be a "passive pull" counterpart to the "active pull" of blue stations.
And purples stations to be the "active push" counterpart to the "passive push" of red stations.

indigo crater
#

Py more or less has to be set up like that or else you will have accumulating boxes of junk that you can't do anything with. I haven't played py so I don't know if that is the case but I presume not.

mild wraith
#

(Additionally, a significant portion of my set of station colors is just to have 6 distinct types, so i can have a clean ROYGBP rainbow)

indigo crater
#

Still I do understand wanting a more feature ritch systen

mild wraith
#

I think the train system is have currently is sufficiently "feature rich" for my current needs.

And by the time the "distance inefficiency" gets to the point that it's a problem, I'll hopefully be able to mass produce trains enough that I can start putting trains on for each specific item, and use a more traditional "all push" system.

Or... I could just deal with the distance inefficiency by upping the threshold at which 🟦s request items, so there's more in the local tank to account for travel time.

mild wraith
#

I keep seeing some trains that get caught waiting at reds in my live file.....
And it's very difficult to diagnose the problem retrospectively.

mild wraith
#

@faint locust if you jump to the top, you can read through my description of my existing system.
it's not a pure pull system, as i did make some function for specific stations to push items.
i can share my blueprints if you're interested.

high arrow
#

Oh shit selectors allow you to sort by distance, and it's not like the stations are moving around. You can cache all the distance information after calcing it once, and each station uses a filter against a list of ready stations. Some requester pops, it takes the list of currently available providers of any type, filter it against the distance list and compare the distances. Can use the lead bits type filter

#

You can automatically determine those timings too, it doesn't need to be GPS, you can request a train to run a clock on it and see how long it takes for that trip

#

My autoclock circuit is only +4 combos

image.png
mild wraith
#

I also had not considered just storing distances centrally and selctor-ing them.

#

Hmmmmmmmmge

high arrow
#

I think each station gets its own, but that should clip things down a fair bit anyhow

mild wraith
#

Could probly clump stations together?

Even if not doing very discrete "city block" style designs, and area doing [crafting process] is likely gonna have a few stations for inputs/outputs close enough together that they can all be said to have the "same" location.

#

To "calc" the distance info for newly constructed stations.... you'd have to assume the 🟩s arent moving. Which is probly a safe assumption?

But you'd also have to calc distances to the new station from each set of 🟩s....

#

And you'd be missing data for older stations around the factory if you end up adding more 🟩s at a later time...

#

So having a system that automatically stopwatch-es travel times, and sends them to the central command, would be highly convenient.

high arrow
#

Yea you can measure from branches and merges with waypoints

mild wraith
#

Hmmge

Right.

So we'll call clumps of stations that aren't 🟩, "Sites".

Currently I've got 3 🟩 arrays, and like 15 Sites... maybe more.

At least that's only 2 dimensions.

Adding another site means another row,
And another 🟩 array means another column.

mild wraith
#

I'm thinking.... just have 1 pace-maker train.
Its entire job is to cycle through all pairs of 🟩 and sites, for the sole purpose of getting times.

high arrow
#

No, though the clocker won't run if the system is operating

#

Clocking assumes it's going to be wrong lol

#

So it'll only send one train and it tracks how long the train is on the clocker station's count

mild wraith
#

Makes sense.

#

Hmmmm actually having a pacemaker train that's just 1 locomotive means it'll be more zippy than the actual trains.

#

And a full-fat pacemaker would maybe be more extra traffic on the network than its worth?

high arrow
#

You only have to run it at startups and honestly, you don't need tick accuracy, so allowing random traffic to impact it isn't the worst

mild wraith
#

Ehh, probly right about how accurate it would need to be.

Still, if times were only measured once, i would have a nagging feeling that maybe one site's time got scuffed by oddly high network activity, or it got an amazing time cos it had all green lights.

high arrow
#

As you noticed for the GPS though, 100 tile tolerances are acceptable

#

If you've got a global clock it's not so hard to have it pause for the clocking train either

mild wraith
#

I guess,

If my route is 500 tiles long, and goes through like 15 intersections, what's the difference in travel time for an all-green-light run VS one that has to stop at all 15 intersections?

high arrow
#

lol quite bad

#

It's 5 seconds at speed

image.png
mild wraith
#

"Bad" meaning, "not a large difference in time"?

high arrow
#

As in, it's 5 seconds for full greenlight, and an additional 5 seconds for one red light

#

The difference in time is exceptionally bad

mild wraith
#

Okay, so. Lots of variance between best and worst case.

And I'm also likely going to upgrade to different fuels at some point, that'll change things regarding single-measure times made on the old fuel.

#

Anyways, regardless of if times are measured once or multiple times,

The data still has to be stored somewhere.
And that's gonna mean learning how to make a central "brain" that can store all the data, and also doesn't require 80 million combinators.

high arrow
#

There's also the funny consideration that maybe you do want to measure traffic

#

If one direction reliably hits 2-3 redlights, and the other hits 5-6, then you'd want to know that

#

if you measure an average run for both, they'll be accurate

mild wraith
#

Oh! Okay I'm sold on having a pacemaker train that just loops between greens and sites;

Blackout protection.

Absolutely no shot I'm gonna go around and manually re-measure all the stations in the event that my electrical grid dies, and I lose all my data.

high arrow
#

lmao yeah for sure, and 'still functions when not initialized' is probably easy enough, if they're all zero distance you still get a pass case

mild wraith
#

Ye

#

This line of thinking seems VERY promising.

#

And while it will involve a sort of "full-fat computer", as Nuggreat would say,

Storing a 2 dimensional array of distances, and dispatching based on a selector sorting the distances from there, seems like a fairly tame computational task.

high arrow
#

1d honestly, just time, it's not even xy

mild wraith
#

Maybe I'm using "dimension" wrong there.
Anyways.

high arrow
#

If you're counting index, I didn't

mild wraith
#

(I'm gonna start using ⬜ to mean sites)

I'll need to store values for each 🟩 - ⬜ pair......
Hmmge

#

Hmmmmmmmmmmm

#

More practice/skill development on my end is needed on memory cells.

high arrow
#

shit

# 
[0.0, 1.65, 3.3, 4.949999999999999, 6.6]
>>> [[x*1.65 for x in range(y)] for y in range(5)]
[[], [0.0], [0.0, 1.65], [0.0, 1.65, 3.3], [0.0, 1.65, 3.3, 4.949999999999999]]```
#

1d array, 2d array

mild wraith
high arrow
#

I get index on both >.>

# 
1.65```
#

[2][1] is 2nd item in the third array

mild wraith
#

Ngl, I'm only sorta understanding what you're conveying here.

high arrow
#

There are programmatic and mathematic conventions about dimensions

mild wraith
#

Ye, I'm just not familiar with the exact conventions/syntax.

#

Been outta school for too long. And even then, my higher level math classes used very little "computer science" notation.

high arrow
#

This is a one dimensional array of pairs

image.png
mild wraith
#

Got it.
First number is station.
Second number is distance.

That does mean you're assuming that one end of any given route is both singular, and static. Right?

Otherwise you'd need the vectors to be <start_station, end_station, distance>, no?

high arrow
#

It'd probably be harder to encode a bunch of maps like that, but I'd try real hard not to

#

But yeah that's definitely an option too, that one you might be better off as a 2d array

mild wraith
#

If I'm assuming the start station is the singular and static, then what's the point here?

That'd mean it doesn't matter which 🟩 i dispatch a train from; there's only 1, so there's no need to decide which train to dispatch.

high arrow
#

Yeah, those are the kinds of simplifications to look for

#

Things you don't have to do b/c of ways to arrange stuff

mild wraith
#

I suppose thinking about a simplified version of the problem is a good exercise

high arrow
#

If you know times to waypoints from places, and times to other places from waypoints, that's both

#

So you can do a lot of simplification with doing clocks to certain points, that's the only reason I could schedule all the trains I did

#

It's not N:M, it's N:1:M, drastically decreases data storage

mild wraith
#

I think I'm misunderstanding something about your approach.... gimme a sec to think through and process things.

high arrow
#

10 providers, 10 requesters, that's 100 unique paths, N:M, 100 clock times. If you time them all through the same point, you need 10 clocktimes for the providers to reach the waypoint, and 10 clocktimes from the waypoint to reach the requesters, and you can reconstruct all of the paths

#

In practice it'll probably be more like 3-4 waypoints but that's still dramatic

mild wraith
#

HMM
But the distance from 🟥-A to 🟦-X isn't necessarily the same as that same path, but with a given waypoint included in the middle?

high arrow
#

I mean, the idea is to put the waypoint at a shared spot so it counts for multiple

#

I know the providers time to the clocker station. I handle the clocker to drops in another way

image.png
#

Launcher to clocker delay

image.png
#

Clocker to desto delay

image.png
mild wraith
#

Ah.
Yes.
Your "Waypoint" is what I'm meaning when I say "Site"

The waypoint is acting as proxy for a specific station, because 🟥-A is close enough to 🟥-B that we might as well just call them both "waypoint-J"

#

Right?

high arrow
#

It's very closely related, in that you're grouping stations, but this concept is about grouping instances of those

#

One red station group has an offset from a waypoint that's shared on your mains, another has a different offset

#

In most train bases there will be some tracks that are more main than others, tracks that most trains travel over

mild wraith
#

Oh.
Yeah I suppose.
I could conceivably have layouts of stations where the spatial difference between stations in the same "site" is non-negligible

high arrow
#

Placing waypoints between groups can allow you to break a true N:M into a few N:1:M subproblems

#

"These 8 destinations all cross this same track, I can time just the shared track and cut the storage down"

mild wraith
#

Ooohhhkay,
So a given "waypoint" isn't just some random point in space.

Its a place specifically close to some subset of stations.

high arrow
#

Yeah, the placement is chosen specifically to group up stations that go across the same track

mild wraith
#

I was assuming the distance from waypoint to any given "irondrop" station is negligible.

high arrow
#

Yeah, if we pretend this is just stretched out for a real map, this is 25 unique paths of varying lengths, but can be stored as 5+5

image.png
#

The red is clocking stations not your red 😛

#

You could have 6 stations in a group if you wanted to, it's very very close to the same concept

#

Those type of simplifications will save you so much work lol

image.png
#

Come to think of it, it'll also tell you what traffic patterns are looking like if you have a pacemaker running

#

Depending on which waypoints are increasing in traveltime overall, those are the ones that need to have traffic routed around, so that they've become longer is inherently correcting for traffic, fucking NEAT

mild wraith
# high arrow Yeah, if we pretend this is just stretched out for a real map, this is 25 unique...

Okay, so.

I put a break line in, to mean the distance between e and v is any potentially very long distance.

It would indeed be very silly to try and track distance from a to b, and a to c, and so on. The distance from any green letter to any other green letter can be assumed to be 0.

The same is true for any pair of blue letters. They're all functionally at the same spot.

And it follows from there, that the distance between a and v is the same as the distance between a and z.
Because v and z are functionally coincident.

There's one distance worth storing in the picture, and that's the distance from c to x.

image-229.png
#

I don't think we have any real disagreements, on the amount of assumptions being made, I think we just talk about them differently and it's muddying the water.

high arrow
#

This is me trying to indicate the grouping you had first mentioned 😛

image.png
#

Both exist

#

I had a feeling you wouldn't take my 'these are spread out' correctly lol

#

Spread out AND subgrouped both

image.png
#

This group is the same in the way you're indicating

image.png
#

You can do that, and also only care about their distance to one point between source and destination

#

Is this more clear, with them all being timed to purple?

image.png
mild wraith
#

Ye.
We on the same page.

high arrow
#

lol fair enough, I was prepared for that to be a miscommunication b/c I knew what I was saying wasn't the clearest

mild wraith
high arrow
#

Yeah I'm definitely coming at it from a 'The base is 5km+ across' perspective lol

mild wraith
#

So....

  • we call the purple point "P"
    • to the west of P is that branch containing multiple "launcher+stacker" blocks.
    • to the east if P is the "rest of the factory"
  • we pick any one "launcher+stacker" block, and call it D.
    • the only way to get to D in the branch West of P, is to go through P
  • we have a set of points "R" within "the rest of the factory", East of P.

An ordered list of points R, sorted by their distances to D, will have the Rs in the same order as if we sorted them by their distance to P.

The distances from D to P is irrelevant, specifically because the only way to get to D is to go through P.

#

But there's not just 1 point functioning like P.

P is also a set of points.

So we still need to store the distances from any R to any P

high arrow
#

I mean, they could be irrelevant

#

I have 32 stations on both ends so for me, it's 32:32 possible paths

#

I can(and did) store that information in 64 numbers. But it's 1024 unique path lengths I have with those 64 numbers

mild wraith
#

I'm not seeing any cases where the distances from P to D are relevant.... I must be missing something.

high arrow
#

D(12) to R(26) is D(12) to P + P to R(26)

#

This is a voltrain and a half of distance for me, but this system covers literally infinite distance

image.png
#

I only need to know how far it is from there, to the clock

mild wraith
#

When selecting which R(i) is closest to D(12) the R(i) that is closest to P will also be closest to D(12), every time.

high arrow
#

Oh for your ordered sets? Yeah I suppose you can simplify an extra step can't you

#

Yeah that's the simplification through P though

#

I was still thinking about actual times, b/c of the traffic thing

#

Allowing them to change

mild wraith
#

I definitely don't need to track distances from each R to every stacker/launcher within a given D

And I also don't need to track distances from each R to each D, within a given P.

If Ps were also branches off a shared point Q, then it'd go another level down, not needing to track from each R to each P within the Q

high arrow
#

Yep, you can nest them

#

This whole thing is really cool, thanks for putting this thread up. I think I can actually take some of it back with me, I've been trying to figure out how to do unsigned grid and this adds a huge piece

mild wraith
#

Regardless of the "depth" of any given branch; how many "levels" it has, there's a list of "highest level shared points" i need to care about.

#

Wait

#

I scuffed the variables.

#

Pretend those "Rs" are Ps.

#

If that was my network layout, and all my Rs are above the "root"

Then I'd only need to store distances from each R, to Q1, Q2, and D8

#

Swinging back to my fancy color scheme;

My R(i) set is my 🟩s
And the "top level sub-root nodes" are my ⬜s

#

D(8), Q(1) and Q(2) would be ⬜s, in the hypothetical network i drew up.

#

That's what I mean when I say I need to store the distances from each 🟩 to each ⬜

high arrow
#

Yeah you may have loops as well, branches that reunite later, alternate paths

#

Maybe

#

Might be better to stipulate not

mild wraith
#

If i had loops, then they shouldnt be treated by the system as "top level sub-root" nodes.

#

And I'm okay adding a stipulation to my network layout of "no loops within branches"

#

If there's loops between 🟩 and ⬜s; that's fine.
The pacemaker train, being tasked with going from 🟩-i to ⬜-j, will pick the shortest route if multiple are available.

#

So, actionable tasks to put on a to-do list;

  • figure out how to make nested interator loops with combinators, so my pacemaker train can loop through all the distances I care about.
  • figure out how to make combinator memory that can store distance data
    • In the format of values existing in a table between indexed 🟩s and indexed ⬜
    • make the memory able to be written to by the pacemaker system.
#

Nice.
Ez.

#

This seems incredibly promising

mild wraith
#

Some cursory thoughts on actual implementation, and how it might mesh with the functions/features of my station blueprint set as it currently exists;

  1. I currently use a list of valid wildcard targets to enable dispatch towards 🟪 or 🟥 -> 🟦 for that given wildcard. I'd like to keep that sort of function.
  2. currently, enabled stations broadcast their counts over radar.
  3. stations that are wildcard dependent ( 🟥 🟦 🟪 🟧 ) append to the count for their color and wildcard this all 32 bits on the red radar wire.
  4. stations that are not wildcard dependent ( 🟩 🟨 ) append their count for color and wagon type to the locomotive signal. This eats all 32 bits for that signal on the red radar wire.
  5. refueling stations ( ⬛ ) do not have their counts of enabled stations broadcast
#
  1. And adjustment value, for each wildcard, is subtracted from the list of valid targets. Adjustment value is composed of the following:
  2. Counts of trains on the way to or at 🟦
  3. Counts of trains on the way to or at 🟥
  4. Counts of trains on the way to or at 🟪
#
  1. I will need to add functionality to my 🟥 and 🟪 stations. Those are the stations for which i might care about distance from 🟩 . I still don't plan to account for total round trip distance for [ 🟩 -> 🟥 -> 🟦 ] routes.
#

Actually maybe I do want to account for that.

high arrow
#

lol if how hard the question is gets easier, two questions doesn't seem so bad

mild wraith
#

Thinking about purples first I think will be easier.

#

When a 🟪 enables, i only need to determine which 🟩 is closest.

So at each 🟪 station, I will need to tell it which ⬜ ID it belongs to.

#

So the system can then find distances from each 🟩 to that ⬜ ID.

#

Which means I'll need to have the 🟪 contain their ⬜ ID in their constants. (And likely, have that be a parameter prompt in the blueprint)

#

I'm gonna need a "processing que"

And a way to ID stations to be added to the que

#

Maybe?

#

My adjustment value is currently carried on bits 0 to 7 of the green radar wire.
I could use bits 8 to 15 for carrying TDX IDs of enabled 🟥s
And 16 to 23 for carrying TDX IDs of enabled 🟦s
And 24 to 31 for TDX IDs of enabled 🟪s

high arrow
mild wraith
#

My brain.... I can feel it overheating.

#

I have purple stations enabling.
Their IDs get put into the que.
The IDs are carried on bits 24 to 31 of the green radar wire... and they're wildcard dependent.

" 🟪 cargo_wagon stone " with ⬜ ID of 1, send 1 on green radar wire stone signal, when 🕐 = 1.
......
That way.... the que can store the station ID and wildcard target at the same time....
If the current front of the que holds " 1 stone ", i can use the 1 to know which ⬜ need to select shortest distance for.

And once I find which 🟩 is shortest, i can flash " 1 stone " to that 🟩s stations.

So any trains present will see the signal, and move to the 🟪

#

Yeaaaaaahhhhhhh

#

I can still use my "forward to next station within the 🟩 site only if this station is empty" trick to ensure only 1 train can see the flash .

#

The flash won't contain any info the interrupt can use to know exactly which 🟪 stone station to go to if there's multiple open.....

It should pick the closest one tho, right?

high arrow
#

If multiple open, yeah

visual fieldBOT
high arrow
#

To save you the trouble, it's a funny circuit trick

#

R+G is insanely stonk

#

.... I should've documented that. It holds until the one below it doesn't have a value, then clears, so to stop it from draining have a signal on the final post

#

Hold while any on green!=0, this pole. Input is green wire on far corner

image.png
#

...red? Maybe red. Fuck

#

That corner lol

mild wraith
#

For purple stations, the interrupt conditions ensure the stop isn't already spoken for.
And the forwarding hold ensures only 1 train can be dispatched on any given tick.

But for the 🟥 🟦 interrupt, things get messy.

I'll still need to check the adjustment list value and/or valid targets list..... and only send the ⬜ ID if its for a valid target.....

■ somewhat new idea newline

  1. 🟦 enables.
  2. It sends its its ⬜ ID over green radar wire bits 16 to 23.
  3. The system puts " < ⬜ ID <wildcard> " into the que.
  4. The system finds the closest green to that ⬜ ID.....

Which isn't what we want. We don't want the closest green to the 🟦's ✅ ID.
We want the closest 🟥 to that 🟦, and in turn, the closest 🟩 to that 🟥......

#

I need to be productive at work. Gonna put this on the shelf for now.

high arrow
#

lol aight, to toss one more concept onto the pile for you, I do like the idea of some decentralization here. The blue makes its request, then once you decide on a red station that station makes its own request

#

Rather than trying to stack it, just recurse

mild wraith
#

That's probably better

mild wraith
#

I'm gonna need to restructure my interrupts.

#

Instead of that,

Have 1 interrupt for "go pickup"

And then another for "if at red station, go to blue station"

#

And then.... I'll need to be clever about when and where to send the signal wildcard requisite for triggering the " cargo_wagon Retrieve Cargo 🟥 " interrupt.

mild wraith
#

So with purples...

  • 🟪 enables
  • 🟪's attached ⬜ ID and Wildcard get sent and put in the que.
  • the dispatcher reads the top of the que for the ⬜ ID
  • the dispatcher determines the 🟩 that is closest to that ⬜
  • the dispatcher pings that 🟩 with the wildcard signal required to dispatch a train.
  • the dispatched train will trigger 🟪 interrupt first, and naturally go to the closest 🟪 if multiple are available.
  • after the train has picked up at purple, other interrupts will tell it what to do with the cargo.

Great.

For the red interrupt.......

  • i still need something to identify that both a 🟥 <WC> and a corresponding 🟦 <WC> are BOTH enabled.
    • currently, that get done by the interrupt conditions.
    • and double dispatch is prevented by clock, valid targets list, and adjustment values.
#

There's a few scenarios that could occur with the 🟥 / 🟦 pairing situation.

A 2x2 grid with rows being "which color enabled?"
And columns being "did it make a match?

#

I only want to take action in the case where a match is made by a station enabling.
And when that happens, the action to be taken is the same.

#

So that's nice.

#

Hmmmmmmmmm.....
It's not a 2x2 grid of occurances.

#

PepoBusiness very productive at work

#
  • non-match cos 1 enables to 0 partners, that's easy.
  • match cos 1 enables to 1 partner, that's also easy.
  • match cos 1 enables to more than 1 partner; that's the complicated one.
#

Hmmge am I gonna deal with tracking ⬜ to ⬜ distances as well?

mild wraith
#

.... no.... I don't need to....

  • If there are multiple 🟦s to a singular 🟥 , and i find the 🟩 closest to the 🟥, it'll naturally go to the closest :blue after finishing at the 🟥
  • if there are multiple 🟥s to a singular blue.... I'll need to find the shortest distance among all the possible 🟥 - 🟩 pairs, and send to that 🟥
#

Yeaaaaaaaahh
That second one is gonna be hard.

mild wraith
#

As much as I don't want to, I think I'm gonna need to make some more major reworks to the blueprints as a whole.

I can clean up combinator count on the way as well.

mild wraith
#

Hmmge I could also rearrange how I encode data to radars.

#

I think the "only enable this stop if X of fewer other of the same stops are available" is a non negotiable feature.

#

So counts of enabled stations has to stay.

high arrow
#

Count of enabled does seem like a pretty necessary step, I think to keep the trains moving properly you'll end up having a few open some of the time but not all

mild wraith
#

Ye.
So that's the whole red radar wire spoken for, at least as far as wildcard candidates for things actually loaded to trains.

mild wraith
#

cool

#

i've learned to count

mild wraith
#

I think today will be "progress on pacemaker train" day.

#

Developing a way to get the train to loop through pairs of stations is gonna be the rough part.

#

Before I can start "writing down" times, I need to ensure that the train actually hits every pair of stations 1 time per loop.
And I need the system to be able to handle me adding new stations of either type.

#

Stations in a schedule with no wait condition..... the trains just blow past at full speed, if there's another station next in the schedule and the rail/pathfinding allows for it, right?

high arrow
#

Waypoint stations, yeah they cruise them if the next is available with no station interaction at all

#

They only interact with stations at 0 speed

#

No interrupts either

mild wraith
#

Great.

#
  • go to ⬜
    • no wait condition
  • go to 🟩
    • wait until [ check = 1 ]
#

Oh!

#

It can't be 🟩.
It'll have to be .... there's no :gray_square: default emoji. Lame.

#

Gray stations represent the spatial approximation of greens.
White stations represent the spatial approximation of... every other station type on the network

#

Hmmmm....
I'll need the central computer to control which pair of gray and whites are enabled.
Such that only those 2 are enabled, then the train can be sent a check , it'll make a round trip, and it's time will be stopwatch'd and written down, before the next pair is enabled....

That'll have the problem of.... needing to get the train to the correct gray station.... before setting up for the next timed run.

#

So, "run for time" will probly have to be an interrupt.

#

The system globally tracking....

  • which white to enable
  • which gray to enable
  • if train is at the enabled gray station
mild wraith
#

.... my system doesn't allow sushi trains.

#

I should make it allows sushi trains.