Alow changing the level of logical blocks in schedule
Moderator: ickputzdirwech
Alow changing the level of logical blocks in schedule
The current system leads to situations like viewtopic.php?t=129566 where the only way to get the desired logic is to duplicate most of the behavior. This could be fixed by allowing you to change the level that and and or blocks are at, so you can do this
Last edited by its a me on Thu Jun 26, 2025 6:02 am, edited 1 time in total.
-
- Burner Inserter
- Posts: 15
- Joined: Mon Aug 19, 2024 9:56 pm
- Contact:
Re: Alow resizeing the area that logical blocks cover in schedule
Yes! You end up with contortions that are probably CPU eaters because we have no parenthesis.
-
- Fast Inserter
- Posts: 143
- Joined: Tue May 24, 2016 1:55 pm
- Contact:
Re: Alow resizeing the area that logical blocks cover in schedule
Agrea. It's the same with decider combinators.
Re: Alow changing the level of logical blocks in schedule
I achieve this goal by moving most of the Platform’s logic into a Combinator Contraption, next to the Platform Hub. I use a lot of different signals depending upon the Platform’s purpose, but generally the logic is “head to (Planet) when running low of (resource)-”. The resulting signal for “next destination Planet” is presented to the Hub using one of the Virtual Signals (the letter “P”), and then an Interrupt detects the Value (eg, Nauvis is “100”; Vulcanus is “200”; Gleba is “300”, etc…) to trigger the Platform’s schedule.
Re: Alow changing the level of logical blocks in schedule
Can we get some more feedback on this it seems to have gotten buried.
Re: Alow changing the level of logical blocks in schedule
I think the best solution to this problem would be to add the ability to create custom, named condition blocks, kinda similar how we can create and name train interrupts.
That way we could create our own logic block, for example "All Vulcanus requests satisfied", and use that instead of checking for all the requests being satisfied. That block would, naturally, contain all the checks for the relevant requests being satisfied, but since it would be it's own named block, it could be both reused multiple times, and also behave as if all the expressions within are enclosed in a parenthesis.
These named, custom logic blocks should be creatable in all relevant places (decider combinator, train schedules, ship schedules).
To expand on this, it would be nice to be able to define constants for these named logic blocks, which constants could be set to a different value at every place where said block is used (kinda like passing a value to a function in programming)
If you could use logic blocks inside of other logic blocks, it would allow creating some truly complex conditions relatively simply, albeit at the risk of creating infinite loops (which would have to be checked for, and the player warned).
To be honest, I don't think it's necessary to allow nesting named logic blocks, almost all use cases should be covered by simply being able to use them.
That way we could create our own logic block, for example "All Vulcanus requests satisfied", and use that instead of checking for all the requests being satisfied. That block would, naturally, contain all the checks for the relevant requests being satisfied, but since it would be it's own named block, it could be both reused multiple times, and also behave as if all the expressions within are enclosed in a parenthesis.
These named, custom logic blocks should be creatable in all relevant places (decider combinator, train schedules, ship schedules).
To expand on this, it would be nice to be able to define constants for these named logic blocks, which constants could be set to a different value at every place where said block is used (kinda like passing a value to a function in programming)
If you could use logic blocks inside of other logic blocks, it would allow creating some truly complex conditions relatively simply, albeit at the risk of creating infinite loops (which would have to be checked for, and the player warned).
To be honest, I don't think it's necessary to allow nesting named logic blocks, almost all use cases should be covered by simply being able to use them.