#Interupt(Interupt) Usecase

1 messages · Page 1 of 1 (latest)

thick rain
#

For determining the usecase of an interrupt within an interrupt for trains

#

Im going to re-read the fffs regarding interupts to make sure im not misinterpreting anything

robust remnant
maiden sparrow
#

i wonder if you could make a computer using interrupts....?!?!

robust remnant
#

I'm pretty sure someone's already made a computer using regular train schedules

split pulsar
#

When they first mentioned it I thought it was going to have something with the land being active. Perhaps the train tracks getting blocked or destroyed temporarily for some reason. However now that I read the FFF it seems more like a spoil-related mechanic.

Imagine a train hauling a bulk of apples and it gets into a traffic jam. Not good. With the interrupt system this train would already be going to a station through some interrupt. However you may want to say "no, you need to deliver this fast because it's spoiling now". I have no idea how exactly that'd work, perhaps priorities or blockage checks, but it's an important decision.
Though I'd imagine that people would be incentivized to directly insert as much as possible instead of train hauling it.

robust remnant
#

It wouldn't work, as trains do not change their route until the leave a stop

#

That is, once they've decided where they're going, they'll go there and won't change their mind

robust remnant
#

I think I know the case now.

#

Well, idk actually Yeah no it wouldn't

thick rain
#

So starting with the first fff about interupts;

The way you control the trains is very static at the moment. You have a list of stops to visit, and the train just goes through them one by one and thats it. The only dynamic part is the wait time at each of the stops.
There is no way to just go somewhere else dynamically based on what is going on.

#

The usecase they go on to describe;

The most obvious annoyance caused by this limitation is the problem with how to refuel trains. In 1.1, you need to make sure that every schedule has a stop which also refuels the locomotives. For example, the Iron drop-off station at the main base also has an inserter for loading fuel. But the more distinct routes you have, the more refueling stops you need.

It is kind of boring and repetitive, and even more annoying when you want to change the type of fuel. The alternative is to have a dedicated refueling station and just put it into every schedule, but it feels very wasteful.

The actual logic of what we would like the train to do is pretty simple:
"Do your stuff, and only when you are running low on fuel, go to the dedicated refueling station".

robust remnant
#

You could just skip to:

Whenever the train wants to leave the current station, it checks all the interrupts one by one, evaluating the interrupt conditions. If the conditions are fulfilled, the interrupt is activated and the targets are pasted into the current schedule as temporary stops.

thick rain
#

id rather start from the beginning to make sure nothing is missed here

#

The available conditions are mostly the familiar set from the wait conditions (full/empty cargo, circuit condition, item/fluid count, etc.), with some special additions that only make sense for interrupts.

#

engithink

This is all very nice, but it kind of created a new problem, and its the fluctuation of trains availability based on all the unloading stations being backed up or not. This can lead to an excess of trains in the system when some of the resources or production is running low, and we need a way to deal with it.

So we just added a special interrupt condition called "Destination full", which allows us to make an interrupt to send a train to a depot if all the item inputs are occupied, so it doesn't block the current station.

#

Initially interrupts were specific to each schedule, but we eventually realized, that it is a really good idea to be able to share the same interrupt between different schedules. We had the problem where once we wanted to upgrade our fuel from coal to rocket fuel for instance, we would have to go through each schedule and update the interrupt, which was not only a big hassle, but often resulted in some trains not being updated.

So we made it that interrupts are shared globally (identified by their name), and when you edit an interrupt it changes for all the trains with that interrupt. This made it much more convenient and less error prone.

@robust remnant I interpret the following to be in the same vein why editing interrupts within interrupts is a pain. However, i think we are allowed to selectively choose which trains listen to which interrupts so not every single train will have the same set of interrupts

robust remnant
#

There are no "interrupts within interrupts"

#

And not every train group needs every interrupt, no

thick rain
robust remnant
#

no, I didn't

#

I'm not sure what that would even mean

#

There is a stack of interrupts, each with their own conditions

#

Every time a train leaves a stop, it assesses these conditions and activates the first one that meats it's conditions

#

Then the activated interrupt has it's schedule inserted as 'temporary stops' into the existing train schedule

thick rain
#

the act of meta interupt is equivalent to the following;

if (condition1) {
  if (sub1) {
    ...
  } 
  else if (sub2) {
    ...
  }
}
else if (condition2) {
  ...
}
else if (condition3) {
  ...
}

Right @robust remnant?

robust remnant
#

Normally, an interrupt cannot activate while another interrupt is in progress, meaning the current interrupt has multiple stops. If one of the interrupts in the stack has the "in interrupt" condition, however, it may override the current interrupt

