Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: General Battuta on May 31, 2014, 09:50:36 pm
-
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?
-
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.
-
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.
-
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.
-
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"...
-
Nightly MediaVPs simply won't happen. We just don't have the bandwidth to allow for that kind of traffic every day.
-
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.
-
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.
-
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.
-
Nightly MVPs are a terrible idea, and they would make this problem worse, not better.
-
Makes sense. What about putting dependency handling into the installer, or improving it if it's already there and doesn't always catch everything?
-
We basically went through this (http://www.hard-light.net/forums/index.php?topic=80836.0) 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.
-
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.
-
Could the installer be used to mitigate this problem like I posted earlier?
-
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.
-
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... :nervous:)
-
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.
-
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?
-
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.
-
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.
-
Can someone explain why mod authors are still relying on internal resources from the MVPs which are too volatile to reliably use between versions? Would it not be better to take the (minor, in this day and age) hit for redundancy and package those resources into your own mod?
-
Because most mod authors don't think about that when they make the mod. The texture/asset is simply there, available to use. So why not use it? I think that old effects (unless replaced with a drop-in upgrade), tilemaps and such should remain in Mediavps, and compatibility should be maintained. I recall that it used to work like that, and 3.6.9 to 3.6.10 switch was rather painless (though some 3.6.9-based ships lost upgraded maps due to moving over to mipmaps, but that wasn't so bad).
-
In working with restoring old campaigns the biggest compatibility problem is with the use of tables and TBMs. Many of the older mods created an entire table instead of a TBM with the changes. Starting with the 2012 mediaVPs this caused errors to be generated. The difficulty in restoring the campaigns is trying to figure out what the author changed from the original campaign and puting that into a TBM. I really haven't run into that many campaigns that relied on the old textures. The change from the 2012 MediaVPs to the 2014 MediaVPs was relatively trouble free as long as you used a recent nightly build. Updating from 2012 to 2014 is relatively easy. It was the change from 2010 to 2012 that caused the most problems. A single version would make it easier.
-
Yes, I have also seen this pattern wherein changing the mod.ini from referring to mediavps 3.2.12 to mediavps 2014 hasn't been causing any harm to barely any mod I've encountered so far ("barely" because I can't really remember having a problem is different from not having had one... my memory sucks)
-
So many thoughts... Where to start.
An example of a ship that can easily break mods... Arcadia. And that's still with the "conservative" upgrade we did. Half the community want a round hole I the middle which would break every mod that ever used Arcadia extensions.
Like it or not (and I know some of you don't, so let's not debate it here), we have chosen to give modelers a little more freedom with upgrades. As Zacam has said, we don't feel that we should limit the few modelers who are interested in working on things as long as they can work in the FS2 campaign. To impose greater restrictions with upgrades and re-imaginings would likely cause those few modelers not to even work on stuff.
For FSU to officially say we are generally backwards compatible means that we will suddenly get all of the support questions. FSU does not have the capacity to deal with that. Yes, I know that the "community" could help, but only a select few will... It will be those few who help in the support forum already. FSU is only a community project so far as in everyone wants it there way, but I have seen little evidence that real contributions would be made outside of the "fun" kind. (Models and the like.) The last time the community said they could help was the Colossus Normal Maps to try and get 2014 out sooner. That didn't work out, because the person suddenly wanted to do it there way causing even more work in the process. We have a hard enough time getting our own team members to consider the project as a whole and not just their own pet models. FSU cannot handle the official capacity of backwards compatibility. More members is not the answer... see previous sentence. People get in FSU to create their own vision of upgraded FS and we have plenty of clashes.
I'll stop there for now.
-
+1 vote of support for handling MediaVPs through the installer. That setup wouldn't break older mods while being more newbie-friendly than the current setup (outside of tech support issues, but that seems like a comparatively minor price).
-
Like it or not (and I know some of you don't, so let's not debate it here),
Uh, no, this thread was created precisely so that this issue can be discussed publicly. The MediaVPs' compatibility policy is creating a support nightmare, one which is in all likelihood driving new users away. This must be solved if FSO is to continue to thrive.
-
No, this thread is about how to best release the MediaVPs in order to limit confusion and make it easy for new users to get started. It is NOT about our policies on modeling restrictions... Conservative vs Anything Goes, or whatever you want to call it. Using this discussion to imply that liberal or conservative upgrades lead to driving users away will not be tolerated.
Consider this a warning. If you, or anyone tries to steer the discussion in that direction... Moderation will take place.
-
All new MediaVP releases should replace old ones and be fully drop-in backwards compatible with all past campaign releases.
I think compatibility policies are a big part of this discussion whether you want them to be or not.
-
FSU will not place arbitrary restrictions on upgrades. We will not base our acceptance of upgrades on some set of arbitrary conservative vs liberal rules (an idea that is infinently more complex that the actual problems we are facing now) for the sake of "infinite backwards compatibility".
This thread is about how best to present the work that has been created to the end user, how best to get it installed with ease on a broad basis.
This is your final warning.
-
I'm with mjn on this one. Trying to make the MVPs eternally backwards compatible is a futile endeavour. This whole discussion is based on a slight misunderstanding of what the MVPs actually are; they're not intended to be a big repository of mod assets, just a comprehensive upgrade package for FS2. That they've been treated as a community asset repository is, in my opinion, a wrong development.
The way to address this issue is, in my opinion, through a better dependency management in the Launcher. The case that sparked this discussion was arguably an enormous anomaly in terms of things not working right, taking it as a benchmark for "this is bad and must be fixed right meow" is IMHO not the right thing to do.
-
When the standard support advice is to install two mostly-redundant 4GB packages separately, you can't really say there's no immediate problem. Who exactly is responsible for this situation isn't really important compared with actually fixing it.
-
As above, I acknowledge the support issues and the possibility that older campaigns will break. I am proposing that we accept this as a tradeoff for enhanced user experience when installing the MVPs.
-
Is there actually any way to have our cake and eat it too as far as redundant files being downloaded?
-
Well kind of, in that I've not heard of any campaigns being incompatible with the 2014 MVPs.
-
As above, I acknowledge the support issues and the possibility that older campaigns will break. I am proposing that we accept this as a tradeoff for enhanced user experience when installing the MVPs.
I would rather pursue mod dependency support in the installer. Your proposal means that every mod since 3.6.12 will need to be updated (if only for the mod.INI), which will add confusion. It also ensures a return of unknown issues with mods that we know work flawlessly on older versions.
As for redundant data and download size... As the installer grows, a complete installation (currently recommended) is going to be more than massive. If that's how people want to install every mod ever, then they should be prepared for that download size. Also consider mods like BP going standalone means more redundant downloading... Should they have to reference the MediaVps to avoid redundant doeliading? What about mods like BtA that are basically FSPort? Should BtA be forced to reference FSPort to avoid having a 3gb 2 mission demo? How far so we take this argument of redundant downloading? (This is a real question.)
-
Well kind of, in that I've not heard of any campaigns being incompatible with the 2014 MVPs.
Test these (http://www.hard-light.net/wiki/index.php/Campaign_List) and let me know what you find.
-
Mod dependency support in the installer is a good step!
-
Some further thoughts and then I'll stop talking for a while.
FS modding is very complex... Technically and socially. We have webs of tables, command lines, and recommended settings so that everyone can play the game the way they want. This was developed during the Windows XP "tinker with your computer" era. But now, we've entered the smartphone "install an app and you're done" era and we are trying to figure out how to make FS Installs that simple. I'll be interested to see how close we can get as we continue to try and support every possible setup ever.
But what I'm seeing here is support thread deferment. We want to deal with any number of mod errors for the trade off of trying to make the MediaVPs simpler to install. Having looked at the logs in the support thread that spurred this discussion, I would rather do what we are doing now. It was super easy to see that he didn't have the MediaVps version required... Which is our fault for not having them in the installer. If we defer the support threads to when mods may not be compatible with the latest MediaVPs,who knows what errors we will run into, but it could truely be anything. You think new users are having issues following instructions editing a mod.INI? What about when a new user wants to play something older than Transcend with the newest MediaVPs? Now they have to edit tables, or other files just to get it to load.. Or just be told they are out of luck. That seems worse to me. But maybe it's just me.
I also don't think the issue as systemic as some are making it out to be, but maybe I'll be proved wrong as we begin to support the new Steam players. I will also note that people don't usually post immediately when the install does work... Because they are shooting Shivans. We have no baseline comparison of the number installs that are going flawlessly.
-
Can someone explain why mod authors are still relying on internal resources from the MVPs which are too volatile to reliably use between versions? Would it not be better to take the (minor, in this day and age) hit for redundancy and package those resources into your own mod?
Well the thing is, while most people may have the filespace to manage this redundancy, having to eventually wind up with hundreds of megabytes' worth of duplicated texture or effect models just to ensure compatibility is a horribly-inelegant solution to the problem, at least as far as I'm concerned. As you said yourself later on, taken to the extreme, it's exactly what we have with the two sets of MediaVPs: two multiple-GB folders that represent, for all intents and purposes, a complete redundancy in function. During my recent Installer run-through to get everything up to date, I was basically gritting my teeth watching both of those download simultaneously. I like to keep my HDD as uncluttered as physically possible, so anything we could do with the aim of eliminating the Department of Redundancy Department would be a huge boon as far as I'm concerned.
I'm with mjn on this one. Trying to make the MVPs eternally backwards compatible is a futile endeavour. This whole discussion is based on a slight misunderstanding of what the MVPs actually are; they're not intended to be a big repository of mod assets, just a comprehensive upgrade package for FS2. That they've been treated as a community asset repository is, in my opinion, a wrong development.
That's the part I don't understand, though: why shouldn't the MVPs be viewed as something of a community repository? Obviously not in the sense of containing modding work that wasn't originally from FS2, but instead in the vein of serving as a gathering-place for any and all upgraded retail assets. It always made a lot of sense to me that various mods would reference MVP material, because they could be viewed as something of a universal baseline, which almost everyone playing the game would already have installed. I know the organization of the MVPs will by necessity change over time, but I think there's inherent value in establishing some sort of baseline structure to them, to the point where external mods can properly reference them. Think of it as an API for the MVPs, if you will.
(And as far as I'm concerned the whole tangent about upgraded models is one big non-sequitur, because in the vast majority of cases, they're not the element presenting the actual compatibility problems.)
-
The goal of versioning is to prevent complaints when new MVPs break old mods. That's why they aren't a community repository - to save the immense workload and support overhead that would come along with being a community repository.
-
But my fundamental argument here is that we should devise a means by which updating the MVPs wouldn't be expected to break old mods, within the realm of sanity. In other words, create a methodology for uploading them that maintains certain basic structures/processes, so that external mods can reference them with a reasonable expectation of continued function in the future. It's obviously not a simple problem to solve, but I think it's certainly a worthwhile one, because it would essentially put an end to the support nightmares that you're referencing here.
-
I don't think it would. That process would require testing, which is unfeasible given the scope of legacy content.
If there were a trivial way to do what you're suggesting I think it would've been done. Of course, it's worth pointing out that there are apparently very few consequential changes between the 3.6.12s and the 2014s, so to some degree what you're suggesting has been done.
-
Yes, that part is certainly a good sign. And I wasn't really trying to imply that we should attempt to stuff the genie back in the bottle and come up with some framework that would automatically work with the vast majority of past mods. I think a far more feasible path forward would be to settle on certain policies or structures, with the expectation that they'd be maintained going forward, and then make an effort to update any currently non-compliant campaigns to play nice with them.
-
What specifics do you have in mind? The problem I see is that we're not worried about known problems, we're worried about problems we don't know we don't know about.
-
Sorry being a newb here but what exactly in the mediavps is that can cause mod breakage? From a model point of view I know that turrets, firepoints, subsystems and debris have to be kept as close to the original as possible to avoid problems. I guess maybe some filename changes could be a problem but is there anything else?
-
Textures get pulled, table structures were altered way back in the day, weapon effects are cut or renamed, so on.
-
What specifics do you have in mind? The problem I see is that we're not worried about known problems, we're worried about problems we don't know we don't know about.
Good ol' unknown unknowns.
I'm not incredibly well-versed in the modding realm, so I don't know that I have many specifics, but I guess the main thing I'm thinking of is avoiding a situation similar to the removal of the upgraded tilemaps with the 3.6.12 release. I understand the justification behind it, particularly that the current upgraded models no longer used them, but I do think that was a situation where past modders had a reasonable expectation that those would remain available: they were upgraded versions of retail assets, which on the face of it is exactly what the MVPs are for. I may be misremembering things, but I think the issue there was that the upgraded tilemaps had had changed names from their retail equivalents, so that there weren't any fall-backs for the mods attempting to reference them. That's the sort of issue that I think can be foreseen, and dealt with accordingly.
-
So, I caught up on this thread and laid down to take a nap for about two hours. I kid you not, this was my dream...
I was alone in some place covered in snow and ice and I had a laptop out on the frozen ice. I ran out there and sat near it to change/update some data that I was responsible for (I cannot remember what the data was in the dream), while a pack of wolves wearing red, orange, and black mixed life vests closed in on me and were super angry. All the while, the ice around me was breaking and I was sinking into the freezing water with the laptop.
I promise you, I am not making this up. Interpret as you wish.
Also.. textures were pulled for the whole redundancy of downloaded data thing. So... We just can't win.
-
correct me if I am wrong, I might be because I have not run the launcher in a long time, but doesn't the launcher provide a list of mods to install? does it not deal with mod dependencies?
maybe what is needed is an ability to mark a mod as a support package so it does not show up in the list, but can be used by other mods?
I feel like I'm horribly out of touch.
-
Sorry, no. The launcher doesn't install anything. The "installer" does deal with certain mod dependencies (i.e. within a group of mods like FSport), but it doesn't deal with the mediavps dependency.
-
ok, well, then I think we've identified where we should apply our resources.
-
Dependency handling in the installer would be a nice feature.
Also.. textures were pulled for the whole redundancy of downloaded data thing. So... We just can't win.
Here it does feel like you can win. If keeping the smaller redundant textures in the MVPs allows them to skip downloading an entire set of legacy MVPs, at least.
-
You are overlooking that having to download several mediavps is a one time deal. Whenever the mediavps are updated, everyone has a big download. Removing things like the unused tiles makes the update download smaller.
No we are not going to figure out how to only have users download updated data with VP patches or whatever crazy to support idea people may have.
-
I don't follow. It seems like the MVPs would have to be updated and completely redownloaded dozens of times before those extra tiles cost you more bandwidth than downloading an entire set of legacy MVPs.
-
Is it just a difference in view between
a) existing users (who have already downloaded the legacy mediavps when they were current)
b) new users (for whom legacy mediavps are a new & separate download)
-
I also have a feeling I know the answer, but I think the option should be mentioned, what about compatibility packs, something that sits on top of the current media vp to replicate the old version.
I really don't like this idea, but I wanted to hear how it stacks up.
-
I don't follow. It seems like the MVPs would have to be updated and completely redownloaded dozens of times before those extra tiles cost you more bandwidth than downloading an entire set of legacy MVPs.
Besides that, a theoretical legacy pack like the tilemaps presumably wouldn't change between releases, since no one's working on those assets anymore anyway. So in that case it's a single relatively-small download once, versus having to download and/or keep around multiple complete MVP releases. Seems like an easy choice.
-
I'm not sure you've thought the idea all the way through. It is a good idea.
However, to get similar and reliable functionality that we have now, we would need a legacy pack for each update that allows each update to function as an older version. Assets are not the only issue between releases. As SCP adds features (new tbms, table features to replace asset hacks, etc.), those are changed or removed in favor of the more modular design. HUD is good example of something table based that has changed several times over the last couple releases. These Legacy Packs would need to restore functionality to 3.6.10, 3.6.12, and eventually 2014 for older mods to receive the full benefit. And even then, how do you install something like that?
Perhaps you were only thinking of assets and not other types of version Legacy rollbacks. In that case, the tiles pack is already available... nothing else critical has been removed unless you really want that old Mentu model. (Actually, for upgraded models that are replaced with upgrades.. that may not be too far fetched.)
Something I haven't seen discussed yet is that even if we did change to a sole 'MediaVPs' install folder now. We have just about 4 years of mods that now rely on 'mediavps_3612' and 'mediavps_2014'. These are, arguably, the mods that most players will be playing and until the mod authors update them, we'll have the same issues as now.. just in reverse.
Also, I have continued to follow the thread that spurred this.. and I'm not convinced the guy is even following instructions correctly. It makes me wonder if this issue has only presented because of one loud user having issues where 40 quiet users are enjoying the game already.
-
If you alias the 3612 and 2014 folders to the mediavps one wouldn't that solve the problem?
-
You cannot install 3.6.10, 3.6.12, and 2014 to 'mediavps' without breaking almost everything. The best idea with the tools we have now would be to require a legacy mod folder 'mediavps_3612' that contains a small rollback VP. However.. that still requires mod authors to update or end users to alter the mod.ini.
-
Something I haven't seen discussed yet is that even if we did change to a sole 'MediaVPs' install folder now. We have just about 4 years of mods that now rely on 'mediavps_3612' and 'mediavps_2014'. These are, arguably, the mods that most players will be playing and until the mod authors update them, we'll have the same issues as now.. just in reverse.
Yeah, this is a huge obstacle.
Also, I have continued to follow the thread that spurred this.. and I'm not convinced the guy is even following instructions correctly. It makes me wonder if this issue has only presented because of one loud user having issues where 40 quiet users are enjoying the game already.
It looks like he may have been the victim of an installer glitch.
-
I also have a feeling I know the answer, but I think the option should be mentioned, what about compatibility packs, something that sits on top of the current media vp to replicate the old version.
I really don't like this idea, but I wanted to hear how it stacks up.
How about turning it the other way around, and turning the MediaVPS into an iterative process with updates, so that you have a
1) Base set of MVP's, let's say the 3.6.12 MVPs
2) An Add-on set called 2014, which is dependant on 3612, containing only what has changed.
3) Another add-on set called 2015, which is dependant on 2014, containing only what has changed.
etc.
That way we have an excuse to stick all the MVPs into one thread, thus simplifying it a bit (download all of these files, extract them, select latest or mod of choosing). It also deals with bandwith issues.
Basically - Backwards compatible delta patching.
-
Then you run into the mod.ini problem where a mod depending on "2015" won't automatically get "2014" and "3.6.12" in the -mod list; your mod.ini would have to refer to all of them in the SecondaryList to get all of them. After a few of these "upgrades", the standard SecondaryList entry starts to get a little ridiculous.
-
Then you run into the mod.ini problem where a mod depending on "2015" won't automatically get "2014" and "3.6.12" in the -mod list; your mod.ini would have to refer to all of them in the SecondaryList to get all of them. After a few of these "upgrades", the standard SecondaryList entry starts to get a little ridiculous.
TBH, a little ridicilous SecondaryList entry (which can be copy pasted anyway) seems like a small issue compared to the user usability, bandwith, and that sorta things mentioned here.
-
Other than ugliness in the mod.ini (which the end user hopefully won't be messing with), what are the drawbacks of doing it this way? Is it a pain in the ass for the FSU team? It seems like that method (combined with the installer checking for and downloading dependencies) would be the minimum bandwidth/maximum compatibility/minimum hassle option for the end user. I guess changing over to that sort of system could be a rocky experience, but that's a one-time difficulty.
-
Ha, how about if we do decide to do that, then we move the secondary list from mod.ini to mod-secondary-list.ini to avoid user confusion? I dunno, just a thought.
-
The best solution would be to completely deprecate mod.ini and use a more powerful and modern format to specify mod dependencies. The launcher could then resolve which mods need to be enabled to play a specific mod.
For example, if a mod requires the 2014 mediavps it would only say that it needs the MediaVPs with version "2014" (or something else, depends on how the versioning works).
-
That sounds a lot like how MS dotNET framework works. You have dozens of versions of the thing, and essentially none of them are compatible with each other. However, the MVPs aren't a couple megs in size, and it could get ridiculous after a few iterations when people run 10 gigs of Mediavps in different versions just to keep their game working.
...and I have no idea how a unified MVP package could be accomplished. I'm leaning towards saying that it can't.
-
"mklink /j mediavps fsu2014" would create a junction point to a directory called fsu2014 from link called mediavps. Unlike symlink, creating junction points do not require admin privileges. This however means that something would actually need to create the junction point, like Goober's installer. Only Vista and newer supported though. XP and older would have to use 3rd party tools or plug into Win32 API for same effect.
-
Make an empty mod called <new MVPs name> and have the mod.ini primarylist point to the mediavps mod?
-
Doesn't work because mod.inis aren't recursive.
-
Add a [+recursive] flag?
-
Honestly ideas along those lines all seem hideously complex and prone to massive failure, at least compared to what I was trying to articulate earlier. I don't know if I ever got it out clearly, but my main thought here wasn't that we should come up with some system that tries to mash previous MVP versions into one massive ball, but that we should establish protocols that allow for mods to reference MVP content with the reasonable expectation that said content will be available in the future. In other words, say something like, "Okay, we're calling these weapon effects X, and these ship models Y, and these sounds Z." That way, even if the individual files are edited to some upgraded version in the future, there will still be a file with the same name in the same place that a mod can reference down the line. And if for some reason a whole category of files were to be removed, like the upgraded tilemaps were, they could be included in a theoretical "MV_Compatibility" pack, something that wouldn't directly be referenced anymore by the MVP's own tables, but that would still exist for the sake of backwards compatibility with third-party campaigns. If that system were set up, then we could tweak all of the prominent mods out there to conform with it, and have them continue working indefinitely, without needing to re-release them every new MVP version when something breaks.
-
Mediavps compatibility with other mods is much bigger in scope than just file names. After compatibility comes the issue of consistent user experience. Even if new major mediavps is technically compatible with a mod in a way that it does not cause any prominent errors, it does not mean user experience is consistent and what the mod creators intended. Naturally errors are the biggest cause for concern, but user experience is not something to forget about.
User experience is something we've had to take into account since mediavps_3612, as that was the first release to use scripts. As mediavps become more complex in enhancing user experience of retail FS2, the harder it is to keep user experience consistent in mods that depend on mediavps. Let's take Blue Planet as an example, it has lots of ships that were not in retail FS2 and even completely new faction (or race, however you want to put it). If Blue Planet had been designed to work with mediavps version X and then suddenly end-users upgrade mediavps to version Y, user experience could be severely uneven and inconsistent even if there are no errors.
This can be avoided if both FSU team and mod creators work together to ensure compatibility and user experience work out with newer mediavps. In a perfect world. In reality, I doubt this is going to happen without significant headaches on the part of FSU and mod creators, potentially leading to many issues and even delaying mediavps releases. It's much better for the community if FSU can work in their own timetable without having to excessively worry about other mods and mod creators can work in their own timetable without having to worry about upcoming mediavps releases. After all, why would FSU have to worry about other mods when their task is to upgrade retail FS2?
I really do not believe one mediavps to rule them all is going to happen. If you want to do away with having to keep multiple versions of mediavps around, then there is really only one solution. Mod creators bundle mediavps contents into their own mods instead of depending on mediavps like they do now. This has the side-effect of increasing mod sizes several times because of duplicate assets as well as additional headache from mod creators having to manage mediavps assets in their mod mod. Managing these assets and somehow keeping them separate from the mod's own assets is extremely difficult and time consuming. Upgrading these assets from newer mediavps release even more so. To make such a situation workable, there would be need for multiple data directories. I don't think fs2_open and fred2_open supports that at this time.
Renaming mediavps to something more approachable and understandable is completely separate issue and I agree with others that better name would be a good idea. As for the name, changing the project name to The FreeSpace 2 Upgrade Project and mod directory name to freespace2_upgrade would be my suggestion. Likewise the FSPort version would be freespaceport_upgrade. Upgrade as a word covers all assets, not just visuals.
-
Dependency control in the installer will resolve many issues raised in this thread.
-
Many of the rest could be solved if mod authors were encouraged to use good hygiene when sourcing their assets, rather than using potentially volatile ones.
-
No, that would not solve anything. Every asset in MVPs is volatile, improvements are made all the time, and there's no telling what will change next. Something seen as a peak of quality one day will, after a time, get old and probably get remade. Also, we need to consider realistic solutions - those that can be implemented by MVP team and they alone. Relying on people following a directive is a shaky assumption at best.
-
I feel like the launcher being able to tell the difference between a mod which requires a specific version of the mediaVPs, and a mod which would like to use the latest mediaVPs available but doesn't need them would be useful. I suppose this goes back to what m!m was saying. This and a big push to get content creators to stop treating the mediaVPs as a "community repository", which places a horribly unfair burden of responsibility on the FSU team, sounds like the right direction to me.
-
are you suggesting to make the mediavps work like windows? XD all that backward compatibility is going to cause a lot of bugs, but I agree this is the best choice, it would be better to fix each other mod in a case by case basis until everything works with a single Mediavp system.
Personally I use the mediavps 2014 with all the mods, and rarely do I get crashes, mostly when stuff like shaders come up do I get some issue. tho I do remember having to edit one or 2 mods to make them work with this files.
-
No, that would not solve anything. Every asset in MVPs is volatile, improvements are made all the time, and there's no telling what will change next.
Exactly. So don't use internal MVP assets in your mod.
-
No, that would not solve anything. Every asset in MVPs is volatile, improvements are made all the time, and there's no telling what will change next.
Exactly. So don't use internal MVP assets in your mod.
So...don't use the mediaVPs at all as a mod dependency.
Unless you're doing a total-conversion, or are okay with retail ships, I don't see how you can do this.
Actually, even if you as the mod creator are okay with retail ships, doesn't mean that people playing the mod necessarily will - cue the endless "there's a hi-poly X why u no use???!"
Throwing away all the community-created graphical updates if you're making a freespace-setting mod for the sake of using "non-volatile assets" is not a sacrifice anyone should be willing to make.
The only viable alternative is to copy every asset you intend to use from the mediaVPs into the modpack itself, which as a result inflates your modpack's download size excessively, wasting everyone's bandwidth and hard drive space. I'm not willing to download a duplicate of the entire mediavps_3612 for every mod that uses it as a dependency, nothx, that's retarded.
-
are you suggesting to make the mediavps work like windows? XD all that backward compatibility is going to cause a lot of bugs, but I agree this is the best choice, it would be better to fix each other mod in a case by case basis until everything works with a single Mediavp system.
Personally I use the mediavps 2014 with all the mods, and rarely do I get crashes, mostly when stuff like shaders come up do I get some issue. tho I do remember having to edit one or 2 mods to make them work with this files.
It's not just about crashes, as Fury said, consistency of user experience is important. While the FSCRP has restored a lot of campaigns to modern-ish standards, there are still some of them out there that used original MediaVPS(the super obsolete ones) and the made-for-campaign assets reflect that quality. And when you put an original ship made in 2003 next to one from the most recent MVPs the difference in visual quality becomes blindingly obvious.
Forcing all mods to use the most recent MVPs could make some of the older ones uglier than they need to be. Being constantly reminded of how much better newer mods look while playing an older one could be a problem for new players, they'll just ignore some of the older campaigns. And that would be a real shame.
-
Ehhh, I'd say that particular line of reasoning is kind of a stretch. I'd agree that user experience should be a concern, but by far the biggest disruption to said experience would be a mod refusing to load in the first place because of some (to the end-user) cryptic error message. I'd say having a random asset or two be lower-poly than the rest would be far less disruptive, so long as the mission actually plays in the first place. If people are going to ditch a campaign just because of a few lower-quality assets, then...well, that's just their loss.
-
I'm not saying I agree with it, but I still believe that mods that are entirely low poly(like say Wings of Dawn) look better than those that are simply inconsistent(like forcing MVPs 2014 on Inferno).
-
No, that would not solve anything. Every asset in MVPs is volatile, improvements are made all the time, and there's no telling what will change next.
Exactly. So don't use internal MVP assets in your mod.
So...don't use the mediaVPs at all as a mod dependency.
Unless you're doing a total-conversion, or are okay with retail ships, I don't see how you can do this.
Actually, even if you as the mod creator are okay with retail ships, doesn't mean that people playing the mod necessarily will - cue the endless "there's a hi-poly X why u no use???!"
Throwing away all the community-created graphical updates if you're making a freespace-setting mod for the sake of using "non-volatile assets" is not a sacrifice anyone should be willing to make.
The only viable alternative is to copy every asset you intend to use from the mediaVPs into the modpack itself, which as a result inflates your modpack's download size excessively, wasting everyone's bandwidth and hard drive space. I'm not willing to download a duplicate of the entire mediavps_3612 for every mod that uses it as a dependency, nothx, that's retarded.
By 'internal assets' I mean reusing textures etc. on your own models. Using ships from the MVPs is obviously fine.
-
You could resort to some kind of restriction to make moders use just "units" from the mvps, units that you know will be replaced/reworked as a whole on each version.
You won't be able to be 100% accurate on what an unit can be though, maybe tomorrow models are still being used as modes with textures, sounds, tables and all but music packs might be dropped in favour of single tracks or something like that.
-
If there was decent documentation per mod/campaign of what MediaVPs/builds they are compatible with, it could be feasible to have some sort of installer that supports this, and it's in fact what I had hoped could come of wxLauncher 2.0. However the feasibility really only works going forward as this would probably involve engine changes to even make it work well, and better indication of versions within the MediaVPs, etc, and thus only mods made to target the engine and MediaVPs after that point would be able to take advantage of such a system. But I think the groundwork for that needs to be laid sooner than later, so that perhaps the work of the FSCRP team wouldn't have to be repeated over and over as time goes on, with every new release.
-
...vidmaster agrees with this topic's title for reasons given in the first post...
-
Nice...
I hope you read the entire thread at least before posting that little necro.
-
Fortunately, that necro brought it back to my attention as I'd been rather busy.
At a root level, FSU is (as noted earlier) intended to be an assets and visual upgrade to Retail. End of story.
Mods that Work: Any mod that has, say, a Myrmidon vs. Ulysses where they haven't tabled or textured anything fancy, they just want two ships/wings having a dog-fight. Regardless of MediaVPs version, that will always work and be "the latest" that the user has installed (or Retail if run with no mods).
Mods that Break: Same as the mod above, but now they've elected to change the glowmaps or textures or utilize team-colors, but they ONLY applied their changed maps and tbm edits into the mod. So if either of those two models get remade or remapped in the MediaVPs, they will now no longer work as intended in the mod because things will no longer be in alignment.
It'd be much easier for the mod to maintain its own model for such significant changes. At the very least, when such a breakage occurs (and model changes like that always have a thread or are announced (or will/should be) in the changelog), grab the previous model at THAT point in time as an over-ride compatibility patch for the mod to use until it can adapt to using the newer model. Assuming there hasn't already been enough of a community awareness that the relevant re-textures to upgrade the mod aren't already done. But it would be a change cycle that would have to be completely re-iterated on with each release one way or the other (either by including the model to go with the texture changes and bulk wholesale updating them later, or updating the textures each time the model changes).
Or reference that the mod is compatible with a version that maintains the intended behaviour.