Hard Light Productions Forums

Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Mobius on January 02, 2011, 09:37:22 am

Title: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 09:37:22 am
I've been thinking about this for quite some time. It has some potential, but there are many things to consider when discussing it.

Basically, a while ago I realized how much free memory we waste because of files we already have. Let's take an FSPort ANI or model for example: you can find it in the Port and in the modpack of various mods using it. You can't make a custom FS2 campaign compatible with the Port, so it's far more convenient to just get that file from the Port itself and put it in modpack X. The drawback is that we end up having a great many copies of a single file in our FS2 directory (I don't know how many copies of the GTF Apollo I have and the principle can be easily applied to all non-FSPort assets).

I remember when Lightspeed's nebula pack was not in the MVPs. Campaign designers like Blaise Russel simply specified in their readme files that campaign X needed LS nebulae to be fully enjoyable, and installing them was quite easy. It was quite handy providing that a) you had LS' pack and b) you knew how to use mods.


Why did I mention Lightspeed's pack? It's quite simple. What about creating stock folders where we can place commonly used files, and then consider them as requirements to play a given campaign? FSPort models, music packs, alternate shockwave effects, new nebulae, different interfaces... if we create specific folders for them and use those as mods, we could save a lot of space and make small modpacks easier to create, upload and download. If I only I had a faster connection I would have taken the initiative, but unfortunately I can't. What do you guys think? Discuss.  :)
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Qent on January 02, 2011, 09:58:23 am
I think that it's misleading to call it a memory saver, because it's saving disk space, which isn't what most people think of as "memory." In fact, my guess is that it wastes more memory because the engine will load assets that are not actually being used by the campaign, but I don't know about such things.

IMHO it's more trouble than it's worth, since disk space isn't a big problem for most people AFAIK. On top of that, unless there are a good many campaigns that use the pack, the savings won't be that great.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Dragon on January 02, 2011, 10:00:26 am
I think that now that Inferno builds are the standard, FSPort should get back to having it's modpack "linked" with FS2.
FSPort versions of ships and weapons that were changed from FSPort to FS2 could be included in two versions, FS1 and FS2.
In general, varius mods ussualy alter the assets they're using, so it'd be difficult to make a "commonly used assets" pack.
Lightspeed's nebulae were the spacial case and in the end, were put into Mediavps.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Satellight on January 02, 2011, 10:02:36 am
I think Mobius is talking more about the bandwidth. Saving it will be good, but I also fear that it will cause more and more problems for newcomers (where to find the addon pack ? When I find them, how I install them ?). 99 % people don't read the "readme-savior-thing"  :doubt:
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 10:14:36 am
Qent, how does the game slow down if it loads an asset present in a mod folder? What's the difference between using 3 mod folders instead of 2?

That's true, Satellight. Problems may be common, but if people don't change the name of those folders we could easily prevent them thanks to ease of installation. A long while ago, for reasons I don't remember, I changed the name of my LS pack folder, and had to edit all mod inis with the old name on them. Ugh.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: MetalDestroyer on January 02, 2011, 10:21:30 am
I think it's feasable right now, but doesn't work very well.
In my custom mods, I have the following in my mod.ini:

Quote
[multimod]
primarylist= Esarai Fleetpack;
secondarylist = Next Gen Render 2010,MediaVP_3.6.12_August_2010;

It would be great to add mods like this as do Operation Flashpoint series and ArmA series. For now, FSO doesn't work well when I put many mods folder on the secondarylist. :(
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Qent on January 02, 2011, 10:33:05 am
I think that now that Inferno builds are the standard, FSPort should get back to having it's modpack "linked" with FS2.
FSPort is supposed to be Retail-compatible.

Qent, how does the game slow down if it loads an asset present in a mod folder? What's the difference between using 3 mod folders instead of 2?
Like I said, I don't know. It's just a hunch that loading a bunch of models and, textures, etc. that are not being used wastes memory. Does it?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 10:38:35 am
MetalDestroyer, don't you have to remove the spaces between words? For example, isn't EsaraiFleetpack handier than Esarai Fleetpack?

Like I said, I don't know. It's just a hunch that loading a bunch of models and, textures, etc. that are not being used wastes memory. Does it?

The amount of models used is exactly the same, so it shouldn't slow the game unless there's some tricky trap in the code allowing that to happen.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 02, 2011, 11:27:38 am
From a coders' point of view, there isn't much of a slowdown associated with such a repository (Startup might take longer, as the engine needs to index all the "repository" directories, and file lookup may be slower), but that slowdown is so little that an end user would likely not be able to tell the difference.

