[Dragon]

There's one problem I see with it all. This system, combined with an automated installer/updater (Turey's installer would do the trick) would be quite foolproof on the user end, but fairly complex to implement and maintain.

The system we have right now is easy to maintain, and easy to explain.

Why, I ask again, **** it up in favour of a more complex system?

My thoughts exactly. One reason would be "end user friendlyness", but I don't think it's worth it. All I originally asked for was a simple "outtakes-revert script changes" VPs. I could most likely make one, but since I can't access Mediavps SVN, I'd rather cobble individual fixes together manually, for my personal use. That is, when I actually need to fix something beyond extracting a few bitmaps. But you said some people would misuse the pack and complain (and I'm not denying that it's true), so I though about a system which would fix that problem. And then it got ridiculous. I'd happily settle for the original compatibilty VP proposal, which is simple and if somebody misuses it, he just needs to learn to read.

[The E]

And all I am saying is that it is FSU's responsibility to keep track of all the changes, and communicate them transparently. We can't do all the compatibility work for all campaigns, but we can make it easy for the people who do that sort of work.

I am of the opinion that it is easier for all concerned when compatibility packages are created for each individual campaign and then distributed via the installer. In other words, what we have been doing so far. It has worked in the past, and there's no reason to assume that it will suddenly stop working.

[Dragon]

The problem is, making individual packages takes a lot of time. Making a since compatibility package for 3.6.12 wouldn't take too long. You don't have to test it with every campaign (just with one or two, the least buggy ones), just make sure it mimicks how old VPs worked and has all the assets removed from the main pack. That's all. Other people may confirm other, more obscure campaigns to work with the package. They can also report ones that don't work. Since such a package would be strictly a troubleshooting measure, it should be expected it won't work everywhere.
FSUP may keep doing their job and churning out proper upgrades, but they also tend to become outdated.

[Droid803]

Iunno, whenever I feel pissed off about this I just go an make my mod independent from the mediaVPs.
Copy everything required over and all, proceed to NEVER WORRY ABOUT IT AGAIN~

This way you don't require anything for your mod (and can even make it standalone!)

[jr2]

Iunno, whenever I feel pissed off about this I just go an make my mod independent from the mediaVPs.
Copy everything required over and all, proceed to NEVER WORRY ABOUT IT AGAIN~

This way you don't require anything for your mod (and can even make it standalone!)

Although that may increase bandwidth requirements, thinking about it, that is in fact the best way to handle this, if you want to be sure your mod runs.  If you want to be double-sure, include the FSO executable it was designed for.  Otherwise, you get people running around trying to find 3.6.7 to get an ancient mod working that people have forgotten.

BTW, I can't compile 3.6.9, TortoiseSVN just says it's done and that's that.  I'll make another thread for this issue, unless someone can tell me off the top of their head what's wrong (I followed instructions for the url to use (svn://svn.icculus.org/fs2open/branches/fs2_open_3_6_9) and it just says it completed at revision 8786 and it puts a hidden .svn folder in, with pristine, tmp as subdirs and files named entries, format, and wc.db

[MatthTheGeek]

You realize you have to use a compiler to compile the code after you grabbed the SVN, right ?

[The E]

You realize you have to use a compiler to compile the code after you grabbed the SVN, right ?

You realize that that was not his problem?

It seems that the 3_6_9 branch of the svn is empty. So no wonder no checkout could be made. If you want to have a 3.6.9 equivalent build, check out trunk revision 4499.

[Dragon]

Iunno, whenever I feel pissed off about this I just go an make my mod independent from the mediaVPs.
Copy everything required over and all, proceed to NEVER WORRY ABOUT IT AGAIN~

This way you don't require anything for your mod (and can even make it standalone!)

