I honestly do not think downloading tracks and mods off a server is going to work. It will effectively kill the bandwidth to the server, particularly if a mod/vmod is linked to many large tracks. Another aspect of allowing content download is that all users who have access to the server will have access to all the content, which is something leagues will probably not want. Speaking from own experiences, we like to hand out access to mods and tracks through private messages after getting to know our members a little, in order to prevent people from just dropping by the forum, reading the server password, click the "Get mod" and disappear again. The hard-linking between mods and tracks needs to be dropped, at least in its current form. I'd say its serious enough to potentially break the whole product, so please, think this through again, carefully.
If you don´t want to allow downloading of content off your server, disable the HTTP server in the Multiplayer.ini Code: HTTP Server Enabled="0" // Whether the dedicated server starts a HTTP server Edit: Another problem I see with the vMod concept as it is now, is that being a lazy person, I´d be inclined to create a vMod, that includes the cars I want and all tracks, just like Sam Moss said before. But what happens, if I then set my server to just run a tiny subset of the available content, say one car and one track? If I understand the concept correctly, the vMod would still dictate to download everything. That´s another flaw I see there, it should be the server settings that determine, which content needs to be present. Wouldn´t it be possible to change the dedicated server, so one can actually choose from all cars and all tracks. And then on session start the program automatically and silently creates a volatile vMod, that just points to the content of that session, meaning track and cars. I´d say it must be possible, since vMod creation can be automated with the Mas2.exe ModMaker, so why not integrate that functionality into the dedicated server? I don´t want to be bothered with such things. As somebody said quite nicely somewhere: Cheers, Marcus
One problem I see with your method is if someone joins with only the current track and cars, finishes the race, and gets booted from the server because they don't have the next track then that could cause frustration.
For league use I don't see any problem with the vmod system. Cars and tracks necessary for installation of any vmod are going to be provided through the league admins. Looking at the problems with the system it comes down to users who want to join public servers. If there is any problem, it is either the server admin not updating the tracks in the vmod and people who did update their content having problems to find the older version of tracks. Or it is the user not having updated a track but the vmod requires it. Which isn't really a problem as people should be able to find the latest version of any given legal track without too much problems. Also keep in mind that this problem would be there if we didn't have a vmod system. And compared to rF1, the vmod system tells you which track it is that needs to be updated and what exact version number it is that you need. Way better than the rF1 mismatch issues. The more tracks a vmod contains, the more likely it is for these problems to occur. So the easiest way to reduce problems is to release vmods that link only one car/mod & one track. Being a league admin myself, I understand that this is not practical as - even though the vmod creation process has been simplified dramatically since the first beta release - it does take a lot of time to create hundreds of vmods. So you usually find one vmod per car that links to all matching tracks for that car. Tim posted an interesting idea some time ago: Not sure whether it was just an idea or if this is something the programmers are actually looking into. If they are not, they sure should as this would eliminate every problem the new vmod system introduced (see above). The server admin could pic a car and track just like in rF1, the server creates the vmod and places it correctly so that 'get mod' works. Get rid of the icons (for server created vmods) so the vmod is only a few kb in size. Maybe even set it up so that these are one-off vmods, automatically deleted on the client after use. edit. was distracted during writing this post, so sorry if this basically repeats what Marcus wrote two posts above but what I just found after finishing my post...
If the server do not use any vmod, then do a check if clients do have the current track and car used on server. If the server changes track then do a check if the client have the next track, if not then boot the client with a message about why. If the server do use vmod, then do the standard vmod check.
With all due respect, I beg to differ, if rf2 gets this thing together somehow it will mean Leagues can/could open up their servers again and do some serious recruiting without a hussle. Sure, for its own members its no issue but Leagues tend to want to reach out. There are many many leagues but a great portion of those struggle with keeping the numbers up. this has allways been the case and rf2 could positively break this momentum. I am actualy more concerned about all of the above as a league admin then i am as a user. Especially when it comes to trying to draw in more people, a reasonable vmod/mod system would greatly help in that respect. It could mean a big (and contineuous) boost in online activity across the board and that is what we want/need with rf2.
Let me just throw this Q in here: How many mismatches have you guys had in rF2 compared to rF ? And that's why this system works...
your kidding yourself mate.. in rF1 how many times did you have the current listed track but couldnt join because you didnt have the other 5 in the rotation? and thats why the current system blows...
The make up of vmod creation still needs sorting, when you get to the section to add sounds, talent etc it's a total mess as you don't knowwhat sounds fit which mod. Really need addressing before the bulk of new mods get released.
I have to agree with that one, there should be some kind of file name structure so the sound and talent files match the mod or track, or have an association within the main mod/track files so the sound and talent files are automatically selected for the mods and tracks selected.
This argument fails immediatly. I haven't had a single mismatch. You know why...because I can't join the server because of some obscure track that I need even though I have the track they are hosting. Oh well, don't know where to get it, don't care to get it, so I move on, or I don't race (not racing is usually the case at this stage). And people wonder why all the rooms except for most very well organized, or established leagues, or default servers have people in them.
As it is now, clients who come unprepared will NOT be able to join OR cause mismatches OR mess up client IDs or the rest of the server for getting booted on entry - prepared clients will NOT have their experience spoiled by constant messages... If you can't join, something is messed up at your end, no longer can you blame ISI, the server, the MOD or League... Love this!
How can you be prepared when there is a GET MOD link that acts like it is downloading, then gives you a list of tracks in red. What does red mean? Would you know what red meant if you didn't have someone let you know? Would you know where to go find the obscure tracks even though you have the track that the server is currently running? Hell no you wouldn't and if you say you would (as a new user) you are full of crap. The VMOD system needs revising - - plain and simple.
You don't need a Vmod for it. The server "knows" exactly why you've banned, it only needs to send a *.txt with the your matching issue and you're ok for corrections. Probably a 1 Kb script would make the trick instead of terabytes of non-used cars and tracks downloaded to your HD.
Just imagine the flood of "BUG" reports ISI would get in these forums by people who messed up - would make debugging a nightmare... And yes, in most cases the server would just kick you, but you'd still require the server to spend valuable time and bandwidth on faulted installs
It actually seems like you are blaming the system, for hosts not knowing how to use it. A proper vmod, which too actually is a .rfmod should only contain references to needed content. If you are required to download allready installed tracks and cars, then whoever made the .rfmod is to blame... "New user" ? You have no idea
That´s what I don´t understand as well. Even in rF1 there was a cause for getting booted because of mismatches. That cause must be known to the server and the client, software not user that is, because the check that failed is known. So instead of being more verbose about the problem, ISI went and designed this vMod concept. And the step from being more verbose about mismatches to actually finding which files a user would need to download (from the server), wouldn´t be that big. And then, after one has downloaded those files, the client could just pack them into .rfcmp files and install them, which is basically what the Mas2.exe packaging tool already does (!). Or make it server side. The server knows, what caused the mismatch, because it knows, which track (singular, since it is the currently running session!) and cars are currently selected and loaded. So it should not be too hard to find the corresponding cars and tracks, roll them into a .rfcmp, optionally compress them and send them to the client. Or just use transport compression if you use the client side approach and want to save bandwidth. Cheers, Marcus
Every component and .MAS has it's own unique checksum, you can't "just make a new" - it wouldn't pass. Also rF2 has a completely new virtual filesystem based on MODIDs so no two MODs will conflict with oneanother, which is a very common reason for mismatches in rFactor(1) - every rfmod and component will now be isolated within this virtual filesystem, or whatever you wanna call it... Simbins Race series are also using MODIDs and CLASSIDs, but they are very limited and several MODs conflict because of this - ISI's submit-system fixes this, they will all be unique
