You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Casting tray cools in 60 ticks.
Basin cools in 100 ticks.
Therefore we want like
DEFINESCHEDULEOF
fill_casting_tray
sleep 60 ticks
after_casting_tray_cooled
ENDDEFINESCHEDULEOF
fill_casting_basin
sleep 100 ticks
after_casting_basin_cooled
ENDEVERY fill_casting_tray DO
input fluid::fromtankbottomside
output fluid::tocasttopsideENDEVERY fill_casting_basin do
input fluid::fromtankbottomside
output fluid::tobasintopsideENDEVERY after_casting_Tray_cooled do
input item::, fluid::fromtraybottomside
output item to storage
if every tray bottom side has lt 144 fluid::then-- just in case
output fluid::totrash
end
ENDEVERY after_casting_basin_cooled to
input item::, fluid::frombasinbottomside
output item to storage
if every basin has lt 1000 fluid::then-- math wrong idk
output fluid::totrash
end
END
? in this case the problem can be reduced from one that depends upon the contents of the inventory to one that depends on how much time has passed which makes it more efficient than checking the inventory contents to determine what to do...
except I guess that's not the case because you could end up with staggered filling of something that takes a long time to cool, you wouldn't want to wait a full cycle to start casting but if you don't then you may end up misaligned
basically, the declarative approach of "for each basin, if fluid insufficient to cast, dump fluid" when reduced to a scheduling problem results in wasted cycles due to waiting for the next cycle to perform the operation, but doing it on a schedule may be more perf efficient for large scale
Given that the manager block ticks every tick, each trigger is a predicate upon the state of the world when the manager is ticking.
Redstone triggers check the unprocessed redstone pulse count on the manager.
Timer triggers check the manager/world clock for remainder.
Schedule triggers (new) are desugarable to timer triggers
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
https://t3.chat/share/8j1i07ksrx
https://discord.com/channels/967118679370264627/967119184209264790/1465142408713994322
Trying to automate casting trays and basins.
(example timing)
Casting tray cools in 60 ticks.
Basin cools in 100 ticks.
Therefore we want like
basically, the declarative approach of "for each basin, if fluid insufficient to cast, dump fluid" when reduced to a scheduling problem results in wasted cycles due to waiting for the next cycle to perform the operation, but doing it on a schedule may be more perf efficient for large scale
Given that the manager block ticks every tick, each trigger is a predicate upon the state of the world when the manager is ticking.
Redstone triggers check the unprocessed redstone pulse count on the manager.
Timer triggers check the manager/world clock for remainder.
Schedule triggers (new) are desugarable to timer triggers
Beta Was this translation helpful? Give feedback.
All reactions