Lymia/MPPatch

MPPatch conflicts with other non-mppatch users

Personwithhat opened this issue · 14 comments

Hello,

Is it possible to make MPPatch not crash games when played with people who do not have it?
Like, if host is not using MPPatch (or is not using any mods but has it installed) then allow others to join and also not have the maps go all wonk? Or when client has MPPatch but joins non-mppatch host etc.

Not sure how to prevent the corrupt map issue but this would help in getting MPPatch integrated with more people.
Argument against some of it is e.g. "I want to play pubs and uninstalling/reinstalling every time annoying"

PWH

Lymia commented

I'll investigate this. This isn't supposed to happen.

Oh interesting

Well you get the same issue as you normally get when someone else has a mod and nobody else does.

People spawn - Caps overlap. Cap replaced with a road. No luxes nearby, etc. etc. just normal 'Oh someone has a mod who is it' shenanagins.

Lymia commented

Wait, hold on. Are you using the normal Multiplayer option, or the Mods>Multiplayer option? If you're doing the latter, I believe this is a known issue on my part, just one I haven't gotten a chance to fix. If you're doing the former, that should be identical to normal multiplayer, and there's a problem on my end if it doesn't work.

I hosted normal multiplayer host without any mods and no mppatch > One of the clients connecting had MPPatch still installed from previous mppatch game.
Map was bugged as usual, rehosted, figured out that one dude had it crash because of mPPatch (he didnt uninstall it beforehand)
He tested it in a 1v1 to confirm it was him and yea it was

I can test it again with a VM later next few days

I can confirm that in the following cases there is a turn 0 desync:

  • Host has MPPatch client doesnt
  • Client has MPPatch host doesnt

No mods active on host. Hosted via the main menu Multiplayer>Internet option, not the Mods>Multiplayer option.

Lymia commented

Can you test if this happens with LuaJIT disabled? If that's the problem, I might have to rethink a lot of how I handle things. u.u

So I unchecked the LuaJIT box -> Pressed apply & & OK > Pressed install
Client had no MPPatch, host had MPPatch.

And.....it worked fine. Looks like the problem.

Not sure what the luajit is for - or how it's even desyncing the games. It does appear to be only a turn 0 desync - subsequent turns after a resync appear all right. (other than the fact that the start is screwed now lol)

Just tried with the "Multiplayer Modding" unticked but LuaJIT ticket -> Same issue.
Looks like LuaJit is the problem for sure.

It's possible that some part of Civ lua code leads to undefined behavior -> Which LuaJIT and Lua5.1 handle slightly differently since, well, it's undefined behavior.
This leads to desyncs when using LuaJIT and no issues when using stock lua. Whatever the issue is, it's not fixable without modded map scripts or modded DLL/etc. files so at that point it's better to have everyone use LuaJIT........though that is annoying and hampers easier access to certain audiences.

Or maybe you have a better idea of how to make these shenanagins work :)

An addendum - Based on some of my other debugging work:
decode32() differs between LuaJIT and base game Lua

Modifying mppatch_serialize.lua decodeMod(id) when playing with mod of UUID <mod 765a4219-449e-494f-b1da-e0fc360deef1 v1>

This is easily reproducible -
Save staging room config with MPPatch LuaJIT enabled
Close Civ5, disable LuaJIT
Run Civ5, attempt to load the same staging room file.
Will 'load unknown mod' and then crash ofc when attempting to load into the game.

Same log more legible.

		local name = modUUIDBlockField(id, i);
		local opt = PreGame.GetGameOption(mungeName(name));
        uuidTable[i] = decode32(opt)
		_mpPatch.debugPrint(string.format("orig <<<%x>>>",uuidTable[i]));
		_mpPatch.debugPrint(string.format("ndec <<<%x>>>",opt));
		_mpPatch.debugPrint(opt);
		_mpPatch.debugPrint(tostring(opt < 0));

WITH LuaJIT

[30532.171] StagingRoom: [MPPatch] orig <<<b1dae0fc>>>
[30532.171] StagingRoom: [MPPatch] ndec <<<ffffffffb1dae0fc>>>
[30532.171] StagingRoom: [MPPatch] -1311055620
[30532.171] StagingRoom: [MPPatch] true

Without:

[30465.828] JoiningRoom: [MPPatch] orig <<<b1dae0fb>>>
[30465.828] JoiningRoom: [MPPatch] ndec <<<b1dae0fc>>>
[30465.828] JoiningRoom: [MPPatch] -1311055620
[30465.828] JoiningRoom: [MPPatch] true
Lymia commented

What the fuck. I'm going to have to do some serious investigation into this. This is something I can easily look at without access to a second computer, so.

The encode differs as well, in that a non-luajit lobby config also has problems when loaded by a luajit instance

I'm a bit lost as to why this is going on, temporarily hacking it to use Modding.GetActivatedMods() instead of _mpPatch.decodeModsList() on FromPreGame (bypass encode/decode) lets me load the save as expected with the mod active and what not.

Afaik luajit should function same as 5.1 so at least this is one reproducible point.

Let me know if you can't reproduce this and I'll double check on a clean VM or something.

Since LuaJIT doesn't work with non-MPPatch users + it has that annoying corrupt lua runtime issue
I'll have to play without it.
It makes the UI/etc. considerably faster even on my fast PC but the instability is too much.

Maybe if you can test to a version of LuaJIT that more closely parallels Lua 5.1, I'm sure at some point it was closer. xd

(btw (0xFFFFFFFF+1) works)