Feature Request: Navigation Method/Event to Read X/Y/Z Location of Remote Terminal and/or Other Attached Components

[Eunomiac]

I would love for a method in the navigation API that would permit a computer, robot or server with the Navigation Upgrade to retrieve the X/Y/Z location of an attached component---particularly an attached Remote Terminal, and, by extension, the location of the player holding it: getComponentPosition(address:string): number, number, number or nil, string.

Reason: I'm writing a program that will allow players to create teleportation waypoints on a map contained in a Remote Terminal, allowing them to more-easily travel around an area. Currently, the only way to do this is to have the player enter the coordinates manually, which is cumbersome. I would much rather be able to include a button that would immediately create a teleportation waypoint at the player's current location.

This would also be very helpful in, say, making sure you're binding the right screen to the right GPU (by checking the screen's position in the world).

[ingie]

sounds like a good idea for your purpose, but quite over powered for any other purpose it could be used for: i.e. being able to track the position of a person without the motion sensor or a radar...

[Eunomiac]

Hmm, then perhaps restrict its use to the Remote Terminal itself, perhaps using an event instead of a method---i.e. something that has to be activated by the player using the Remote Terminal, instead of a consistent "where's that Terminal now" ability on the server? (I updated the title to reflect this possibility.)

Although, for the sake of argument... I don't necessarily think tracking a player would be overpowered, at least in a "real world" context; consider all those cellphone apps that parents can use to track their kids. Indeed, I think it would be pretty cool if an add-on mod used this feature to create tracking chips that could be surreptitiously placed on players for this very purpose :D

And radars/motions sensors would still have their place---both can be used to check for multiple players/entities in a certain range, rather than a single player carrying a specific device.

[ingie]

I suppose what I mean is, re the overpoweredness, is that the devices for tracking a player exist - and have less power [in terms of what they can do] and this would negate them... i don't mean that it's not a good feature to be able to track someone... :)

but yeah, ensuring that the server couldn't "poll" would help that in some way...

[Eunomiac]

Sorry, I may have ninja-edited my post after you read it to address that very point: I don't think radars and motion sensors would be rendered obsolete by the introduction of a tracking device, just as they haven't been made obsolete in the real world by the existence of tracking devices---they're really quite different in what they do, and each has an important niche.

Motion sensors/radars work well for security systems, public automatic doors/lights, or any other form of automation you want to trigger off of anyone in range. A tracking device, on the other hand, must be locked to a single player who carries it on their person. Yes, motion sensors and radars wouldn't be as good at tracking a single player's location... but they can do a lot of other things that a tracking device cannot.

[ingie]

you make a good case ...as long as it's not polling

... and as long as it's very expensive :)

interesting thought from your cellphone analogy... maybe to enable this, you'd have to erect triangulation masts of some form.

[fnuecke]

Hm, I must admit, I don't really like it, even the nav upgrade only provides relative coordinates, and that's the most I'd be willing to provide for terminals, too, and that 1) wouldn't be helpful for you anyway, since you'd need the absolute coordinates for creating waypoints, right? 2) might not even be feasible, since servers don't even keep track of the terminals (which is why the virtual screen + kb remain even when a term is rebound to another server). I'd have to actually have a look at the code, but I think it'd be quite ugly to keep track of this.

What might make more sense in your case would be to code an addon component (card?) that handles waypoint/teleportation stuff (e.g. have a callback that takes a player name, internally gets the player's entity and its coordinates, stores those as a waypoint that can then be teleported to -> no "real" coordinates anywhere in-world).

[Eunomiac]

... even the nav upgrade only provides relative coordinates, and that's the most I'd be willing to provide for terminals, too, and that 1) wouldn't be helpful for you anyway ...

No, that would work perfectly---I'd just need to add the coordinates of the computer, which I'd know as it's stationary, to get the absolute coordinates. But that's moot if 2) makes the idea unfeasible

