GPS - Use distance the server received.

[fatboychummy]

I had a very random thought at 2 am today.

The GPS hosts receive a distance from the client, but then the hosts all send separate messages to the client. These separate messages may be sent at different times, meaning the player, turtle, or whatever, might have moved a slight bit in that time.

Thus, my thoughts are as follows:

1. Each host receives a distance at the same time, assumedly originating from the same location.
2. Each host can send that distance back to the client.
3. The client can use that distance instead to calculate its position. It should be more accurate, since the distances come from one message sent to all servers at the exact same time.

This is a really half-baked idea and fueled by way too much caffeine, but I thought I'd get the thought out there before I forgot about it. I have no idea how I'd test if this actually is happening (or if these changes even mitigate anything), but I recall having minor accuracy issues with GPS in the past. In theory (if my theory is right), this would resolve some accuracy issues.

[Wojbie]

I feel like this is something that would need to be well tested.. Like is there actually meaningful difference between distance that GPS host gest vs distance that GPS locate call gets?

[SquidDev]

Like is there actually meaningful difference between distance that GPS host gets vs distance that GPS locate call gets?

So there is potentially some delay between the original message being sent and the response being received. On most systems I'd expect this to occur in the same tick (see some of the comments in ComputerThread about latency), but on a very over-burdened system it might be different.

That said, I still don't entirely understand the behaviour of GPS when the querying computer is moving. See also the discussion in #901, where I'm still very confused why queueEvent(); pullEvent() doesn't work to clear the queue.

Speaking of which, it might be interesting to do similar experiments like in #901 and see how it compares.

[SquidDev]

I do have some concerns here about how this now requires a unique message for each requesting computer¹, but that's probably niche enough it doesn't really matter.

Footnotes

1. In the past, I have had built GPS servers which broadcast a packet once a tick, rather than in response to a request. This does help when you've got a lot of computers making GPS requests every tick. ↩

[fatboychummy]

I do have some concerns here about how this now requires a unique message for each requesting computer1, but that's probably niche enough it doesn't really matter.

Ooh, yes. I did mean to account for that. In theory the IDs wouldn't need to be anything fancy. Just enough that a collision doesn't occur once per tick essentially -- a randomly generated number. Having an ID could also be beneficial so you don't receive GPS pongs meant for other requests.

There's an easier solution to receiving pongs meant for other computers, though...

os.queueEvent("clear")
os.pullEvent("clear")
local x, y, z = gps.locate()

In the past, I have had built GPS servers which broadcast a packet once a tick, rather than in response to a request. This does help when you've got a lot of computers making GPS requests every tick.

I'm curious if this would be worth implementing into the GPS program. Something like gps busyhost x y z.

[fatboychummy]

Hmm, update on that. Including an ID would be a breaking change. Currently gps.locate() just sends out the string PING, and the server responds with its location. To include an ID we would need to change what gps.locate() sends, which will break any custom GPS servers.

[SquidDev]

Sorry, I think I missed your latest reply! This is one of those cases where I'm not actually too worried about breaking custom GPS servers - as long as protocol changes don't cause crashes it's probably fine.

I'm was a little wary about how this will interact with anonymised GPS, but it occurs to me that while the computer ID is hidden, it's still fairly easy to track players with the current system.

I have mentioned some changes to long-distance GPS in #955 which I don't think affect this (compliant GPS servers can still choose not to broadcast the distance component), but worth mentioning.

[djmattyg007]

Perhaps it would be better to just create a gps2 wth a bunch of breaking changes, rather than trying to shoehorn everything into the existing code?