Player position thread

[hugeblank]

Basically what I want is a thread where players positions are constantly updated in real time. Currently this isn’t possible due to the latency of getting a players position using an armor stand, and the max event queue, and a potential other issue.

1. Latency: It would take 2 ticks in order to get the players position: one to teleport each armor stand to the user, and then another to query the armor stands position for each player. No way around that afaik.

2. Max event queue: this one I think has a config option tied to it so it may be a non-problem, but the most events that can be queued by any computer is 255. If you have a server with 100+ players events are going to become a problem and nothing really can be done about it.

3. Potential other issue: How fast do chunks get unloaded on player death/exit? If they get unloaded before Allium recognizes this, the armor stand will get unloaded before it can get killed. Leaving excess entities around is never good as most players know, so if I can prevent that I will.

I proposed to squid that a creative chat module should be made for plethora so that the ability to make such a position thread is possible. If you have the chance I suggest you thumbs up the issue so he’s aware of how many people actually would like to see this implemented: SquidDev-CC/plethora#178

[hugeblank]

Note that the implementation of a creative chat module allows for much more than just player position. It would allow for easily detecting death, velocity, look, health, hunger, obviously inventory, and much more all in 0 ticks.

[roger109z]

The armor stand method does not work in other dimensions not to mention you cant teleport someone cross dimension, also you would be better off just not pinging all at one and instead only pinging necessary positions

[hugeblank]

@roger109z thanks for pointing that out, that complicates things a lot more.

[hugeblank]

Also roger I opened this issue because of a request for block break/place events which would require threading the players position.

[roger109z]

Not really, just testforblock really

[roger109z]

The only issue with that is you're going to run into lag issues

[hugeblank]

@roger109z You're really not thinking about the structure/possible structure of the system.

1. I would never use /testforblock. CC provides commands.getBlockInfos.
2. Blocks are only ever going to be changed (we will assume) around players. How can we get the position of the player in order to check the area that they can mine? Enter position thread.

From here it would be really easy, just get the information/position of the block and evaluate what has changed.

[roger109z]

Still sounds laggy and unfeasible

[hugeblank]

You do know that if commands are put in parallel they execute in the same tick right? Basically anything command based per-player in CC should be put in parallel, which allows for execution in the same tick. This is why allium.forEachPlayer exists. The only drawback that this has is it clutters the queue kinda quickly, see number 2 in the initial comment.

[roger109z]

Ok and it's still laggy because you're pinging 10 blocks every 2 ticks at least

[hugeblank]

We're not pinging 10 blocks we're pinging something like a 5x5x7 grid around the player every 1 tick. Nothing is laggy about that it takes 1 tick, that's an arbitrary value.

And anyways this isn't even set in stone. We don't even know IF Squid is implementing the creative introspection module (big brother module?). Let's talk about efficiency after it has been implemented and tested large scale.

[roger109z]

Imagine the toll on a server to check 5x5x7x10 blocks every tick, youd bring a server to its knees

[hugeblank]

You don't know how efficient/quick the getBlockInfos function is, and I don't either. Let's start optimistic and face the reality in debugging.

[osmarks]

Are you sure there's not a different way to get player positions somehow?

[hugeblank]

@osmarks I'm not sure if there is any other way. Any proposals?

[osmarks]

TP them to themselves? Maybe the command computer API has something.

[hugeblank]

Oh yes tping the player to themselves using /tp <name> <the same name> will say "Teleported to " which gives us nothing. /tp <name> ~ ~ ~ will get us coordinates, but in my testing it made it impossible to break blocks, the bounding box around the block that was in front of my cursor didn't appear to be there at all.

So the next best option would be to summon an armor stand either for each user... or one that bounces around to all players in one tick collecting their positions. <- I think I'll have to do some testing with this.

[fatboychummy]

For the chunk unloading/armor stand issue...

Does the successful destruction of an entity return a truth value (Ie false if it failed, true if it did not)?

You could keep a table of failed entity destructions, if so.

We could also talk to Squid to see if we could get chunk loading abilities in the command computer (because honestly, why not?).

[hugeblank]

@fatboychummy

Yes it does give a true/false which would be useful if we had an armor stand for each user which solves a problem, but we want to use the least amount of armor stands. I think a single armor stand that gets TP’d around to all players in a single tick is an idea (for the overworld), but we run into the issue that we don’t know where the armor stand is (unless we know that a tick completes) on server crash/shutdown.

[hugeblank]

As for your comment on a feature where a command computer is given chunkloading abilities, if you don’t make a feature request, I totally will because that is smart.

[hugeblank]

1.13 implements the /data command which is like the introspection module on steroids. Will be using it to provide data on position, rotation, and dimension. Armor stands are out of the question. Rejoice!

[hugeblank]

After mentioning 1.13 and experimenting with some of the features, I have decided that not only will the player positioning thread be released for 1.13, but so will getPosition as a whole. 1.11 and 1.12 simply do not provide a stable and functional means to get the players position in every possible situation. I strive to make Allium as resilient as possible, and the getPosition method accomplished in 1.11/1.12 really undermines that.

In other news, @fatboychummy suggested a feature where command computers have the ability to load/unload chunks. 1.13 not only provides that, but as mentioned above, a direct access to the user's position, rotation, and dimension making the suggestion (almost) moot. As more and more bugs for CC and Forge get squashed I'll be investigating features like a chunkloading API, and several player interaction methods.

[hugeblank]

20 will be pushed to master in a bit, getPosition has been reimplemented, on a whole 'nother level. Consider this discussion re-opened!