[mjn.mixael]

You cannot install 3.6.10, 3.6.12, and 2014 to 'mediavps' without breaking almost everything. The best idea with the tools we have now would be to require a legacy mod folder 'mediavps_3612' that contains a small rollback VP. However.. that still requires mod authors to update or end users to alter the mod.ini.

[General Battuta]

Something I haven't seen discussed yet is that even if we did change to a sole 'MediaVPs' install folder now. We have just about 4 years of mods that now rely on 'mediavps_3612' and 'mediavps_2014'. These are, arguably, the mods that most players will be playing and until the mod authors update them, we'll have the same issues as now.. just in reverse.

Yeah, this is a huge obstacle.

Also, I have continued to follow the thread that spurred this.. and I'm not convinced the guy is even following instructions correctly. It makes me wonder if this issue has only presented because of one loud user having issues where 40 quiet users are enjoying the game already.

It looks like he may have been the victim of an installer glitch.

[Grizzly]

I also have a feeling I know the answer, but I think the option should be mentioned, what about compatibility packs, something that sits on top of the current media vp to replicate the old version.

I really don't like this idea, but I wanted to hear how it stacks up.

How about turning it the other way around, and turning the MediaVPS into an iterative process with updates, so that you have a

1) Base set of MVP's, let's say the 3.6.12 MVPs
2) An Add-on set called 2014, which is dependant on 3612, containing only what has changed.
3) Another add-on set called 2015, which is dependant on 2014, containing only what has changed.
etc.

That way we have an excuse to stick all the MVPs into one thread, thus simplifying it a bit (download all of these files, extract them, select latest or mod of choosing). It also deals with bandwith issues.

Basically - Backwards compatible delta patching.

[AdmiralRalwood]

Then you run into the mod.ini problem where a mod depending on "2015" won't automatically get "2014" and "3.6.12" in the -mod list; your mod.ini would have to refer to all of them in the SecondaryList to get all of them. After a few of these "upgrades", the standard SecondaryList entry starts to get a little ridiculous.

[Grizzly]

Then you run into the mod.ini problem where a mod depending on "2015" won't automatically get "2014" and "3.6.12" in the -mod list; your mod.ini would have to refer to all of them in the SecondaryList to get all of them. After a few of these "upgrades", the standard SecondaryList entry starts to get a little ridiculous.

TBH, a little ridicilous SecondaryList entry (which can be copy pasted anyway) seems like a small issue compared to the user usability, bandwith, and that sorta things mentioned here.

[swashmebuckle]

