Replies: 3 comments
-
|
Disks have a LabelPositionHolder which use private final Map<String, Set<BlockPos>> LABELS = new HashMap<>();That is, a label is a When you do INPUT FROM chestThat creates a lazy transformation that is first invoked at the next output statement with the result being cached SuperFactoryManager/src/main/java/ca/teamdman/sfml/ast/OutputStatement.java Lines 200 to 318 in 515d3c0 Basically, the output statement collects ArrayDeque<LimitedInputSlot> inputSlots = new ArrayDeque<>();
ArrayDeque<LimitedOutputSlot> outputSlots = new ArrayDeque<>();
public LimitedInputSlot(
Label label,
BlockPos pos,
Direction direction,
int slot,
CAP handler,
InputResourceTracker<STACK, ITEM, CAP> tracker, // holds info for how much is allowed to move
STACK stack // cache for contents of the slot, invalidated when transfer executed
) {}
public LimitedOutputSlot(
Label label,
BlockPos pos,
Direction direction,
int slot,
CAP handler,
OutputResourceTracker<STACK, ITEM, CAP> tracker, // holds info for how much is allowed to move
STACK stack // cache for contents of the slot, invalidated when transfer executed
) {}then just tries to move each input to each output until either has run out I imagine that It should be noted that INPUT FROM a WHERE INPUT ITEM IS iron_ingot -- bad
INPUT iron_ingot FROM a -- better
INPUT FROM a WHERE SLOT IS EVEN -- bad
INPUT FROM a SLOTS EVEN -- better (this doesn't exist yet)
INPUT FROM a EVEN SLOTS -- better (this doesn't exist yet)
INPUT FROM a SLOTS 2n -- better (this doesn't exist yet)might also want INPUT FROM a SLOTS EXCEPT 5-7There's also discussion to offset the timer to not overlap every 20 ticks do
end
every 20 ticks offset 1 ticks
end
every 20 ticks offset 2 ticks
endwhich is different from every 20 ticks do
end
every 21 ticks do
end
every 22 ticks do
endsince the I've proposed EVERY 20 TICKS DO
-- whatever
END
EVERY 20n+1 TICKS DO
-- always comes the tick after above
ENDso the This is inspired from nth-child css selector some more thoughts // INPUT *seed* FROM phyto
// OUTPUT TO phyto WHERE OUTPUT BLOCK SLOTS 0 HAS INPUT ITEM
//
// INPUT FROM first
// OUTPUT TO second WHERE INPUT SLOT IS OUTPUT SLOT
// INPUT FROM first
// OUTPUT TO second WHERE INPUT SLOT IS OUTPUT SLOT PLUS 1 WRAPPING -- idk lmao
//
// INPUT FROM dump
// OUTPUT TO storage_barrels WHERE OUTPUT BLOCK HAS INPUT ITEM -- only add items to blocks that already hold them
let inputs = (label, pos, direction, slot)[]
let outputs = (label, pos, direction, slot)[]
for (srcSlot,destSlot) in zip(inputs, outputs) {
if destSlot.where.is_satisfied() { // memoize what makes sense for slots from the same pos n stuff
move(srcSlot,destSlot)
}
} |
Beta Was this translation helpful? Give feedback.
-
|
also want to add slot randomization and 'even distribution' something like LET src = INPUT FROM chest // creates a lazy list of LimitedInputSlots when used as an rvalue
shuffle(src)
LET dest = OUTPUT TO bruh // creates a lazy list of limitedoutputslots
shuffle(dest)
INPUT FROM src // adds those slots to the global input slot list
OUTPUT TO dest // begin moving slots until src or dest runs outLET src = INPUT FROM chest
LET dest = OUTPUT TO bruh
LET per_slot = src.amount.sum()/dest.count() then .ceil() // i'd love to avoid needing parens somehow
INPUT FROM src
OUTPUT $per_slot TO EACH destthis is messy because INPUT FROM chest
OUTPUT 5 TO EACH bruh -- outputs 5 to each block labelled bruhwhere the example above INPUT FROM src
OUTPUT per_slot TO EACH dest
-- outputs 5 to each slot, of which more than one could come from the same block
-- identifier "per_slot" could also be the ID of an item, so variables would always take precidence
-- alternatively, use $per_slot but that looks ugly when we can just inferso perhaps something like INPUT FROM src
OUTPUT 5 TO EACH bruh BY BLOCKINPUT FROM src
OUTPUT 5 TO EACH bruh BY SLOT |
Beta Was this translation helpful? Give feedback.
-
|
Lazy evaluation will help avoid doing unneeded computation and also gives opportunity to barrel logic that is currently lacking. Barrels usually have one slot cap.getSlots() // 1
cap.getStackInSlot(0) // 55555 x minecraft:cobblestone
cap.extract(0, 55555, no_simulate) // 64 x minecraft:cobblestoneso if we are lazily supplying slots, when we are in the core loop while input_slot = input_slot_supplier.get_next():
while output_slot = output_slot_supplier.get_next():
move(input_slot, output_slot)we must be careful of infinite loops. Consider a creative barrel and a trash can. If we have the input slot supplier never advancing because the input slot never depletes, and the output slot supplier never advances because the trash can slot never fills up, then that would cause an infinite loop. There would need to be a break condition that detects infinite loops but doesn't break trash cans and creative barrels on their own while input_slot = input_slot_supplier.get_next(): -- always returns the undepletable creative slot
while output_slot = output_slot_supplier.get_next(): -- always returns the unfillable trash can slot
let input_pre_count = input_slot.amount
let output_pre_count = output_slot.amount
move(input_slot, output_slot)
let input_post_count = input_slot.amount
let output_post_count = output_slot.amount
if input_pre_count == input_post_count and output_pre_count == output_post_count then
output_slot_supplier.force_advance_slot()
end
end
endthis would also boost SFM's perceived power in barrel-based logistics competitions |
Beta Was this translation helpful? Give feedback.
-
Feature first proposed in #155
Branch tracking feature: 1.19.2-feat-where
Sample programs from proposal:
Some ideas I had:
There is also a discord discussion thread for a similar feature
Filtering based on condition + labeling
WHEREcould be implemented using anonymous labels similar to inner java classes, with basic variable support being added.Alternatively, avoid label variables and just use WHERE
Currently,
FORGETmodifies input statements in the execution context which is reset between executions.Would need to make sure it can properly drop labels for an execution
Modifying labels permanently is also something desired, with the discord thread mentioning
I'm not sold on
SETLABELandREMLABELas the exact keywords, but I vibe with the intentI anticipate WHERE to increase the computation performed, so having it on a less frequent execution cycle to modify labels may be desirable
An append-instead-of-clobber behaviour may also be desirable.
Beta Was this translation helpful? Give feedback.
All reactions