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

    • Lizzy Trickster

      Latest Stable OpenComputers Version   11/26/16

      The latest released version of OpenComputers is version 1.7.2 for MC 1.7.10, 1.10.2, 1.11.2 & 1.12.2. See more information here! Beta/Dev builds can be found at the Jenkins Build Server (ci.cil.li)

Bodo Eggert

Members
  • Content count

    5
  • Joined

  • Last visited

About Bodo Eggert

  • Rank
    Junior Member

Contact Methods

  • GitHub
    https://github.com/7eggert
  1. Redstone I/O Block and different outputs on one side

    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
  2. Geolyzer using absolute vs. relative direction in robots

    " breaking change" - Yes, that's why I didn't post it as an issue yet, also I expect more feedback from users here.
  3. 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.
  4. Does more active Components drain more Power?

    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.
  5. Navigation Virtual waypoint

    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.
×