[Solatar]

FSPort models, music packs, alternate shockwave effects, new nebulae, different interfaces...

Lightspeed's nebula pack was a single addition that was quite common.  I'd love to see something like this, but expecting the newbie end-user to manage all the requirements for campaigns is a bit much.

[Droid803]

And if I were around back then, I would have just lumped them with my mod instead of askign people to have it.
Hell, I've done that to the MediaVPs as well...

Never worry about compatability again. >.>

[Solatar]

IIRC most of Blaise Russels stuff that used Lightspeed nebulae had whichever sets it needed bundled.

[karajorma]

Guys, did Lightspeed's pack frighten people back when it wasn't part of the MVPs?

Yes they did. You have no idea how many issues I had to deal with caused by people putting them in the wrong folders, extracting them, etc.

[T-Man]

I think i see what Mobius means here; if a particular file is being used by a lot of mods (such as Lightspeeds pack) than have some kind of extra modpack for things outside of the MediaVPs where all those mods can load it from and prevent them all having to have identical files in the modpack.

Its good thinking, but unfortunately if any more than one or two files were added to a modpack using the currrent setting than it would increase the loadtimes for all of them as they had to load files in the pack but which they didn't use, and files used so much would likely end up in the MVP anyway.

Its still a nice idea though. If some kind of automated function existed that could detect files that existed multiple times (and perhaps somehow the global modpack thing only loaded those files it needed) it would likely be effective too.

[Fury]

This is not worth the trouble, not by a long shot. A repository like this is subject to many issues, such as following
* People who manage this repository need to know wtf they're doing and actually have the time to manage it.
* Hosting this repository requires plenty of disk space and bandwidth.
* There will be various variants of any one asset. Original asset won't necessarily be the most popular and yet there might be more than one popular variant, further complicating things.
* There is no installer to manage this repository for end-users. Leaving this to end-users to manually manage is sure-way nightmare to support people.
* Popular mods almost always use more or less altered assets.
* Bandwidth savings are minimal if good compression is used in downloads. Please forget about zip, use 7z instead. In worst case scenario you're downloading huge repository of assets that won't be used by mods because variant of assets included is incompatible.
* Disk space savings are questionable because a lot of mods use altered assets and by downloading this large repository you're likely to end up with a lot of assets that simply won't get used by most people.
* We already have one repository of commonly used assets. It's called mediavps.

If there is one thing I'd like to see, that is making FSPort modular in a way that both FS1 and FS2 campaigns work as designed while you get access to assets from both. But to accomplish this, we'd need to overhaul how the interface works so that we have default interface and then interface that is selected by campaign file. Then there are a lot of tables that still aren't modular and that prevent this from being achieved. And of course, briefing icons too. Might have forgotten a few others.

Even if FSPort staff would refuse to make FSPort fully modular, making this possible would still be huge achievement in reaching another milestone in modding of FSO. This would reduce asset overhead in specific situations quite a lot, these situations might be limited but they are there. The day we can play both FS1 and FS2 campaigns as intended while having fsport-mediavps selected as mod would be a glorious day indeed, because then we'd have achieved full modularity of tables and interface.

[Mobius]

The FSPort is just an example, let's not mention that project all the time and make it look like the cause of a problem.


Here's a possible scenario. Watsisname and/or any other creates a new set of nebulae, planets, skyboxes, etc., which for a variety of reasons are not included in the MVPs. They're not popular enough, the MVPs will come out in a few months time or more, said bitmaps do not fully match the style of FreeSpace, whatever.

The set is big in terms of dimensions, let's say many dozen mbs.

Now, imagine that the pack is successful enough to become common in fan-made campaigns, but still doesn't qualify as something you'd add to the MVPs. How would you handle the situation? Would you simply allow each campaign design to add all those files to their own modpacks and release them?

[The E]

Well, yes. Because unless you have an automated installer to do the dependency management for you, depending on the users following instructions to get everything they need is a recipe for disaster. Witness the BP: WiH release thread, and the many people who, despite the installation instructions being quite clear, nonetheless forgot to install the .12 mvps, or AoA.

[Mobius]

It shouldn't be that hard, though. If the mod folder has a fixed name and the mod.ini is well written, all the instructions are reduced to a mere "be sure to have folder X in your main FreeSpace 2 folder" before running the campaign on the launcher.

[General Battuta]

