Why desync is fixable:
" The only thing GGG said is 'It won't work.', but from a mechanical standpoint a lot of discussion in this thread made clear that it should work (it depends on the server, but every system depends on the server...). And it should work at least to the same degree the actual system works, in my opinion even better. One point i didn't brought up is that for hardcore gamers (the group they aim for) it is even more important to have full control over your character and don't have to guess 'hm where may my character on the server be?'. It is pretty interesting anyway that there is no answer from GGG now, because there are only so much reasons why. Last edited by DE3me#2347 on Sep 16, 2013, 9:34:36 AM
|
|
"Although I agree with you that the claim that wait-based netcode cannot work is pretty much a lie (it can work, and has in other games), I can say without hesitation that prediction-based netcode is the superior option. What's troubling in GGG's manifesto is not the conclusion, but the logic presented on how they arrived there. When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
|
|
" That is your opinion. We got at least 8 Pages of discussion about this at least 50% will disagree on your opinion and unless you or GGG can present an argument to proof your point i don't see any reason for a prediction-based netcode not to be worse than the direct approach. " Just to do this again: The problem they talked about ("If you're far away (New Zealand, for example), it feels like you're playing drunk. Every time you issue an order, nothing happens for quarter of a second.") is a server point and has not much to do with the solution itself and "This does not work for Action RPGs." is no reason, it is just garbage. Last edited by DE3me#2347 on Sep 16, 2013, 11:10:14 AM
|
|
"Computers don't care about opinions. This is a computer performance issue. Opinions are for the most part irrelevant, and you could get 80 pages of idiots expressing fallacies and it wouldn't change a thing. It's mostly a message delivery issue — that is, purely dealing with latency and message processing. The wait vs prediction thing is a triviality. When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted. Last edited by ScrotieMcB#2697 on Sep 16, 2013, 12:51:26 PM
|
|
" The system you use is still relevant, because if you run the direct system on higher latency you will have delay, while with the actual system you get non predictable desync errors. |
|
" A good summary of this entire thread. Also, programming is easy, it's debugging that's hard. |
|
" No a really bad summary of the thread; implementations are based on human decisions and I think it is not so much the technical problem that is being discussed but more the decisions resulting in that problem that are being discussed. Also why would debugging be so much harder than programming exactly? Last edited by Startkabels#3733 on Sep 16, 2013, 5:05:11 PM
|
|
" Finally, a reasonable question rather than another unfounded opinion. There are many reasons why debugging is harder than programming, but I think the crux of it is this: Computer programs are divided into many hierarchical layers of sub-systems, each designed to process a narrowly-defined slice of the overall functionally of the application. This enables each programmer to focus on solving a series of limited and relatively self-contained problems. The central question most programmers ask themselves: What will it take to make this sub-system work as specified? When unanticipated bugs emerge, they often involve multiple layers of sub-systems, and can be challenging to isolate. This may require understanding and investigating numerous sub-systems and the interactions among them. Once a culprit is identified, a solution must be implemented and tested to verify that the bugfix does not itself cause further unanticipated bugs. The central question seasoned debuggers ask themselves: What will it take to insure this sub-system will not fail to work as specified? That's what I mean by hard. Last edited by RogueMage#7621 on Sep 16, 2013, 5:56:23 PM
|
|
" I think you have no idea what you are talking about The most common types of mistakes when programming are: Programming without thinking Writing code in an unstructured manner Before you starting debugging you reproduce and isolate. And you know what then? YOU TURN ON LOGGING AND GET AN ERROR CODE |
|
|
If I'm not mistaken, even GGG agrees that desync is improveable. It just takes time to engineer a solution.
So what's the discussion? No one is disagreeing. |
|