robust remnant
thick rain
# 
if (condition1) {
  if (sub1) {
    ...
  } 
  else if (sub2) {
    ...
  }
  else {
    ...
  }
}
else if (condition2) {
  ...
}
else if (condition3) {
  ...
}

This time with the else statement

#

is that correct?

robust remnant
#

No, interrupts are not nested

#

They get evaluated one at a time, if one doesn't trigger, it goes to the next

thick rain
robust remnant
#

It's not an interrupt within an interrupt, it's just another interrupt

#

They are not nested

thick rain
#

so,

if (condition1) {
  if (condition2) {
    ...
  }
  else if (condition3) {
    ...
  }
  else {
    ...
  }
}
else if (condition2) {
  ...
}
else if (condition3) {
  ...
}

is what you are describing then

robust remnant
# 
if (condition1) {
  ...
}
else if (condition2) {
  ...
}
else if (condition3) {
  ...
}
thick rain
robust remnant
#

Well you didn't specify the conditions

#

condition2 could include (in interrupt)

thick rain
robust remnant
#

yes, that's what I did

thick rain
#

so if it makes sense, interchange conditionN with interuptN if suits for readability

robust remnant
#

so say condition2 includes the (in interrupt) condition, then it would only ever activate if any other interrupt inserted a schedule with more than one stop.

thick rain
robust remnant
#

Because if it has only one stop, then it will go to the stop, and the interrupt will end when it leaves, so it will no longer be in an interrupt

#

So then any other interrupt could trigger

thick rain
#

Normally, when an interrupt is activated, other interrupts won't be able to interfere until it is finished. But in some specific cases, this is too limiting, so we added a another special interrupt condition, called "In interrupt". This allows the interrupt to trigger while another interrupt is in progress, which clears the original interrupt and replaces it with the new interrupt targets.

engithink So this sounds like the conditions that we can place exclusively inside of interrupts. Right?

robust remnant
#

Yes, "in interrupt" wouldn't make sense as a schedule condition.

thick rain
#

ok, so note the following image. They are editing the depot interupt which can have more than one station assigned to that particular interrupt

fff-389-depot-interrupt.png
#

so if theres more than 1 station that it needs to travel to as part of the interrupt, it wont listen to any other interrupts as its navigating through its stations.

#

correct?

robust remnant
#

According to their description, no.

Normally, when an interrupt is activated, other interrupts won't be able to interfere until it is finished.

#

With the exception of interrupts with the "in interrupt" condition

#

I agree with the FFF when it states that

There is some very specific case where this is a crucial thing to have, but it is on a planet we didn't reveal yet, so more on that later 🙂 .

#

It must be absurdly specific due to the conditions for it to possible be required

#

Being

  1. you have an interrupt with multiple stops
  2. this interrupt can be cancelled without creating issues
  3. you somehow can't use a different train for this purpose
  4. it's either not possible or otherwise unreasonable to use a dedicated train
    probably more too
thick rain
#

i think we are saying the same thing but just to make sure...

Take the following train schedule;

- Interupt Albert (Fire on condition A)
  -> navigate to station Alpha, wait 30 seconds
  -> navigate to station Bravo, wait 30 seconds
  -> navigate to station Charlie, wait 30 seconds
- Interupt Bob (Fire on condition B)
  -> Navigate to station Echo, wait for item input amount
  -> Navigate to station Alpha, wait for cargo empty
- Interupt Carl (Fire on condition C)
  -> Navigate to station Delta, wait for item count
  -> Navigate to station Bravo, wait for circuit condition
#

Now, if condition A fires, I am to believe that the navigation to stations alpha, bravo, and charlie are all part of the interrupt Alberts schedule, right?

robust remnant
#

Yes, assuming none of the interrupts have the "in interrupt" condition, it will go to all 3 stations if condition A is fullfilled

thick rain
#

So in this scenario, if I am in interupt Albert, navigating from station Alpha to station Bravo, and the condition for interupt Bob activates, I wont do Bob's interrupt until Ive completed station charlie AND assuming condition A doesnt fire again, right?

robust remnant
#

Yes

thick rain
#

now, if i want interupt Bob to fire, even while im doing interupt Albert or interupt Carl, Id use the "in interupt" logic to be part of condition B, right?

robust remnant
#

Yes, if you only included "in interrupt" it would also only trigger while another interrupt is in play.

#

you could include "in interrupt or not in interrupt" and my understanding is it would trigger either way

#

Actually I've just had a thought

thick rain
robust remnant
#

Theoretically an in-interrupt interrupt could interrupt itself

#

say that 10 times fast

#

So if you had some hypothetical situation where a train needed to visit a series of stops in order, but it could run out of "something" at any one of them, then it would need to interrupt itself to go back to the first.

#

The stops being in order would have to be important

