Scott Barnes
Comments
@unknown- Stick to managing what's in/out with SpigotMC and also to what you "know" vs "think". As that reads "I think" vs "i know", as until you can substantiate the opinion provided with provable / tested code that illustrates the ROI failures in this equation, then really, it's about offering alternative options to just "bug fixes" whilst highlighting ways a refactor or deferred by design can occur. Fact is there's a cloud of CPU's available to hand off workable tasks to clients, even if its discrete calculations that are obfuscated.
If anything why SpigotMC hasn't done an out of band patch to this issue (thus reducing constant bottle necks currently been seen) probably summarises the peak abilities being on offer here.
The chunk queue / calculations on server seems an awful waste of resources. Instead why not hand off the calculation to the client to come back to the server with the generated index, in that tap into the client's actual CPU cycles if it reaches a certain perf / benchmark (easily detectable).
To then counter "hacking" attempts (ie never trust the client) you then ask someone another client that's connected the server (randomly) to verify the calculations etc. If there are no other's on the server, it's only then does the server perform the calculations in a thread.
The point is, start offloading CPU cycles to the mesh network that which is player(s) to do as much as the heavy lifting as one can without impact to perf of their experience. Using a transaction pub/sub system ?
@unknown well three things:
Firstly, see what happens when you think outside the narrowminded box - https://www.youtube.com/watch?v=JjSKqQI6Cr0&feature=youtu.be - you end up with moments like these.
Secondly, in 2008 had the same assnine response to how HD video can't work because of the roundtrip latency involved in clients negotiating between server<->client on how much CPU, GPU and Bandwidth can be consumed at intervals that reduces load on server/cloud infrastructure (and to prevent buffering)... oh...you now call this HD video online as a result of the team i was in via Microsoft (FYI we got it working to over 280million PC's during the beijing olympics and it was extremely rare you saw buffering symbols). Furthermore in SCADA style solutions where mission critical response times need to occur (think support operator staring at a screen looking for breakdowns) a 500ms-3 second response time for a visual catchup is undetected unless there's a deliberate interrupt in the users experience. So if an industrial grade emergency response solution like these can live with the existence of a 500ms - 3 in cognitive load to reactionary response... we can as well (assuming your limited theory on such matter were to come true, which it actuall wouldn't but this would involve an education process on threading, network latency compression etc etc)
The lifespan of a users behaviour at ahead-of-time chunk loading is as follows. The client makes the prediction ahead of time, generating chunks according to the intended seed/behaviour (and you can obfuscate the seed or encrypt that data better as well - but since MCP exists any client-side code is still open to hacking but there's more ways around that as well). While that client generates the behaviour client-side, it then sends back its findings BEFORE AND/OR AFTER the visual queue has been rendered or during such procedure.
All the server is doing is polling clients for verification of the truth, in that the clients return back the index associated within the Chunk with its findings, it then acts in the same capacity as Rendering nodes do in 3D rendering pipelines (you won't find this in your web developer textbooks btw, so may need to upgrade your Amazon account). The reality is the consequences vs likelihood of a client being without trust is actually lower than one would think, but just in case the server continues to apply verification protocols to ensure that the truth is always held to higher standard, in the event the truth fails and culprits are found it also can increase banning behaviour management whilst at the same time the server can then re-generate the suspicious chunk anyway only during non-peak-processing times.
That is to say, using crowd sourcing approaches you can furthermore generate chunks ahead of time while CPU's are idle, that is the client can tack onto the existing chatty packets that go between client/server that there are in a semi-idle state or what we called "refractory processing time", During this periods the server can predict players movements based on basic square root math(s) and historical data "User is x:1000,y:128, z:1000" therefore it can assume that another 1000 block radius is likely to be rendered in the next N amount of ticks, it can then ask spare CPU cycles to generate such information / data even if the user doesn't action that 1000 block radius. Keeping in mind its really a 1x time call per server per chunk ratio.
Lastly,
If i wanted a Wordpress blog update or fix, i'd respect your attempt at asserting authority, in the mean time, you play with your JavaScript/PHP toys and leave the hard thinking to the rest of us who look beyond what blind ignorant obedience has to offer.
As to how it relates to the topic at head.. simple... the chunk creation queue needs refactoring period. As all this does is put a band-aid upon a broken limb.