[Spoon]

Spoon, read Fury's post. He explains the reasons for the new system quite well. If you have a better idea that can address the shortcomings of the old system, please share it.

Read my post, I already did. Just keep the new mediavp's 'bloated' with the old stuff. Don't remove effects which you think aren't used anymore and such. You'd still end up with a mediavp version that is a whole lot smaller than having two seperate versions combined in your folder. Or hell, what dragon said. A compatibility package.
It's also a lot easier to grasp for the end user. Just install the newest mediavp version and you're set for everything. Instead of having them install 2-3 seperate things. Cause with .14 released, do you want people to have .10&.12&.14 mediavp's installed in their freespace folder?    Where do want to draw the line with this? In a few years you'd need .10 .12 .14 and 3.7 mediavp's in your freespace folder just to guarantee that ever campaign and mod is going to run? Ye gods the redundancy. This is so incredible messy. Its just that the FSU doesn't want to take on the responsibility of providing backwards compatibility and just dumps it all on the modders and helpful community.

Our goal is upgraded Freespace 2, not upgraded Blue Planet, or upgraded Inferno, or upgraded Derelict.

Maybe its time to revise that goal. The time that the mediavp's are only used for a shinier retail freespace experience is waaaaay past.

[mjn.mixael]

Our goal is upgraded Freespace 2, not upgraded Blue Planet, or upgraded Inferno, or upgraded Derelict.

Maybe its time to revise that goal. The time that the mediavp's are only used for a shinier retail freespace experience is waaaaay past.

Spoon... I like you, but you need to understand that what you are asking here is an infinitely lofty goal. How are we supposed to test the MediaVPs with every campaign that might use it? It's an unrealistic expectation. At this time, we are not changing our stance on being an upgrade for the main Freespace 2 only.

A "compatibility package" is something we'll discuss. However, I'd prefer you post in a more level headed manner...

EDIT: As a further thought... Since this is considered a community project (MediaVPs), and everyone expects us to build the MediaVPs as they, individually, would build it... It would be nice if the community could work on the compatibility package ala FSCRP style for old MediaVPs. If this truely is community driven, then I'd like to see more community contribution to this issue than just pointing fingers at us every few months.

[Dragon]

I agree with Spoon on that one. Almost all campaigns require Mediavps these days, and those that don't are total conversions. Ignoring just about everything the community has made is irrational.
Of course, fully supporting other campaigns is impossible. But if it's possible to at least give them a chance to run, IMHO it should be done. In many cases, it's as simple as not removing old effects (since they're the most common part of the VPs on which various mods depend).

[mjn.mixael]

No. We've talked about this so many times, and I'm getting weary of repeating myself in this thread alone. We are not, and will not, guarantee full compatibility for any campaign other than the main Freespace 2 campaign for the reasons I discussed right here. It's impossible. We'd have to play favorites. We won't do it. Done.

We've already extended our good faith by offering the tile maps package. We are continuing to help mods by pointing them toward things that have changed.

[The E]

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.

Please, go ahead and make one. And then debug it. And then take care of the people who use it wrongly. Have fun.

Maybe its time to revise that goal. The time that the mediavp's are only used for a shinier retail freespace experience is waaaaay past.

How long do you want to wait between releases? How many campaigns and mods do you expect us to test for compatibility?

Why do you expect the FSU to do all this work for you?

In many cases, it's as simple as not removing old effects (since they're the most common part of the VPs on which various mods depend).

So you want us to keep the mvps bloated with data that is only used by a portion of all mods, and that is utterly irrelevant for the stated main purpose of the MediaVPs (which is to improve FS2 retail).

[General Battuta]

I didn't like this decision when it was made but the decision is made and it would probably be even more frustrating to reverse course. The call's the call.

[Snail]

Perhaps the FSCRP could help with this sort of compatibility stuff?

[headdie]

