[Mongoose]

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?

Clearly the solution would be to yell at Axem.  That always works!

[The E]

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.

I expect your code patches.

[jr2]

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.

What exactly needs to be changed in the launcher behavior, versus how it handles things now?  Can you list them as a comparison to how they currently are?

[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.

The above, basically. Add an option for the launcher (in the mod.ini) to read mod.inis of all mods from secondarylist and add their dependencies the the commandline.
BTW, how exactly does one get the code and all the other stuff for the launcher? Depending on how complex this code it, maybe we could take a look at it with my father. The Windows launcher is basically a glorified shortcut (though a rather smart one), so I wouldn't expect it's code to be as labyrinthine as that of FSO or FRED2.

[mjn.mixael]

Wait wait wait.

So you want the launcher to load FSO with the dependencies of all mods recursively? Am I the only one that is seeing a giant red flag here?

[Dragon]

Only as an option (controlled via an additional line in mod.ini), and with a failsafe for loops. I already thought about the "red flag" you mentioned.

[headdie]

how does this help the needing redundant MVPs and the associated space issue that started this?  as I read your suggestion dragon I just see a system that loads each MVP version in a set sequence.

[The Dagger]

Just a thought, but maybe the tbms parser should check if the name has already been used and if the case, it should replace the old entry. So the last loaded entry with the same ship's name overrides all the others.

And you wouldn't need for the launcher to search recursively in each mod's mod.ini file if you want this to work for different MediaVPS versions. You keep all versions in different folders as it is now, and the last version points to all the prior versions it needs to load in the order it needs to load them. This totally avoids circular calls.

Finally, if you want to free up disk space you make each MediaVPS to contain only the parts that must be overriden from the older one, thus avoiding to have duplicate information. And if your mod points to an older release of the MediaVPS, it would still work, because the folder is still there like it was the first day you donwloaded it.

Just trying to help...

[The E]

This does not sound like a good idea.

The problem with loading mods recursively is that you may end up loading dependencies you do not want to load. Yes, you can get around that with even more options, but why **** up a perfectly usable, simple and robust system?

In the end, Dragon, the decision on how the MediaVPs will be organized has been made quite some time ago. We have considered the alternatives, and found that the path we've chosen offers the best compromise between usability, extendability, and robustness.

Your idea increases complexity, and as a result, increases the risk for bugs to appear, in exchange for a minor decrease of modder effort in exchange for making FSU's work harder.

You may be able to see why, as an FSU member, I do not see that tradeoff to be worth it.

Just a thought, but maybe the tbms parser should check if the name has already been used and if the case, it should replace the old entry. So the last loaded entry with the same ship's name overrides all the others.

Just a thought, maybe you should inform yourself about the way tbms work.

Finally, if you want to free up disk space you make each MediaVPS to contain only the parts that must be overriden from the older one, thus avoiding to have duplicate information. And if your mod points to an older release of the MediaVPS, it would still work, because the folder is still there like it was the first day you donwloaded it.

So instead of one mod install that may get corrupted, or wrongly installed, you now have a chain of mods that can get corrupted or wrongly installed.

As they say in programming, you have a problem that you want to solve with recursion. Now you have two problems.

[Kolgena]

@The Dagger: Basically that makes it so that every MVP iteration is a patch upon the oldest MVP that exists. That sounds like making hard drive bloat mandatory rather than optional, while complicating installs and mod management.

We should do some sort of poll to see how many people actually use previous MVP versions at all. I've only ever kept the latest MVPs around and have never had issues. If only a handful of people get to save 2 gigs of space with a massive revamp in how mediavps versions are handled, it's not worth it.

[butter_pat_head]

@The Dagger: Basically that makes it so that every MVP iteration is a patch upon the oldest MVP that exists. That sounds like making hard drive bloat mandatory rather than optional, while complicating installs and mod management.

Not if you run the process in reverse, make every previous version a patch on the newest MVP.  Have the main MVP download the latest version and the compatibility download be the versions that refer to the latest.

[The E]

...

That idea is even worse. Seriously guys, have none of you ever spared a thought about ease of maintenance and usability issues?

[The Dagger]

Don't get me wrong, I'm happy with the current system.

But as a part-time OOP programmer, that's how I would implement Dragon's idea.

[The E]

Don't get me wrong, I'm happy with the current system.

But as a part-time OOP programmer, that's how I would implement Dragon's idea.

And as a full-time FSO programmer, and as someone who has done his share of work in the trenches of FSO tech support, I am telling you that it's a bad idea.

[The Dagger]

I wasn't critizint your work, you guys are awesome.
I apologize if I was out of place, I know I wouldn't like newbies making wild claims over my own code.
(Note to self: keep out of programming discussions)

[The E]

No apologies necessary. It's just that this topic has brought out its share of backseat modders and half-baked ideas.

[butter_pat_head]

...

That idea is even worse. Seriously guys, have none of you ever spared a thought about ease of maintenance and usability issues?

I spared a few thoughts 

Seriously, doing it like that means the MVPs are maintained pretty much exactly as they are now.  When a new version is about to be released, do a directory compare on the two versions, deleting the files from the old version that are replicated in the new and adding zero sized version of brand new files.  Alter the old version mod.ini accordingly, package, release, forget.  Yes forget because the old mod would override the newer content from the new version and would have the effect of running the full old version.

Usability?

A new player comes along, grabs FSO and the latest MVPs then decides to try one of the older mods.  Won't work because the player dosn't have the older MVPs to go with it. "What I have to download another 2+GBs to get this thing working?  No thanks. Ragequit."

A smaller compatibility pack would be a much easier pill for the payer to swallow and old mods that may never get updated to the newer version MVPs would still have life.

[Dragon]

This does not sound like a good idea.

The problem with loading mods recursively is that you may end up loading dependencies you do not want to load. Yes, you can get around that with even more options, but why **** up a perfectly usable, simple and robust system?

First, it won't change the current system, because it'd pretty much add a self contained, new option.
Second, I assume mod.inis are made by modders, and that those modders know what they want to do. So, if, say, mod A depends on mods B and C, mod B depends on C and D, and mod D conflicts with A, then you simply can't use this feature to link mod A to mod B and load mod B's dependencies (because they include mod D). But it can easily be done the "old" way. It's up to the modder to tell the mod what he wants to load. Note, I'm not proposing any actual changes in loading, just a way to automate part of the process which is usually done manually. For example, BP2 could only list BP as dependency, and load mod.ini from BP that would tell it to load the current mediavps. In the end, this would be no different from the way it's now, since the final command line found in settings.ini would look exactly the same.

Now, I thought about using this so that all mediavps folders older than the current one would have self contained compatibility packages, each dependent on the current VPs. So, loading the folder Mediavps (3.6.10 and before) would first load 3.6.14, then apply the 3.6.10 package on top of that. Mediavps folder would have a special trigger, which would tell the launcher that if it's loaded, it's supposed to add Mediavps3.6.14 to the mod list. That way, there would be no need for altering the old mod.inis, the compatibility package could be optional, relatively small and easy to both automatically install and update.


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. I could most likely try to lay the groundwork for it (the recrusive mod loading part), but the question is, does that even makes sense? I don't know if it isn't easier to just make a compatibility package as a drop-in VP and tell an occasional illiterate fool to learn to read and follow the installation instructions.
I don't think we should try to carter to the lowest common denominator. If the user's too stupid to grasp that the compatibility package is a troubleshooting measure, then what is he doing in front of a PC? Consoles fill that niche, and PC stuff (especially mods) sometimes requires actual thinking.

[The E]

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?

[General Battuta]

Lots of complex plans in this thread from people who will never have to deal with either the implementation or maintenance of them.