Duck and Cover

I did some tests on speed with mutliple paths and it doesn't slow down the performance that much. That said, it still does slow it down, and a lot of people are alrady complaining how the game is slow, so I really don't see us establishing a standard which would inherently slow the game down by it's concept. Additionally, the engine looks for the files in a default directory (entities for entities, sprites for sprites and so on), so using the nick/reserved string as the previous propesed standard simply wouldn't work.

<FOT_root>/core/sprites/<YourReservedDirName>/<whateverFloatsYourBoat>

Now for the certification:
- Even simple zip files containing just a new sprite will need to be certified. To be MOFO certified, you'll simply need to include the full directory structure starting from the FO:T root (I've chosen the FO:T root as a starting place instead of core as it will confuse less the end users).

So if you have a new tile you made, say "YellowBrickStonePath.til", and you reserved the dir "AliceInWonderland" directory then you should find your path within the zip to be core/tiles/AliceInWonderland/<YouCanAddMoreDirsHereIfYouLike/>YellowBrickStonePath.til

Additionally, readmes should be SEPERATE for EVERY file you wish to comment (core/tiles/AliceInWonderland/tiles/<YouCanAddMoreDirsHereIfYouLike/>YellowBrickStonePath.txt).

Why? because I'd like to avoid two problems. First, two MOFO certified authors' readmes overwriting eachother, and second, your OWN readmes overwriting eachother.

Now you might ask, since we include your own folder for each why don't we just put a big readme there? Well, there's the reason posted above, so it doesn't overwrite, but additionally, there'll be several folders you need to create on your own (tiles, sprites, entities, and possibly others...) and then you'd need to include several instead. And all these risk being overwritten...

Versioning: If you update a tile, generally speaking, don't. If someone decides to include their your old tile in their project, then a user downloads your new tile, install the mod that uses the old one, and then he's left with the old tile instead of the new. So avoid at all costs, and simply make a new tile from the original one (and stop distributing the old tile if you don't feel like it).

Copyrights/Terms of use: If you use the MOFO certification, it's because you PLAN ON OTHER PEOPLE USING YOUR TILES... So noone should reserve any special terms of use on files certified with this, apart from a VERY important one: if you use any tiles (well, other then your own), you may not use it for your own profit. Well, someone should look into a better way to formulate that

Adcditionally, if this goes well, I'll add "MOFO Certification support" to my viewer, and if a file is in a proper MOFO directory, it will look for the .txt file equivalent of the file and display it in a textbox (so you could include a copyright notice there - I probably won't make it editable since it's easy to edit on your own and you won't want people viewing the tiles to modify it with just a click anyway).

Using other people's MOFO files: Well, I'll have to come up with a proper legal citation for this, but basically if you use anyone else's tile, you'll need to credit them where appropriate (at least in a readme.txt...)

[edit] updated this post to respect scond post in thread

BIG CHANGE:
Since adding the MOFO directory all over the place simply adds and extra directory almost uselessly, the MOFO directory is simply taken out. What this means is simply that no reseved names can match any of the subdirectories in any of code. This of doesn't invalidate the original standard, but switching between the two isn't recommented, and using this one over the last will make it less convulated and is thus recommended.

The prefix rules (for <tt>gui/char</tt> and possibly custom music).
Since using the -paht option simply to add new character pictures to the game would be simply overwhelming, instead we'll use a simple naming scheme:
<tt>[reserved_name]_[whatever].zar</tt>
Say you wanted to make a custom pic for the entity Sebastien, and your MOFO reserved nick is Red!, then in the zip file the end result would be <tt>core/gui/char/Red!_Sebastien.zar</tt>

Readmes
You should place readmes appropriate to specific files next to the file. Say you have a comment on a mission, it should be next to the mission, with the same name as the mission, but with a .txt extention (or doc of you happen to like Word, though I don't recommend making readmes in other formats then txt).
so if you have a mission called "Kickass.mis" and made a readme JUST FOR THE MISSION (not the entire mod), in the zip you'll have <tt>core/missions/Red!/Kickass.txt</tt>

Central directory
Since it's useful to put readmes and whatnot in your own directories, with your own names and possibly extra related files, a directory under the FO:T root will be directly under your control, named <tt>[fot_root]/MOFO/[reserved_name]</tt> (Note that this is the only MOFO directory left in the standard). There, you should pout the central readme for your mod. Note that YOU are responsible for files not to overlap, so if you make a new mod called AliceInWonderLand, your readme would ideally be in the zip:
<tt>MOFO/Red!/AliceInWoderLand.txt</tt>
Though the name of the files needn't necessarely match the mod name, it's intuitive to do so, and it does need to be unique to your mods so two mods don't overwrite the same readmes...

Replacing file mod directories
Since some mods will replace files and thus require a -path option, we'll need to reserve these paths too, but this time one for each of your mods that requires a path. This means that you'll need to reserve any directory that uses the -path option EXCEPT the one already reserved by your reserved directory. This also means that you won't be able to reserve someone else's directory under that premise