3
<title>cube » Distributing Maps</title>
4
<link rel="stylesheet" href="../style.css" type="text/css" />
5
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
8
<div class="wiki" id="content_view" style="display: block;">
9
If you have created a script, map, or some other form of media for Sauerbraten, chances are you will want to distribute it on the internet. However, there are certain standards and procedures that you will need to follow in order for your creation to reach its audience.<br />
12
<h2 id="toc0">Quick-Info</h2>
14
Place your own content only into a ZIP-file so it can be extracted directly into the base game-folder.<br />
15
./ : base game folder :<br />
17
1. README_appropriate_name_here.txt [or .html]<br />
19
./packages/base/ : base package folder :<br />
21
1. a_single_map.ogz<br />
22
2. a_single_map.cfg<br />
23
3. (optional) a_single_map.jpg - this should be 256x256 - which will be displayed in the GUI menu, assuming it's made menu selectable by the user or some of your own scripting<br />
25
./packages/my_package_folder/ : personal package folder :<br />
27
1. mappak_map1.ogz..mappak_mapN.ogz<br />
28
2. map/pak/misc CFG files<br />
29
3. texture image files<br />
30
4. skybox-folder with appropriate images<br />
34
<h2 id="toc1">Creating a ZIP</h2>
36
You should always package your content into a ZIP file. Don't use your favourite file compressor! ZIP is the most popular file compression and packing filetype, and is easily compressed on all target platforms. Even with popularity aside, ZIP often gives better compression on the already well compressed data used with Sauerbraten. Maps, for example, are already saved with ZIP compression, therefore other packers (eg RAR) will go to lengths to try compress the files even further, often resulting in overhead (making the file larger than the ZIP).<br />
38
You could ask "why ZIP a map at all?" But the beauty of packing your files up like this is that you can include a readme with your file(s). Including a readme is seen as good practice, and allows you to include licensing information (Creative Commons etc), contact information, detailed map description/information and maybe even something about yourself.<br />
40
Therefore, a minimalistic distribution file would be a ZIP containing a OGZ map file, a CFG map config and a README_mapname.txt. Of course, remember to make sure that the OGZ and CFG are in a subfolder structure so unzipping into the user's Sauerbraten folder will put them into "packages/base/". Placing your README in this folder is a bad idea as the base folder is cluttered as it is. It is far more logical to place it in the main Sauerbraten directory, keeping the base folder as manageable as possible. Putting the README into the packages directory is a good option as well, but consistency is also critical. More importantly however, always package what is required, not everything used (ie repackaging core Sauerbraten textures used in your map is a bad idea).<br />
42
See FAQ #1 below for information on using your own packages subfolder which can help to keep directories clean. This negates the usage of getmap/sendmap, folders cannot be created remotely this way!<br />
46
<h2 id="toc2">Create a README</h2>
48
Many people make the mistake of calling their READMEs README.txt. This results in people overwriting other people's READMEs, and the whole thing gets confusing fast. Therefore, an easy solution is to call it README_mapname.txt, where mapname should be replaced with an identifying name.<br />
50
<h3 id="toc3">Information your README should include:</h3>
52
- Your identification<br />
53
Self explanatory but it's up to you if you want to include your real life information or just your pseudonym in the Sauerbraten community (or both).<br />
55
- Description of content<br />
56
A title or short sentence giving (at least an indication) of what to expect. If your release is "beta" (ie not final) you should say so here!<br />
59
Often forgotten and always sorely missed, the date can give an indication as to which release of Sauerbraten was the design target, saving users troubleshooting time. For example even some maps in the 2006-04-26 release gave "old map format" errors, and things like this can happen in the future.<br />
61
<h3 id="toc4">Optional information your README could include:</h3>
63
- Background information<br />
64
Tell the story behind the map, talk about the usage of the script, give location of further documentation and/or explain your intentions/reasoning if required for your package.<br />
67
You should note everybody and anybody who has in some way contributed to your package enough to earn a mention here. Include the source of any packages you used (include a URL) and of course don't forget all those that gave you critique on the way to finishing your package.<br />
70
A list of any issues or caveats users may encounter that you are aware of (for example platform independencies).<br />
72
- Contact information<br />
73
Methods to contact you will make it possible for feedback and bug information to reach you, however this might also lead to more spam reaching your inbox.<br />
77
<h2 id="toc5">Frequently Asked Questions</h2>
79
<h3 id="toc6">1. What goes into the ZIP and what does not?</h3>
81
Your ZIP should include a subdirectory structure so it can be unpacked into the main Sauerbraten directory. A simple checklist would be:<br />
83
- Map file (OGZ) in "packages/base/file.ogz" inside the ZIP<br />
84
- Map config file (CFG) in "packages<br />
85
- Your package data in "packages/mydata/" (mydata usually being your pseudonym within the Sauerbraten community)<br />
86
- Scripts can be placed inside the main Sauerbraten directory, the data folder or your package folder.<br />
88
Using third-party package data (like a skybox from Quadropolis) should only be included if:<br />
90
a) You have permission from the original author<br />
91
b) You really need to be independent from possible changes on the original data<br />
93
If a) and b) apply, create a folder in "/packages" for holding your package data but be sure to adapt all paths (in your CFG's) to this new folder.<br />
95
If you don't have the author's permission, the best way to do it is to provide a download link to the required third-party package. Creating two versions of your package is also a viable solution, one including the whole data set (requires author's permission) and another with just the additions you have created.<br />
97
In some cases, you will not need the author's permission, depending on the license they have included with their package, however if you do use their package, send them an email to let them know anyway. This can be useful in situations where the author is no longer active in the Sauerbraten community and is hard to get in touch with.<br />
100
<h3 id="toc7">2. How do I get my package into the next release of Sauerbraten?</h3>
102
If your work is of a high standard and useful in the development of Sauerbraten, it will. SHOUTING AT THE DEVELOPERS IN CAPS LOCK CAN MAKE YOU SEEM IMMATURE and repeated requests will make you somewhat of an annoyance, reducing your chances of ever getting something into Sauerbraten, therefore maturity is also extremely important.<br />
105
<h3 id="toc8">3. How can I ensure everybody will enjoy my work?</h3>
107
Well, actually you can't, but that's just aesthetics for you! More seriously though, there are some known issues with platform dependencies with Sauerbraten. Safest bet is to package all data in (preferably) PNG for images, OGG for music and WAV for sounds.<br />
109
Also ensure that all filenames are lower-case! Some operating systems are case sensitive, meaning that Texture.JPG is different to texture.jpg, causing all sorts of problems with your package. This applies to all files included with the package. Don't forget to make sure that your map does not begin with a capital letter so that TAB completion works!<br />
111
Windows, by default, doesn't show file extensions. This can cause problems with other operating systems (as mentioned above). You can fix this by following these instructions:<br />
115
<li>Open Windows Explorer/My Computer</li>
116
<li>Click on the Tools menu</li>
117
<li>Select Folder Options</li>
118
<li>Click on the View tab</li>
119
<li>Untick "Hide extensions for known file types"</li>
124
Don't forget to rename all your package files with lowercase letters (including the extension) after changing the setting!<br />
128
<h2 id="toc9">Common Mistakes</h2>
130
Many people make the same mistakes when packaging their files, over and over again. To prevent this happening to you, make sure you don't make any of the same mistakes here:<br />
132
<h3 id="toc10">- Including garbage with your package</h3>
133
Other than including content already distributed with Sauerbraten, many users include rubbish such as thumbs.db (created by Windows when Thumbnail view is used) and CVS folders. Windows users in particular should make sure hidden and system files are set to visible so this doesn't happen (thumbs.db is invisible otherwise).<br />
135
<h3 id="toc11">- Giving maps extremely common names/existing names</h3>
136
There are probably more than ten maps titled 'castle' on Quadropolis (for example), and this becomes a problem when they start overwriting each other. Also, don't name your new map 'metl4'.<br />
138
<h3 id="toc12">- Copyright violations</h3>
139
Including other user's content without permission is wrong (unless of course they provide it under a license which allows that). Expanding on this, modifying existing maps and then republishing them on Quadropolis is also a copyright violation, unless you have the author's permission (highly unlikely).
b'\\ No newline at end of file'
added
removed
docs/static_wiki/Distributing Maps.html
