-
Notifications
You must be signed in to change notification settings - Fork 0
Dev: oc_energistics
Thomas Depke edited this page Jan 17, 2023
·
3 revisions
- Storage server controls transposer network.
- Crafting server controls auto-crafting jobs and drone flight plans.
- Interface server presents the user interface. Each user that wants to connect needs their own interface server.
- Want to keep storage network separate from the auto-crafting stuff, so that it can be used independently.
TODO
- Add some dynamic port assignment maybe (start with default port, and switch everybody to new port when they first chat).
- Would be neat to have some security. When system first set up we could keep track of all addresses in a file and validate packets with these.
- This could also be a performance issue, may want to use broadcasts when communicating with interfaces.
- There is a way to have a device set its own Lua version with component.computer.setArchitecture(), might be a good idea (instead of adding compat with 5.2).
- Should probably have wnet accept the address string "*" for broadcast, not a nil value.
- May want to adjust checkRecipe() in crafting to send tickets with fake status ("missing" for missing materials).
- This allows user to queue up an item that can't currently be crafted in order to purge expired pending requests.
- Implies that stor_recipe_reserve just needs to handle special case "missing", and crafting sends this on missing items (I think).
- The packer lib could be improved by using a memoize function for string deserialization. See https://www.lua.org/pil/17.1.html for ideas.
- May want to disable this feature for low memory systems.
DONE
- Using os.sleep() may be evil, same thing for event.pull() with filter.
- Need to investigate how signals get dropped and possibly make a separate event library that queues signals.
- Solution for now: os.sleep() is fine as long as it's not used within a thread that must catch events.
- wnet needs some adjustments to handle invalid data format (drop these packets).
- Something needs to be done about the network communication. Instead of the : structure, use :.
- Might be good to create a new network module to keep track of all packet types. We would have a function for each packet that can be sent/received.
- Modem thread should be adjusted to be more generic and not check the packet headers for each type.
- Need a testing system for robots (and drones later) for running commands like interactive lua interpreter. Maybe use existing firmware with remote-code-exe script.
- The packer module could be rewritten to use a data-driven approach. Have a single pack and unpack function, and a table of packet headers to an ordered list of expected data types.
- May be an improvement to have packer module not store a global table of callbacks, and instead allow callbacks to be passed into handlePacket().
- This would allow callback tables for different network ports running on same server.
- Rejected this idea for now, you can still filter the ports within the handlePacket() loop or within the callback function.
TODO
- May want to add optional feature to import constantly, the redstone sensor is cool but not really needed.
- Might be good to allow setup script to "merge" a previous config.
- This would allow user to add a few more inventories on network and then run setup for just the new ones.
- Verify all transposers are correct in config when app starts. Make sure all ones listed are there and there are no extras in system.
- Allow user to modify the contents of the storage inventories directly by re-scanning the contents periodically.
- This should scan one inventory at a time and wait a short delay to avoid starvation of other threads. Also should be possible to disable completely.
- Potential problem if a crafting operation is running while user pulls out items that are reserved, we would just cancel the crafting operation in error for this case.
- How do we skip reserving outputs from crafting? maybe pass list of exceptions to handleDroneInsert().
- For now, outputs will buffer and all release when operation completed.
- Might be able to determine which outputs are not used as inputs (not listed as a dependency) and allow negative reservations for these?
DONE
- Storage auto imports with redstone comparator and redstone I/O.
- Item formatted name should really use 'n' at end of name to indicate it has NBT and kept separate from other items.
- Item list sent to interface should use a simpler format, don't need to know insert/extract points in interface.
- Storage needs to send item diffs when contents change.
- Maybe interface will need to do a "fake" pending update of contents and confirm when it gets the message (this could be bad idea)?
- More likely not, doesn't work well with multiple users.
- We will need to keep a secondary storage table that represents the "available" items, this is reported to interfaces and stuff.
- This solves the issue of hiding away intermediate ingredients in crafting process.
- Solution: instead of keeping a second list, just keep list of reserved items and amounts.
TODO
- Need scheduling algorithm for crafting steps to keep crafting jobs running in parallel.
- If crafting operation fails for some reason, it should probably cancel (or just pause) the crafting instead of killing app.
- Just gonna leave 'error("Craft failed")' calls in the code for now.
- Is max-stack-size necessary in recipe definitions? Would be nice to leave this out for ease of use and clarity.
- Good idea to have only first output in a recipe (for both crafting and processing) show up as craftable (AE2 does this in modern versions).
- The other outputs can still be crafted as intermediate steps in a recipe, just not requested directly by the user.
- We can use a navigation upgrade with waypoints to do inventory level detection!
- The waypoints need comparators pointing into them, and we may want a dedicated robot(s) to do a periodic scan.
- Should be an optional feature to improve performance, and not require full coverage.
DONE
- Network module needs compressed version and testing with drones.
- Storage may need to know which robots can see which inventories.
- Either have storage fully keep track of which robots see what inventory, and do this by having robots scan adjacent inventories during setup script.
- Or do this dynamically each boot by dropping items off in any drone inventory and robots report if they can reach (might be tricky).
- For robots, need to have them adjacent to drone inventories for crafting tasks.
- The robots spin around to access items.
TODO
- Scroll bar should be clickable and same for search bar.
- Log should display at bottom of GUI and report success/fail of item requests.
- Maybe also display item insert events and crafting completion?
- MRU sorting option? Would be handy for items that are requested frequently.
DONE
- Better item display interface with easy selection.
- Should feature sorting.
- Scrolling if possible, else use a key combo with arrow keys instead.
- Select with arrow keys and enter.
- Maybe enter + number input for amount, shift-enter for 1, ctrl-enter for stack, ctrl-shift for all?
- If we have time, consider a color display for this as an option.
- Click and scroll to get what you want, nice.
- May be a good idea to convert all GUI draw calls to the lazy system (so we can have redundant draw calls without a problem).
- When clicking item to request, left/right-click prompts input of amount in the search bar (press enter to confirm or enter with empty string to cancel).
- Shift + left-click grabs one stack, shift + right-click grabs half stack, middle-click grabs one.
- Middle click doesn't work cuz it doesn't report screen coordinates, right-click grabs one instead.
- Need to display craftable items along with the rest, crafting system will need some work first.
- Press left-alt to hide totals and display a 'C' for craftables.
- Too many, thanks lua.
- Got a very strange "process library exception handler crashed: table: " when pulling an item out of input inventory (that was unable to insert into storage cuz full).