[General Battuta]

Smart people don't want to waste time installing something they're not even sure will be any fun. Complex install procedures help no one and provide a series of failure points that cause user attrition.

[headdie]

Dragon, You are forgetting there are many who will download and try to use something because it exists.  The smart ones don't change anything and use it as advertised and occasionally hit problems, the rest which are the ones you find on here go:-

Code: [Select]

Player A
"I download the Compatibility pack because someone on the forum said once I might need it sometime and I decided I wanted to make sure X wasn't missing from mod Y so I did Z and now Y wont work, what did I do wrong"

The_E/other knowledgeable person who decides to help
"Y wont work because it was designed to work WITHOUT the comparability pack. by doing Z you stopped mod Y from calling a key feature because it is not in the compatibility pack tables."

Player A
"So how do a fix this?"

The_E/other knowledgeable person who decides to help
/head desk "Reinstall the mod and/or media VPs"

or

Code: [Select]

Player A
"I download the Compatibility pack because someone on the forum said once I might need it sometime and I decided I wanted to make sure X wasn't missing from mod Y so I did Z and now the hattie looks nothing like the uber cool one in the screen grabs"

The_E/other knowledgeable person who decides to help
"The hattie was changed between MVP A and MVP B, by doing Z you told Y to use the compatibility version instead of the new one"

Player A
"So how do a fix this?"

The_E/other knowledgeable person who decides to help
/head desk "Reinstall the mod and/or media VPs"

These and untested mods are the main issues I would expect to see hence why I can understand FSU being reluctant to handle it themselves.  Untested mods would be a legitimate issue if the mod is not on the list of tested/to be tested

[Dragon]

The way I see it, the pack would be a drop-in replacement. So, the last point would be "Delete the Compatiblitiy.VP from the folder", a one click action. Also, the installation instructions should be typed very, very clearly, and in a hard to miss way. Maybe it could be even said "Don't use it unless the old mod doesn't work". Some mods have no problems with Mediavps updates, so this pack wouldn't  be needed for those. If somebody tries to fix something that isn't broken, he has noone to blame but himself. You don't enable the compatibility mode on Windows because the app you're trying to run is old (granted, you often end up doing that anyway in on newer Windows versions, but you do that only after you find out the app in question doesn't work).

[headdie]

problem is that unless you are going to use the "mediaVP" folder name (which might cause confusion) you are then looking at mod.ini edits for all the campaigns that need it

[Dragon]

What confusion can it cause? Aside from people not deleting the previous version before installing the new one (which they should be warned about in installation instructions), I don't see any problems. It worked from 3.6.7 to 3.6.10 and TBH, I preferred when it was just called Mediavps. Version information could be placed in Mediavps' mod.ini, where it'd be seen upon selecting them in launcher.

[General Battuta]

I don't think you fully appreciate how much of a usability barrier these bullet-point instructions are. They are intimidating, irritating, and they signal to the user that we do not have our **** together from a user experience standpoint.

In an ideal world a mod would require the following steps to install:

Download
Extract to /FreeSpace2/
Select in launcher, hit 'autoupdate' to make sure it's up to date

[MatthTheGeek]

Nope.

In an ideal world, humans wouldn't be morons.

Unfortunately, we have to do with what we have.

[Fury]

In an ideal world a mod would require the following steps to install:

Download
Extract to /FreeSpace2/
Select in launcher, hit 'autoupdate' to make sure it's up to date

You're forgetting that we cannot take for granted that a mod will be updated in the first place. Original author may not be inclined to do so because the mod works fine with mediavps version the mod was intended to work with. Or the author is no longer around. The community will likely update the mod eventually if it is important enough to do so, which puts most mods rather low in FSCRP to-do-list.

Can't update if there is nothing to update. Hence we still need fall-back version of mediavps.

[General Battuta]

I'm not arguing that mods would be updated to be MVPs compliant.  I'm saying that Dragon's 'compatibility VP' idea is a bad one if it requires additional install instructions.

I'm not 'forgetting' anything, you're 'forgetting' what I'm talking about.

[Dragon]

Regardless, Mediavps will be updated. You're free to keep old, redundant junk on your disk, but others might not want it. Nor will new users want to download the old VPs (which will get de-sticked and quickly get lost, and then links will expire) just to play a few campaigns. A compatibility package would be a good solution for 90% of the mods which would require any changes at all. The remaining 10% will not be a big loss, and could be updated if necessary (fixing the old JAD to work with the latest VPs most likely isn't difficult).