There IS a penalty associated with having large VP files (TBP's Core vp, which clocks in at > 1GB is an example for this), but it would likely not apply here.

The biggest issue is that something like this will only make an impact if you have lots of campaigns/mods installed, and even then, the benefit is dubious.

In addition, what happens if someone wants to reskin/reUV/returret a given ship? Once you do that, the benefit of having this repo disappears, as the mod designer will have to include the altered files once more.

Finally, who would be responsible for maintaining this pack? Who would make the call on what goes in and what stays out?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 12:09:08 pm
I'm not refering to a single pack, but rather to a possible series of packages that may be used for different purposes. FSPort files are a relevant example (think about FS1's ANI files for a moment), but there are many other uses. What about Nighteyes' latest shockwave, for example?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Droid803 on January 02, 2011, 02:51:01 pm
Unfortunately, the chance I will actually use a model present in a shippack without modifiying it in some way is basically zero (for a number of reasons, really - its hard to find something that will slot into whatever you want perfectly right off the bat), thus, this will not reduce my modpack sizes at all.

I'd also probably hue/sat a few effects as well. I've seen some pretty good alterations of Nighteye's shockwave (with the end frames desaturated and whatnot).

Basically, the gain is minimal for the effort expended.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: ShadowWolf_IH on January 02, 2011, 03:25:25 pm
I agree with you driod, but how many of us modify the textures for our mods?  A standard texture pack would allow mod creators to remove, or not bother installing the textures for the most common ships.  Perhaps a modpack inclusive of the the most common fighters and bombers, something like stratcomm's fleetpack.  Once i get a bunch of skyboxes done, I plan to release them in the form of a .vp, as in a base model that is just modified by the skybox textures i make. Kind of a mix and match thing.  People are always on the lookout for skyboxes, this allows them to create thier own with ease.   I will probably incluse all of the skybox textures that I can find, and a credits list for them.  I can see the problems inherent in this, but it is still worth exploring.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 03:31:10 pm
Please note that if you use different textures you can simply retexture the model via tbms unless, of course, you remap it.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Droid803 on January 02, 2011, 03:50:21 pm
Maybe it's just me but I like fudging with turret layouts and FoVs.

I guess the majority of the stuff I do is because a lot of the assets actually floating around are bugged as hell though (crummy smoothing, bad POF data, etc). The smoothing is a big one, like half the models out there are uniformly smoothed cause true**** sucks monkey balls and people are terrible at converting. I just fudge with the turret layouts and whatnot because I have to go into 3D Studio Max to fix the stupid smoothing anyway and might as well do something else while I'm at it.

If you do this there better be some good quality control or noone's gonna use it.

Even Stratcomm's fleet pack, I had to make the FOVs on a lot of the turrets bigger cause by default they're tiny, and hence suck.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: ShadowWolf_IH on January 02, 2011, 04:08:43 pm
Just saying that with the proper execution it's worth a discussion and worth thinking on. 
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Droid803 on January 02, 2011, 04:10:05 pm
Yes, it is, but it's also a lot of work, and there's no guarantee it'll actually be used.
Or that it'll actually reduced hard disk space usage.

