Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Bodo Eggert

  • Content Count

  • Joined

  • Last visited

About Bodo Eggert

  • Rank
    Junior Member

Contact Methods

  • GitHub

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 option for placed blocks)
  2. 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. HTH * untested yet
  3. " breaking change" - Yes, that's why I didn't post it as an issue yet, also I expect more feedback from users here.
  4. 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 feature if the robot was supposed to do that. I think either the geolyzer is supposed to know north, then it's sensible to add a getFacing() call. Or it isn't then it's sensible to make scan() be directional - possibly breaking a lot of programs.
  5. 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.
  6. 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 visible: local classicWaypoint = component.navigation.createVirtualWaypoint(x, y, z, label) { [1]=x, ..., virtualHandle = random_unique_number } -- an entry you might find in .findWaypoints()[1], -- but contains an additional record -- returns nil if waypoint would be outside of the map -- .findWaypoints(sufficient_range) does include this waypoint local storedWaypoint1 = component.navigation.printVirtualWaypoint(x, y, z, label) -- same result, but different virtualHandle -- component.navigation.findWaypoints(...) does NOT include this waypoint -- table.insert(component.navigation.findWaypoints(sufficient_range), storedWaypoint1) -- may differ only in the order of elements local storedWaypoint2 = component.navigation.exportVirtualWaypoint(virtualHandle) { virtualHandle = virtualHandle, label = virtualHandle.label, data = decryptable_knowing_seed } = component.navigation.createVirtualWaypoint(storedWaypoint1) = component.navigation.createVirtualWaypoint(storedWaypoint2) -- returns true or false, string with reason of failure -- .findWaypoints() does include the waypoint iff the result was true -- executed using the same map it will include TWO waypoints now, -- since one virtualHandle was the same as an existing one -- and the result was false, "waypoint exists" = component.navigation.deleteVirtualWaypoint(storedWaypoint1) -- the one that was inported after being printed = component.navigation.deleteVirtualWaypoint(storedWaypoint1.virtualHandle) -- same effect, use either = component.navigation.deleteVirtualWaypoint(classicWaypoint) -- only works if virtualHandle is not nil -- now the list of waypoints is empty -- notice that I didn't include a way to export waypoint blocks, -- but maybe it would be sane to be able to print/create them, too.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.