I agree that is how it should work. But I suspect the reasons they haven't done it like that are along the lines of; copyright, maybe ISI would be liable to being sued if people were sharing tracks converted from other games; and bandwidth reasons, the mod files would have to be served from somewhere, this would probably be users dedicated servers which have limits on bandwidth and having lots of people downloading mod files then the bandwidth will add up considerably.
Year 2013: iRacing It is just that nothing competes with that when it comes to ease of online racing. Every other system is a compromise and troublesome.
That is a somewhat too easy a statement i think. Most of us will tweak the .PLR file so that new joiners cars do not get loaded untill we exit track into garage. Because otherwise it might cause abit of lag. And thats just a car/skin everyone allready has.. Emagin the server having to feed joiners complete tracks and mods, nobody would be able to race anymore. we're all waiting untill someone has finished his instant-download. This is not Call of Duty where it dont matter if a granade ends up 10 feet from where you aimed it, we need pixel perfect accuracy, one slip and yer off-track or in the back of another car. And when he finaly gets it all and can join, the session is over and moves to a different track, instant-download starts again...for half or most of the people on the server. (because with auto-downloads, whom will bother getting this stuff before joining? 90% of them will start using instant-d/l) IF it was a server capable of dealing with that, which most are not. And someone simply hosting a quick game will not be able to do this anyways. And even if we would host instant-download via an external server, there are many servers whom simply would not go for this option. Peeps are paying for their webspace and bandwidth and i dont think anyone wants to pay so that a bunch of random joiners can download 300MB mods and whatever mb tracks , times what, 10 per night x 7 days x 4 weeks. that easily removes most of the allowed bandwidth on a payed hosting deal. And hosting companies are not going to be polite, you simply get cut off. cya next month.
Not used iracing for a while now, i was not aware that they moved from pre-installing mods/tracks before you can join a race to auto-installing mods and tracks when you join a server. how is that working out so far?
First there is no tweaking required, it´s a default setting. You´d have to tweak it to not have it wait until you leave the track. Anyway, this has nothing to do with the network code. It is done that way because the loading of the graphics on the client side would halt everything else until it is done. You also have this "lag" when you are in chat - ever noticed that there are letters missing, when you were typing away and somebody joined in the meantime? That´s due to your client loading the textures of the new car and not even accepting your keystrokes; somewhat nasty but not mission critical. This could and I believe will be addressed by prioritized packet queuing. There was a mention of something like that in the context of custom skin propagation. As a consequence this could happen: But that really is some kind of worst case scenario and is no excuse to not have it. The other "options" we are using now, like getting the content by other means would still be there. And by referrencing a track component (.rfcmp) it would be even easier, since, if properly filled with meta data, it would contain the URL of origin. Think vComponents. Just because not all will be able to make use of this feature is no reason to brush off the merits of such. If I took that argument far enough, I could as well say, why allow 30+ clients, a home line will not be fit for that anyway. Not quite sure what you´re aiming for here, but no matter when it is done, before or during the join procedure, which also dpends somewhat on how one defines those two points in time, You are only required to have the content relevant for the currently running session. A session in this context is a server instance, defined by the car filter and the track (singular). This is an in-sync solution, whereas ISI´s approach is out of sync, since a vMod hardly even defines a server instance. It defines the superset of available content, whereas the server instance itself could very well use only a subset of it. Cheers, Marcus
Fair enough, my point was skins vs mods/tracks, if we allready have 'some' issues with tiny skins and indeed chatlag, it will increase greatly with auto-mods/tracks. To me its abit too easy to claim it will just work so why not do it. I agree, no excuse not to have it, even if we dont use it, more options are allways better. My reaction was abit clouded because i was abit pee'd with the notion that its 2013 and therefore everything should work and should be free. Someone will be paying for this and someone is going to have to provide space and bandwidth. So either ISI increases the prize of rf2 or setup a delivery-system we will pay for, or hosts pay for it. so the idea that 'its easy because 2013' is just silly. I dont see ISI setting this up for us, why would they, so we pay for it. But yes, if i could have auto-install-everything for just our members (whom pay for the server/web space with donations) then it would greatly enhance the whole thing. Good point, again [iracing] I was aiming at the notion from Johannes that this was better in iracing. yet iracing does not use auto-install-uppon-join at all. silly to say something is better when neither use it. But to elaborate, iracing is a closed system, they decide how it works and have full controll on what happens and users are not allowed to change things. So yeah sure, the system becomes better with full control. And i suspect that is what the '2013' remark came from as well, playstation networks, xbox network, all seamingless and effortless, because its closed and people pay for it. And no way of changing anything. Its not free, they make allot of money from sales and subscribtions and are able to implement systems where things become effortless-ish. Rfactor is an open system, or at least 'ish' and that comes with a whole lot of opourtunities (modding etc) and also flaws. Which one is better is a whole different discussion but if we want one thing (open source) i suspect we also have to deal with its effects. can't have it all although we should indeed allways be aiming for improvement.
And my point was that the skins/texture loading combined with ones client frozen during that procedure has nothing to do with some other client downloading content from the server. There will be nothing loaded on the clients already connected. The only lag that is possible would be network lag and could be dealt with by a QoS implemetation. The iracing vs rFactor 2 thing is indeed not a fair comparison. There are fundamental differences. But my point was, that they have the in-sync solution worked out, and ISI haven´t. I think the ISI solution relies on a terrible design flaw or two for that matter. First, as I said in different words, (v)Mods are not really describing what is the "now" on the server, they describe the "what could be". And secondly the definition of a Mod as consisting of "at least one vehicle component and one Location component", to be found in ModMaker.chm. I think this came to be to have a quick and dirty "solution" for the mismatches, because it bears no logic, or I simply fail to see it. "Traditionally" a Mod always contained at least one vehicle component and optionally other kinds of components as well. The said thing is, design flaws/bugs are the hardest to fix, but I am still confident that there will be a change for the better.
That people are sick of Clios at Mills and my take on the reason. Case in point: I changed our server setup, created that one vMod that references all ISI content. I figured the official recommendation is to have it all anyway, nobody should have a problem getting that vMod to install. On top of that I changed the setting to not pause when idle. The car filter is set to the Clios, but there is quite a selection of tracks, that run on rotation. This server instance has an uptime of well over one day, and only one driver has joined it so far, one. It is running fine, has not fallen off the matchmaker list, and it is not only Mills running. Makes one think, what keeps people from joining then? On the other hand a Server instance that only runs the default Clio mod would have had several "joined" and "left" messages in the chat log by now. And that despite people are so sick of it.
Exactly why we run one on Mills only. As you just mentioned Diablo, many leave and join, change to any other tracks and people stay clear.. At least we will all be expert drivers around Mills
But isn't the 'only lag' abit of an understatement though? even if the filesharing between server/client does not effect other clients allready on the server, surely the data and bandwidth will greatly effect in-game lag? Even now with 15 plus drivers one client with a shady connection could seriously effect ping for others. And with QoS implemetation, where would this come from? by ISI design? if so, wouldn't they be the ones having to provide the complete package then? (design/request/delivery/d/l and install) which then sends us towards a more closed system? I have to admit this is rapidly going towards the limits of my knowledge on the subject hehe. But that has never stopped me before You make a fair point though on creating one vmod for all default content, thats an easy solution indeed and would/should not stop people from joining. yet they only/mostly join clio's/mills servers? Wierd stuff. Experience from rf1 tells me random joiners join servers that allready have at least 1 driver in it, they search for occupied servers and avoid the empty ones. In rf1 they even randomly join without knowing if they have the mod/track. This could maybe be it, if most clio/mills servers are not dedicated but quick-hosts. a quick-host usualy allready has 1 driver, the host, and others join in and then the rest follows. Does that make sense?
Denstjiro, by "the only lag possible" I meant, it would be network related, and that´s what packet queuing as a means of QoS (Quality of Service) guarantee can prevent. That would not by any stretch of my imagination be a more closed system. It would be there to make sure that critical packets get through as quickly as possible everything else in the network stream grinds to a halt if need be. I know the phenomenon of people joining populated servers, but still I see more ocassional joiners on a Clio/Mills server even if it is empty.
With critical packets you mean preventing packetloss right? thats the first stop i asume in making things run smoothly. But that would not solve lag as these two are, whilst related, still two different things? So even with no packetloss we can still be influenced by other factors as te mentioned bad connections or what we are discussing with auto-loads for mods and tracks. Which brings us all the way back to the original post....so, 4 pages of nonthingness?
You cannot prevent packet loss by software, unless it´s a bug causing it. Packet loss is more likely to occur somewhere in transit over the internet and/or by faulty hardware. Unless the faulty hardware is on your end, there is nothing one can do about that. QoS means Quality of Service. If it is defined by "mission critical packet leave this network interface first to have the least latency possible" then that´s what it´s going to do, but it has to be implemented. I am still trying to get my point across. People want to join with least amount of hassle, especially new community members. Those have very likely not yet noticed that it is recommended to have everything provided by ISI installed, so they get a mismatch, err vMod installation failure. Not bothering to fix the problem they move on... to a default mod they happen to have already installed.
That was my point as well, least amount of hussle i mean hassle. So conclusion? all default content becomes available both ofline and online, and ISI have to release rf2 as one-install and not 'help' us by providing seperate components forcing people to try and understand the system?
Auto mod and tracks would be a nightmare That is why we have torrents and not before time. You would slow up the server and everyone else with it. Why should ISI pay your bandwidth usage for addons. Conclusion, rF2 don't have to do anything. You barking up the wrong tree somehow associating a mismatch in rFactor and other sims with the rFactor2 vmod system.
Applause, you have proven once again, that you are not capable of reading or understanding what I have posted. Thanks for quoting out of context by the way. Welcome to my ignore list, enjoy your stay...
I would like to know why there is no random weather at these races? It is awesome feature in this sim and nobody uses it. And with Clios it should not be even too hard, just more interesting.
