We have today come across an issue where a server runs a mod with a patched physics to which you can join without the patch but still without any sort of mismatch issues at all, which is a bit strange. The base mod is an rfmod package consisting of a number of components, one of them being the vehicles. After the first release, a patch was done to the vehicle component, but this change was packaged as a single component, not as an update to the original mod. The new (single) component has the same name and version number as the original component that is part of the mod, and the included MAS file has the same file name as the one in the original rfmod component. When installing it, it adds a new version folder with an additional "(1)" suffix added to the version number. I know the update is incorrectly done, but it seems as if it exposes a weakness in the mismatch detection system. I had accidentally forgotten to install the (incorrect) update but was still able to join a server running with the update, which gave me a different physics than the other players, without any mismatches. @ISI: Let me know if there is anything more you need if you want to take a look at this.
we had a similar issue with a track, toban. the server was a vmod using toban v0.78, members were able to join with toban v0.51, no mismatch.
I think that could be, because from version 0.51 to 0.78 the track geometry is the same and the objects are named the same way only changed the material settings. Cheers.
It is possible to change physics, repackage these as a new component, install it and join a server that runs different physics? Wow. You have to be kidding.
Sent Jeremy a link, not sure, but AFAIK you would be racing on what the server is presenting. He'll look at it to confirm.
they ran together, not as what was on the server only. we identified the issue by replays not working, cars stacking on each other in the pit stalls, and lap-times were very different between the versions. once the members installed the correct version the issues were resolved. i would have thought by repackaging anything rfmod or rfcmp the mod id and signature would flag them from running together. even different file size should have been blocked.
I forgot that there is more to this. The server was started from a vMod which I assembled without having the patch installed. The vMod links a custom track and the original vehicle component of the rfmod, but does not include any of them. What I cannot understand though, is why there was no error when the server was started. Apparently it read the vehicle physics from the update, while my local game read the physics from the original rfmod vehicle component. One of the modified things in the patch was the maximum fuel load and the engine fuel consumption, and we confirmed that I couldn't exceed the original max fuel limit while the players with the patch could do that. After disconnecting and installing the patch locally I could rejoin and verify that the server physics was now in use.
There is known bug that this maybe possible in the first minute the server is in session. Let the server uptime past a minute and see if this is still and issue or is it the case the server has been running for quite some time?
I just went through the log files, and we were around 30 minutes into the FP1 session when I first detected that there was something wrong with the fuel settings in the setup menu.
The problem is much bigger than described here. It is possible to change any kind of car-physics data related to tyres, engine or whatever, save the changes into main-mas-file and overwrite existing mas file (or first rename original mas file to have a backup of it). With this modified vehicle, lets say one gave it little extra HP or/and made tyres more grippy or both, it is easily possible, without any problem and WITHOUT MISMATCH to join a server and drive for gold This procedure was tested in many different constellations and by some different persons inside the community where i'm driving in. Again, what does that mean ? Everybody with at least a little knowledge of gmotor-physics-data and files is able to CHEAT in any possible way ONLINE on public servers without getting any mismatch at all. Guys, that really suxx !!! I would very much like to know if ISI actually knows anything about this backdoor and what are the plans to handle this case in the future ? Actually online-racing is in no way as it was before IMHO.
I can only confirm what dawave writes here. I think this should be a quick solution her.that is very important.
Thanks for the info, guys. Asking if ISI knows? Jeremy already replied. Sent from a mobile device using Tapatalk
Hello, Also, this two lines in multiplayer.ini Report Mismatches="3" // server should report mismatches for: 0=physics/GDB/RFM only, 1=physics/GDB/RFM/EXE, 2=physics/GDB/RFM/track geometry, 3=everything Mismatch Response="2" // how the server responds to mismatches: 0=does nothing, 1=kicks the mismatched client at the beginning of the Race session, 2=kicks client immediately, 3=kicks client from Qualifying or Race disappear when you start a server. I can not find "mismatch" in multiplayer.ini or player.plr
Just found a B156 server still up and could modify files without mismatch too, of course I have no idea if that B156 server had mismatch reporting turned off or not but how long could this have been going on?
So it was not caused by our incorrect update then? Wow.... This must be fixed immediately as it completely voids ALL forms of competitive league racing.
I think it is necessary to immediately remedy this problem, because it is not good to run thinking that some pilot cheats,no chance to know his loyalty. So I hope ISI,fix already from the next build this nasty bug. Babs
Thank you for your answer,and I'm glad that someone at work to solve this problem. If you serve some testing,please contact me,ISR is available to help the development of rFactor 2. Babs