#

It's a very bizzare scenario and I'm not sure what would fit it

#

I'm also not 100% sure this would require in-interrupt and couldn't be broken down into other interrupts and a schedule

thick rain
robust remnant
#

If the conditions match, it triggers shrug

#

If you make a looping interrupt, that's on you

#

Theoretically whatever values the condition checks would change between the trigger and leaving the first stop so it doesn't loop

#

It's just a possible idea for a vague use case, I still don't see how it would translate into gameplay

#

But it just might be specific enough to be what they were talking about trianglepupper

thick rain
#

Ok, lets say the in-interupt condition is also paired with the condition of needing to remove a particular item from the train. Now if we are inside interupt Bob doing this, if the interrupt is allowed to trigger again, then we would be stuck in a cycle of navigating to station Echo, right?

robust remnant
#

The only viable use case I remember being theorycrafted for in-interrupt was immediately invalidated by stop priorities.

#

For interrupt bob to trigger, some condition would need to be met, one of which is the in-interrupt condition. If non of these conditions change when the train leaves Echo, it will retrigger interrupt bob and go to station Echo again

#

so yeah, it would get stuck. But only if you set up the conditions and/or stations incorrectly

#

if leaving station echo has conditions that contradict interrupt bobs trigger conditions, it necessarily won't loop there

thick rain
robust remnant
#

The "in interrupt" condition is the exception to not interfering until finished

#

Why you would want to do basically require that is a whole other question

#

one that I haven't seen a good answer to since stop priorities were announced.

#

It's potentially related to other conditions we know nothing about yet, maybe a new type of wagon as well

#

Which we can't speculate about with any accuracy

thick rain
# robust remnant The "in interrupt" condition is the exception to not interfering until finished

Lets explore this from a different angle. Say we have the additional schedule;

- Interupt Albert (Fire on condition A)
  -> navigate to station Alpha, wait 30 seconds
  -> navigate to station Bravo, wait 30 seconds
  -> navigate to station Charlie, wait 30 seconds
- Interupt Bob (Fire on condition B)
  -> Navigate to station Echo, wait for item input amount
  -> Navigate to station Alpha, wait for cargo empty
- Interupt Carl (Fire on condition C)
  -> Navigate to station Delta, wait for item count
  -> Navigate to station Bravo, wait for circuit condition
- Interupt Darwin (Fire on condition D)
  -> Navigate to station Zulu
- Interupt Euler (Fire on condition E)
  -> Navigate to station Xray

If condition D fires, the train will navigate to station Zulu. After it is completed, and condition D is still active, and conditions A, B, and C are not active, Interupt Darwin will take place again, correct?

robust remnant
#

I imagine it should, yes

#

It would be a very bizarre situation, You would want the trigger condition to be cleared by the station/route you send it to.

thick rain
#

In the same vein, Interupt Carl with conditions C active, and nothing else, will do stations delta and bravo as part of its interupt

#

correct?

#

ok, now when we are in interupt carl, and condition C is still active, we arent going to process these conditions again until after we finished navigating to station Bravo, correct?

robust remnant
#

not until the train is leaving station bravo, assuming "in interrupt" is not a part of condition C

thick rain
#

but the in interrupt is already a condition. Is it not at the same level as all the other conditions?

robust remnant
#

If "in interrupt" was a part of condition C, and condition C is active when leaving station Delta, it would re-trigger interrupt Carl and go to station Delta again

#

assuming condition A and B are not active

thick rain
#

But didnt we just establish that an interupt would only be processed once it finished its current interupt?

The way i understand this is that for every interupt defined, theres a hidden condition behind the scenes that basically says "not in interupt". With an "in interrupt" condition, it basically allows that interupt to fire outside of that condition.

robust remnant
#

That's why I said assuming "in interrupt" is not a part of condition C, because otherwise it would be activated again

thick rain
#

because the conditions can be still calculated AS its doing the interrupt, but simply not acting upon them. And it doesnt make sense to try and process the same interupt again for the obviously buggy behavior of navigating to the same first station as part of its interrupt

robust remnant
#

It wouldn't be buggy behaviour, it would be poor planning on whoever designed the interrupt and stations

#

If you have an interrupt trigger on some condition, the condition needs to be cleared by the time the interrupt is finished, otherwise it will loop

#

If you include the "in interrupt" condition, being cleared when the interrupt is finished is no longer good enough, it needs to be cleared at the first stop it visits

novel rivet
#

Doesn’t it evaluate its state when it leaves a station

thick rain
robust remnant
#

Yes, so an easy way around this is to have the condition to leave the station contradict the condition to trigger the interrupt

thick rain
#

it kinda comes down to the question does an interupt reprocess doing itself as its executing itself? A simple identity check can prevent this behavior from occurring

