search

barbudreadmon / fbalpha-backup-dontuse-ty

Deprecated port of Final Burn Alpha to Libretro (v0.2.97.43).
61 stars 43 forks source link

Finding solutions for netplay desyncs #251

Open furiadeoso opened 5 years ago

furiadeoso commented 5 years ago

From time to time we continue to experience desync issues and try to find the cause.

The game bubble bobble has helped one community mate to find a new cause of desync that probably is affecting other games:

If hiscores.dat is present (we are using them from some months ago) it seems that only each local file.hi is used. So, if there are different file .hi (the most usual) netplay peers get desync because some game variables depends of hi scores and this information is not seeded as part of savestates in a undefined number of games. In my community we can solve it by asking everyone to delete hiscores.dat, as well as all the saves. But I wanted to warn here and try to find a solution that will help others who use netplay.

Another cause of desync well known and controlled by us is to have different core-options, since these are not transmitted in the savestates. But it is also convenient to emphasize that this way of working makes it difficult for netplay to work well among people who do not know these details.

I wanted to ask if, apart from these known causes, there are more relevant data that are not currently being transmitted in the savestates and may cause desync. For example, is all the information in the .nv and .fs files and always transmitted in the savestates? Otherwise, it would be good to know them to think how to control (or include) them.

If there is not a coded solution I might help writing a netplay notes or warnings in some readme file in this repo or similar.

barbudreadmon commented 5 years ago

Disabling hiscores should be possible if the fast save thing is detected. However i'm wondering if using the already existing fast save callback for netplay is such a good idea, considering it's not only about savestates anymore. I'll tag @fr500 @twinaphex @dwedit

furiadeoso commented 5 years ago

For the hiscores issue I thought in that solution, but I think it wouldn't work if the host/client begins netplay mode after start the game, because hiscores will be loaded before.

Ideally, the host should send to the clients not only a savestate but also core-options and hiscores (maybe .nv .fs also?). And to avoid overwriting own offline configuration files maybe those files might be separated from offline. But I understand that would be a great task. Maybe doing a "Retroarch netplay mode", that turned ON would let an user hosting, joining, etc, using different files system.

RagingNoob commented 5 years ago

I would have thought that the host of a netplay session is in control for a large variety of variables reading from the "retroarch.cfg" file. It should be common sense to have this control forced onto connecting clients so mismatch of key netplay variables are matched or at least have the announcements warn with a list of required settings to match the host (or even noted in the log file?).

The imminent desyncs are competely inevitable if these settings are not matched spoiling what is otherwise an excellent 'regional range' netplay session.

I would also like to know are the key variables that need to correctly match up a netplay connection.

furiadeoso commented 5 years ago

@RagingNoob As far as I know, retroarch.cfg has no influence on netplay synchronizing . Yes it does, however the core-options.cfg that may affect the savestates. Different is that some options such as latency produce negative effects when they differ from peers, but it is not a matter of this issue.