Who said anything about making new .MAS files? The server would know which .MAS it had to open to load its contents. So my quick idea would be: - new client tries to connect - server remembers the actions necessary to load the currently running session, like: I had to open file <name here>.MAS in directory <path here>, corresponding to unique IDs <ID list here>, so I send this to the client to check if they are present. - client receives the above server message, finds it´s missing file corresponding to <unique ID here> and sends a request to the server for download. - server packs those files into an .rfcmp file, sends it to the client. - client uses "mod" instalation procedure, already in place, to install just received files. - retry connect from the client side.
Who would want there server to do all that while ppl. were racing - besides you don't get it. If whoever made the rfmod repacked all cars and tracks (people DO, sadly) then you'd need everything none the less Not all hosts are sitting on 100mbits
Well, first there is the option to disable downloads as a whole or limit the max file size. Also, I already asked for bandwidth control. And I do get it. I don´t want to make vMods myself to begin with. But I don´t have a choice, if I want to run, say, the Corvette as it is not part of any official "mod". As it is now, I would have two choices, to outline the extremes: Create a vMod with the bare minimum, which is the selection of cars and only one track, to minimize the possibility that people trying to join have to download something, be it from my server or somewhere else. This would defeat any kind of track rotation whatsoever, except for different layouts of one and the same cicuit. And I would need to create a vMod manually every single time, I want to run a different circuit on my server, until I have one for any possible combination of cars and a single track. Now you tell me, how would I keep track of the gazillion quite redundant vMod packages. And it is a real burden for an admin to login to the root server every single time someone wishes to switch tracks, because "/callvote track" is effectively non-existent. Plus, if I do want "lazy" people to be able to download missing content from my server, I would have no choice but to include those components in the (v)Mod. How´s that for redundancy storage wise? Create a vMod which contains all cars and all tracks, just to minimize my server admin overhead, which in turn would require people to have all the tracks installed, even if they are just in for "quickie", see "oh Limerock, got that one, let´s see what´s what. Oh damn, 2GB of content I haven´t even heard about?!" Edit: As I said earlier, I am a lazy person, but I am an admin as well. Now go figure, which would be the option I would choose. No offense, but you don´t get it. Cheers, Marcus
That is the server admins option. I personally have 6TB a month so I would not care but I understand your point. You will notice a URL field will be/has been added to rfcmp/rfmod file. This information can be shared by the dedicated server to rF2 clients so they can download from any HTTP server, not just the built in HTTP Server in the dedicated server. Disclaimer, as always this work is in flux and subject to change however we are currently working towards that stated goal.
Sure... the bandwidth is not the problem at all, the server could just provide a link for download de Vmod from any place else. The problem is: In the current system you must have undesirable content in your HD, which perhaps will never be used! This goes against all of optimization concepts and, after all, it might even degrade the simulator performance… not good. So, as Marcus said, why not a verbose TXT informing you which file or files is causing the mismatch, including the folder (s) involved? In addition, it would be recommended the server host publish a quick set of information on the server windows (links for cars and tracks which are being used in that specific room). Thus, you'll pick only the content that you want and need to race online.
When you get to the package mod screen click the Info button and there is a URL text box there as well as a description box where you could provide further information.
Even if I might sound repetitive now, I´ll try to put my ideas and my understanding of others´ into different words, so maybe ISI can understand what is not working with the vMod concept and how it could be changed for the better with infrastructure already in place. A vMod is a meta-mod, meaning it does not really contain the content, but merely contains pointers or symbolic links to the necessary components. By definition a mod, not only vMods, is comprised of at least one vehicle component and one location component. From what I see this vMod concept is just one level to high in the structure for being actually useful for running or connecting to a dedicated server. Also vMods are misused or abused, I´d say, for the purpose of describing or defining a server instance, which in fact they don´t. Go one level lower to the components level (.rfcmp). A server session can be distinctly described just by this level alone. By session I mean the currently running track (as opposed to all available in a vMod!), the cars that are allowed by the filter and technically the session status (practice/qualy/etc.). The latter is not important for determining, which conditions a client must fulfill to join a server, so will be left out of this discussion. From the client perspective, one wants to join such a session not a mod. It is and should be of no concern, which kind of session might come next, as many have already pointed out. As it is now, the server demands to have a vMod installed which of course points to the content that comprises the current session, but it also very likely points to surplus content not relevant in the current context. This requires a client to have that content installed, regardless of the fact, they might never want to use it. And a new problem came to my attention just this morning, the list of installed mods will get very messy with time, because of inherent redundancies with this approach. As I said before there is a goal conflict with creating vMods. One either takes the atomic approach, including only the bare minimum, which will make that list cluttered up very fast, and also makes administration a nightmare. Or with the monolithic approach, including everything, clients have to install a massive overhead, depending on their usage pattern, but this is way easier for an admin and basically brings back the "All cars and all tracks" option of rF1. Also, joining another server with the exact same vMod contents but different Mod name and ModID will require you to install that vMod as well, if I am not mistaken. That cannot be right, because that would result in perfect redundancy. Atomic: Clients happy(ish), admin bangs head against wall. Monolithic: Clients very unhappy. Admin, being happy and having time, becomes client, so is unhappy again. Back down one level to the components themself. During session initialization the server creates the definition of the current session on a components level, that could be a volatile vMod. With volatile I mean, it will only exist during session runtime. On session change or when the server is closed it will get uninstalled and then deleted so to not clutter up the Mod Manager. This would only be the second best solution, but I could live with that. An even better solution would be if the above component level session definition only lived in memory, so would be volatile already. The connection initialization procedure would not make use of vMods, but only tell the client, it needs to have the necessary components installed, with the option to download them directly from the server or by redirection to a mirror. I emphasize redirection, because it is very cumbersome to get a URL from the rFactor2 UI into the browser, which basically means, one would need to type it manually, not very convenient for longer more complex URLs. As ISI staff members have pointed out, one of the goals for rFactor2 is, that you don´t have to break your installation by manually installing or more precisely copying files into the filesystem structure of your installation. The means involved in achieving this are version control and unique IDs. rFactor2 components have these implemented, so they have everything necessary, you don´t need vMods for this, not on a server anyway. This aslo solves the above goal conflict which is the essential reason for user frustrations. As a side effect this also reduces complexity, since mere users/admins, don´t need to use Mas2.exe, leave that to mod creators who actually know what they are doing, or at least have a better understanding of rFactor 2´s inner workings. A reduction in complexity also usually reduces the probability of errors and/or mistakes. So please, ISI, please do rethink this vMod concept. I know, my summerization of ideas, mine and others´, means you have to restructure or redesign the dedicated server, which might be more work short term, but it will pay off long term. In its current state it is just a frustrating experience, because of the added complexity and very limited flexibility, which I believe results in less online activity of the community in the long run. That in turn would lead to less revenue. I do want to love rFactor 2 for you do so many things right on the simulation front, but I am having a hard time actually getting there. Best regards, Marcus
I see that, but isn't that just a reference URL for the mod team? I took Jeremy's post to mean that we could place an URL somewhere and the GET MOD could pull mods from another server (separate from the dedicated game server).
