Bodo Eggert

I'm using geolyzer and getStack(…) to tell what to do with items or placed blocks. Mine them, mine them with silk, leave them alone, put the mined item into pulverizers or furnaces … but some mods don't cooperate. I'm wondering weather it's a good idea to include the oredict value if availabe (and weather it's a available for placed blocks). Also since currently the meta value isn't available on the geolyzer, I'm thinking about having a whitelist for mod or mot:block_name - or even a JSON/LUA database. (Currently I'm mapping the damage value to item name, but that's not an opt

The redstone card* / block does control it's individual sides. You can connect a redstone wire to each side ... but classical redstone dows interfere with it's environment, that might be tricky. Using an enderio redstone conduit, I can control 16 outputs per side (bundled). You can read individual bundle colors or get the whole bundle table.That uses a separate set of functions. (The classic functions will probably work and interfere, too) If you output a signal, that side will read at least the value you are sending. So for IO, you have to write a signal strength of 0 first. HT

" breaking change" - Yes, that's why I didn't post it as an issue yet, also I expect more feedback from users here.

The geolyzer will use relative directions for analyze(), but absolute directions for scan(). I don't think this is a good combination. On a robot, most actions are supposed to be direction-agnostic - you need a navigation upgrade to get an absolute direction. But having a geolyzer, you can not sensibly use it to scan unless you do have an absolute direction … that is, you can, given certain circumstances. You can analyze() the surroundings and correlate it to scan() results, thereby getting the absolute direction. It doesn't seem to be an intended feature, and it's not a good featur

The screens are documented to drain power by the amount of characters on screen (non-space). So I'd assume that they always drain a basic amount plus x * number_of_non_space_characters and none if turned off. Thermal expansion generators and EnderIO probes may be a way to verify that. I don't know about colored characters and spaces with background - if you can tell, I'd like to know that too.

Maybe the locally-stored waypoints could be shared using one of the communication links (e.g. wlan or link card) or stored in a file, so there would be no global list of waypoints and you can't just magically switch on a drone with knowledge about it's surroundings. The records for retrieving and exchanging waypoints must contain the absolutes but not be readable, e.g. being encrypted by f(seed .. random_number, absolute_waypoint_data) . The navigation upgrade would have a function to load these waypoints if it falls into the area of the map. -- assuming no waypoint blocks being visib