God forbid this ever happen. Mods should pack all dependencies (heck I think Droid's right, even the MVPs) in their modpacks, death to mod.ini and secondary folders

[The E]

It shouldn't be that hard, though. If the mod folder has a fixed name and the mod.ini is well written, all the instructions are reduced to a mere "be sure to have folder X in your main FreeSpace 2 folder" before running the campaign on the launcher.

Mobius, the problem is that people do not read install instructions. That is why you need either a "drop in" type of installation (as in, "drop these unpacked folders in your FS2 dir") or an automated solution.
The former solution is incompatible with your repository idea, while the second needs a certain amount of infrastructure work in place before it can be used.

[Fury]

The FSPort is just an example, let's not mention that project all the time and make it look like the cause of a problem.

It is exactly that, an example. It is also the best example to give. It is also not cause of the problem, the problem is that FSO still hasn't reached a point of modularity where the situation I described would be possible.

How would you handle the situation? Would you simply allow each campaign design to add all those files to their own modpacks and release them?

Exactly.

It shouldn't be that hard, though.

There's no if's or but's about it. It is.

Even mediavps have caused its own fair share of problems after each and every major version upgrade. Since all mod.ini's were pointing to mediavps folder, a lot of mods and campaigns broke because new ones never were (and never will be) 100% backwards compatible. So this was a question of compatibility. In the case of BP2 which depended not only to mediavps, but also BP1. Despite thorough installation instructions, a lot of people still failed to get BP1 or update it.

Now, imagine a mod having half-a-dozen dependencies. It's a recipe for disaster. You can't get anywhere with this idea until we have solid framework and installer to handle dependencies. But that's in the best case scenario. In reality asset compatibility will be an issue, or did you forget about any one asset likely having multiple different variations and then of course potentially breaking something if it ever gets altered, or even as much as "fixed" from bugs. It's just never going to work in scale you imagine, its usefulness will be so limited any real disk and bandwidth savings are minimal and potentially you end up using more of both. But we just got a whole load of support problems in exchange.

No thank you.

[Mobius]

The former solution is incompatible with your repository idea, while the second needs a certain amount of infrastructure work in place before it can be used.

How so? What makes the former solution incompatible?

[Fury]

I believe my post actually covers that part.

[The E]

It does.

[Mobius]

I believe my post actually covers that part.

Your post calls for half a dozen dependencies, which is not the case IMO. I expect one, two at best (bitmaps + music), and if a developer decides to go beyond that limit, that'd be pure exaggeration. Not even a TC would need 6+ additional folders, each one containing 40+ mbs of files.

[The E]

I believe my post actually covers that part.

Your post calls for half a dozen dependencies, which is not the case IMO. I expect one, two at best (bitmaps + music), and if a developer decides to go beyond that limit, that'd be pure exaggeration. Not even a TC would need 6+ additional folders, each one containing 40+ mbs of files.

No, since a TC, by definition, should contain all files needed in its core download.

Mobius, 6 dependencies is far from unrealistic in a scenario like the one you're envisioning. Let's see...... Assuming Esarai, StratComm, and Steve-O had model packs out and distributed. That would mean BP: WiH would depend on: BP AoA, the Esarai, Steve-O and Stratcomm packs, and the mediavps. That's 5. If we're really covering everything, we should also mention that we're using at least one model by Scooby, meaning his pack would be included as well.

[Mobius]

Don't forget the role of common sense on this. If the main goal is to reduce size, stockages should only be used to prevent players from downloading dozens and dozens of unnecessary mbs.

If you use an average 5-10mbs from any of the packs you mentioned, you'd rather add the files directly to your own folder.

[The E]

 

I feel like talking to a wall. Mobius, the issue is (sorry to any user reading this) that users are stupid. They will never read install instructions, they will misinterpret what they read, and they will make mistakes while following the instructions. No matter how clearly you think you worded your instructions, there will always be people who will **** it up anyway, and who will have to be taken care of by whoever does support work for your mod (After, possibly, posting on the SCP Mantis and the FSO support boards first, or GenFS, or any number of random places). Reducing the number of install steps is the only way of reducing the probability of this happening. Your proposal would increase the complexity of the install process, and as long as there is no automated way in place to deal with mod dependency management, there is no way to implement this in a way that would keep installation procedures simple.

[General Battuta]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this

with luck desura will help