The rfmod issue

If you’ve been modding for rF2, or run a server for rF2, or tried joining a non-ISI server for rF2 you’ll probably have had to deal with .rfmod files. With rF2 it is not enough to have the car and the track you want to run online. You also need a .rfmod file that says “Car A at Track B”. A fair amount of protest arose on the forum which culminated in a “petition” to remove the rfmod elements.

You’d think that would be the end of that, but it apparently isn’t. While the “petition”-thread also contains some emotional statement and less pervasive arguments (which is why I stoppped participating in the thread after page 5 or 6), there’s a whole row of well reasoned arguments for why the current implementation is lacking. See the end of this post for some examples. And yet that would all still be fine if the response from ISI would have been more productive. Gjon put in the effort relatively early on to answer points raised until then. The most definite statement I saw on the issue was:

“The CarID/TrackID split isn’t out of the question, its just not possible until components get tracked in a similar fashion.” Gjon Camaj

The only thing that I learned through that statement was that the current implementation is not set in stone. Good, it would be a disaster set in stone if it was. It however doesn’t declare that the system definitely will change. It doesn’t tell me much of how other options than the current implementation are shaping up in internal discussions, only that there are other options.
After this moderately productive start the statements from the pro-.rfmod side became less helpful. “It’s only beta and I’m sure it will all be better soon” seems to be the standard response in varying degrees of harshness (here in a more kind version).
Seeing how the rfmod issue is rather extensive and significant – it affects all online racing and how car and track mods are created after all – that’s not good enough for me. The latest comment towards the rfmod issue came from Tim Wheatley when Slothman (who without doubt can make his arguments either kindly or harshly as well) pointed out the rfmod issues again when a presumably technical error with Build 68 made older rfmods dysfunction. Instead of responding to the issue or ignoring it, Tim mentioned the possibility of a ban for Slothman and despite right away denying it that comment put it on the table and set the tone.
I believe we have long since passed the point of discussion of actual issues with the current implementation and crossed into a massive communication issue about it. Tim’s post is the perfect example for it. I very much doubt he wanted to stir up the issue even more but inadvertently did so by alienating those discontent with the rfmod-system even further.
Later in the thread, D.Painter drew an accurate picture of where we ended up. We’re seeing the issues pointed out two months ago happening already, with a small amount of content. They are neither hard to see, nor were they hard to foresee. In D.Painter’s words:

IT’S RIGHT IN FRONT OF YOU NOW!!

And we’re still left with no definite answer and communicative mishaps like Tim’s post.

As an afterthought, the emotional responses and frustration shown by people in the “petition” thread or by D.Painter in the post I linked are neither very helpful, constructive or clever. However I have much more sympathy for their reactions than for ISI still being quiet about a solution.

If you’re interested, here’s my personal list of issues I have with the current implementation and why I think a more definite word on whether/how it will be changed in the future is needed.

– Why? What’s the benefit of a .rfmod? The only benefit I can see is the possibility to distribute cars and tracks at the same time. Fine, I like that, please let’s keep that possibility. But if you don’t want to distribute a “complete” mod like that, it only carries disadvantages with no single advantage I can make out.
– If I have Car A and Track B, why can’t I just race Car A at Track B online? Why do I need Mod C that just says “Car A at Track B”? This is a few bytes of information that can easily be transmitted between server and client machines, like it was in rF1.
– It doesn’t even clear up mismatches. In fact, you could have Car A and Track B in the exact same version as the server, but you might not have the rfmod file at all or in a slightly different version. If you had different versions of the car and/or track, your rfmod would also differ (different hash value). It introduces a new kind of mismatch instead of curing any mismatches. Car A and Track B is not enough anymore, it now also needs rFMod C.
– Components can be version tracked just like .rfmods, with none of the repercussions. As far as I can see, they are already similarly version tracked through a version number and a hash value. They just don’t include a .rfm.
– .rfmod is supposed to make life easier for non-modders but actually requires extensive modding knowledge (creating a .rfm, building a .mas file, submitting a mod and receiving a Mod ID) to race a new combination of car/track online.
– All Cars/All Tracks (mentioned as a way to handle the sim like with rF1) will become a convoluted place once more car/track mods get installed and is not a fix for any of the multiplayer issues.
– As a track maker I need to rely on others including my track with their .rfmod or throw my own .rfmods out there including cars from third parties.
– This isn’t a issue of rF2 being in beta. These are systemic issues. They significantly impact modders and users.