[Phantom Hoover]

Can someone explain why mod authors are still relying on internal resources from the MVPs which are too volatile to reliably use between versions? Would it not be better to take the (minor, in this day and age) hit for redundancy and package those resources into your own mod?

[Dragon]

Because most mod authors don't think about that when they make the mod. The texture/asset is simply there, available to use. So why not use it? I think that old effects (unless replaced with a drop-in upgrade), tilemaps and such should remain in Mediavps, and compatibility should be maintained. I recall that it used to work like that, and 3.6.9 to 3.6.10 switch was rather painless (though some 3.6.9-based ships lost upgraded maps due to moving over to mipmaps, but that wasn't so bad).

[Macfie]

In working with restoring old campaigns the biggest compatibility problem is with the use of tables and TBMs.  Many of the older mods created an entire table instead of a TBM with the changes.  Starting with the 2012 mediaVPs this caused errors to be generated.  The difficulty in restoring the campaigns is trying to figure out what the author changed from the original campaign and puting that into a TBM.  I really haven't run into that many campaigns that relied on the old textures.  The change from the 2012 MediaVPs to the 2014 MediaVPs was relatively trouble free as long as you used a recent nightly build.  Updating from 2012 to 2014 is relatively easy.  It was the change from 2010 to 2012 that caused the most problems.  A single version would make it easier.

[Luis Dias]

