Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: FoeHammer on August 13, 2010, 07:10:59 pm
-
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.
-
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.
-
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?
-
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.
-
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.
-
*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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
Mods take precedence but other than that, CP5670 speaks truth.
-
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.
-
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.
:wtf: 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.
-
:eek:
Goober +1
:nervous:
I agree with Goober... it makes much more sense.
:warp:
-
And I would say he's wrong.
The mediavps, whether they were designed to be that way or not, have over the years become a shared resource. Many mods have been designed to REQUIRE the mediavps (Like BP, for example), simply because it saves on total download volume if you just use ressources already present in the mvps. In addition, by using "known good" content from the mvps, you save yourself a lot of trouble in troubleshooting.
And seriously? The number of systems that can't even use the "standard" mediavps without the advanced stuff is really, REALLY low. Making sure that mods run on every little piece-of-crap VIA S3 system (to pick an example) is simply not viable.
-
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.
Let me check my calendar. Hrm, I'm sure this must be broken. Let me check another. No dammit, even this says it's 2010. Must be something wrong with my calendars.
Or maybe not.
If you have a computer that cannot handle mediavps, I feel sorry for you. You are entitled to your opinion about mediavps and dependency on them, but let me just say that I believe far majority of this community disagrees with you. Me included. And now, let's not make this a flamewar.
-
I personally think Goober doesn't have a bloody clue. And fixing a mod to work with a new version of MVPs is most of the time a 5min job at most anyway.
-
And fixing a mod to work with a new version of MVPs is most of the time a 5min job at most anyway.
This is true for smaller mods, but with larger ones, no. Not so much.
-
I see benefits to both sides.. but here is my main concern.
I'm down with mods having to update to work with 3.6.12. And I'm also Ok with having to keep 3.6.10 until those mods do update...
But what about the older ones where the teams/leaders aren't around or don't care anymore. Am I supposed to sit and wait for FSCRP to get around to them while taking up precious HDD space with a lot of the same assets in 3.6.10 AND 3.6.12?
I'm just guessing that this painful process (while having many good benefits) will alienate some mods to the "too old to play anymore" category...
As a new guy, I wouldn't download mods that required me to search for and also download 3.6.10...
-
I tried to keep compatibility without MVPs in PI mainly for the debugging reason Goober indicated. The MVPs change over time and I wanted to make sure that there was always a baseline for what the campaign should play like, if any issues come up later. I made the base campaign operate on the retail data, and used a collection of extra vp files that replace tbms from the corresponding MVP files. In one case, it was also necessary to have two different copies of a mission due to different turret positions on the original and high-poly Hecates.
-
:eek:
Goober +1
:nervous:
I agree with Goober... it makes much more sense.
:warp:
Don't FSPort and STR require the media VPS to work?
Anybody that says fixing a mod to work with a new version of the media VPs is at most a five minute job has never done it.
-
Don't FSPort and STR require the media VPS to work?
IIRC they will still work not only with retail data, but with the retail executable as well.
-
:wtf: 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.
The mediavps are probably the most extensively tested and heavily used custom assets in the entire FreeSpace community. Any bugs they have will get caught and fixed rather quickly due to the amount of use they get. They contain a vast amount of content that forms a sort of common platform for mods to work on. It's a vast amount of content that I don't have to bloat my own mod with because it's already there. And no, I will never, ever, ever, ever support retail or "retail look" with any of my projects. The graphical features are an integral component of my mods, and they are designed around them. Many other mods are like this too--Blue Planet: War in Heaven would be crippled without the new graphical features of 3.6.12 (which were not only meant to be there but created for the project). Video games are after all a visual experience above all--it's even in the name of the medium. Many people want their projects to look a certain way, and that way need not be the retail way.
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.
It's also meant to be a common platform for advanced mods, a sort of mod equivalent to a DLL that you can plug in and work off of instead of dumping it all into your mod ("statically linking" it, if you will), and increasing both the size of the mod and your workload (integrating it, maintaining it, updating it) tremendously if you wish to use its entire feature set (and I use its entire feature set--any advancement made to the mediavps goes into Twist of Fate). And again, a lot of people do not care about the "basic" functionality of retail. I'm not making FreeSpace 2 1.06 mods, I'm making FreeSpace2_Open 3.6.12 mods, and I'm going to make the most of what's available to me. I'm not interested in retail, I'm not interested in 640x480, and I'm not interested in the hypothetical complaints of someone who can't spare $50 to get a used graphics card that can run the basic mediavps, whose numbers must be getting rather small these days considering that performance requirements haven't increased significantly for the base mediavps in years. I wouldn't be surprised if using the mediavps this way was one of the reasons why the mod.ini format has the primarylist and secondarylist features.
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.
And at least the backgrounds and some of the effects were already in the mediavps and their presence in a separate download was entirely unnecessary. You could cut quite a bit from the optional media and replace it with a mod.ini linking to mediavps. And now that the mediavps have versioned folders, you'll be sure that the version of the mediavps loaded is always the correct one.
But what about the older ones where the teams/leaders aren't around or don't care anymore. Am I supposed to sit and wait for FSCRP to get around to them while taking up precious HDD space with a lot of the same assets in 3.6.10 AND 3.6.12?
Well, not only are the mediavps moving, but the codebase is moving--unless you're developing without FSO at all, you're going to have to support your mod and test it with new builds occasionally because you never know when a code change might break your mod--and even then it could still happen (INFR1 is a notable example--out of the box it to my knowledge only works with retail). The only assets truly "safe" are the stock Volition materials and missions.
-
And I would say he's wrong.
The mediavps, whether they were designed to be that way or not, have over the years become a shared resource. Many mods have been designed to REQUIRE the mediavps (Like BP, for example), simply because it saves on total download volume if you just use ressources already present in the mvps. In addition, by using "known good" content from the mvps, you save yourself a lot of trouble in troubleshooting.
The larger your asset pool, the harder it is to maintain as well. Adding new assets is not a one-time investment of time and effort. I recently did a large-scale reorganization and updating of ToF's existing assets that made the mod not only look better but cut the total size by 200 megabytes (770 MB to 580). God only knows how large it would be as a standalone mod as it sits atop three mod folders listed as dependencies--FSPort mediavps, FSPort, and mediavps 3.6.12. Working on, say, 1500 MB of data would be far more tedious, time-consuming, and frustrating.
-
It is okay for me that FSU team like things up to date. However this whole new level of gfx enhancments needs optimization,because they still far away from modern games graphic quality, but in the same time they are more demanding for hardware juice and this is obviously bad.
Also backward compatibility in mods should be preserverd for folks who just want play favorite freespace game even on pentium 3 or cheap laptop,but this is modders call and they probaly don`t care and nothing about this can be done hehe.
-
It is okay for me that FSU team like things up to date. However this whole new level of gfx enhancments needs optimization,because they still far away from modern games graphic quality, but in the same time they are more demanding for hardware juice and this is obviously bad.
Also backward compatibility in mods should be preserverd for folks who just want play favorite freespace game even on pentium 3 or cheap laptop,but this is modders call and they probaly don`t care and nothing about this can be done hehe.
I do not know what to say here, except to suggest to you to learn to code, or model, or texture, and then help making it better. *****ing about it is the least efficient way of making the situation better.
Also, backwards compatibility to hardware that is 10 years old? Sorry, but I think that's not going to happen, at least from a model side. We're living in 2010, time to upgrade.
-
It's especially absurd considering that the hardware described is the hardware retail was designed to run on. If you upgrade a 10-year-old game to modern standards, you aren't going to run it on the hardware the original assets ran on. That's just not possible.