Is there a standard for where to "root" the ZIP archive of a mod download?

[John FX]

This is precisely why we don't have a standard. You live in a world where you simply dump the contents of a package into the game folder, hoping for the best while trusting that the mod author didn't make a mistake, and then deleting the package. I live in a world where the user opens the package, inspects the contents, and then pulls out what is needed, only deleting the package (and the supporting files) once the mod is running properly.

Myself I live in the same world but I would prefer to live in the world where the contents of the mod install zip could be extracted into KSP root (by having `gamedata` in the zip root) and all would be fine and the source would be in a separate zip for those that want it which avoids crufting (I like this word, not rude but you know what I mean) up the KSP installation with source files.

I have all my packages in a `ksp downloads` folder but as a user I have no need for any source. Then people that want the source can store it where they like and the ones that just want the mod just get the mod.

[pizzaoverhead]

My personal packaging standard:

• ModNameModVersion.zip
  
  • GameData
    
    • ModName
      
      • Plugins
        
      • Source
        
      • settings.cfg

    [*] OtherFolders

    [*] Readme - ModName.txt

My reasoning:

• Having GameData up front gives a clue that this is the directory structure that you should try to match in your install. Occasionally files need to go places other than GameData; this also makes that clearer.

• The readme and the mod files are the only two files visible on opening the package. If you don't get the GameData clue, the readme has full instructions. The readme contains the mod name to prevent clobbering the KSP readme, and to allow identifying it for reference in future. Digging through readme(1) to readme(5) to find what is the correct keyboard shortcut is not fun.

• The readme includes the licence, release date, KSP version compatibility and a link to the forum thread clearly visible in the header. You shouldn't have to hunt for these things. Version history is at the end of the file, out of the way of people who just want to know how to get things done.

• The source is included. There is nothing worse than a dead but appropriately licensed mod that needs a single fix after a new release, but only exists in its packaged form, without source. Based on the conversation above, it seems more appropriate to move the sources from GameData to root/Sources/ModName/source.cs to improve loading. The ModName sub-folder allows inter-mod compatibility without confusion or collision (Utilities.cs anyone?). In that case, the layout would be:

• ModNameModVersion.zip
  
  • GameData
    
    • ModName
      
      • Plugins
        
      • settings.cfg

    [*] OtherFolders

    [*] Sources

    • ModName
      
      • sources.cs

    [*] Readme - ModName.txt

Edited April 17, 2014 by pizzaoverhead

[Undeadbanana]

I think I live in the same world as Regex.... I have never just unzipped files onto my computer. I always open the zip file and pull out what I need.

In the case of organizing Kerbal mods, I keep the zip files so that if I need the readme files, I can just go look at them without having to clutter up my KSP Folders.

[HeadHunter67]

This is precisely why we don't have a standard. You live in a world where you simply dump the contents of a package into the game folder, hoping for the best while trusting that the mod author didn't make a mistake, and then deleting the package. I live in a world where the user opens the package, inspects the contents, and then pulls out what is needed, only deleting the package (and the supporting files) once the mod is running properly.

I live in the same world - but in five years of taking calls for Microsoft, I came to learn that the average end-user is a dolt that does not read, does not exercise common sense, and in many cases, shouldn't be operating electric appliances. So that safe recourse is to try and make software as idiot-proof as possible. That is almost never detrimental to the tech-savvy users, but it saves a lot of needless questions and support requests from people who aren't as experienced or sensible.

[Dunbaratu]

This is precisely why we don't have a standard. You live in a world where you simply dump the contents of a package into the game folder, hoping for the best while trusting that the mod author didn't make a mistake, and then deleting the package. I live in a world where the user opens the package, inspects the contents, and then pulls out what is needed, only deleting the package (and the supporting files) once the mod is running properly.

Why are you choosing to deliberately design a fragile packaging scheme that mandates such caution when it's completely unnecessary if done right? Done properly, you make an archive which never extracts files directly into the directory it is being run from, and always makes subdirectories instead. Maybe I'm spoiled coming from the UNIX world where Tar.gz and bzip packages are almost never, ever, designed to put files directly into the current directory, and while possible its considered very poor form to design them that way.

