Navigation Virtual waypoint

[Molinko 43]

I suggest that the Navigation component should be able to set and delete a virtual waypoint around itself. This would be useful for robot/drone to robot/drone navigation thus further extending the reusability of drone programs and setup of robot programs alike. Also, perhaps some logical limitations to this could be that while the virtual waypoint is deployed drone or robot movement is stopped. However, I don't think this is necessary.

Examples of le code..

nav = component.navigation
nav.setWaypoint('waypoint 1', 12, -1)
-- # waypoint label, redstone level, vertical offset of virtual waypoint from caller( -1 is below the robot/drone. nil or 0 for actual position, 1 is above)
nav.deleteWaypoint()

-- # This makes me imagine usecases such as refueling requests
nav.setWaypoint('[refuel:charcoal 10]', 0, 1) -- # bring me 10 charcoal so I can refuel & resume...
-- # some code to check for my darn charcoal delivery...

You could do other cool things too like set a waypoint to yourself from you tablet. This could be a nice simple and beginner-friendly way to do navigation that isn't a far stretch in my opinion from normal waypoints. I don't think this feels cheaty, and I think it would make a handy addition to the limited ability of the navigation component thus making it more appealing to use.

Thanks for reading,

  - Molinko a.k.a Fast Eddie

[LightningShock 0]

So like, that virtual waypoint can be seen by any robot in range?

[Molinko 43]

The virtual waypoint is within the map boundaries of a navigation component. Really it's like a navigation upgrade can detect other navigation upgrades while the latter posts it's virtual waypoint.

[LightningShock 0]

Let me ask again. Is your virtual waypoint supposed to be seen by navigation upgrades in range other that the one who created it?

[Molinko 43]

3 hours ago, LightningShock said:

Is your virtual waypoint supposed to be seen by navigation upgrades in range other that the one who created it?

Yes.

Here's an example.

1. drone 'A' (with a navigation upgrade) calls the 'setWaypoint' method, setting a waypoint relative to its current position.
2. drone 'B' (with a navigation upgrade) calls the 'getWaypoints' method, returning a list of waypoints (1 of these waypoints is drone 'A').

Considering that navigation upgrades are limited by the map they were created with, drone 'A's "real world" location would have to lie within the map bounds of drone 'B's navigation upgrade.

I hope this is clearer. Cheers.

[Gorzoid 10]

Navigation upgrade having the ability to magically share waypoints with eachother seems a bit weird, I like the idea of setting local waypoints that only the component itself can see but networked waypoints can be recreated with just a wireless card.

[Molinko 43]

Virtual waypoints for the self are pretty useless. There's no reason you couldn't just navigate using script local variables. Navigation components deploying a discoverable waypoint isn't any weirder really than the nav component detecting normal waypoint blocks. I just figured if the nav component can detect them why not be able to spoof them within reasonable limits. Its not op because any navigation card would be limited to detecting virtual waypoints with the same proximity limitations of normal waypoints.

[webbster64 0]

i would find this useful, could work nice for base patrol bots, at call for guard bots then unknown entities is found 

   

[Bodo Eggert 0]

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.