comkieffer / terrapin Goto Github PK

Most tools that have some logging still use custom functions for logging. We should migrate them to the new logging API.

When a movement fails the turtles just emits an error and the programs aborts.

Now that the checkin functionality is in better shape we can have the turtle notify the server that an error occurred and wait for a human intervention to resume the task.

When the move fails use turtle.attack to see if the obstruction is a mob, use turtle.detect to see if the obstruction is a block. If unable to continue send a checkin message to explain the problem.

This script should display the state of the checkin system.

Is it connecting to the remote server ?
What is the packet loss ?
How many messges have been sent ?
...

Prompt the user to upgrade his installation.
Can be overridden with a configuration string.

The programs have a terrible UI.

A GUI wrapper written with Bedrock would improve things signifcantly. The idea at the moment is to create a wrapper script that acts as a genric UI for all the digging programs. This script would listen for the "terrapin:dug" and "terrapin:log_item" events and use those to update its interface.

the commands

pm list available
pm list installed

help provide a high level of the system status. I should implement them sooner or later.

Our main workhorse script, digmine, is full of legacy code. We need to implement the following:

• Smartslot for torch management
• isOre for ore detection
• inventory management even in explore mode
• ender chest support.
• smart inventory emptying

The scheckin system was conceived with this in mind but this is broken a the moment.

Steps:

• Add a script to deploy a GPS satellite to the distrbution

• Get GPS coords if available in the checkin process

• Get relative coords from the terrapin API

  This last part is the hardest. I think that the best way is to use persistent variables to store the relative position and access those directly. This exposes us to many edge cases:

  I think the best way to do this is to produce an event every time the turtle moves that contains the coords if they exist.

Inventory tracking would allow the turtle to keep its inventory state in memory. This allows some nifty features like:

• calculating the number of remaining slots in the inventory without iterating over all of it.
• reporting the status of its inventory to the checkin server without having to rescan it
• ????

The easiest way to do this is to add an event listner for the 'turtle_inventory' event. This event is fired any time the inventory changes. This probably means that it is fired every time the turtle digs anything. This also means that we need to have a program listening for the event at all times. Maybe we can hook it into the checkin server.

The recent checkins pane should implement infinite scrolling and load checkins from the database as required.

Currently the only a the checkin code knows what task is running is to look at the task data in the checkin messages. This means that the daemon cannot know if a task has crashed, if it has finished, ...

We should make the daemon keep a local copy of the task stack it can use to track the current task.

Some questions still need to be answered:

• How long should we wait before declaring a task dead ? 1 minute ? 5 minutes ?
• What happens when an error occurs ? Should checkin.error() make the task die ?

The package manager has been conceived as a part of terrapin.

We should add the basic components needed for it to run as a standalone system.

The startup file should load the require API and run through the autoruns in order.

Currently all the checkin messages received by terrapin_web, whatever minecraft world they come from, are stored identically in the database.

Adding a "world" field to the database rows would allow us to differentiate them.

The checkin daemon uses hardcoded paths for everything. We should be able to configure it with our tusty config module.

Add the following configuration options :

• checkin server
• world name

The daemon should check that the configuration is complete and graciously fail otherwise.