Dylan T.
Dylan T.
It looks like we can fix this by having explosions pretend to be diamond pickaxes for `Block->getDrops()`. Out of all the blocks which require a tool to harvest, the vast...
> After this event, events such as EntityExplodeEvent/ExplosionPrimeEvent will be called anyway, so I don't think this event need to be cancellable This depends on the behaviour of the entity...
Years ago I found that doors were slightly thinner in Bedrock than Java (0.1825 blocks instead of 0.1875). I'd bet good money this is a similar, if not the same...
Well, I don't know how you're drawing that
To address something you said earlier: I did try to fix this problem a couple of times in the past, but couldn't figure out a way to do it that...
Really the ideal world would be if the client would tell us what predictions it made, or if we could associate a transaction ID with block updates so that the...
So my understanding of that field is that we can interpret it as "did the client make _any_ predictions". If it didn't, we should be able to avoid syncing in...
> This solution I think would reduce the amount of times the scenario I mentioned previously (the 4 tick RTT one), but it would still happen. This mainly affects jump-bridging,...
I implemented a check based on the predicted result field, and it completely eliminated the lag on my localhost client & server. Basically we can avoid failure syncing if the...
This occurs if the recipient is an operator.