Edited April 18, 2014 by Steven Mading

[Justin Kerbice]

Why are you choosing to deliberately design a fragile packaging scheme that mandates such caution when it's completely unnecessary if done right? Done properly, you make an archive which never extracts files directly into the directory it is being run from, and always makes subdirectories instead. Maybe I'm spoiled coming from the UNIX world where Tar.gz and bzip packages are almost never, ever, designed to put files directly into the current directory, and while possible its considered very poor form to design them that way.

This is quite irrelevant as archivers allow users to "extract here" or "extract into directory something" so someone who want trouble will surely get them, and nothing can be done against that, even Microsoft tried a lot to make idiot-proof software resulting of dumb-software who "think" they're smarter than you and fail miserably at the end of the day.

One intermediate level could be defined by making package kind of thing like Debian ones (or more generally speaking Linux and co), users can only install binary package unless they know what they're doing, and here it's really up to the packager to make it's job properly.

As long as KSP will be as it is: open and not hidden (which is a great thing), people will always be able to mess up with it.

[Guest]

Maybe I'm spoiled coming from the UNIX world

mkdir KAS && unzip -d KAS uploads-2014-04-KAS_v0.4.7.zip

Which I'm sure you've done, right? Have you made a shell script for it yet? If you exclusively use Spaceport mods you could even have the script get the mod name and version from the filename, and automatically create a directory.

The difference in opinion and design comes from using visual tools over command line tools and, since I play KSP on a Windows box, I'm naturally going to prefer double-clicking the package, looking at the contents, and then dragging what I need to the destination. You can do the same thing on Kubuntu or Slack, for instance, using Dolphin + Ark, or whatever other combination of file manager + archive manager you prefer, but command line users are going to be a minority.

Any mod packaging scheme is naturally going to favor the vast, unwashed, uneducated masses of Windows users who need "subtle" cues indicating how something should be installed. I'll stress again that the mod community here will probably never arrive at a standard because there are very good points on all sides of this issue and hobbyists are wont to do things their own way.

[Superfluous J]

If the game enforced a standard, there'd be a standard.

Getting mod authors to enforce their own is impossibe. It's not so much herding cats as trying to get them to perform Shakespeare.

[Dunbaratu]

This is quite irrelevant as archivers allow users to "extract here" or "extract into directory something" so someone who want trouble will surely get them, and nothing can be done against that, even Microsoft tried a lot to make idiot-proof software resulting of dumb-software who "think" they're smarter than you and fail miserably at the end of the day.

One intermediate level could be defined by making package kind of thing like Debian ones (or more generally speaking Linux and co), users can only install binary package unless they know what they're doing, and here it's really up to the packager to make it's job properly.

As long as KSP will be as it is: open and not hidden (which is a great thing), people will always be able to mess up with it.

You're really not seeing what I'm referring to. If it's packaged well, then when you install it into somewhere, no matter where you install it to, the only thing you get IN the location you installed it is a directory. Everything else is under that.

[Dunbaratu]

mkdir KAS && unzip -d KAS uploads-2014-04-KAS_v0.4.7.zip

Which I'm sure you've done, right? Have you made a shell script for it yet? If you exclusively use Spaceport mods you could even have the script get the mod name and version from the filename, and automatically create a directory.

The difference in opinion and design comes from using visual tools over command line tools and, since I play KSP on a Windows box, I'm naturally going to prefer double-clicking the package, looking at the contents, and then dragging what I need to the destination. You can do the same thing on Kubuntu or Slack, for instance, using Dolphin + Ark, or whatever other combination of file manager + archive manager you prefer, but command line users are going to be a minority.

Any mod packaging scheme is naturally going to favor the vast, unwashed, uneducated masses of Windows users who need "subtle" cues indicating how something should be installed. I'll stress again that the mod community here will probably never arrive at a standard because there are very good points on all sides of this issue and hobbyists are wont to do things their own way.

The claim that what I was talking about has anything to do with command-line usage versus GUI usage is false. The rest of what you said is based on your decision to adhere to this strawman.