Also, Compatibility VP wouldn't be a part of "main" install instructions, but it'd be mentioned in the "troubleshooting" section. If somebody doesn't have trouble, he shouldn't bother with shooting it.
I imagine that it'd be used just like compatibility mode in Windows.

[butter_pat_head]

Still, a "compatibility package" would be a better idea than keeping an entire set of old VPs, which serve no purpose other than clog up the disk space. Something like the outtakes pack, also containing tables and scripts from the old core. It would disable all new 3.6.14 features, essentially making the new VPs work like the old ones. Just drop it into the old mod folder and the mod should work, benefiting from all the cosmetic improvements that were made for the new VPs.

It could be made a little easier than that.  I'm no expert on how mod support works, only what I've read here but I gather a mod can reference a mod that references a mod and so on.  With the mediaVPs directory names containing the version numbers it is obviously very easy for each mod to tie itself to what ever version it wants to.

Lets say the latest version of vediaVPs is version 'C' and lives in 'mediavps_C'.  The stuff that version C replaced from version B lives in its own folder 'mediavps_B' as if it was the full package but in reality it references version C as it only contains old stuff that was changed in version C... diff mods as you could call it.

A old mod built for version B should act as if it had the full version B package.  When mediaVPs version D is released the same process happens to version C and all mods built for version C should continue working as if nothing happened.

There would be two downloads, the latest version with the last version's diff mod and a download containing all the older diff mods.  When version E is released all the player would have to do is delete version D, download version E and extract as normal.  Everything should work as normal.

The point is that this would maintain a endless and possibly seamless chain of compatibility.  No dropping compatibility files in to mod folders, that could generate its own unneeded redundancy if you have multiple mods requiring the compatibility pack and would require no mod.ini editing on the part of the player.

The only down side I can see... possibly longer load times for older mods?  I don' know but Id rather wait a few more seconds then waste more GBs on redundant files.

/end ill-informed but well meaning rant here 

[headdie]

The issue is that each iteration of the mediaVPs is 1gb+ so quickly chews up hdd space on older machines

[butter_pat_head]

So there's more than 1GBs worth of difference between mediaVPs versions?    I'm rather impressed at that.  Show how much work goes into the thing. 

[headdie]

Sorry crossed wires, there is probably a few hundred meg between the textures in 3.6.12 and 3.6.10 but the issue as I understand it is that some want it to include depreciated table and other files which complicates the mod structure some what

[butter_pat_head]

Why would it make it more complicated?  Isn't is just files at the end of the day?  Just take the complete old version and the complete new version and delete any file in the old version that is duplicated in the new version.  Alter old version's mod.ini to reference new version, package and release.

[headdie]

the issues come with loading precedence of files, not to mention MediaVPs tend to rely on tbm files which opens up a can of worms with conflicting table entries.

[Dragon]

That would work if there was a change to mod.ini files.
Right now, let's say mod A has "mod B" in it's mod.ini, and mod B has "mod C" in it's mod.ini. When you load mod A directly, it'd load mod A and mod B, but not mod C. If you load mod B, it'll load mod B and mod C.
Now, if there was a way to tell the launcher, when you select mod A, to also select mod B and mod C, your idea could work. I'd see it as a mod.ini parameter, like +load other mod ini files line. If the launcher detected it in mod.ini of a mod you selected, it'd check for mod.ini files in all mods it references, and if they're found, load additional mods they reference. With a few checks to prevent loops, this could actually be a very useful feature.

[butter_pat_head]

the issues come with loading precedence of files, not to mention MediaVPs tend to rely on tbm files which opens up a can of worms with conflicting table entries.

Ah I get you now.  I can understand how tbms might fudge up the place but I thought the loading precedence was that files earlier in the chain got priority over ones later on.  The mod modifies the mod its referencing and so on.

[jr2]

Yes but IIRC tbm files do not replace, they append.  Right?  Or am I mistaken?

I think it would have to be something of a 'backport' (instead of secondarylist) in the mod.ini, basically, if a mod tries to load 3.6.8 MVPs and all that's there are the diff files and a reference to 3.6.10, which is diff files and a reference to 3.6.12, somehow, the engine needs to know not to use that .tbm in 3.6.12 that messes everything up. Or actually, I think perhaps this could be addressed by putting a blank file with the appropriate name.tbm in 3.6.8?

Hmm....  /interesting stuff

[Dragon]

Exactly what I've had in mind. Folder called "Mediavps" would have a couple of blank files disabling problematic TBMs from later versions, outtakes from 3.6.12 and a mod.ini that would reference 3.6.12 . Same goes for 3.6.14. Now that I think of it, it only requires a slight modification to the launcher to be possible.