[info] Desync Code - Epic Fail ?

[Varlock]

Clients don't do desync checking on their own because they don't have access to the state hashes being generated by other clients. If someone desyncs it's up to the host to disconnect them. If the host doesn't, they will remain in the game, they will just see different things happening than the other players.

I'm not saying this is a bad thing, but don't expect clients to disconnect themselves when they desync. That's why the desync code was added to GHost++. I'm not defending the code as being efficient, I'm just saying that it does actually have a purpose.

[Unreal]

A desynced player who is not dropped from the game will see the other players just idleing? Or is this hugely messing up the game?

[PapayaDealer]

why not remove the desync-part and try out to see what happens?

[Zephyrix]

why not remove the desync-part and try out to see what happens?

That's what it was like before...

[PapayaDealer]

See how it will affect the performance at all...
won't be the same as in v13 since there have been many other changes made to ghost++.

[Sir Rogers]

So, I removed the desync code. The obvious problem is if players are playing from 1.24d and 1.24e. This obviously wasn't a problem on battle.net as wc3 would automatically prevent this problem. I am now adding a wc3 version checker in the next rgc patch to get rid of that.

I'm sure there will be other desyncs based on the map, but they shouldn't affect the gameflow that much. Tough I have no data on that.

I haven't been able to check for the server performance increases yet. I will do that when I have time.


Regards,
Sir Rogers

[PapayaDealer]

Simply set up some autohosts (only for testing purposes of course) and wait them to fill up.
Then use the ghost++ without desync-code and do the same.
Would be interesting to see if it affects the performance noticeably.

[Sir Rogers]

Simply set up some autohosts (only for testing purposes of course) and wait them to fill up.
Then use the ghost++ without desync-code and do the same.
Would be interesting to see if it affects the performance noticeably.

Define "noticeably".

If you compare the latest GHost++ version with the GHost++ version two years ago, you might say something like "Wow, the cpu required to run ghost++ has doubled in the last two years."

However if you just remove the desync feature, or the autohost, or any other number of the features added in the last two years, your results may not show a noticeable difference.

It's the whole that is greater than the sum of its parts.
Basically, remove all of the unneeded features and make ghost++ slim, you'll get a highly noticeable performance increase. :-)
That's what I'm trying to do anyway, bit by bit.


Regards,
Sir Rogers

[PapayaDealer]

For only a few players or games it won't make a difference.
Get a few bots with ~100 games at all running and see the difference... that's what i thought.

[Caesar555]

Desynced players play their own game. They may notice that something is wrong because the enemies move around and attack but they act like totally stupid bots. You can kill them without huge problems. Funny is you can also destroy the throne/tree but the game won't end. It really is fun when u chat with the desynced players and they tell u what happened in their game.

[jjackman]

yea, you own them in your game and they own you in their game

[Prince.Zero]

it doesn't really burden the bot.

Small evaluations of variables...

If you need to fix the ghost cpu problems just recode the sockets and the mysql class.
Some small fixes like threading some heavy functions would also be ok.
Aside from that anything else is just irrelevant.

[Krauzi]

If you need to fix the ghost cpu problems just recode the sockets and the mysql class.

what's the problem with the sockets?

[PapayaDealer]

I think the database-class is a problematic part.
The sockets seem to be okay.