Well, this is what I do, but unfortunately, this wouldn't work for everyone. I'm not asking for a compatibility package for myself (well, I would benefit from having old effects stashed somewhere, but that's it). If it was just about me, I can handle adapting mods to new Mediavps for personal use.

[jr2]

It seems that the 3_6_9 branch of the svn is empty. So no wonder no checkout could be made. If you want to have a 3.6.9 equivalent build, check out trunk revision 4499.

Done; thanks!  (I'm assuming you use svn://svn.icculus.org/fs2open/trunk/fs2_open and select "Revision" and type in 4499, right?)

[The E]

Correct.

[FelixJim]

I'm just jumping in to give a +1 to the current system. You can't try to tell another mod how to do things just because you've made the decision to have your mod dependant on it - I think the FSU team is already going somewhat above and beyond in providing the help modders need to update their mediavp-dependant mods.

I can't help but feel that if you're not going to have the time to maintain your mod (understandable) you shouldn't make its use utterly dependant on something which is constantly changing (I feel stupid in having to admit this applies to FSO itself, but the FSCP appears to have taken responsibility for maintaining compatibility simply because FSO-dependance is more or less impossible to avoid without sticking to retail and rendering their efforts completely wasted. The mediavps differ in that your mod can make use of them without being reliant on them.)

[Zacam]

The mediavps differ in that your mod can make use of them without being reliant on them.)

Emphasis mine. That right there. I don't know why how or where anybody ever got the idea of making a mod specifically dependent on how the MediaVPs are structured.

And by making the MediaVPs adhere to "Upgrade Retail only" the solution is simple: If your mod will run in FSO with Retail assets, then it will also run with the MediaVPs.

The problems with older mods is when they would take a ship, apply ONE of the tiles from the MediaVPs (not retail) to their ship and then expect that tile to stick around forever and a day. And then one day that tile disappears and their ship now has a massive hole in the side of it or whatever. Or worse, is completely invisible. Or maybe they would copy a model for making alterations to it, but since they never changed any of the maps (despite the model no longer being the same) they then end up with a broken ship.

That's the part that needs to stop. That is the practice that we need to not continue carrying over from the past. That is the problem that keeps mod.ini edits to update the version from being "guaranteed" as something some one can do without having problems.

Because by making the MediaVPs an enhancement to FS2's Retail Assets and Effects, what it SHOULD work with is any best-practices mod that is ALSO capable of operating under the same. Any additional customization beyond that needs to be inherently present in that mod in order to retain an ability to continue working as intended regardless.

[gloowa]

A tiny bit of thread necromancy. Slap me if i am out of line here.

I skimmed over the thread, and i won't pretend to know how exactly asset loading looks like, but couldn't next version be released as a delta from previous version?
So lets say i have versions A, B and (newest) C. (in their respective mediavps_X folders)
If i run mod that has B in ini, it will load A, and than override everything it needs to with B.
If i run mod that has C in ini, it will load A, override with B, and then override with C.

I'm sure i am missing something that makes this impractical/impossible (hmmm... on Univ they taught me that in programming, there is nothing impossible, some things are just very expensive...) but it seems to me like an golden compromise?

[General Battuta]

Please don't take this personally, I genuinely see where you are coming from but

NO

GOD

NO GOD PLEASE NO

NOOOO

NOOOOOOOO

[General Battuta]

The reason is dependency hell and install instructions and end users changing folder names

[gloowa]

The reason is dependency hell and install instructions and end users changing folder names

right. that's the part i missed.

perhaps it could still be done as an optional pr0-users-only install? My issue is bandwidth actually. Downloading things larger than 1GB takes several days for me
(256kbps, don't ask.)

[Crybertrance]

perhaps it could still be done as an optional pr0-users-only install? My issue is bandwidth actually. Downloading things larger than 1GB takes several days for me
(256kbps, don't ask.)

I feel ya bro  I'm on a 512 Kbps connection... But I think the needs of the many outweigh the needs of the few here, unfortunately.

[SypheDMar]

An option would be to torrent the mediavps for future releases.

[The E]

The reason is dependency hell and install instructions and end users changing folder names

right. that's the part i missed.

perhaps it could still be done as an optional pr0-users-only install? My issue is bandwidth actually. Downloading things larger than 1GB takes several days for me
(256kbps, don't ask.)

The issue is that most people have an inflated sense of their own competency when it comes to computers. Install instructions, no matter how clearly written, are routinely ignored. People who would be better off using automated installers will go and try manual installs "because that can't be hard, right?".

By issuing "pro" packages for advanced users, we just invite people to **** up their installs. That is a bad idea.

[gloowa]

The issue is that most people have an inflated sense of their own competency when it comes to computers. Install instructions, no matter how clearly written, are routinely ignored. People who would be better off using automated installers will go and try manual installs "because that can't be hard, right?".

By issuing "pro" packages for advanced users, we just invite people to **** up their installs. That is a bad idea.

You won't get an argument from me here. Every day in my work i have to fix the mess that users made of their computers by trying to fix some issue they are having by themselves.

The undisputed winner managed to crash his linux workstation by updating glibc to version that requires newer kernel. How did he manage to do that without root access is still a mystery to me...