todos.txt

TODO: print actually useful info on the screen
 - a dot for every hopper_step retry (and debug info if the dots get too numerous)
 - the stage hopper_step is currently in (for performance profiling)
 - number of sources and destinations
 - transfer count for the last iteration (useful with void)
 - a console to type one-off hopper commands
 - a better way to view dozens of commands separated by `/`

TODO: add warning hook to the logging api

TODO: syntax highlighting for comments in display_loop and display_exit

TODO: replace `nbt or ""` and `tag or ""` with default values in the slot metatable

TODO: buffer for transferring between incompatible inventories
	- have -storage storages act as buffers (the setup requirements are identical)

TODO: handle termination events using provisions and waitForAll instead of halt and waitForAny
	- this is required for ensuring proper cleanup of more complicated operations

TODO: implement more complete regular expressions
	- & for and (with priority over |)
	- ! for not (with priority over &)
	- () for priority overrides
		- technically not necessary due to aliases existing, but it'd be nice to have
	- it'll probably be helpful to use an actual parser instead of the current string replacement mess
TODO: use the above to overhaul item filtering
	- proper aliases on everything (currently they only work on chest names and item filters)
	- matching by item type (item/fluid/energy/etc.)

TODO: make a bug report to CC:T explaining the issue with getItemLimit

TODO: limit rescans
	- opt-in with `-manual_rescans`
	- trigger a rescan with `-rescan *`
	- `void` will need refactoring because `voided` is getting ignored in a ton of places
	- multiple instances of hopper() running in parallel should share their scan cache and should not scan the same chest at the same time
	- can get rid of TIL right after this is done!!!

TODO: parallelism! (for massive furnace stacks and other massive logistics)
	- parallelize `/` syntax?
		- might break things

	- slots should be grouped into "nice" and "not nice"
	- nice->nice transfers will be assumed to succeed and then pushed onto a queue for later execution
	- when the queue is full, execute all operations in parallel until at least one finishes

	- parallel transfers should be opt-in, as they can mess up transfer logic upon failure

TODO: speed up item pulling operations by transferring full slots directly into empty slots if there are any

Q: why is the basin not working with ME bridge on forge?

TODO: why does scope.lua show so many 0.00ns threads even when running the program with -scan_threads 1?
TODO: implement a cc-compatible version of `coz`

TODO: should I publish hopper.lua on the pinestore?

TODO: make a separate lua api based on tables instead of strings
- the goal is to avoid people programatically constructing strings only for hopper.lua to have to parse said strings back into a table
- keep the existing string-based api and only switch to the table api if hopper() is passed a table

TODO: is there any way at all to integrate with JEI/EMI???
- it's a tremendous QOL feature that AE2 gets to use and abuse but CC does not

TODO: conditional transfer
 - based on the state of another inventory
	- -if to use a condition (named or unnamed)
	- -condition to define named conditions (can use named conditions within itself)
 - based on redstone
	- use redstone event to watch for redstone, then queue that to control the next transfer operation
		- -wake_on_redstone - sleep until a redstone event triggers
	- NO guarantees about transfer amount. no redstone pulses please
		- "for more precise control, use the lua api."
	- cli:
		-redstone_enabled {side}
		-redstone_disabled {side}
		- {side} can be a glob, so `*` to watch all sides or | to watch multiple sides



TODO: fix build script situation
	- the built output should not be committed alongside everything else, as that results in duplication
		- teal also does this but they do it for a reason



TODO: simple pipeline autocrafting by supplying a reference recipe in a dropper

TODO: more options for hopper.list()
	- implement filters and aggregations using `void` and `inform_limit` (in order to reuse code)

TODO: networking
	- connect two instances together with `-network [name] [nil/password]` 
		- two networks are identical iff name and password both match
		- if no password then it's an unencrypted network
	- every peripheral name will then be prefaced with `[computer id]->` or just `->` if it's on the local network
		- `*chest*` will match every chest everywhere, `->*chest*` will match only local chests
	- transfer across networks by using the digitizer as an intermediary

TODO: virtual chests
	- inserting items doesn't actually move anything?
	- inserting items *digitizes them through the digitizer*?
		- this is two different kinds of virtual chests
		- requires persistent storage of ids *and* networking
	- taking out items takes them out of the original chest
	- this depends on -manual-rescan being implemented
		- a `-manual-rescans -rescan *` at the start of a list of commands makes it rescan between iterations but not between commands





FIXME: propagate and reset errors correctly



TODO: some way to treat chests as queues
	- -queue flag to mark a chest as a queue
	- keep track of start and end using the empty slots
	possible use: feeding botania flowers items in order

TODO: better errors with debug.traceback and xpcall
TODO: log all errors and warnings on a separate screen

TODO: staggered startup (sleep between 0 and 20 ticks on startup)
TODO: -nap for shorter sleeps some period after a successful transfer (-nap 0 1 to -sleep 0 for 1 whole second after a success)
	- naps should not reset transfer limits, thus maintain the validity of throughput calculations
	- second argument should probably be number of iterations instead


TODO: milo-style gui for using hopper.lua as a storage system

TODO: AE2-style machine autocrafting (crafting table autocrafting can be made with a turtle autocrafter)
	Stage 1: have hopper.lua use AE2 for autocrafting (equivalent to an exporter with a crafting card)
    Stage 2: implement a cc-based autocrafter that functions similarly to AE2 to interface with hopper.lua
		- autocrafting should be a property of -storages, crafting using materials in said storage


TODO: hopper repl to avoid restarts when using `-storage`

FIXME: storagedrawers mod's drawers has items change slot numbers on forge, messing up transfers





TODO: -spread to distribute items evenly
	when is this actually useful?

TODO: rice cooker functionality
	cut off power when temperature rises to above 100C

TODO: integrate with an LLM to get some of that venture capital

TODO: create-style factory gauge logistics (aka. promises)




TODO: digital items support. two use cases:
- dense item storage (ae2-like)
	- requires persistent storage of ids
- long-distance item transfer (echest-like)
	- requires encrypted communication (otherwise people can steal the items)



Q: is mekanism support even possible?
- listing can be done with .input, .output, .inputItem, .outputItem
- but it doesn't give push/pull methods of any kind
- pushing/pulling can theoretically be done as a cannot_wrap peripheral
	- except mekanism only supports sided transfers so it doesn't actually work