I'm running into an issue where if I make a track rfcmp update users get a mismatch message trying to join other dedicated servers using the same base track. When they unsubscribe to my track update then they can join that server. This is how I'm packaging the rfcmp and rfmod. First, I take a track that's in the workshop and say it's version is V1.0 and I make a change to the GDB, SCN, or other updates and package them in a mas and into a rfcmp update as V1.1 (checking the box to reference the "update from" and putting the old and new versions in the fields). Next, I include the V1.1 update when I package my rfmod (checking the box in the track list). Everything works fine for users when they join my server, no issues. But they need to unsubscribe to my update to not get the error joining the other server with the same base track. Both versions are installed in the track folder. Shouldn't one rfmod simply use the V1.1 update I created and the other rfmod use the V1.0? I'd hate to have to create an entire new independent track/version that is 100s in MB size that everyone would need to download for a 5mb or less update. Also, unrelated but I find the workshop is not always updating smoothly for users. If a vehicle version changes and a new rfmod is also created only one of the changes is recognized upon the next RF2 startup. The workshop may not remove the old track or vehicle component referenced in the old rfmod upon the first start. Its like the first restart the workshop removes the old rfmod but it doesn't update the components, another restart does this and installs the new component updates. I've had people having to restart RF2 multiple times to be able to join a server. It's like there's a coding loop missing to ensure there are no more updates and when there are none to load RF2.
Apparently a known issue and nobody will tell me. Don't care anymore. Whatever. I'll just make a new fully packaged track at 100s MB for a less than 5 MB change.
@Brent As far as i remember, it has ever been like that, with own Updates. But when i remember it right too, the Packaging System was announced with something like "will make it easier to avoid Mismatches, when you join an online Server", from ISI back then. Target not reached, i would say. But it probaly makes Cheating harder.
this, and the reason the client must have the exact same carset as the server. All in the name of cheat prevention.
@redapg Right, I understand that reasoning. The issue is when users go join another dedi which is using the V1.0 track it won't let them join (mismatch) until they've uninstall the V1.1 track. I don't understand why the rfmod is unable to use either version without issue. I'm sure this will never change, I already have a workaround, and reminded yet again why I never "piggybacked" revisions on anything.
The illogical thing is that both versions are installed and should be possible yo use and check the integrity of both.
I also don't like the Way how it works now. And as @lagg has said already, it should be easily possible to still use the "basic" Version, even if an own Update is installed, because all of them use different Folders. The Problem is, that we don't know the Games Code. Maybe "easily" is not doable with the Code.
This issue can only be avoided if original base track has used a separate "upgrades" folder to store layout mas (which is packaged as upgrades to base, this is one of the trick many skin packs also uses on DLC cars), which almost all DLC tracks have those (for example you can find two folder in any of 397's dlc track, but not in none dlc track such as silverstone). So if you do the same upgrades stuff to base version number of a DLC track, there won't be mismatch, user won't need to uninstall. Unfortunately almost all none DLC tracks are single folder structure without upgrades, so they will have mismatch. (That's why quite a lot new car mods releasd on workshop are based on two folder upgrades structure to avoid such issue which has big impact on league race.)
You can avoid mismatches when also renaming the layout name in the gdb. Would need to check the exact parameter names when i am back at home this evening. Also, the layout name in the aiw or scn needs to be changed to the new name.
