[General Battuta]

After considerable thought, a lot of time spent helping users, no little dabbling in psychology, and some light discussion with user research guys at Bungie, I have a proposal.

We should remove a major obstacle to new user comprehension of FreeSpace Open by unifying all the MediaVPs as one product, 'the MediaVPs'. We should consciously avoid having '3.6.12 MVPs', '2014 MVPs', '2015 MVPs', or any other form of version tagging. All new MediaVP releases should replace old ones and be fully drop-in backwards compatible with all past campaign releases.

The reason is twofold. First, numbers and versions are intimidating and confusing. Players should not be told they need the 3.6.12 MVPs for this campaign, the 2014 MVPs for that campaign, and the plain ol' MediaVPs (no number, but those ones are WAY out of date!) for that campaign. It is an overwhelming environment for new users to navigate.

Second, it will cut down on tech support issues. If we have a single set of MVPs that are infinitely backwards compatible, we will never need to tell users to edit mod.inis. This is a significant source of confusion, especially for new users. New players will never select an old campaign, only to get mysterious errors and learn that they have 'the wrong MediaVPs.'

The closer we can get to 'click install, click run, and you're off' - as with professional game products - the more we can expand our userbase and make people happy.

I'm open to feedback. Thoughts?

[mjn.mixael]

Summary from IRC response...

This is complicated.

Infinitely backwards compatibility is a whole separate and increasingly complex issue. Mods are just too complicated these days.

But I hear you and am interested in others thoughts.

[deathspeed]

I personally love the idea.  Even as a person more experienced with FSO than someone who never heard of FreeSpace until they saw it on Steam, I get somewhat confused at times, and I have not even had to edit a mod.ini yet. 

I'm no coder, but I had always assumed that there was a reason it is not already done that way.  Wouldn't it get more and more difficult to maintain backward compatibility over time, especially when some things are coded to take advantage of a specific MVP feature but then that particular feature is improved or otherwise changed?  Who would be responsible for all the regression testing?  But as I write this, I guess those are the same hurdles faced by any SCP upgrades?  Those seem to be handled OK, with actions such as relying on some of the user base to test by using nightly builds.

[General Battuta]

Yes, it would get harder to maintain compatibility over time. And without old MVPs to pair with old campaigns, they would be more likely to break without any easy solution.

[AdmiralRalwood]

I personally love the idea.  Even as a person more experienced with FSO than someone who never heard of FreeSpace until they saw it on Steam, I get somewhat confused at times, and I have not even had to edit a mod.ini yet. 

I'm no coder, but I had always assumed that there was a reason it is not already done that way.  Wouldn't it get more and more difficult to maintain backward compatibility over time, especially when some things are coded to take advantage of a specific MVP feature but then that particular feature is improved or otherwise changed?  Who would be responsible for all the regression testing?  But as I write this, I guess those are the same hurdles faced by any SCP upgrades?  Those seem to be handled OK, with actions such as relying on some of the user base to test by using nightly builds.

I do not think it would be practical to generate or use "nightly MediaVPs"...

[mjn.mixael]

Nightly MediaVPs simply won't happen. We just don't have the bandwidth to allow for that kind of traffic every day.

[jr2]

Would it be possible to select MVPs that satisfy dependencies of selected mods in the installer automatically?

Eg,

"You've selected Transcend, which requires MVPs 3.6.10. I'll go ahead and select that for you now, or you can press cancel to deselect Transcend."

Also, have Installer check for dependencies of mods already installed.  Maybe scan mod.ini to be sure the user didn't customize the dependency folder name? Nah, if they do that, they know how to manually fix stuff I'm sure.

As well, how about moving all MediaVPs into their own subdirectory under one folder, maybe called all_MediaVPs ? Or just MediaVPs and put the old old MediaVPs as legacy_MediaVPs?  Eg,

\MediaVPs
       |-legacy_MediaVPs
       |-MediaVPs_3.6.10
       |-MedisVPs_3.6.12
       |-MediaVPs_2014


But idk if that would be so necessary if installer was handling dependencies automatically. But it would clean up the root directory some.
     

[jr2]

Nightly MVPs would probably require the ability to post a sort of diff update where only the changed data was downloaded, and patched on the end users machines. Like use QuickPAR or similar.

[mjn.mixael]

It's still not going to happen. When things change in the MediaVPs SVN, it's not usually just table file changes. It's bulk model and texture uploads.. usually untested. I am strongly against the idea of Nightly Mediavps.. if not because of bandwidth size, because of the amount of nightly "this is broken" posts we'd receive, and how mods may rely on things in the nightly that aren't tested and refined until closer to release. Meaning that suddenly they get stuff "unexpectedly" changed on them.