Other than ugliness in the mod.ini (which the end user hopefully won't be messing with), what are the drawbacks of doing it this way? Is it a pain in the ass for the FSU team? It seems like that method (combined with the installer checking for and downloading dependencies) would be the minimum bandwidth/maximum compatibility/minimum hassle option for the end user. I guess changing over to that sort of system could be a rocky experience, but that's a one-time difficulty.

[jr2]

Ha, how about if we do decide to do that, then we move the secondary list from mod.ini to mod-secondary-list.ini to avoid user confusion? I dunno, just a thought.

[m!m]

The best solution would be to completely deprecate mod.ini and use a more powerful and modern format to specify mod dependencies. The launcher could then resolve which mods need to be enabled to play a specific mod.
For example, if a mod requires the 2014 mediavps it would only say that it needs the MediaVPs with version "2014" (or something else, depends on how the versioning works).

[Kolgena]

That sounds a lot like how MS dotNET framework works. You have dozens of versions of the thing, and essentially none of them are compatible with each other. However, the MVPs aren't a couple megs in size, and it could get ridiculous after a few iterations when people run 10 gigs of Mediavps in different versions just to keep their game working.


...and I have no idea how a unified MVP package could be accomplished. I'm leaning towards saying that it can't.

[Fury]

"mklink /j mediavps fsu2014" would create a junction point to a directory called fsu2014 from link called mediavps. Unlike symlink, creating junction points do not require admin privileges. This however means that something would actually need to create the junction point, like Goober's installer. Only Vista and newer supported though. XP and older would have to use 3rd party tools or plug into Win32 API for same effect.

[jr2]

Make an empty mod called <new MVPs name> and have the mod.ini primarylist point to the mediavps mod?

[Phantom Hoover]

Doesn't work because mod.inis aren't recursive.

[jr2]

Add a [+recursive] flag?

[Mongoose]

Honestly ideas along those lines all seem hideously complex and prone to massive failure, at least compared to what I was trying to articulate earlier.  I don't know if I ever got it out clearly, but my main thought here wasn't that we should come up with some system that tries to mash previous MVP versions into one massive ball, but that we should establish protocols that allow for mods to reference MVP content with the reasonable expectation that said content will be available in the future.  In other words, say something like, "Okay, we're calling these weapon effects X, and these ship models Y, and these sounds Z."  That way, even if the individual files are edited to some upgraded version in the future, there will still be a file with the same name in the same place that a mod can reference down the line.  And if for some reason a whole category of files were to be removed, like the upgraded tilemaps were, they could be included in a theoretical "MV_Compatibility" pack, something that wouldn't directly be referenced anymore by the MVP's own tables, but that would still exist for the sake of backwards compatibility with third-party campaigns.  If that system were set up, then we could tweak all of the prominent mods out there to conform with it, and have them continue working indefinitely, without needing to re-release them every new MVP version when something breaks.

[Fury]

Mediavps compatibility with other mods is much bigger in scope than just file names. After compatibility comes the issue of consistent user experience. Even if new major mediavps is technically compatible with a mod in a way that it does not cause any prominent errors, it does not mean user experience is consistent and what the mod creators intended. Naturally errors are the biggest cause for concern, but user experience is not something to forget about.

User experience is something we've had to take into account since mediavps_3612, as that was the first release to use scripts. As mediavps become more complex in enhancing user experience of retail FS2, the harder it is to keep user experience consistent in mods that depend on mediavps. Let's take Blue Planet as an example, it has lots of ships that were not in retail FS2 and even completely new faction (or race, however you want to put it). If Blue Planet had been designed to work with mediavps version X and then suddenly end-users upgrade mediavps to version Y, user experience could be severely uneven and inconsistent even if there are no errors.

This can be avoided if both FSU team and mod creators work together to ensure compatibility and user experience work out with newer mediavps. In a perfect world. In reality, I doubt this is going to happen without significant headaches on the part of FSU and mod creators, potentially leading to many issues and even delaying mediavps releases. It's much better for the community if FSU can work in their own timetable without having to excessively worry about other mods and mod creators can work in their own timetable without having to worry about upcoming mediavps releases. After all, why would FSU have to worry about other mods when their task is to upgrade retail FS2?

I really do not believe one mediavps to rule them all is going to happen. If you want to do away with having to keep multiple versions of mediavps around, then there is really only one solution. Mod creators bundle mediavps contents into their own mods instead of depending on mediavps like they do now. This has the side-effect of increasing mod sizes several times because of duplicate assets as well as additional headache from mod creators having to manage mediavps assets in their mod mod. Managing these assets and somehow keeping them separate from the mod's own assets is extremely difficult and time consuming. Upgrading these assets from newer mediavps release even more so. To make such a situation workable, there would be need for multiple data directories. I don't think fs2_open and fred2_open supports that at this time.

Renaming mediavps to something more approachable and understandable is completely separate issue and I agree with others that better name would be a good idea. As for the name, changing the project name to The FreeSpace 2 Upgrade Project and mod directory name to freespace2_upgrade would be my suggestion. Likewise the FSPort version would be freespaceport_upgrade. Upgrade as a word covers all assets, not just visuals.

[General Battuta]

Dependency control in the installer will resolve many issues raised in this thread.

[Phantom Hoover]

Many of the rest could be solved if mod authors were encouraged to use good hygiene when sourcing their assets, rather than using potentially volatile ones.

[Dragon]

No, that would not solve anything. Every asset in MVPs is volatile, improvements are made all the time, and there's no telling what will change next. Something seen as a peak of quality one day will, after a time, get old and probably get remade. Also, we need to consider realistic solutions - those that can be implemented by MVP team and they alone. Relying on people following a directive is a shaky assumption at best.

[FelixJim]

I feel like the launcher being able to tell the difference between a mod which requires a specific version of the mediaVPs, and a mod which would like to use the latest mediaVPs available but doesn't need them would be useful. I suppose this goes back to what m!m was saying. This and a big push to get content creators to stop treating the mediaVPs as a "community repository", which places a horribly unfair burden of responsibility on the FSU team, sounds like the right direction to me.

[assasing123]

are you suggesting to make the mediavps work like windows? XD all that backward compatibility is going to cause a lot of bugs, but I agree this is the best choice, it would be better to fix each other mod in a case by case basis until everything works with a single Mediavp system.

Personally I use the mediavps 2014 with all the mods, and rarely do I get crashes, mostly when stuff like shaders come up do I get some issue. tho I do remember having to edit one or 2 mods to make them work with this files.