Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: Black Wolf on May 13, 2012, 07:35:33 am
-
...and, if it has, my apologies, but I was thinking about this this afternoon and I haven't come up with a satisfactory answer.
Currently, people release mods with a mod ini that tells the game to look for their mod folder and mediavps3612. Well, aren't we getting ever closer to the next release of the mediaVPs, which will (presumably) be called mediavps3614 or something. Now, this is fine for me and, I assume, most of you, since we all know how to edit mod.ini files. But for the future end-user, this will be a potential source of frustration. They DL the latest mediavps and an older campaign (and not neccesarily ancient ones here - everything from the last several years is like this) and suddenly they're getting errors because the game can't find mediavps3612.
So, has anyone thought about this? Is there a solution planned? Will all mediaVPs just be dumped in mediavps3612 from now on? Are people expected to keep multiple mediavp folders? Is every campaign for the last x number of years going to need a patch? Or is there a simple (possibly codeside?) solution that I'm missing?
This is relevant to me (and anyone else who plans to release a campaign in the not too distant) since I've got to admit while I'm not super keen on the idea of repatching everything in a few months when new mediaVPs are released, if it turns out that that's going to be the only viable solution, it'll be important to design the downloadable package with that in mind.
-
We expect people to keep multiple mvp installs around. Among all the various ways of dealing with compatibility issues, this was deemed the least bad.
-
If so, it could be useful to keep the links to 3.6.12 Mediavps around once 3.6.14 are released. If you want to get 3.6.10 VPs now, you have to dig through the board for them.
-
They DL the latest mediavps and an older campaign (and not neccesarily ancient ones here - everything from the last several years is like this) and suddenly they're getting errors because the game can't find mediavps3612.
On the contrary. One should not expect previously released mod to work 100% with recently released mediavps. Mediavps change and evolve, stuff are removed and changed. Hence there is no guarantee mods that were released before the newest mediavps work without errors.
Is there a solution planned? Will all mediaVPs just be dumped in mediavps3612 from now on? Are people expected to keep multiple mediavp folders? Is every campaign for the last x number of years going to need a patch? Or is there a simple (possibly codeside?) solution that I'm missing?
Modder states what version of the mediavps a particular mod was designed for and mod.ini points to that version. Older versions of mediavps should remain available for download. So yes, you will have to keep as many versions of mediavps around as the mods you want to play require. In a perfect world their authors have or will update their mods to fully support the latest mediavps, but this is not always the case.
The situation is very similar to FSO builds. Some mods do not work correctly with newer FSO builds mostly due to bugs, either bugs in the mod or in FSO. There's no way around that as long as mods depend on something else. The only way around that is not to depend on mediavps or any other mod and supply your own FSO builds with the mod.
I've got to admit while I'm not super keen on the idea of repatching everything in a few months when new mediaVPs are released
Let's assume in your case your mod would work 100% with new version of mediavps that was just released. You should have a small core package (and .vp file) containing config, fiction, missions, scripts and tables for easy updates. This small package also contains mod.ini. If your mod just so happens to be perfectly compatible with new mediavps, all you need to do is update mod.ini and reupload the small package.
But what if your mod has issues with new mediavps? Maybe missing textures or effects for example? Or maybe a script conflicts with your mod. If we had still used "mediavps" folder without version numbers, then now everybody would be plagued by errors and warnings and possibly unplayable mod until they are fixed by mod author or helpful community. But with version numbered mediavps folders, your mod continues to work fine with previous version of the mediavps.
Everybody wins. The old method was bad because it ALWAYS broke mods whenever new mediavps was released. And there is no need to update your mod to support new version of mediavps if you don't see the need for it. The mod continues to work with older mediavps and people don't need to mess with mod.ini or mod dirs, only thing that is required of them is to keep older mediavps.
-
We at also keeping track of changes so as to communicate those to mods and help them update if they want to. We have a list of changes and things to check for mods.
-
We expect people to keep multiple mvp installs around. Among all the various ways of dealing with compatibility issues, this was deemed the least bad.
I still think this is the ugliest solution and one that doesnt make a lot of sense to me.
Wanting people to have like 3.5gb in mediavp's around, majority of which is just redundancy. Instead of having each new version just being backwards compatible. Sure the new version would be 'bloated' but there is no way that will compare to having an whole extra 1.5gb redundancy of the previous version around.
But meh whatever, not my call.
-
Spoon, read Fury's post. He explains the reasons for the new system quite well. If you have a better idea that can address the shortcomings of the old system, please share it.
-
I still play a lot of the older campaigns. The size of my FreeSpace folder is now 20.3 GB - I even got a dual core chip and a 9600 gt so I could use advance effects. Both the mediavps and the campaigns are getting bigger. This is getting expensive. But then that is what I have top do to continue playing high quality games. May be Freespace to be split into a full and a light (compatible) version?
-
What about having a mediavps "compatibility" install? Basically, after the 3.6.14 vps are released, include a separate download that includes everything that was changed between 3.6.12, and have that reference the 3.6.14 vps as a dependency. That way, you get rid of redundancy.
So, base->3.6.14->3.6.12
-
@BlasterNT: I'm pretty sure the idea is to get the mod creator to ensure compatibility with the newest MVPs. For older mods that are no longer being maintained, no one would be around to fix bugs should they arise, so it's best to freeze their requirements at the mediavps version they're designed for.
If you're an advanced user, no one's stopping you from fiddling with older mods to work with new mediavps. Most of the time, a mod.ini change is sufficient, and nothing will break as a result. If something does break, then you can attempt to fix it or revert to the older MVPs.
As an aside, I am unaware of any material being removed from the mediavps as they get more recent. The only thing I can think of were the tile maps that were torn out (and released as a standalone package). What sorts of compatibility issues are we talking about here? Subtle differences in turret placements and hitboxes that might affect balance?
-
As an aside, I am unaware of any material being removed from the mediavps as they get more recent. The only thing I can think of were the tile maps that were torn out (and released as a standalone package). What sorts of compatibility issues are we talking about here? Subtle differences in turret placements and hitboxes that might affect balance?
Yes, and possible script conflicts. Also differences in POF names a few other things that might change.
Again, I want to make it absolutely clear that when the MediaVPs gets closer to another release, we are going to reach out to the mod and campaign developers with a list of changes. We want to help them be ready and/or easily make the switch to the newest MediaVPs. We feel very strongly that this is the best solution that doesn't completely limit what we can and can't do.
Additionally, it's an incredibly difficult task to maintain compatibility with every mod ever designed with the MediaVPs since its inception. Our goal is to upgrade Freespace and it's main FS2 campaign. Beyond that, we can't make guarantees, but we will be trying to ease the switch as much as possible.
-
I know it probably is the simplest solution from a support standpoint, but I'm kind of with Spoon that keeping ever-increasing gigs' worth of outdated media files to ensure full compatibility doesn't seem all that great. At least for the moment, I'm not exactly made of hard drive space, so the fewer unnecessary/redundant files that I have to keep around, the better. I can't really think of any feasible alternative at the moment, though.
I guess what I'm really left wondering is just how many campaigns/mods run into these compatibility issues in the first place. Before a certain point in time, say 3.6.10 and earlier, I'd think a lot of the issues would be the sort resolved by the texture compatibility pack, since most mods were probably a good order of magnitude simpler than they are today. As for the more recent stuff, most of the original creators are still active, and could presumably release a patch if need be. Is this fundamental incompatibility something that's actually happened on a frequent basis?
-
It's been frequent enough that we've talked about it many times.
Keep in mind that a lot of this is to protect us from joe-modder that comes back to HLP after 3 years from complaining that our updated MediaVPs broke his campaign. In many cases simply changing the mod.ini to use the new MediaVPs won't cause any issues. What we are trying to communicate is that we can't be held responsible for backwards compatibility for every campaign ever made.
If we start offering backwards compatibility for the 'mainstream' or 'popular' campaigns, then where do we draw the line? What's the standard for campaigns that we are supposed to check? After much deliberation, we set this standard at the main FS2 campaign and no others. We think that is the easiest and most fair solution.
Realistically, as previously mentioned, most mods can simply have their mod.inis updated without issue. Most of the people commenting in this thread have the ability to do that and have the ability to fix possible issues especially if we have a public list of things to check and how to resolve them. Now this really only applies to older campaigns. In theory this method might spark some more life into projects like FSCRP. We also consider it a good thing when campaign developers, who are still around, upkeep and patch their campaigns.
I want to acknowledge the downside of taking up a lot of hard drive space. That's sort of a side-effect of the method we've chosen. We chose this method to effectively communicate that this release of the MediaVPs is different and that it might not work with any given campaign flawlessly. Our goal is upgraded Freespace 2, not upgraded Blue Planet, or upgraded Inferno, or upgraded Derelict.
Now, this does not mean that we are willy-nilly throwing in things that will break compatibility. We still thoroughly test each asset to ensure it keeps to the original specs as close as absolutely possible. We are trying to make it as simple as we can for any mod to use the newest MediaVPs as a drop in, but what we can't do is guarantee it. That is the central reason why we are now keeping to MediaVPs versions.
I hope you all can understand our reasoning on this and that we didn't do it just to get on your bad side but instead to give us a small amount of freedom and to protect us from being the target of mods not working with a new release.
EDIT: As an additional thought to BW's original questions. Perhaps we can work with Scotty to include which MediaVPs a campaign was made for in his list? Along with that, when I make the post about what has changed for each revision, perhaps I can include simple instructions on changing the mod.ini for people who are so brave. Of course I would still include a warning about potential incompatibilities.
EDIT 2: I don't want to sound harsh, but I'm not entirely certain the issue over hard drive space is really valid. I just checked the size of my 3.6.10 and 3.6.12 Media VPs folders. Both of them combined are just around 4GB which isn't a whole lot in the world of multi-Terrabyte HDDs. Now I understand many have bandwidth issues and download caps. However, given you don't delete your 3.6.12 that you already downloaded when it was new and hot, then it shouldn't be too bad from a MB per year perspective.
-
I can't speak for anyone else, but my personal issue isn't bandwidth at all, but the physical space. I only have a 320 GB HDD right now, and it's already 2/3 full, so I'm kind of at the point where avoiding multi-GB dumps is something I try to do. That being said, I'm definitely a fringe case, and I fully acknowledge the points you're making.
-
You could always burn the older MediaVPs and campaigns to DVD and only copy them over when you do a playthrough. Just make sure to take care of the disks or they'll become unusable!
-
I can't speak for anyone else, but my personal issue isn't bandwidth at all, but the physical space. I only have a 320 GB HDD right now, and it's already 2/3 full, so I'm kind of at the point where avoiding multi-GB dumps is something I try to do.
If you can't buy internal HDD for some reason, external HDD's are always available in a retail outlet near you.
-
This is starting to sound like the out takes thread asking for the FSU to release the assets removed between version to allow better backwards compatibility.
-
I can't speak for anyone else, but my personal issue isn't bandwidth at all, but the physical space. I only have a 320 GB HDD right now, and it's already 2/3 full, so I'm kind of at the point where avoiding multi-GB dumps is something I try to do.
If you can't buy internal HDD for some reason, external HDD's are always available in a retail outlet near you.
Still, some people might not want to waste a couple GBs for something purely redundant. Most of Mediavps assets are not changed between versions, and some of the things that do change are purely aesthetic and not break anything.
-
Still, some people might not want to waste a couple GBs for something purely redundant. Most of Mediavps assets are not changed between versions, and some of the things that do change are purely aesthetic and not break anything.
It's somewhat unrealistic to expect us to cater to what every single person here wants, especially if the only reason given is their distaste for a couple GB of redundant data.
-
Still, a "compatibility package" would be a better idea than keeping an entire set of old VPs, which serve no purpose other than clog up the disk space. Something like the outtakes pack, also containing tables and scripts from the old core. It would disable all new 3.6.14 features, essentially making the new VPs work like the old ones. Just drop it into the old mod folder and the mod should work, benefiting from all the cosmetic improvements that were made for the new VPs.
-
Spoon, read Fury's post. He explains the reasons for the new system quite well. If you have a better idea that can address the shortcomings of the old system, please share it.
Read my post, I already did. Just keep the new mediavp's 'bloated' with the old stuff. Don't remove effects which you think aren't used anymore and such. You'd still end up with a mediavp version that is a whole lot smaller than having two seperate versions combined in your folder. Or hell, what dragon said. A compatibility package.
It's also a lot easier to grasp for the end user. Just install the newest mediavp version and you're set for everything. Instead of having them install 2-3 seperate things. Cause with .14 released, do you want people to have .10&.12&.14 mediavp's installed in their freespace folder? :blah: Where do want to draw the line with this? In a few years you'd need .10 .12 .14 and 3.7 mediavp's in your freespace folder just to guarantee that ever campaign and mod is going to run? Ye gods the redundancy. This is so incredible messy. Its just that the FSU doesn't want to take on the responsibility of providing backwards compatibility and just dumps it all on the modders and helpful community.
Our goal is upgraded Freespace 2, not upgraded Blue Planet, or upgraded Inferno, or upgraded Derelict.
Maybe its time to revise that goal. The time that the mediavp's are only used for a shinier retail freespace experience is waaaaay past.
-
Our goal is upgraded Freespace 2, not upgraded Blue Planet, or upgraded Inferno, or upgraded Derelict.
Maybe its time to revise that goal. The time that the mediavp's are only used for a shinier retail freespace experience is waaaaay past.
Spoon... I like you, but you need to understand that what you are asking here is an infinitely lofty goal. How are we supposed to test the MediaVPs with every campaign that might use it? It's an unrealistic expectation. At this time, we are not changing our stance on being an upgrade for the main Freespace 2 only.
A "compatibility package" is something we'll discuss. However, I'd prefer you post in a more level headed manner...
EDIT: As a further thought... Since this is considered a community project (MediaVPs), and everyone expects us to build the MediaVPs as they, individually, would build it... It would be nice if the community could work on the compatibility package ala FSCRP style for old MediaVPs. If this truely is community driven, then I'd like to see more community contribution to this issue than just pointing fingers at us every few months.
-
I agree with Spoon on that one. Almost all campaigns require Mediavps these days, and those that don't are total conversions. Ignoring just about everything the community has made is irrational.
Of course, fully supporting other campaigns is impossible. But if it's possible to at least give them a chance to run, IMHO it should be done. In many cases, it's as simple as not removing old effects (since they're the most common part of the VPs on which various mods depend).
-
No. We've talked about this so many times, and I'm getting weary of repeating myself in this thread alone. We are not, and will not, guarantee full compatibility for any campaign other than the main Freespace 2 campaign for the reasons I discussed right here. (http://www.hard-light.net/forums/index.php?topic=80836.msg1608168#msg1608168) It's impossible. We'd have to play favorites. We won't do it. Done.
We've already extended our good faith by offering the tile maps package. We are continuing to help mods by pointing them toward things that have changed.
-
Still, a "compatibility package" would be a better idea than keeping an entire set of old VPs, which serve no purpose other than clog up the disk space. Something like the outtakes pack, also containing tables and scripts from the old core. It would disable all new 3.6.14 features, essentially making the new VPs work like the old ones. Just drop it into the old mod folder and the mod should work, benefiting from all the cosmetic improvements that were made for the new VPs.
Please, go ahead and make one. And then debug it. And then take care of the people who use it wrongly. Have fun.
Maybe its time to revise that goal. The time that the mediavp's are only used for a shinier retail freespace experience is waaaaay past.
How long do you want to wait between releases? How many campaigns and mods do you expect us to test for compatibility?
Why do you expect the FSU to do all this work for you?
In many cases, it's as simple as not removing old effects (since they're the most common part of the VPs on which various mods depend).
So you want us to keep the mvps bloated with data that is only used by a portion of all mods, and that is utterly irrelevant for the stated main purpose of the MediaVPs (which is to improve FS2 retail).
-
I didn't like this decision when it was made but the decision is made and it would probably be even more frustrating to reverse course. The call's the call.
-
Perhaps the FSCRP could help with this sort of compatibility stuff?
-
Perhaps an easier solution is just to have a folder in the FSU SVN called compatibility and when you select the outdated stuff to delete, you hit move instead targeting the compatibility folder, you dont even have to organise it the folder, just post it as an asset dump when you post the new version of MVP then someone else in the community can organise it even if you guys dont want to, I know I don't have a problem with doing that as it would only take a couple of minutes to do, plus a few more to test and VP the files.
Once you have posted the dump file, clear out the compatibility folder and start again, this way your SVN dont get clogged up with masses of redundant data, just the difference between the last release and the current WIP. go thought the same update process again, then when you release again you replace the dump file with the new one and someone like me will add that to the old compatibility pack and release the new version.
For a the cost of a few seconds per update you get to keep the MVP shiny and new, while the guys who want to play older mods get to keep playing them with the improved on retail content, all the while guaranteeing compatibility is someone else's problem because you are not producing the compatibility pack.
Still, a "compatibility package" would be a better idea than keeping an entire set of old VPs, which serve no purpose other than clog up the disk space. Something like the outtakes pack, also containing tables and scripts from the old core. It would disable all new 3.6.14 features, essentially making the new VPs work like the old ones. Just drop it into the old mod folder and the mod should work, benefiting from all the cosmetic improvements that were made for the new VPs.
Please, go ahead and make one. And then debug it. And then take care of the people who use it wrongly. Have fun.
How is that different to any other mod? Look If you want to create a septate project board for it so mods and admins can divert compatibility mod related issues, I will happily take the flack from newbies and the incompetent. I know I am a glutton for punishment but I Also like a good challenge (queue comments from veterans like The_E along the lines of you dont know what you are getting into) and I am prepared to take it on.
Perhaps the FSCRP could help with this sort of compatibility stuff?
That's a big ask for a team with a heavy workload as it is
-
Perhaps the FSCRP could help with this sort of compatibility stuff?
That's a big ask for a team with a heavy workload as it is
Yes, but I think this sort of work is more their sort of thing than the FSU's.
-
Dragon, get this already. A compatibility package is only viable to add whatever files were removed, like tilemaps. It cannot address incompatibility issues presented by script or tbl changes for example. Hence usefulness of such a package is severely limited.
-
Perhaps the FSCRP could help with this sort of compatibility stuff?
That's a big ask for a team with a heavy workload as it is
Yes, but I think this sort of work is more their sort of thing than the FSU's.
Perhaps but i thought their main aim was to deal with table, mission and campaign issues cause by changes in FSO, especially in error catching?
-
Thank you, Headie for a well thought out post. Your idea has merit. The difficulty would be what to do with changed files such as tables or scripts. Granted we are mostly talking about hypothetical issues here (as is the whole thread, I suppose).
I'm going to reiterate my feelings on these issues one last time, the others on the team may disagree with me though...
We are not, and will not, change our stance on the issue of upgrading the main Freespace 2 campaign only. I've talked about the issues enough and you can go re-read them.
I'm open to civilly discussing compatibility packs, or other ways to do something similar. But we feel pretty comfortable with the method that we came up the last time someone started this topic.
Many of you are acting like we are going out of our way to screw over whatever mod you are working on... and frankly, you need to chill out.
-
Many of you are acting like we are going out of our way to screw over whatever mod you are working on... and frankly, you need to chill out
I'm not dependent on the mediavp's anymore so I'm not speaking from that perspective. In case you were getting that impression.
How long do you want to wait between releases? How many campaigns and mods do you expect us to test for compatibility?
Why do you expect the FSU to do all this work for you?
The most popular ones at least.
Why do you expect the rest of the community to all this work for you? I for one expect you guys to do it since you are the ones responsible for the mediavp's. I'm not.
Anyway, it appears to be futile to spend any more time on this. I've made my opinion heard and you've all made yours heard. (To continue on this path of messiness and boring traditional freespace 2 campaign support only.) I'll just quote Battuta and leave you all to your own devices.
I didn't like this decision when it was made but the decision is made and it would probably be even more frustrating to reverse course. The call's the call.
I'll check back with you guys once you want players to have 3-4 seperate mediavp's installed to ensure that everything is playable
-
I'll check back with you guys once you want players to have 3-4 seperate mediavp's installed to ensure that everything is playable
We don't!
We just don't want the extra headache of testing "the most popular campaigns" for compatibility with every new MVP version. That's the FSCRP's job, or at least it should be.
This whole problem, IMHO, is only really pertinent during the transitional phase between two MVP versions. Ideally, we want players to only have the most recent version installed, but since we cannot take responsibility for every campaign out there, we have to ensure that there's always a way to play older campaigns that haven't been adapted for use with the mvps. We chose to do this by versioning the MVPs, and releasing changelogs and such so that the FSCRP and mod teams can do all the required compatibility work.
Keeping old effects, maps, and models around is only part of the problem. What happens when we need to do table changes? Or script changes?
I mean, we aren't going out of our way to make things incompatible, but sometimes this stuff happens. What do you want us to do in those cases?
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?
-
Dragon, get this already. A compatibility package is only viable to add whatever files were removed, like tilemaps. It cannot address incompatibility issues presented by script or tbl changes for example. Hence usefulness of such a package is severely limited.
You missed the point, and didn't read my original post at all.
My idea was that a compatibility package would not only contain removed stuff, but also all old tables and scripts, and files disabling all new scripts and tables that were added and could affect compatibility. That would cover most possible compatibility issues. It'd also be very simple to use, just drop it into the mod folder of the campaign that you want to play. Of course, testing it would be a challenge, but if it's kept as simple as possible, it'd be easy to debug "on the fly". Of course, not everything will work with the compatibility package, but such campaigns should be in minority.
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?
Keep the old textures around, if it's the case of another model using the Hattie's textures.
If it's a case of Hattie with FRED-side texture replacement, then the effect is completely impossible to reproduce on the new model without editing the UVmap. In that case, this campaign must be updated in order to work. But that's only one case, and texture replacement isn't too commonly used.
-
You missed the point, and didn't read my original post at all.
My idea was that a compatibility package would not only contain removed stuff, but also all old tables and scripts, and files disabling all new scripts and tables that were added and could affect compatibility. That would cover most possible compatibility issues. It'd also be very simple to use, just drop it into the mod folder of the campaign that you want to play. Of course, testing it would be a challenge, but if it's kept as simple as possible, it'd be easy to debug "on the fly".
Yeah, that kind of support nightmare is just not a good idea. You do not seem to get the amount of issues this can cause when people are using it wrong as they are bound to do.
-
Dragon, get this already. A compatibility package is only viable to add whatever files were removed, like tilemaps. It cannot address incompatibility issues presented by script or tbl changes for example. Hence usefulness of such a package is severely limited.
You missed the point, and didn't read my original post at all.
My idea was that a compatibility package would not only contain removed stuff, but also all old tables and scripts, and files disabling all new scripts and tables that were added and could affect compatibility. That would cover most possible compatibility issues. It'd also be very simple to use, just drop it into the mod folder of the campaign that you want to play. Of course, testing it would be a challenge, but if it's kept as simple as possible, it'd be easy to debug "on the fly".
inb4TBMdependencynightmare
Or not...
-
Yeah, that kind of support nightmare is just not a good idea. You do not seem to get the amount of issues this can cause when people are using it wrong as they are bound to do.
It's pretty simple. If the campaign isn't marked as 3.6.14, then put the file in it's main folder. If it is, don't do it.
It seems rather easy to me. The pack would be self-contained, and tested on a campaign known to run on 3.6.12 without errors. Besides, it's not like there are many campaigns specifically for 3.6.12.
Also, people too incompetent to use something so simple could just download the old VPs.
-
Your faith in the abilities of the average player is astonishing. I wish I could share it.
-
I think that anyone with half a brain and knowledge of English should be capable of using such simple thing, and I don't care about the rest. People stupid enough not to be able to grasp two simple sentences wouldn't care about clogging up their disk space. Smart people, on the other hand, could download the compatibility pack.
-
Smart people don't want to waste time installing something they're not even sure will be any fun. Complex install procedures help no one and provide a series of failure points that cause user attrition.
-
Dragon, You are forgetting there are many who will download and try to use something because it exists. The smart ones don't change anything and use it as advertised and occasionally hit problems, the rest which are the ones you find on here go:-
Player A
"I download the Compatibility pack because someone on the forum said once I might need it sometime and I decided I wanted to make sure X wasn't missing from mod Y so I did Z and now Y wont work, what did I do wrong"
The_E/other knowledgeable person who decides to help
"Y wont work because it was designed to work WITHOUT the comparability pack. by doing Z you stopped mod Y from calling a key feature because it is not in the compatibility pack tables."
Player A
"So how do a fix this?"
The_E/other knowledgeable person who decides to help
/head desk "Reinstall the mod and/or media VPs"
or
Player A
"I download the Compatibility pack because someone on the forum said once I might need it sometime and I decided I wanted to make sure X wasn't missing from mod Y so I did Z and now the hattie looks nothing like the uber cool one in the screen grabs"
The_E/other knowledgeable person who decides to help
"The hattie was changed between MVP A and MVP B, by doing Z you told Y to use the compatibility version instead of the new one"
Player A
"So how do a fix this?"
The_E/other knowledgeable person who decides to help
/head desk "Reinstall the mod and/or media VPs"
These and untested mods are the main issues I would expect to see hence why I can understand FSU being reluctant to handle it themselves. Untested mods would be a legitimate issue if the mod is not on the list of tested/to be tested
-
The way I see it, the pack would be a drop-in replacement. So, the last point would be "Delete the Compatiblitiy.VP from the folder", a one click action. Also, the installation instructions should be typed very, very clearly, and in a hard to miss way. Maybe it could be even said "Don't use it unless the old mod doesn't work". Some mods have no problems with Mediavps updates, so this pack wouldn't be needed for those. If somebody tries to fix something that isn't broken, he has noone to blame but himself. You don't enable the compatibility mode on Windows because the app you're trying to run is old (granted, you often end up doing that anyway in on newer Windows versions, but you do that only after you find out the app in question doesn't work).
-
problem is that unless you are going to use the "mediaVP" folder name (which might cause confusion) you are then looking at mod.ini edits for all the campaigns that need it
-
What confusion can it cause? Aside from people not deleting the previous version before installing the new one (which they should be warned about in installation instructions), I don't see any problems. It worked from 3.6.7 to 3.6.10 and TBH, I preferred when it was just called Mediavps. Version information could be placed in Mediavps' mod.ini, where it'd be seen upon selecting them in launcher.
-
I don't think you fully appreciate how much of a usability barrier these bullet-point instructions are. They are intimidating, irritating, and they signal to the user that we do not have our **** together from a user experience standpoint.
In an ideal world a mod would require the following steps to install:
Download
Extract to /FreeSpace2/
Select in launcher, hit 'autoupdate' to make sure it's up to date
-
Nope.
In an ideal world, humans wouldn't be morons.
Unfortunately, we have to do with what we have.
-
In an ideal world a mod would require the following steps to install:
Download
Extract to /FreeSpace2/
Select in launcher, hit 'autoupdate' to make sure it's up to date
You're forgetting that we cannot take for granted that a mod will be updated in the first place. Original author may not be inclined to do so because the mod works fine with mediavps version the mod was intended to work with. Or the author is no longer around. The community will likely update the mod eventually if it is important enough to do so, which puts most mods rather low in FSCRP to-do-list.
Can't update if there is nothing to update. Hence we still need fall-back version of mediavps.
-
I'm not arguing that mods would be updated to be MVPs compliant. :confused: I'm saying that Dragon's 'compatibility VP' idea is a bad one if it requires additional install instructions.
I'm not 'forgetting' anything, you're 'forgetting' what I'm talking about.
-
Regardless, Mediavps will be updated. You're free to keep old, redundant junk on your disk, but others might not want it. Nor will new users want to download the old VPs (which will get de-sticked and quickly get lost, and then links will expire) just to play a few campaigns. A compatibility package would be a good solution for 90% of the mods which would require any changes at all. The remaining 10% will not be a big loss, and could be updated if necessary (fixing the old JAD to work with the latest VPs most likely isn't difficult).
Also, Compatibility VP wouldn't be a part of "main" install instructions, but it'd be mentioned in the "troubleshooting" section. If somebody doesn't have trouble, he shouldn't bother with shooting it.
I imagine that it'd be used just like compatibility mode in Windows.
-
Still, a "compatibility package" would be a better idea than keeping an entire set of old VPs, which serve no purpose other than clog up the disk space. Something like the outtakes pack, also containing tables and scripts from the old core. It would disable all new 3.6.14 features, essentially making the new VPs work like the old ones. Just drop it into the old mod folder and the mod should work, benefiting from all the cosmetic improvements that were made for the new VPs.
It could be made a little easier than that. I'm no expert on how mod support works, only what I've read here but I gather a mod can reference a mod that references a mod and so on. With the mediaVPs directory names containing the version numbers it is obviously very easy for each mod to tie itself to what ever version it wants to.
Lets say the latest version of vediaVPs is version 'C' and lives in 'mediavps_C'. The stuff that version C replaced from version B lives in its own folder 'mediavps_B' as if it was the full package but in reality it references version C as it only contains old stuff that was changed in version C... diff mods as you could call it.
A old mod built for version B should act as if it had the full version B package. When mediaVPs version D is released the same process happens to version C and all mods built for version C should continue working as if nothing happened.
There would be two downloads, the latest version with the last version's diff mod and a download containing all the older diff mods. When version E is released all the player would have to do is delete version D, download version E and extract as normal. Everything should work as normal.
The point is that this would maintain a endless and possibly seamless chain of compatibility. No dropping compatibility files in to mod folders, that could generate its own unneeded redundancy if you have multiple mods requiring the compatibility pack and would require no mod.ini editing on the part of the player.
The only down side I can see... possibly longer load times for older mods? I don' know but Id rather wait a few more seconds then waste more GBs on redundant files.
/end ill-informed but well meaning rant here :D
-
The issue is that each iteration of the mediaVPs is 1gb+ so quickly chews up hdd space on older machines
-
So there's more than 1GBs worth of difference between mediaVPs versions? :wtf: I'm rather impressed at that. Show how much work goes into the thing. :D
-
Sorry crossed wires, there is probably a few hundred meg between the textures in 3.6.12 and 3.6.10 but the issue as I understand it is that some want it to include depreciated table and other files which complicates the mod structure some what
-
Why would it make it more complicated? Isn't is just files at the end of the day? Just take the complete old version and the complete new version and delete any file in the old version that is duplicated in the new version. Alter old version's mod.ini to reference new version, package and release.
-
the issues come with loading precedence of files, not to mention MediaVPs tend to rely on tbm files which opens up a can of worms with conflicting table entries.
-
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 issues come with loading precedence of files, not to mention MediaVPs tend to rely on tbm files which opens up a can of worms with conflicting table entries.
Ah I get you now. I can understand how tbms might fudge up the place but I thought the loading precedence was that files earlier in the chain got priority over ones later on. The mod modifies the mod its referencing and so on.
-
Yes but IIRC tbm files do not replace, they append. Right? Or am I mistaken?
I think it would have to be something of a 'backport' (instead of secondarylist) in the mod.ini, basically, if a mod tries to load 3.6.8 MVPs and all that's there are the diff files and a reference to 3.6.10, which is diff files and a reference to 3.6.12, somehow, the engine needs to know not to use that .tbm in 3.6.12 that messes everything up. Or actually, I think perhaps this could be addressed by putting a blank file with the appropriate name.tbm in 3.6.8?
Hmm.... /interesting stuff
-
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.
-
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!
-
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.
-
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?
-
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.
-
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?
-
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.
-
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.
-
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...
-
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.
-
@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.
-
@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.
-
...
That idea is even worse. Seriously guys, have none of you ever spared a thought about ease of maintenance and usability issues?
-
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.
-
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.
-
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)
-
No apologies necessary. It's just that this topic has brought out its share of backseat modders and half-baked ideas.
-
...
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.
-
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.
-
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?
-
Lots of complex plans in this thread from people who will never have to deal with either the implementation or maintenance of them.
-
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.
-
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.
-
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.
-
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!)
-
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
-
You realize you have to use a compiler to compile the code after you grabbed the SVN, right ?
-
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.
-
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.
-
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?)
-
Correct.
-
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.)
-
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.
-
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?
-
Please don't take this personally, I genuinely see where you are coming from but
NO
GOD
NO GOD PLEASE NO
NOOOO
NOOOOOOOO (http://www.youtube.com/watch?v=umDr0mPuyQc)
-
The reason is dependency hell and install instructions and end users changing folder names
-
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.)
-
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.
-
An option would be to torrent the mediavps for future releases.
-
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.
-
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...
-
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.
Hmm... How about password protecting the link to the pr0-only install? ;7 The password being the answer to a question only pr0s on HLP would know? Like for example; "Why do we blame Axem for everything?" or "What is the best way to make The E come to your house and hit you with a base-ball bat?" or better still "Why does the retail Hecate suck?" ;7 :cool:
-
Hmm... How about password protecting the link to the pr0-only install? ;7 The password being the answer to a question only pr0s on HLP would know? Like for example; "Why do we blame Axem for everything?" or "What is the best way to make The E come to your house and hit you with a base-ball bat?" or better still "Why does the retail Hecate suck?" ;7 :cool:
o_0
I just been downgraded to HLP_newb.v_0_1. It seems > 4 years of (very infrequent mind you) reading HPL forums does not give enough insight to answer those :P
"What is the best way to make The E come to your house and hit you with a base-ball bat?"
hmmm... place all vps to root FS2 folder and than come crying to the forums about SCP being #@%$#@% that won't work? ;7
-
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.
Hmm... How about password protecting the link to the pr0-only install? ;7 The password being the answer to a question only pr0s on HLP would know? Like for example; "Why do we blame Axem for everything?" or "What is the best way to make The E come to your house and hit you with a base-ball bat?" or better still "Why does the retail Hecate suck?" ;7 :cool:
For your health, I am going to assume this was more in jest than serious. In any case, it does not solve the root problem (inflated sense of competence). The thing is that by the time you're actually able to do a manual install, you should have the know-how to see why manual installs are a bad idea.
-
The thing is that by the time you're actually able to do a manual install, you should have the know-how to see why manual installs are a bad idea.
True enough.
On that topic, is the online installer project updated? Because the frontpage still lives in 3.6.10 era my work includes Java programming, and if installer is outdated, perhaps i could do something useful for the community?
-
If you want to help, the person to contact is Goober5000. I'm sure he could use a talented hand.