Nightly mod releases are in no way comparable to nightly code releases.

EDIT: And even then.. Nightly MediaVP releases would not solve the issues brought forth in the first post.

[General Battuta]

Nightly MVPs are a terrible idea, and they would make this problem worse, not better.

[jr2]

Makes sense. What about putting dependency handling into the installer, or improving it if it's already there and doesn't always catch everything?

[Black Wolf]

We basically went through this prior to 3.6.14 being released. If memory serves, there were lots of ideas, but mostly they were impractical, and the consensus was more or less thatthe system we have now (multiple versions required) is bad, but that there's nothing practical that would be any better.

[General Battuta]

I followed that discussion. I think enough time has passed - and enough new experience has come to late with respect to end user experience - that it's time to discuss this proposal.

[jr2]

Could the installer be used to mitigate this problem like I posted earlier?

[deathspeed]

Sorry; I wasn't suggesting nightly MediaVP builds and I didn't mean to derail the topic at all.  I was just using the nightly code releases at an example of how this community has found ways to deal with testing.  I agree that it totally gets away from the original point of not having multiple versions of MediaVPs.

[niffiwan]

tl;dr: a single mediavps version makes it easier on users, but makes it much harder on content creators, will this kill off new/updated content? I think an installer with dependency management is the solution.

----

The issue I see is that maintaining backwards compatibility "forever" is going to eventually make it impossible (or just very difficult and time consuming) to move forward.  It'll put an incredible burden on the mediavps maintainers to ensure that nothing breaks, which will introduce a chilling effect.  Who wants to make a model for 6 months (for example) and then have to spend 18 months testing it to ensure that it hasn't broken any one of a hundred mods? I'd wager that modellers would stop upgrading models, OR the testing wouldn't get done (which is *perfectly* understandable) and then you have backwards compatibility issues anyway, and those issues won't have any solution apart from the mod creator updating their mod (which shifts the maintenance burden onto mod creator instead, and they get to experience said chilling effect). For products produced by a professional game company this is not an issue - they don't support games / updated content for that long. They can make a clean break and toss out backwards compatibility when they make the sequel / next title.  (Can quake4:2005 read quake1:1996 data?)

My *opinion* is that the best way to manage this is to have the installer handle all mod dependencies, if someone wants to install a mod that requires mediavps (3.6.10) then the installer will also install mediavps (3.6.10) without further user interaction.

(I hope that's all clear, I drank too much wine at lunch today...  )

[General Battuta]

I don't think rigorous testing with every past mod is possible or realistic. I think that some breakage will simply have to be accepted and dealt with as it occurs.

[niffiwan]

Doesn't that breakage lead to an equally poor user experience? Or.... iunno - maybe they've had more time to enjoy the game and would be willing to spend more time working to fix the problem?  i.e. shift the issue from initial impressions (where bad == don't play, don't go back) to "halfway" through a campaign, which might induce them to continue working to fix it?

(I must admit that my experience is obviously more with the code side rather than assets... I guess that asset issues are less likely to be a game breaker than code issue are)

Anyway - what about the better mod dependencies idea - do you have any comments/thoughts on it?

[General Battuta]

If the process can be reliably automated that sounds like a decent solution...though it does not improve the end user experience if we ever actually have to talk through how to fix the MediaVPs.

[Mongoose]

Speaking theoretically, even though I recognize the massive danger in doing so, the majority of campaigns out there shouldn't have fundamental issues with incremented MediaVP versions, should they?  I mean by far the biggest change between versions has historically been the addition of new models, which as far as function is concerned are drop-ins for the retail models anyway, which most campaigns don't touch.  If a campaign adds a few custom models or effects, they should generally do their own thing, since they're separate from the now-upgraded retail assets.  I know one of the major problems in the past was the removal of the upgraded tilemap textures that some older mods relied on, but those were compiled in a handy .vp, which would be trivial to include in the Installer.  I know there are some more esoteric cases involving scripts or .tbm files or the like that I don't entirely understand, but those tend to be found in more recent releases that could presumably be updated for the general compatibility standard.  I think the middle-ground campaigns are where I'd expect the most trouble: those with more complex modding than a couple of added ship classes, but not new enough to still have the creators around to work on them.  Even there, as the FSCRP has shown, the more popular of those could be fixed by the community, and as for the less-popular...well, newer players probably wouldn't be playing those right off anyway.

But like I said, this is all theoretical, and there are probably at least twenty good reasons why most of what I said is utterly wrong.