Now, if we could configure multimod to only draw from specific *.vps, then I could see that saving HDD space, as well as a reason for actually using *.vps (as of now, I feel they're absolutely useless, they don't compress anything, they increase the chance of corruption, and they're basically just a glorified folder.)

Say, you tell it to only load the CB anis vp from FSPort, then it won't load the ships you don't need. So, I could point to only load the effects from mediavps, cause I don't need anything else, for instance. You could even tell it to load, say, bp2-visuals1.vp for the UEF ships (and not have to worry about the tables being loaded too).

However, that might be veering off into dreamworld. Also, it'd be annoying as you say "requires X, Y, and Z to run".
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Snail on January 02, 2011, 04:14:51 pm
However good-intentioned this may be, it sounds like it'll just cause problems. It'll complicate installation matters (especially for newbies), it'll complicate mod setup, it'll need to be constantly updated, more campaigns will go out-of-date more quickly, the list goes on.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 04:22:08 pm
If there's a positive thing it will do is keeping campaigns up to date thanks to updated graphical effects and such. If an updated version of a given model comes out, you have to completely overwrite campaign X's VP file to use it.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Solatar on January 02, 2011, 04:58:48 pm
Seems like this could easily scare newbies.

Now if we could set up a SCP and campaign package manager that automatically kept the dependencies up to date. . . ;7
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 02, 2011, 07:36:00 pm
Guys, did Lightspeed's pack frighten people back when it wasn't part of the MVPs?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Solatar on January 02, 2011, 08:26:20 pm

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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Droid803 on January 02, 2011, 08:27:18 pm
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. >.>
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Solatar on January 02, 2011, 08:28:28 pm
IIRC most of Blaise Russels stuff that used Lightspeed nebulae had whichever sets it needed bundled.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: karajorma on January 03, 2011, 03:19:14 am
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: T-Man on January 03, 2011, 03:58:41 am
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 06:15:33 am
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 12:40:38 pm
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?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 03, 2011, 12:45:22 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 12:50:51 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: General Battuta on January 03, 2011, 12:53:37 pm
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
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 03, 2011, 01:01:54 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 01:06:23 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 01:08:43 pm
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?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 01:11:41 pm
I believe my post actually covers that part.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 03, 2011, 01:13:18 pm
It does.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 01:17:17 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 03, 2011, 01:21:58 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 01:28:34 pm
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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 03, 2011, 01:40:04 pm
 :beamz:

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.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: General Battuta on January 03, 2011, 01:41:10 pm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this

with luck desura will help
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 01:46:10 pm
If users don't read anything, what's the point in even writing tutorials and instructions? :nervous:

Seriously, I don't see how this should make installing mods any harder than it currently is. Dropping a folder in FreeSpace 2 it's the easiest thing to do if mod.ini will do the rest without any problems. And TBH, if users know there's a way to reduce the filesize of whatever they want to download, that'll probably attract their interest.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: General Battuta on January 03, 2011, 01:47:40 pm
most users don't read tutorials or instructions

of those that do, most of them are confused

the instructions we have for installing FSO are too confusing

desura will help fix this

mod.inis should never have to be touched by the end user
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 01:49:49 pm
Don't forget the role of common sense on this.
But you already forgot it when you posted this topic. :p Unless we're talking about hundreds of megabytes, like 500MB or more, dependencies are evil. The only reason why BP2 depends on BP1, is that there are about 500MB of assets shared with BP2. If it had been 50 MB, then if you ask me, BP2 wouldn't have used BP1 as dependency. The support trouble from managing dependencies simply isn't worth it.

I'm sorry for all those people who have to live with internet connections that have limited monthly bandwidth or are otherwise slow, but screw them. A repository like this would be such a support nightmare I'd rather not have any dependencies at all than use this repository. But luckily for all of us, there lies a common ground dictated by common sense which has served us well up to now. Now all we need is that bloody installer to manage the few dependencies that mods use. But let me tell you, even is dependency management is someday realized through an useful installer, this repository shall remain a fairy tale as far as I am concerned.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 01:51:20 pm
most users don't read tutorials or instructions

of those that do, most of them are confused

the instructions we have for installing FSO are too confusing

desura will help fix this

mod.inis should never have to be touched by the end user

Mod.inis are touched because AFAIK people tend to give MVP folders the names they prefer, thus increasing the odds. Packs with fixed names will hopefully be different.

Anyway, is Desura any compatible with my controversial idea?
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 01:54:25 pm
Mod.inis are touched because AFAIK people tend to give MVP folders the names they prefer, thus increasing the odds. Packs with fixed names will hopefully be different.
:wtf:

Wall, meet head.
Head, meet wall.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: General Battuta on January 03, 2011, 01:55:36 pm
ahahahahahahahahahahaha
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: The E on January 03, 2011, 01:58:32 pm
Mod.inis are touched because AFAIK people tend to give MVP folders the names they prefer, thus increasing the odds. Packs with fixed names will hopefully be different.

No, it's because users are idiots who tend to not read, ignore, or misinterpret install instructions, or who believe they know better than the mod designers.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 02:00:24 pm
Well, I'll make that statement clear to all newbies who will be asking for help. :p

j/k
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Shivan Hunter on January 03, 2011, 02:13:04 pm
facepalm.jpg

Thing is, if we needlessly increase the number of dependencies being used, we'll be getting a metric frakton more support requests. If they have to be handled at all by the end user, DEPENDENCIES ARE BAD. We've actually been having a discussion on IRC about why even the MVPs should not be a dependency for mods- the only dependency should be the core system which is unchanging and can thus be relied upon.

It's way too complex for too little gain. Desura might fix it, but simplicity is much more valuable than a couple of megabytes, especially with how difficult it is to support FS even now.

in short, facepalm.jpg
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 02:17:56 pm
We've actually been having a discussion on IRC about why even the MVPs should not be a dependency for mods- the only dependency should be the core system which is unchanging and can thus be relied upon.
doublefacepalm.png
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Qent on January 03, 2011, 02:20:27 pm
people tend to give MVP folders the names they prefer
If you're reading this, please never ever do that! :shaking:

Given how few mods I've encountered that share resources, I am now convinced that this proposal will increase the size of downloads, not reduce it.

And facepalm-normal.dds for the next post. :P
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 02:21:42 pm
facepalm.dds
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Jeff Vader on January 03, 2011, 02:24:24 pm
lock.gif if this stupid picture joke continues.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Droid803 on January 03, 2011, 02:35:44 pm
If users don't read anything, what's the point in even writing tutorials and instructions? :nervous:

We write them because we hope people read them.
Also, because we can go ***** at them about not reading the instructions if they don't get it. Duh.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 02:45:54 pm
I think you got it right.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: MatthTheGeek on January 03, 2011, 02:47:24 pm
Yeah, it's our safe bet. If we didn't have instructions, noobs would complain about us because they don't exist. Now, WE can complain about THEM for not reading the instructions. And flame them, and beat them to death for being stupid. THAT is the good way.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Shivan Hunter on January 03, 2011, 02:49:58 pm
Hopefully Desura wil negate most of these issues anyway. All hail Desura
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Mobius on January 03, 2011, 02:51:51 pm
Plus, let's make sure it's promoted on ModDB. There are people there who complain about installations.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Macfie on January 03, 2011, 04:47:58 pm
mod.inis should never have to be touched by the end user

Some one should have told that to whoever named the new media VPs folder "mediavps_3612" instead of "mediavps", thus requiring changing the name of the folder or all the mod.ini's to be able to use them. 
And then there was the freespace FSPort mediavps that had a dash in the folder name that caused them not to work when they first came out unless they were renamed.

It would appear that we have not yet gotten to the point where the mod.ini's do not have to be touched by the end user.

Edited for clarity. --Jeff Vader
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Droid803 on January 03, 2011, 05:34:53 pm
That's more due to oversights than anything (at least on the part of the fsport mediavps).
The 3.6.12 mediavps are named differently intentionally, because theres so much in it that break backwards compatability or something.
Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Solatar on January 03, 2011, 05:58:33 pm
FSPort was an oversight, but as you can see from the 3.16.12 mediavps release thread, the different folder was intentional.

Quote

The zip (and 7z) have been set up to extract to a numbered folder called "mediavps_3612" as part of a concept for being able to retain compatibility going forward, rather than always directly over-writing the previous version.

This means that you will need to be sure about your mod.ini's and Launcher Mod selection to accomodate this change. We feel it is a good way to allow for existing mods to have a better amount of time in which to keep up.

As an example of this, while the MediaVPs make enhancements to the presentation of FS2 Campaign and provide updated assets, many times portions of assets get used in other areas. An example of this is Blue Planet. One of the warp gates uses maps (some, but not all) from the Hatshepsut. Because that model has now changed, Blue Planet must now include the maps that it sourced, which it should have done in the first place. But by providing the MediaVPs with the changes to it's own versioned directory, we spare users the headache of older mods breaking while the mod get's updated to working with the newer set (since not every mod can update and release at the same time as the MediaVPs) by letting them still continue to play with the older set since that's what the mods mod.ini will by default be pointing to.

Title: Re: A possible way to reduce the size of modpacks. What about it?
Post by: Fury on January 03, 2011, 10:22:46 pm
Exactly. Naming change of mediavps mod folder was intentional. You would have had a ton of broken mods and campaigns in your hands if that hadn't been done. The bottom line is that anyone should be able to play mods and campaigns as-intended regardless of what mediavps version they were built on. Mucking around with mod.ini's is not recommended and should not be done unless you are sure the mod or campaign in question actually works with 3.6.12's without debug errors. That is a problem for authors to handle and issue an update, not end-user.

Next major update of mediavps should again use version number in the mod folder to avoid mods and campaigns designed for 3.6.'12 from breaking. In best-case scenario you only have current and previous mediavps installed. But of course, that all depends on authors to keep their mods up-to-date, which is not given.