What might make more sense in your case would be to code an addon component (card?) that handles waypoint/teleportation stuff (e.g. have a callback that takes a player name, internally gets the player's entity and its coordinates, stores those as a waypoint that can then be teleported to -> no "real" coordinates anywhere in-world).

This would be fantastic, of course, but I wonder if it's a little narrow to justify a whole new component/card?

We might have a difference of opinion on the OP'ness of pinpointing the location of a player holding a Remote Terminal; I'd argue that the interesting and unique mechanics it could support (including checking if a player is online---which is one thing I've always thought should be easier than it is---to fun programs that track a player's movements for projection on a holographic map) outweigh any potential for abuse. After all...

• re: tracking players without their consent, the player has to be holding the Remote Terminal voluntarily---so the "trickery" necessary to exploit such a function this way would make for all kinds of "be careful who you trust" awesomesauce
• re: reporting a player's coordinates with their consent, all you're really doing is eliminating the need for the player to hit F3 and type in their coordinates manually (contrast with the nav upgrade on robots: because a robot can't manually enter their coordinates, adding the ability to pinpoint a robot's coordinates would be a very powerful ability)

Alternatively, to simplify things (and eliminate the need for a whole new block): Perhaps a callback within the computer/component API that, upon being given a component address (and perhaps a player name), (1) checks to see whether that component is a Remote Terminal, (2) gets the name of the player holding it, (3) verifies that the player is online and (4) retrieves (and returns) the player's (relative) coordinates?

ALT-Alternatively maybe the callback does nothing but return the range of the player? Then, you'd need three computers in different locations to triangulate the player's precise coordinates---and that could be a lot of fun to set up!

CTRL-ALT-Alternatively, if there were an API for the Remote Terminal itself (and I could see a lot being done with such an API, come to think of it), this callback might more-easily be included there.

CTRL-ALT-SHIFT-Alternatively, the ability to pinpoint a player's location would be especially useful in adventure maps and, as such, could even be restricted to Creative servers (perhaps even in combination with some of the above---e.g. non-Creative servers only get the range, requiring triangulation, while Creative servers retrieve the full, absolute coordinates of the player).

(My god I've spent two hours rambling away on various issues in here; have I convinced you how much I love this mod yet? ;) )

[fnuecke]

Hmm, the problem is, as mentioned before, that there's no easy way to "track" the terminals from the server's point of view - which is what would be necessary, after all. Because there's no built-in way to track item stacks (because, well, technically you usually actually get a new item stack whenever it enters or leaves an inventory, amongst other things). So that'd be a major thing to implement. It's one of the more complex parts in the tablet implementation. Meaning however it's done, it'd make more sense to somehow resolve the coordinates via the player (name) rather than the remote terminal itself...

Since you mention creative stuff, an alternative approach might be to extend the debug card a little, to allow accessing entity information, including players. If the terminals shouldn't be able to query that directly, you could then set that up as a network service that can be queried, for example.

Btw, I don't really think having an extra card for this would be overkill, that's the nice thing about the modularity of things, after all (it'd still have to be an addon mod though, since it is, as you say, quite specialized).

Or... it might actually be a lot more sensible for you to use tablets for this; while they're testing only right now, they'd pretty much allow for this using the triangulation approach you suggested yourself (using wireless network messages).

TL;DR: providing entity information via the debug card and have that as a network service would be the most realistic way, I think?

[Eunomiac]

Hmm, the problem is, as mentioned before, that there's no easy way to "track" the terminals from the server's point of view

Ah, yep, apparently I needed to hear that twice before it clicked; I'm not a mod programmer, so it seemed intuitive to me that querying a Remote Terminal with "what's the name of the player holding you" would be easier than it is.

I also assume a separate API for remote terminals is likewise too bulky/unworkable? By the same intuitive thinking that led me astray on that first point, I'm envisioning the Remote Terminal object itself asking "what's the name of the player holding me" as being somewhat easier.

Since you mention creative stuff, an alternative approach might be to extend the debug card a little, to allow accessing entity information, including players.

That's a brilliant idea. In designing my map (in which, as I've mentioned, OC plays an absolutely pivotal role), I've come to realize that OC is an absolute godsend for map designers---and extra functionality specifically for creative-mode mechanics would, I selfishly submit, be a huge asset. The Wireless Adapter block I suggested is another great example of something that would be hugely helpful to map designers, allowing us to encase computers and attached command blocks in bedrock (... and I mention this only as another example, not to poke/rush you---I know you still have it on your to-do list :) )

The debug card would be a great way to isolate any creative-mode only functionality, giving you the freedom to provide powerful callbacks that are unfettered by balance concerns. Indeed, I might even suggest changing the name to something like "creative card" or, if you want to be cheeky, "the God card", just to broaden its application to more than debugging. As the callbacks on this card grew, map-makers everywhere would rejoice.

I understand security concerns likely make this next suggestion dangerous and/or unfeasible, but damn wouldn't it be nice if a full-blown command block were included inside the card (i.e. the card has the power to execute slash commands without connecting to an external command block)!

Or... it might actually be a lot more sensible for you to use tablets for this; while they're testing only right now, they'd pretty much allow for this using the triangulation approach you suggested yourself (using wireless network messages).

This... is actually... a very good point. I'm still a few weeks away from closed alpha testing of my map, so even though the tablet is still in testing, perhaps transitioning from the Remote Terminal to the Tablet is something I should consider. (This Remote Terminal/Tablet is probably the single-most important object in my map, with an absolutely massive program that's basically a combination of a custom-built Hardcore Questing Mode plus a remote control for virtually every system). I'll play around with it tonight and see what's what.

(By the way: Your commitment to this mod is absolutely outstanding. Thank you so much for all your hard work, and responsiveness to all of my rambling walls of text ;) )

[fnuecke]

I also assume a separate API for remote terminals is likewise too bulky/unworkable?

I'm afraid so. To make this maybe a bit more understandable: technically the terminal is a one-directional "link" to the server. When opening the GUI (rightclicking the term in hand) what basically happens is the server being treated like a screen block, just activated remotely (this is oversimplified, but I hope it gets the point across).

Renaming the card to 'creative card' may come, it just doesn't deserve the name just yet, IMHO. I would like to add entity lookup/interaction and possibly even NBT editing for blocks; maybe then. I originally just had it in to mass produce computers/networks to debug, hence the name.

absolutely massive program

I hope you don't run out of memory on the tablets then :P Tablet tiers are something I'm considering, though I'm currently not really in favor of it.

[fnuecke]

Since the debug card has player interaction now I'll be closing this.