Michael Juliano
Track Team
I'd like to "quickly" give you an overview of the packaging system as it currently stands:
Those familiar with rF1 and adding mods to it will be familiar with the \gamedata sub-folder of the rF1 install. You should also be familiar with the pounding-your-head-against-a-wall inducing effect of getting booted for mismatches
The packaging system is our effort to reign in the mismatch madness, as well as an attempt to control content cheating.
For those that make rF2 mods, please note that \gamedata has changed to \ModDev (Mod Development). The structure within remains the same, as does the file structure for cars and tracks. This is where you will create mods for rF2 and test them locally offline using the "Developer" version of rF2 (which is part of the beta release). In this area things will be just about exactly as you remember from rF1.
When you are ready to start testing your mod online you will need to apply for a ModID number from us for your mod (it's EASY to do and free of course). Only mods that have a ModID will show up on the matchmaker. Components (single cars or tracks) do not need ModID's...
When testing is over and you're ready to release your mod to the community you will need to submit a SigID to us (signature ID) that links the contents of your mod to your ModID. This is how we can verify that people have the proper mod installed so they can join servers running it, and that no one is joining a server with altered components. Again, single components do not require this process.
Sounds a bit confusing, I know, but it's really not. Let's take a track and break it down a bit:
--Loose files for a single track in a "locations\track" folder. This is as you should remember from rF1.
--Loose files are packed into .mas files. Again, .mas files should be familiar to you if you modded rF1.
--.mas files are packed into a .rfcmp component file. This is where things get new. Each .mas file is given a unique signature, and any change to the files within change the signature. When you pack those mas files into a component, the component also gets a unique signature ID, and any change to the mas files within changes that. This is how we can guarantee a component you have matches a component on a server you want to join.
--At this point you can either release the track component on its own, or pack that along with other tracks and cars into a complete .rfmod package file.
While offline you can use All Cars & Tracks to race any combination you like, currently only content in a .rfmod file can be used online. So, let's say you wanted to race F1's on a series of kart tracks (why anyone would--who knows ). You could take the components you wanted to use, package them up in a mod file, and release that as a mod. This is basically what we've all been doing all along, but now it's just more organized. We have some ideas to loosen this up a bit down the road, but this is the current state...
You could also release a "virtual mod" with the components you wanted to use. What this does is reference certain cars and tracks you have installed, but doesn't actually include the components, so the download is VERY small. It is up to the other users to make sure they have the proper components. This is VERY close to what we had in rF1, but again we're validating you have everything you need to join the server by hosting it on a mod basis.
And don't worry, if a .rfmod contains a component you already have installed it is not installed a second time. And, if you uninstall a mod and and another mod uses a component from it the component is retained so the other mod isn't suddenly broken...
So, let's say you are a league admin, and you want to get your drivers what they need for the upcoming season. You could either provide them the components to download, and then a virtual mod for the series that uses those. Or you could package everything up and they can get them in one go. Also, if you had to make a change you could release an update that would take your "super great racing series 1.0" to 1.1, or whatever.
By the way, modders, don't be afraid to let people use your components in their own mod packages. We have in mind a way to allow you to encrypt your components so the data within can't be extracted. So, you could, for example, put some "credits" on the loading screen of a track and whenever that component is used everyone will be able to see who made it. This isn't working yet, but shouldn't be too hard to do once we get to it.
It's a lot to digest, and I'm sure a bit confusing at the moment. It's okay--it took me a couple weeks to get the hang of it myself. Now, I can't imagine releasing content any other way. It even makes uninstalling components and mods as easy as a single click, rather than hunting and searching through the gamedata folder to delete what you THINK you no longer need.
Trust me, once you get the hang of it, and learn to use the system, I think you'll find you can do just about everything you could before. And of course, we will be listening to you all, and will try to find ways to deal with special case situations. As with the rest of rF2, the packaging system will grow and mature as we get more and more feedback...
Those familiar with rF1 and adding mods to it will be familiar with the \gamedata sub-folder of the rF1 install. You should also be familiar with the pounding-your-head-against-a-wall inducing effect of getting booted for mismatches
The packaging system is our effort to reign in the mismatch madness, as well as an attempt to control content cheating.For those that make rF2 mods, please note that \gamedata has changed to \ModDev (Mod Development). The structure within remains the same, as does the file structure for cars and tracks. This is where you will create mods for rF2 and test them locally offline using the "Developer" version of rF2 (which is part of the beta release). In this area things will be just about exactly as you remember from rF1.
When you are ready to start testing your mod online you will need to apply for a ModID number from us for your mod (it's EASY to do and free of course). Only mods that have a ModID will show up on the matchmaker. Components (single cars or tracks) do not need ModID's...
When testing is over and you're ready to release your mod to the community you will need to submit a SigID to us (signature ID) that links the contents of your mod to your ModID. This is how we can verify that people have the proper mod installed so they can join servers running it, and that no one is joining a server with altered components. Again, single components do not require this process.
Sounds a bit confusing, I know, but it's really not. Let's take a track and break it down a bit:
--Loose files for a single track in a "locations\track" folder. This is as you should remember from rF1.
--Loose files are packed into .mas files. Again, .mas files should be familiar to you if you modded rF1.
--.mas files are packed into a .rfcmp component file. This is where things get new. Each .mas file is given a unique signature, and any change to the files within change the signature. When you pack those mas files into a component, the component also gets a unique signature ID, and any change to the mas files within changes that. This is how we can guarantee a component you have matches a component on a server you want to join.
--At this point you can either release the track component on its own, or pack that along with other tracks and cars into a complete .rfmod package file.
While offline you can use All Cars & Tracks to race any combination you like, currently only content in a .rfmod file can be used online. So, let's say you wanted to race F1's on a series of kart tracks (why anyone would--who knows
). You could take the components you wanted to use, package them up in a mod file, and release that as a mod. This is basically what we've all been doing all along, but now it's just more organized. We have some ideas to loosen this up a bit down the road, but this is the current state...You could also release a "virtual mod" with the components you wanted to use. What this does is reference certain cars and tracks you have installed, but doesn't actually include the components, so the download is VERY small. It is up to the other users to make sure they have the proper components. This is VERY close to what we had in rF1, but again we're validating you have everything you need to join the server by hosting it on a mod basis.
And don't worry, if a .rfmod contains a component you already have installed it is not installed a second time. And, if you uninstall a mod and and another mod uses a component from it the component is retained so the other mod isn't suddenly broken...
So, let's say you are a league admin, and you want to get your drivers what they need for the upcoming season. You could either provide them the components to download, and then a virtual mod for the series that uses those. Or you could package everything up and they can get them in one go. Also, if you had to make a change you could release an update that would take your "super great racing series 1.0" to 1.1, or whatever.
By the way, modders, don't be afraid to let people use your components in their own mod packages. We have in mind a way to allow you to encrypt your components so the data within can't be extracted. So, you could, for example, put some "credits" on the loading screen of a track and whenever that component is used everyone will be able to see who made it. This isn't working yet, but shouldn't be too hard to do once we get to it.
It's a lot to digest, and I'm sure a bit confusing at the moment. It's okay--it took me a couple weeks to get the hang of it myself. Now, I can't imagine releasing content any other way. It even makes uninstalling components and mods as easy as a single click, rather than hunting and searching through the gamedata folder to delete what you THINK you no longer need.
Trust me, once you get the hang of it, and learn to use the system, I think you'll find you can do just about everything you could before. And of course, we will be listening to you all, and will try to find ways to deal with special case situations. As with the rest of rF2, the packaging system will grow and mature as we get more and more feedback...