Yes, I have also seen this pattern wherein changing the mod.ini from referring to mediavps 3.2.12 to mediavps 2014 hasn't been causing any harm to barely any mod I've encountered so far ("barely" because I can't really remember having a problem is different from not having had one... my memory sucks)

[mjn.mixael]

So many thoughts... Where to start.

An example of a ship that can easily break mods... Arcadia. And that's still with the "conservative" upgrade we did. Half the community want a round hole I the middle which would break every mod that ever used Arcadia extensions.

Like it or not (and I know some of you don't, so let's not debate it here), we have chosen to give modelers a little more freedom with upgrades. As Zacam has said, we don't feel that we should limit the few modelers who are interested in working on things as long as they can work in the FS2 campaign. To impose greater restrictions with upgrades and re-imaginings would likely cause those few modelers not to even work on stuff.

For FSU to officially say we are generally backwards compatible means that we will suddenly get all of the support questions. FSU does not have the capacity to deal with that. Yes, I know that the "community" could help, but only a select few will... It will be those few who help in the support forum already. FSU is only a community project so far as in everyone wants it there way, but I have seen little evidence that real contributions would be made outside of the "fun" kind. (Models and the like.) The last time the community said they could help was the Colossus Normal Maps to try and get 2014 out sooner. That didn't work out, because the person suddenly wanted to do it there way causing even more work in the process. We have a hard enough time getting our own team members to consider the project as a whole and not just their own pet models. FSU cannot handle the official capacity of backwards compatibility. More members is not the answer... see previous sentence. People get in FSU to create their own vision of upgraded FS and we have plenty of clashes.

I'll stop there for now.

[Lepanto]

+1 vote of support for handling MediaVPs through the installer. That setup wouldn't break older mods while being more newbie-friendly than the current setup (outside of tech support issues, but that seems like a comparatively minor price).

[Phantom Hoover]

Like it or not (and I know some of you don't, so let's not debate it here),

Uh, no, this thread was created precisely so that this issue can be discussed publicly. The MediaVPs' compatibility policy is creating a support nightmare, one which is in all likelihood driving new users away. This must be solved if FSO is to continue to thrive.

[mjn.mixael]

No, this thread is about how to best release the MediaVPs in order to limit confusion and make it easy for new users to get started. It is NOT about our policies on modeling restrictions... Conservative vs Anything Goes, or whatever you want to call it. Using this discussion to imply that liberal or conservative upgrades lead to driving users away will not be tolerated.

Consider this a warning. If you, or anyone tries to steer the discussion in that direction... Moderation will take place.

[Phantom Hoover]

All new MediaVP releases should replace old ones and be fully drop-in backwards compatible with all past campaign releases.

I think compatibility policies are a big part of this discussion whether you want them to be or not.

[mjn.mixael]

FSU will not place arbitrary restrictions on upgrades. We will not base our acceptance of upgrades on some set of arbitrary conservative vs liberal rules  (an idea that is infinently more complex that the actual problems we are facing now) for the sake of "infinite backwards compatibility".

This thread is about how best to present the work that has been created to the end user, how best to get it installed with ease on a broad basis.

This is your final warning.

[The E]

I'm with mjn on this one. Trying to make the MVPs eternally backwards compatible is a futile endeavour. This whole discussion is based on a slight misunderstanding of what the MVPs actually are; they're not intended to be a big repository of mod assets, just a comprehensive upgrade package for FS2. That they've been treated as a community asset repository is, in my opinion, a wrong development.

The way to address this issue is, in my opinion, through a better dependency management in the Launcher. The case that sparked this discussion was arguably an enormous anomaly in terms of things not working right, taking it as a benchmark for "this is bad and must be fixed right meow" is IMHO not the right thing to do.

[Phantom Hoover]

When the standard support advice is to install two mostly-redundant 4GB packages separately, you can't really say there's no immediate problem. Who exactly is responsible for this situation isn't really important compared with actually fixing it.

[General Battuta]

As above, I acknowledge the support issues and the possibility that older campaigns will break. I am proposing that we accept this as a tradeoff for enhanced user experience when installing the MVPs.

[jr2]

Is there actually any way to have our cake and eat it too as far as redundant files being downloaded?

[Phantom Hoover]

Well kind of, in that I've not heard of any campaigns being incompatible with the 2014 MVPs.

[mjn.mixael]

As above, I acknowledge the support issues and the possibility that older campaigns will break. I am proposing that we accept this as a tradeoff for enhanced user experience when installing the MVPs.

I would rather pursue mod dependency support in the installer. Your proposal means that every mod since 3.6.12 will need to be updated (if only for the mod.INI), which will add confusion. It also ensures a return of unknown issues with mods that we know work flawlessly on older versions.

As for redundant data and download size... As the installer grows, a complete installation (currently recommended) is going to be more than massive. If that's how people want to install every mod ever, then they should be prepared for that download size. Also consider mods like BP going standalone means more redundant downloading... Should they have to reference the MediaVps to avoid redundant doeliading? What about mods like BtA that are basically FSPort? Should BtA be forced to reference FSPort to avoid having a 3gb 2 mission demo? How far so we take this argument of redundant downloading? (This is a real question.)

[mjn.mixael]

Well kind of, in that I've not heard of any campaigns being incompatible with the 2014 MVPs.

Test these and let me know what you find.

[General Battuta]

Mod dependency support in the installer is a good step!

[mjn.mixael]

Some further thoughts and then I'll stop talking for a while.

FS modding is very complex... Technically and socially. We have webs of tables, command lines, and recommended settings so that everyone can play the game the way they want. This was developed during the Windows XP "tinker with your computer" era. But now, we've entered the smartphone "install an app and you're done" era and we are trying to figure out how to make FS Installs that simple. I'll be interested to see how close we can get as we continue to try and support every possible setup ever.

But what I'm seeing here is support thread deferment. We want to deal with any number of mod errors for the trade off of trying to make the MediaVPs simpler to install. Having looked at the logs in the support thread that spurred this discussion, I would rather do what we are doing now. It was super easy to see that he didn't have the MediaVps version required... Which is our fault for not having them in the installer. If we defer the support threads to when mods may not be compatible with the latest MediaVPs,who knows what errors we will run into, but it could truely be anything. You think new users are having issues following instructions editing a mod.INI? What about when a new user wants to play something older than Transcend with the newest MediaVPs? Now they have to edit tables, or other files just to get it to load.. Or just be told they are out of luck. That seems worse to me. But maybe it's just me.

I also don't think the issue as systemic as some are making it out to be, but maybe I'll be proved wrong as we begin to support the new Steam players. I will also note that people don't usually post immediately when the install does work... Because they are shooting Shivans. We have no baseline comparison of the number installs that are going flawlessly.

[Mongoose]

Can someone explain why mod authors are still relying on internal resources from the MVPs which are too volatile to reliably use between versions? Would it not be better to take the (minor, in this day and age) hit for redundancy and package those resources into your own mod?

Well the thing is, while most people may have the filespace to manage this redundancy, having to eventually wind up with hundreds of megabytes' worth of duplicated texture or effect models just to ensure compatibility is a horribly-inelegant solution to the problem, at least as far as I'm concerned.  As you said yourself later on, taken to the extreme, it's exactly what we have with the two sets of MediaVPs: two multiple-GB folders that represent, for all intents and purposes, a complete redundancy in function.  During my recent Installer run-through to get everything up to date, I was basically gritting my teeth watching both of those download simultaneously.  I like to keep my HDD as uncluttered as physically possible, so anything we could do with the aim of eliminating the Department of Redundancy Department would be a huge boon as far as I'm concerned.

I'm with mjn on this one. Trying to make the MVPs eternally backwards compatible is a futile endeavour. This whole discussion is based on a slight misunderstanding of what the MVPs actually are; they're not intended to be a big repository of mod assets, just a comprehensive upgrade package for FS2. That they've been treated as a community asset repository is, in my opinion, a wrong development.

That's the part I don't  understand, though: why shouldn't the MVPs be viewed as something of a community repository?  Obviously not in the sense of containing modding work that wasn't originally from FS2, but instead in the vein of serving as a gathering-place for any and all upgraded retail assets.  It always made a lot of sense to me that various mods would reference MVP material, because they could be viewed as something of a universal baseline, which almost everyone playing the game would already have installed.  I know the organization of the MVPs will by necessity change over time, but I think there's inherent value in establishing some sort of baseline structure to them, to the point where external mods can properly reference them.  Think of it as an API for the MVPs, if you will.

(And as far as I'm concerned the whole tangent about upgraded models is one big non-sequitur, because in the vast majority of cases, they're not the element presenting the actual compatibility problems.)