#

kinda half tempted to ask klonan about this given they and kovarex wrote that FFF togethor

robust remnant
#

I don't see why it wouldn't. Not doing so would be even more limiting

novel rivet
#

This is gonna be one of those things that smart people understand and I don’t

#

How about this use case

thick rain
novel rivet
#

You have some junk that the train carries around cause it has to dump that stuff into the recyclers. So you want to wait until the junk is almost full and it’s near the recyclers in order to dump it

robust remnant
#

It is limiting by description, you'd be preventing otherwise normal behaviour by disallowing a trigger that has all the conditions met just because it would trigger the same interrupt.

novel rivet
#

So you wait until like your steel dropoff is happening to dump the junk

#

That’s maybe when you interrupt an interrupt

#

That’s all my smooth brain can come up with

thick rain
robust remnant
robust remnant
#

not a perfect analogy ChibiOhno

thick rain
#

i mean if you assume the ball is the interrupt, the act of it being in your possession is executing the interupt. You passing the ball is singaling the end of your interupt and deciding which other interupt to execute. But following that logic, it also makes sense to reprocess passing the interupt to yourself again, as all conditions should be viewed as equal

#

so then the in-interupt can be viewed as someone intercepting the ball when its being passed to a particular person trianglepupper

robust remnant
#

If you have a list of interrupts, it'll trigger the first one that has it's conditions fulfilled. (the interrupt sends the train to multiple stops)
After it's finished it's first, second, (not last) stop, it goes through the list again. It triggers the first interrupt that has it's conditions fulfilled, but because it's in an interrupt, it ignored any that didn't have the "in-interrupt" condition.

#

That's how I've interpreted it

thick rain
# robust remnant If you have a list of interrupts, it'll trigger the first one that has it's cond...

im viewing it as a secondary priority list. Sure you have the priorities of the non-interupts, but you can also prioritize the in-interupts in the same vein.

- Interupt Albert (Fire on condition A)
  -> navigate to station Alpha, wait 30 seconds
  -> navigate to station Bravo, wait 30 seconds
  -> navigate to station Charlie, wait 30 seconds
- Interupt Bob (Fire on condition B, includes an or-interupt)
  -> Navigate to station Echo, wait for item input amount
  -> Navigate to station Alpha, wait for cargo empty
- Interupt Carl (Fire on condition C)
  -> Navigate to station Delta, wait for item count
  -> Navigate to station Bravo, wait for circuit condition
- Interupt Darwin (Fire on condition D, includes an and-interupt)
  -> Navigate to station Zulu
- Interupt Euler (Fire on condition E)
  -> Navigate to station Xray

Interupt bob could be allowed to fire when its condition b fires, or while its in an interrupt. Interupt darwin would only fire when condition d and its in an interupt. But between bob and darwin, bob takes higher priority than darwin.

robust remnant
#

You can, but I don't see how that contradicts what I said.

#

The list is still there, it will activate the first in the list with it's conditions fulfilled, so ordering is important for priority

thick rain
#

I think its an agreement

#

All interupts are processed when it arrives at a station, right?

#

processed meaning evaluating conditions

robust remnant
#

When it leaves a station

#

or about to leave

thick rain
#

ok good. So if the in-interupt is defined to be a condition, then it should exist that all other interupts have a "not in-interupt" condition.

robust remnant
#

So once the current stations schedule conditions are fulfilled.

robust remnant
#

if it doesn't have the 'in interrupt' condition, in necessarily won't activate during another interrupt

thick rain
#

right.

robust remnant
#

which would be the same as having a "not in interrupt" condition

thick rain
#

so if we are inside of an interupt, then each time we are about to leave a station as part of that interupt, we would evaluate over the interupts that have the in-interupt condition.

robust remnant
#

You could look at it as two different lists of interrupts, but some interrupts could exist on both

#

one activates when no interrupts are active, the other list activates when there is an interrupt active

thick rain
#

this leaves the question if we are in the middle of an interupt with an in-interrupt, whether or not its allowed to execute again. If you view the in-interupt and not-in-interupt as seperate scopes of where they execute, its unclear if the in-interupt scope would move to an n+1 scope, or move back to the same scope as the in-interupt.

robust remnant
#

I would say given the information we have, all interrupts are fundamentally the same thing, there isn't "types" of interrupts. I would consider it odd if the "in interrupt" condition suddenly did nothing because another interrupt was also using the condition.

#

seeing them as different scopes might be useful to compartmentalise them, but fundamentally they are (or at least I think they should be) of the same scope.

#

Not clearly delineating the difference in the UI would be very confusing if it was of different scope.

thick rain
#

probably need a dev to speak on it at this point engithink