Perhaps an easier solution is just to have a folder in the FSU SVN called compatibility and when you select the outdated stuff to delete, you hit move instead targeting the compatibility folder, you dont even have to organise it the folder, just post it as an asset dump when you post the new version of MVP then someone else in the community can organise it even if you guys dont want to, I know I don't have a problem with doing that as it would only take a couple of minutes to do, plus a few more to test and VP the files.

Once you have posted the dump file, clear out the compatibility folder and start again, this way your SVN dont get clogged up with masses of redundant data, just the difference between the last release and the current WIP. go thought the same update process again, then when you release again you replace the dump file with the new one and someone like me will add that to the old compatibility pack and release the new version.

For a the cost of a few seconds per update you get to keep the MVP shiny and new, while the guys who want to play older mods get to keep playing them with the improved on retail content, all the while guaranteeing compatibility is someone else's problem because you are not producing the compatibility pack.

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.

Please, go ahead and make one. And then debug it. And then take care of the people who use it wrongly. Have fun.

How is that different to any other mod?  Look If you want to create a septate project board for it so mods and admins can divert compatibility mod related issues, I will happily take the flack from newbies and the incompetent.  I know I am a glutton for punishment but I Also like a good challenge (queue comments from veterans like The_E along the lines of you dont know what you are getting into) and I am prepared to take it on.

Perhaps the FSCRP could help with this sort of compatibility stuff?

That's a big ask for a team with a heavy workload as it is

[Snail]

Perhaps the FSCRP could help with this sort of compatibility stuff?

That's a big ask for a team with a heavy workload as it is

Yes, but I think this sort of work is more their sort of thing than the FSU's.

[Fury]

Dragon, get this already. A compatibility package is only viable to add whatever files were removed, like tilemaps. It cannot address incompatibility issues presented by script or tbl changes for example. Hence usefulness of such a package is severely limited.

[headdie]

Perhaps the FSCRP could help with this sort of compatibility stuff?

That's a big ask for a team with a heavy workload as it is

Yes, but I think this sort of work is more their sort of thing than the FSU's.

Perhaps but i thought their main aim was to deal with table, mission and campaign issues cause by changes in FSO, especially in error catching?

[mjn.mixael]

Thank you, Headie for a well thought out post. Your idea has merit. The difficulty would be what to do with changed files such as tables or scripts. Granted we are mostly talking about hypothetical issues here (as is the whole thread, I suppose).

I'm going to reiterate my feelings on these issues one last time, the others on the team may disagree with me though...

We are not, and will not, change our stance on the issue of upgrading the main Freespace 2 campaign only. I've talked about the issues enough and you can go re-read them.

I'm open to civilly discussing compatibility packs, or other ways to do something similar. But we feel pretty comfortable with the method that we came up the last time someone started this topic.

Many of you are acting like we are going out of our way to screw over whatever mod you are working on... and frankly, you need to chill out.

[Spoon]

Many of you are acting like we are going out of our way to screw over whatever mod you are working on... and frankly, you need to chill out

I'm not dependent on the mediavp's anymore so I'm not speaking from that perspective. In case you were getting that impression.

How long do you want to wait between releases? How many campaigns and mods do you expect us to test for compatibility?

Why do you expect the FSU to do all this work for you?

The most popular ones at least.
Why do you expect the rest of the community to all this work for you? I for one expect you guys to do it since you are the ones responsible for the mediavp's. I'm not.

Anyway, it appears to be futile to spend any more time on this. I've made my opinion heard and you've all made yours heard. (To continue on this path of messiness and boring traditional freespace 2 campaign support only.) I'll just quote Battuta and leave you all to your own devices.

I didn't like this decision when it was made but the decision is made and it would probably be even more frustrating to reverse course. The call's the call.

I'll check back with you guys once you want players to have 3-4 seperate mediavp's installed to ensure that everything is playable

[The E]

I'll check back with you guys once you want players to have 3-4 seperate mediavp's installed to ensure that everything is playable

We don't!

We just don't want the extra headache of testing "the most popular campaigns" for compatibility with every new MVP version. That's the FSCRP's job, or at least it should be.

