[FoeHammer]

Having looked for and not found a similar thread, I made this to provide a place for modders to post links to patches providing compatibility for the 3.6.12 mediaVPs.  This should save time looking through the dozens of updated release threads bound to pop up in the coming days/weeks.  Remember to include the name of the mod with the link, for ease of searching.

[Scotty]

I highly doubt that most campaigns are going to be upgraded to mediavps_3612 anytime soon.  There are a whole lot of them, and some of the creators have since disappeared or gone inactive.  The major new ones (like Vassago's Dirge, Blue Planet: War in Heaven, and Wings of Dawn) already are or will be mediavps_3612 compatable.

Honestly, I'd just keep the 3.6.10 mediavps in your FS2 folder and play with them.

[TopAce]

But if "updating to mediavps_3612" takes only adding 5 characters to the mod.ini, then why not just tell people how to do that?

[Fury]

Because doing that to untested mods is not wise. At the bare minimum every mission needs to be loaded in debug build to ensure there are no debug errors. Secondly, visual effects are inconsistent if mod has added custom ships and/or weapons. Thirdly, if mod is using scripting it needs to be tested more thoroughly as debug does not necessarily complain about conflicts with scripts used in new mediavps.

[Macfie]

I"m really starting to ask myself if I really want to use the new media VPs at all.  Based on Fury's comments, there are only a very few campaigns that will work with them.  The errors are not evident and it requires extensive testing to determine if older mods and campaigns will work.  I'm supposed to wait on the campaign originator to fix his mod or campaign and most of the older campaigns originators are not around.  It sounds like Bill Gates has taken over the FreeSpace upgrade project and we now have windows version 3.6.12.  It would seem that the FreeSpace Upgrade project has forgotten the end user by not maintaining compatibility.   

[The E]

*Sigh*

No, wrong. Most mods should be OK with the new mediavps, however we can't give blanket guarantees that they will be. You'll have to test it.

Also, it was a choice between maintaining compatibility to old campaigns, and having new stuff like the various scripts, the HTL Hattie, HTL Lilith, HTL Cain, the list goes on.

[Fury]

Assuming a mod was properly developed in the first place and has no debug errors when used with mediavps .10, then fixing up a mod to be .12 compatible is a matter of an hour of work, assuming there are even any problems.

For visual consistency mod can either disable mediavps scripts, or add their own mv_shp_exp_flashes.cfg and mv_wep_exp_flashes.cfg which contain all custom weapons and ships. Again an hour of work at best unless it is really large mod.

Only very few mods have ever used scripting, those who did should know how they work and check if they conflict. Cross-checking scripting functionality should be an hour, or two of work.

All in all a day's work for most mods assuming they didn't have problems or debug errors with earlier mediavps. If they did, then the mods weren't properly done in the first place.

As for compatibility. All FSU can really do about it is to add a vp-file containing removed files, nothing more can really be done. If you stick with full backwards compatibility, you can't really improve mediavps anymore and that would be end of the line for mediavps. Full backwards compatibility is nothing more than a fairy tale because any modification or addition to mediavps can break mods no matter how unlikely it can be.

Even such a minor thing as tabling differences between two versions of mediavps can cause visual or other inconsistencies in mods, if not debug errors. Consistency is almost as important as is being free of debug errors. Mods need to work as they were designed to and altered tabling or other assets in new mediavps can break that consistency.

The bottom line is, while new mediavps and old mods can cause problems when used together, these problems are more often than not minor problems and very easy to fix. However, because even minor problems can affect how enjoyable playing experience is, mods are better off using the version of mediavps they were designed to work on until they are updated, if needed. If there are mods out there that are no longer maintained by anyone, then what stops the community doing what communities do best and update those?

Also, this community has short memory. Have you forgotten how much grief mediavps releases in the past caused for mods and players alike? Each and every release have always broken mods. It's just that 3.6.10's have been around for so long that people take compatibility for granted. The only difference in mediavps .12 release is that instead of forcefully breaking mods, more than one version of mediavps can exist peacefully without breaking any mods.

[Macfie]

This just further illustrates my problem.  What may seem easy to a modeler is incomprehensible to the normal user.  Again the problem goes back to not having the original creator of the mod available.  Something as simple as converting a tbl to a TBM can be complicated if you don't know what all the changes were that the creator made.  Quite frankly it has taken me since the release of 3.6.10 and the 3.6.10 media VPs to get all the campaigns I have to run and that does not include getting rid of all the debug errors.  Since it is not always clear what some of the problems are going to be it means that I have to look at every campaign.  As for using the campaign with the set of media VPs it was designed for, I don't happen to have kept a library of media VP revs.  I'm saying that there needs to be some means of uncomplicating these changes to the media VPs.  What kind of things in the campaign are likely to cause errors?  What things are not affected?  This would be information that would be nice to know and would make it easier to fix things.  Because I'll tell you, I'm not holding my breath on seeing updates to campaigns to make them compatible with 3.6.12. 

[General Battuta]

I"m really starting to ask myself if I really want to use the new media VPs at all.

You don't have to. The 3.6.10 MVPs are right there.

It sounds like Bill Gates has taken over the FreeSpace upgrade project and we now have windows version 3.6.12.  It would seem that the FreeSpace Upgrade project has forgotten the end user by not maintaining compatibility.   

3.6.12 is totally backwards compatible with all campaigns (that are not packed with errors.) It's the 3.6.12 MVPs that aren't - and MVPs have never been universally backwards compatible.

[Goober5000]

If campaigns were designed from the start to run independently of the mediaVPs -- meaning they didn't require the MVPs to contain any specific maps, sounds, tables, or settings -- then they should work perfectly fine with the new mediaVPs.  FSPort, TVWP, and (the as-yet-unreleased) Scroll of Atankharzim all fall into this category.  So do any campaigns designed for retail FS2.

However, the majority of mod designers did not perform due diligence, relying on mediaVP assets for their stuff to work, and did not consider that the assets may not always be available.  For example, if they relied on an old mediaVP texture for their customized model, and that texture was removed or renamed in the 3.6.12 mediaVPs, the model will fail to work.  This will result in a nasty debug error and possibly an invisible ship, depending on how the mod is used.  You may remember that this has been a recurring point of contention in the past, although in the past it was mainly because it's easier for the SCP to debug problems if the mediaVPs are disabled, and very few mods allowed you to run with the mediaVPs disabled.

I have my disagreements with the way the FSU team assembled this latest version, but the mod designers that use the mediaVPs should really accept their share of responsibility in contributing to the compatibilty problem.

[Klaustrophobia]

it sounds to me like the fix to the incompatitbility you are describing is really easy.  if you need anything out of the MVPs, just copy it out and put it in your own mod's VPs.

no?

[TopAce]

it sounds to me like the fix to the incompatitbility you are describing is really easy.  if you need anything out of the MVPs, just copy it out and put it in your own mod's VPs.

no?

If you know which textures are the ones that you need to copy into your /maps, then it's easy. Realistically speaking, though, you just don't know which specific textures were in MVP3610, but were removed in MVP3612.

[Fury]

Realistically speaking, though, you just don't know which specific textures were in MVP3610, but were removed in MVP3612.

Ummm, what? Finding out if textures are missing is as easy as loading missions in fred debug. Weapons you can check in one well swoop by using -loadallweps launcher flag. Either write down missing map names or open debug log afterwards. For a modder, this is really easy.

[Galemp]

For a competent modder, this is really easy.

Fixed that for you.

And yes, the FSU team is well aware of this issue... which is why they have 3.6.12 installed into a new folder. If we had put everything into the normal MediaVPs folder, then everything would break and it would be havoc. As it is, everyone is still welcome to use the 3.6.10 MVPs until their mods are patched.

[CP5670]

If a campaign simply needs some MVP assets, that's easy enough to fix as described earlier. However, there are other sources of problems with MVP updates that are trickier to deal with.

One issue is if the campaign needs to overwrite stuff in the MVP tbm files. As far as I remember, entries in the MVP tbms have precedence over campaign tbl or tbm data even if the MVP mod has lower priority in the mod.ini. The only way around this is for the campaign to override the tbm files themselves by having its own copies of them, and they need to be updated every time an MVP release comes out. The same comments apply to any other files that the campaign replaces, such as models.

Any new high-poly models can also create problems, which are hard to detect but can potentially be game-breaking. This was a big problem back when the models had holes in them, which I think is no longer an issue, but any differences in geometry, subsystem locations, FOVs and so on can still result in subtle changes to how missions pan out. Ideally, a mission should be retested with the new models to make sure it still works as it used to.

[The E]

One issue is if the campaign needs to overwrite stuff in the MVP tbm files. As far as I remember, entries in the MVP tbms have precedence over campaign tbl or tbm data even if the MVP mod has lower priority in the mod.ini.

Wait, what? No, they don't.

[Fury]

Mods take precedence but other than that, CP5670 speaks truth.

[Woolie Wool]

If campaigns were designed from the start to run independently of the mediaVPs -- meaning they didn't require the MVPs to contain any specific maps, sounds, tables, or settings -- then they should work perfectly fine with the new mediaVPs.  FSPort, TVWP, and (the as-yet-unreleased) Scroll of Atankharzim all fall into this category.  So do any campaigns designed for retail FS2.

However, the majority of mod designers did not perform due diligence, relying on mediaVP assets for their stuff to work, and did not consider that the assets may not always be available.  For example, if they relied on an old mediaVP texture for their customized model, and that texture was removed or renamed in the 3.6.12 mediaVPs, the model will fail to work.  This will result in a nasty debug error and possibly an invisible ship, depending on how the mod is used.  You may remember that this has been a recurring point of contention in the past, although in the past it was mainly because it's easier for the SCP to debug problems if the mediaVPs are disabled, and very few mods allowed you to run with the mediaVPs disabled.

I have my disagreements with the way the FSU team assembled this latest version, but the mod designers that use the mediaVPs should really accept their share of responsibility in contributing to the compatibilty problem.

Why should I bloat my mods up by hundreds of megabytes rather than use external resources that work just fine? Dynamic linking has been standard in programming for years for a reason. To my knowledge you have never particularly cared about staying on the bleeding edge of SCP's graphics or other features, but some people do and it creates a lot of work for developers and a lot of wasted disk space for users. Using the mediavps is not "due diligence", it's an application of sound programming/design practice (dynamic linking) and a courtesy for people who don't want to download 800 megs of stuff they already have. This is actually an aspect that greatly annoyed me with TVWP--it would have been a smaller, leaner, and better-looking mod if it didn't waste space duplicating assets the mediavps already had.

One issue is if the campaign needs to overwrite stuff in the MVP tbm files. As far as I remember, entries in the MVP tbms have precedence over campaign tbl or tbm data even if the MVP mod has lower priority in the mod.ini.

Wait, what? No, they don't.

TBMs override TBLs. To override mediavp TBM changes, you have to create a TBM of your own.

[Goober5000]

Why should I bloat my mods up by hundreds of megabytes rather than use external resources that work just fine? Dynamic linking has been standard in programming for years for a reason. To my knowledge you have never particularly cared about staying on the bleeding edge of SCP's graphics or other features, but some people do and it creates a lot of work for developers and a lot of wasted disk space for users. Using the mediavps is not "due diligence", it's an application of sound programming/design practice (dynamic linking) and a courtesy for people who don't want to download 800 megs of stuff they already have. This is actually an aspect that greatly annoyed me with TVWP--it would have been a smaller, leaner, and better-looking mod if it didn't waste space duplicating assets the mediavps already had.

Take your foot out of your mouth and do some research instead of jumping to conclusions.  This is not about dynamic linking or graphical enhancement, this is about functionality.  A mod should not require the mediaVPs in order to work, and it should be so for several reasons, the most important two of which have been explained on this forum ad nauseam for years.  First of all, if your mod has a bug that the SCP team is trying to track down, it's a lot easier to debug the mod by itself (with the mediavps disabled) than to debug the mod plus mediaVPs.  Second of all, there are users who don't use the mediaVPs for whatever reason -- perhaps their computer can't handle them, perhaps they have retail nostalgia -- and they don't want to be forced to play a mod that requires the mediaVPs to always be turned on.

You forget the primary purpose of the mediaVPs is to take existing assets and upgrade them.  That means that your mod should work without the upgrade.  If you want to use a high-res fancy texture that the mediaVPs supply, then your default mod sans-mediaVPs should supply the low-res, basic texture.  It shouldn't supply the high-res fancy texture itself -- if you think I'm saying that the mod should provide exactly what is in the mediaVPs in all respects, then you obviously don't understand the concept.  If your mod takes advantage of the mediaVPs' enhanced functionality, then you need to make sure it provides its own foundational functionality.

And you also have several easily refutable misconceptions about TVWP.  First of all, TVWP was developed independently -- and in a large part, actually before -- the mediaVPs, so it has very little in common with them.  Second of all, TVWP shares almost no models or weapons in common with the Port or retail FS2, so there's very little there for the mediaVPs to upgrade.  And finally, the core download of TVWP is only 32.1 megabytes.  The other 82.4 megabytes -- consisting of the brand new high-res interface, the glow/shine/normal maps, the backgrounds, and the rendered cutscene -- is entirely optional, and clearly marked as such, and TVWP was designed to run perfectly fine without it.

[mjn.mixael]

 

Goober +1

 

I agree with Goober... it makes much more sense.