Hopefully this is what we can avoid in the future tbh, we have a imo great mod management system - easy to install/uninstall mods/tracks etc however teams/skins are missing. I've given your method a try and it does work fine (minus the fact it says Virtual Ride for each new creation (personal preference)), however it is the case of as you said manual work which is less than ideal for everyone.
What manual work? If we meet each other on a server. Our virtual rides will transmit via custom skin sharing. You don't need to install/uninstall anything. Incase a league organiser want to have some control over the skins used in his league. He can make skin pack that has to be manually installed. That's still less work then repacking the whole mod to add a new car. The " 's Virtual ride " in the car list is indeed a bit annoying. Anyway the repack system is still available. But it's nice to know there are option.
It is some manual work for the drivers compared to just installing an rfcmp package, but way less work for the admin. Also much more flexibility, teams can use special skins for events without need of re-distributing new mod version. With FSR we had big lag and other odd problems on server when we attempted to use virtual teams in March, but maybe it has improved since.
Same here. It's a shame that skin/veh xfer does this. It would be cool if you could point the skin/veh xfer stuff to a standalone IIS or Apache server. Or maybe we could get a new component type for RCDs. It would still be redundant to repackage a skin component just to add a team but at least you wouldn't be downloading sounds and maps at the same time.
I think that my method has an advantage for league-use here. I you do it my way, people who don't have it installed, can not join the server, because the league "package" is treated like a normal component, that has been installed. It has an own mft file. So you can force the league participants to have the "package" installed. And i think the risk that someone cheats with a virtual driver is much higher.
There were some issues in build 930 with a virtual ride. But i haven't seen issues in build 946 with a virtual ride. But the Virtual ride might be a bit limited for big leagues like the FSR or VEC: For example assigning cars to pit groups isn't possible. But for most leagues who run series on a weekly basis: it might be an alternative.
That's exactly what i don't want to do. For example i have made my Clio virtual ride and i'm doing a race in the RD VWSR Clio league. Just after the race i can jump in the Pitlane.com server participate in the Michelin Clio Cup with the same car: My car. Without uninstalling/downloading/installing skin update packages... A virtual ride is just an alt skin with a Car name and a Team name. It doesn't contain physics.
From my point of view this virtual-car option is useless for leagues and also skin-packages. For me it would be more important to have an exactly defined package of cars. E.g. if you create a skin-package for a special season and want to have a possibility to create races only with these or, for league-use, you want to be able to create a dedicated server with only vehicles of the in a championship participating members, this virtual-car thing is useless, because i would e.g. need the possibility to edit the class-entry of the *.veh file. I would say the virtual-car is more a disturbing thing for leagues, if it allows to race every race with another skin if you want. Is there a possibility to make it impossible to use a virtual-car on a dedicated server? If not, for me the virtual-car option is not very welcome, as long as i can't deactivate it. I have to say that i didn't care for and played around with these things in the last time, since our community felt asleep and i don't have to create servers anymore. But it's just a discussion here, right? EDIT And the Thread-Opener called this: @isi-tim-Vehicle-files-is-this-possible?
You can't do that with a virtual ride. Once the client has uploaded his virtual ride, he can't change it no more. He needs to ask permission of the server admin. Yes. the .rcd file = .veh file. It overrides the Team name and Car description from the .veh The virtual ride is useable online since a few month and maybe it needs more tweaking. - Car number override - Car class override (==> not a big fan of that: you'll end up with cars all over the place in your car list) - Pitgroup override - and remove the " 's virtual ride" in the car list. If that is implemented you won't notice the difference. The only thing it doesn't override is car physics, 3D model etc... If you want to change that for your league you need to ask permission from the modder to do that.
The .rcd file = .veh file is not right, as you already mentioned. Currently the *.veh file gives the possibilities that you normally need for a league mod or also for a skinpack. Like said before, just to be able to set an own class is a big advantage. And there are some more. One thing what you said is a little problem indeed. Some modder let their team-mas files encrypt by ISI (i guess it is done by ISI?) I don't know why they do it, what can be so "mysterious" inside of a team-mas, that you have to protect it that way? But i think every modder will give permission to use original *.veh files as pattern for league use, if he is interested in seeing his work will be used for league servers. And perhaps even physics and other files.
There is absolutely no reason for a modder to protect the teams mas. There isn't any black magic in the teams mas that needs protecting. The only thing I can think of is they want to protect there skins. It's possible to have two mas files with teams so you could alway make a second one. The problem is you would need an existing veh as a template along with a skin template which you would need from the modder. I really don't see why the RCD option is getting so much negativity. With just a few more changes it could be perfect solution. I think a one way xfer option would also be needed so that leagues have full control. The ability to overwrite the category line would also be nice. That way a league could build their own folder structure on the car select tree view. I am guessing that all of these changes could be done with minimal work. Where as overhauling the packaging system would probably take a lot more work. And with the RCD option it is possible for the drivers to create their own car without the admin getting involved which is a plus for smaller more casual leagues.
Okay.. take a look at virtual rides on the new build. "'s virtual ride" is no longer appended to the name. You now enter the driver name, team name, description (this is what actually shows on the menu) and car number.
Wondering if in the end (with ISI help) we could packup addons in the already used mas file app. Instead of choosing car, location etc... there could be a new type "skinpack" which would tell the files where to go in the users directory? Just as long as you typed in the right series for it to go in so it shows up.
I really like that idea. Basicly a Team package instead of a sound package and make a multicmp with it. Or install it seperatly. But it's basicly an update package with only the team.mas. If it was up to me: i've a few wishes to that solution. - the "team" package doesn't need to be uninstalled if the host uses the original car. - the "team" package is independent from version numbers. So you don't have to make a new team package if the car gets an update. - more them 1 team package can be installed. So you can ad new teams without repacking the whole thing. If the above isn't possible, it's still a good solution for leagues that wishes to controle the skinpack used in their leagues.
I guess the mod would have to be split up this way, but I wonder if the main multicmp mod could have the main stuff but a singlecmp that would install into the mod directory referencing some of the files but not increasing the version number. So you could still run the main mod without updated, and uninstalling the update ad nauseum But my other solution above kinda works to
The most simple and obvious solution would be to remove the packaging system, its a great idea in theory but in practice it doesn't work very well at all and all the efficiencies it offers are lost when you have to continuously remake packages. So you make your skin pack, package in ref to a mod, any time in the future when the mod is updated, your skin pack needs updating too. All the while creating extra work for all concerned, compare that to the old rF1 way and tbh it's borderline laughable. People in the know always knew how to handle these things in the day when it was rF1, and it was a doddle. The packaging system is a solution to a problem that never existed, and was made for people who got confused by the ways it was like in rF1, I mean who are these people? and why develop a system to help them out which makes it completely obtuse to those who understand. The only people who had trouble before were mostly un-informed and didn't take the time to learn it in the first place. It's great people like Noel have developed stuff to help the community out and alleviate certain aspects like this, but that in itself illustrates it's not really working. It's about time ISI considered removing it and make all our lives simpler, but in reality, when you have taken a path that has eaten a lot of time into a direction like that, your not likely to be swayed easily, it takes balls to write off that stuff but sometimes you have to. How about an official ISI poll, asking what the community needs, regarding this, now that would be interesting, but only worthwhile if ISI are going to take action off the back of it. There are an army of content creators out there, not working with rF2 because of packaging, moddev, lack of proper up-to-date documentation, tyres too difficult to make etc etc and its key that ISI look into these things and take action, because rF2 is a dead product without something being sorted out eventually, which none of want to see anytime soon.
The virtual ride skinpack system: - The skinpack is no package but loose skins with a reference file. - it's independant from updates. (The EGT virtual ride skinpack still works after 2 updates from URD) - add and remove skins without releasing a new package. - online: you don't need all the cars pre-installed: you recieve them from the server. But from a league point of view there are some disadvantages: - you can't use the automatic skin-transfer if you want to check the submitted skins first. But you can turn skintransfer off and share the league skinpack with a .rar like you would do with rF1. - you can't make a separate car class for your league. (IMO: not a big issue, but a wish for some)
That's nice! So there is almost no difference between a car from the team.mas and the skin + .rcd. But i wonder if a driver swap is possible with a "virtual ride"? In previous build it didn't work. I ended up in the pitbox.
Rubbish! Packaging system.... see all the mods you have installed in mod manager. Right-click install/uninstall. Much better than fiddling around with all the files all over the directory structure. With the packaging system you don't have to. The mod dev part? Doesn't even need packaged files to test... you can test them loose until you wish to package into the final product. No more do you have the rf1 problem where one rogue file causes a mismatch and FRUSTRATION. Packages have hash files so they are truly independent from each other. You bash the rF2 system, but to be quite honest with you, the rF1 system (once modding got seriously big) was a damn nightmare!
Package system might be a bit complicated at first, but what many seem to forget is the 'lack' of weird mismatches in RF2 of which we had PLENTY in RF1... DEV actually works 'rf1-style' (kinda), and with alot of projects or duplicate versions you can experience the oddest things due to conflicts. On the whole TEAM discussion all we really need is for updates to OVERRIDE older versions, as it now a change in say .veh for #56 in an update will have you end up with TWO #56 cars :/ But as RF2 doesnt really know or care about .MAS naming or whichever content they hold this is prob. never gonna happen.