This whole problem, IMHO, is only really pertinent during the transitional phase between two MVP versions. Ideally, we want players to only have the most recent version installed, but since we cannot take responsibility for every campaign out there, we have to ensure that there's always a way to play older campaigns that haven't been adapted for use with the mvps. We chose to do this by versioning the MVPs, and releasing changelogs and such so that the FSCRP and mod teams can do all the required compatibility work.

Keeping old effects, maps, and models around is only part of the problem. What happens when we need to do table changes? Or script changes?
I mean, we aren't going out of our way to make things incompatible, but sometimes this stuff happens. What do you want us to do in those cases?

Case in point: The new Hatshepsut model. Because the new model is no longer tilemapped, and thus uses very different texture names, the new model broke one of the JADs. There was no way around that. What should we have done?

[Dragon]

Dragon, get this already. A compatibility package is only viable to add whatever files were removed, like tilemaps. It cannot address incompatibility issues presented by script or tbl changes for example. Hence usefulness of such a package is severely limited.

You missed the point, and didn't read my original post at all.
My idea was that a compatibility package would not only contain removed stuff, but also all old tables and scripts, and files disabling all new scripts and tables that were added and could affect compatibility. That would cover most possible compatibility issues. It'd also be very simple to use, just drop it into the mod folder of the campaign that you want to play. Of course, testing it would be a challenge, but if it's kept as simple as possible, it'd be easy to debug "on the fly". Of course, not everything will work with the compatibility package, but such campaigns should be in minority.

Case in point: The new Hatshepsut model. Because the new model is no longer tilemapped, and thus uses very different texture names, the new model broke one of the JADs. There was no way around that. What should we have done?

Keep the old textures around, if it's the case of another model using the Hattie's textures.
If it's a case of Hattie with FRED-side texture replacement, then the effect is completely impossible to reproduce on the new model without editing the UVmap. In that case, this campaign must be updated in order to work. But that's only one case, and texture replacement isn't too commonly used.

[The E]

You missed the point, and didn't read my original post at all.
My idea was that a compatibility package would not only contain removed stuff, but also all old tables and scripts, and files disabling all new scripts and tables that were added and could affect compatibility. That would cover most possible compatibility issues. It'd also be very simple to use, just drop it into the mod folder of the campaign that you want to play. Of course, testing it would be a challenge, but if it's kept as simple as possible, it'd be easy to debug "on the fly".

Yeah, that kind of support nightmare is just not a good idea. You do not seem to get the amount of issues this can cause when people are using it wrong as they are bound to do.

[mjn.mixael]

Dragon, get this already. A compatibility package is only viable to add whatever files were removed, like tilemaps. It cannot address incompatibility issues presented by script or tbl changes for example. Hence usefulness of such a package is severely limited.

You missed the point, and didn't read my original post at all.
My idea was that a compatibility package would not only contain removed stuff, but also all old tables and scripts, and files disabling all new scripts and tables that were added and could affect compatibility. That would cover most possible compatibility issues. It'd also be very simple to use, just drop it into the mod folder of the campaign that you want to play. Of course, testing it would be a challenge, but if it's kept as simple as possible, it'd be easy to debug "on the fly".

inb4TBMdependencynightmare

Or not...

[Dragon]

Yeah, that kind of support nightmare is just not a good idea. You do not seem to get the amount of issues this can cause when people are using it wrong as they are bound to do.

It's pretty simple. If the campaign isn't marked as 3.6.14, then put the file in it's main folder. If it is, don't do it.
It seems rather easy to me. The pack would be self-contained, and tested on a campaign known to run on 3.6.12 without errors. Besides, it's not like there are many campaigns specifically for 3.6.12.
Also, people too incompetent to use something so simple could just download the old VPs.

[The E]

Your faith in the abilities of the average player is astonishing. I wish I could share it.

[Dragon]

I think that anyone with half a brain and knowledge of English should be capable of using such simple thing, and I don't care about the rest. People stupid enough not to be able to grasp two simple sentences wouldn't care about clogging up their disk space. Smart people, on the other hand, could download the compatibility pack.