<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.uqm.stack.nl/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mcmartin</id>
	<title>Ultronomicon - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.uqm.stack.nl/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mcmartin"/>
	<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/Special:Contributions/Mcmartin"/>
	<updated>2026-08-11T00:08:18Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.6</generator>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22723</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22723"/>
		<updated>2009-02-16T00:49:00Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. Migrate all 3DO content into standalone addon packs. &#039;&#039;Completed in Revision 3104.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated. &#039;&#039;Completed in Revision 3105.&#039;&#039;&lt;br /&gt;
* Allow saves to strip some or all of the common prefix to save only the &amp;quot;submap&amp;quot; component. &#039;&#039;Completed in Revision 3105.&#039;&#039;&lt;br /&gt;
* Merge user settings and key configuration into the main resource map, eliminating the now-redundant mapres.c routines.  &#039;&#039;Completed in Revision 3108.&#039;&#039;&lt;br /&gt;
* Turn melee data (teams, current situation) into resource maps like the other two.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22576</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22576"/>
		<updated>2009-01-04T06:35:01Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. Migrate all 3DO content into standalone addon packs. &#039;&#039;Completed in Revision 3104.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated. &#039;&#039;Completed in Revision 3105.&#039;&#039;&lt;br /&gt;
* Allow saves to strip some or all of the common prefix to save only the &amp;quot;submap&amp;quot; component. &#039;&#039;Completed in Revision 3105.&#039;&#039;&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Right now, user and key data use mapres.c to handle all this. Those routines should be folded into getres.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22475</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22475"/>
		<updated>2008-12-08T01:25:42Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. Migrate all 3DO content into standalone addon packs. &#039;&#039;Completed in Revision 3104.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
* Allow saves to strip some or all of the common prefix to save only the &amp;quot;submap&amp;quot; component.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Right now, user and key data use mapres.c to handle all this. Those routines should be folded into getres.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22466</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22466"/>
		<updated>2008-11-29T06:36:11Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current Development Status */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. Migrate all 3DO content into standalone addon packs. &#039;&#039;Completed in Revision 3104.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately using the material in mapres.c. The mapres routines will eventually all fold into getres.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22465</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22465"/>
		<updated>2008-11-29T03:45:12Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress, but only refactoring, cleanup, and testing remains.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* It needs to be possible for resources to be polymorphic; that is, some resource keys may be one of several types. It needs to be possible to react to this appropriately. The simplest solution is to be able to interrogate a resource&#039;s type before actually loading it. &#039;&#039;Completed in Revision 3099.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
** Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  Replace it with an integer resource that is that index. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** INT32 integral value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** STRING value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** BOOLEAN value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps. &#039;&#039;Completed in Revision 2978.&#039;&#039;&lt;br /&gt;
** Value types for the 3DO videos. &#039;&#039;Completed in Revision 3101.&#039;&#039;&lt;br /&gt;
*** Rewrite the presentation code to more uniformly handle 3DO videos vs. String-based presentations. &#039;&#039;Completed in Revision 3101.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately using the material in mapres.c. The mapres routines will eventually all fold into getres.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22447</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22447"/>
		<updated>2008-11-23T22:33:47Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* It needs to be possible for resources to be polymorphic; that is, some resource keys may be one of several types. It needs to be possible to react to this appropriately. The simplest solution is to be able to interrogate a resource&#039;s type before actually loading it.&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
** Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  Replace it with an integer resource that is that index. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** INT32 integral value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** STRING value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** BOOLEAN value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps. &#039;&#039;Completed in Revision 2978.&#039;&#039;&lt;br /&gt;
** Value types for the 3DO videos.&lt;br /&gt;
*** Rewrite the presentation code to more uniformly handle 3DO videos vs. String-based presentations.&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately using the material in mapres.c. The mapres routines will eventually all fold into getres.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22080</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22080"/>
		<updated>2008-06-25T02:03:57Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current Development Status */ Some updates of what needs to be done and what no longer needs it.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
** Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  Replace it with an integer resource that is that index. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** INT32 integral value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** STRING value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** BOOLEAN value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps. &#039;&#039;Completed in Revision 2978.&#039;&#039;&lt;br /&gt;
** Value types for the 3DO videos.&lt;br /&gt;
*** Rewrite the presentation code to more uniformly handle 3DO videos vs. String-based presentations.&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately using the material in mapres.c. The mapres routines will eventually all fold into getres.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
**At the moment we just load all .rmp files in any given directory. This may be good enough.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22025</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22025"/>
		<updated>2008-05-18T14:02:33Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
** Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  Replace it with an integer resource that is that index. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. &#039;&#039;Completed in Revision 2971.&#039;&#039;&lt;br /&gt;
** INT32 integral value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** STRING value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** BOOLEAN value type. &#039;&#039;Completed in Revision 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps. &#039;&#039;Completed in Revision 2978.&#039;&#039;&lt;br /&gt;
** Value types for the 3DO videos.&lt;br /&gt;
&lt;br /&gt;
It&#039;s now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a &#039;&#039;little&#039;&#039; to gather interest.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately using the material in mapres.c. The mapres routines will eventually all fold into getres.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in Revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22014</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22014"/>
		<updated>2008-05-15T03:18:35Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
** Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  Replace it with an integer resource that is that index. &#039;&#039;Completed in version 2971.&#039;&#039;&lt;br /&gt;
** Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. &#039;&#039;Completed in version 2971.&#039;&#039;&lt;br /&gt;
** INT32 integral value type. &#039;&#039;Completed in version 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** STRING value type. &#039;&#039;Completed in version 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** BOOLEAN value type. &#039;&#039;Completed in version 2973&#039;&#039;, but will remain unused until configuration is merged or hardcoded data is removed.&lt;br /&gt;
** CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps.&lt;br /&gt;
** Value types for the 3DO videos.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately using the material in mapres.c. The mapres routines will eventually all fold into getres.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22012</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22012"/>
		<updated>2008-05-14T06:12:52Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
** Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  Replace it with an integer resource that is that index. &#039;&#039;Completed in version 2971.&#039;&#039;&lt;br /&gt;
** Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. &#039;&#039;Completed in version 2971.&#039;&#039;&lt;br /&gt;
** INT32 integral value type.&lt;br /&gt;
** STRING value type.&lt;br /&gt;
** BOOLEAN value type.&lt;br /&gt;
** CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps.&lt;br /&gt;
** PRESENTATION value type.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately because we can&#039;t keep value types in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22011</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22011"/>
		<updated>2008-05-14T03:50:55Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step.&lt;br /&gt;
** We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
** We should support value-type resources like INT32 that don&#039;t refer to files at all. &#039;&#039;Completed in version 2970.&#039;&#039;&lt;br /&gt;
*** ...which would let us retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  This would be replaced with an integer resource.&lt;br /&gt;
*** This also lets us treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately because we can&#039;t keep value types in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22001</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22001"/>
		<updated>2008-05-11T03:31:06Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well. &#039;&#039;Completed in Revision 2969.&#039;&#039;&lt;br /&gt;
* The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step.&lt;br /&gt;
** We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
** We should support value-type resources like INT32 that don&#039;t refer to files at all.&lt;br /&gt;
*** ...which would let us retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  This would be replaced with an integer resource.&lt;br /&gt;
*** This also lets us treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately because we can&#039;t keep value types in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22000</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=22000"/>
		<updated>2008-05-10T22:02:40Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well.&lt;br /&gt;
* The resouce vtable should not automatically assume its value is a file, but should instead have a separate parse step.&lt;br /&gt;
** We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
** We should support value-type resources like INT32 that don&#039;t refer to files at all.&lt;br /&gt;
*** ...which would let us retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  This would be replaced with an integer resource.&lt;br /&gt;
*** This also lets us treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately because we can&#039;t keep value types in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated.&lt;br /&gt;
** This will change the user configuration format; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
** Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*Online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21998</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21998"/>
		<updated>2008-05-08T07:33:31Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Typo fixes, some progress marked, redundant entry removed&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before: see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implementing a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resources. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. &#039;&#039;Completed in Revision 2968.&#039;&#039;&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well.&lt;br /&gt;
* The resouce vtable should not automatically assume its value is a file, but should instead have a separate parse step.&lt;br /&gt;
** We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
** We should support value-type resources like INT32 that don&#039;t refer to files at all.&lt;br /&gt;
*** ...which would let us retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  This would be replaced with an integer resource.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately because we can&#039;t keep value types in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated. This will break user configurations; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21996</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21996"/>
		<updated>2008-05-08T00:19:54Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Total rewrite of the roadmap&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in Revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Replace the integer-based resource system with string-based key mappings that are easier to extend. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
# Rework resource types to allow for a wider range of resource. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. &#039;&#039;In progress, but largely blocked on the previous step.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The ResMap resource system has broken the &amp;quot;resource = specific file&amp;quot; assumption, but it still assumes that resources are at some level individual files. Our current goal is to break this assumption, allowing us to remove a number of ugly hacks in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index. &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
* Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably.&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well.&lt;br /&gt;
* The resouce vtable should not automatically assume its value is a file, but should instead have a separate parse step.&lt;br /&gt;
** We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
** We should support value-type resources like INT32 that don&#039;t refer to files at all.&lt;br /&gt;
*** ...which would let us retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  This would be replaced with an integer resource.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
There is also the matter of unifying other configuration data into the resource map. At the moment, these are kept separately because we can&#039;t keep value types in the resource map.&lt;br /&gt;
&lt;br /&gt;
* Keep user settings in a resource-map. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
* Keep key configuration in a resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
* Keep Melee configuration in a resource-map.&lt;br /&gt;
* Allow loads of resource files to be placed into isolated submaps to keep values separated. This will break user configurations; to minimize disruption this should be deployed at the same time as the unification of user settings with the main resource map, below.&lt;br /&gt;
* Merge all three into the main resource map.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21882</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21882"/>
		<updated>2008-04-10T03:52:58Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Keep user settings in the resource-map system. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Unify key configuration into the resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
# Unify Melee configuration into the resource-map.&lt;br /&gt;
# Unify file-loading with the resource-map system. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one.  &#039;&#039;Previous steps require partial progress, but not currently an explicit target.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Instead of pointing from resource numbers to files, point them to string IDs that the resource map will forward to files. &#039;&#039;Completed in Revision 2868.&#039;&#039;&lt;br /&gt;
*Have addon packs modify the resource map, not the underlying file system. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*Efficiency concerns indicate resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct. &#039;&#039;Completed in Revision 2918.&#039;&#039;&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. &#039;&#039;Completed in Revision 2963.&#039;&#039;&lt;br /&gt;
*Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index (starcon.ls2). &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
* Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
* Uniform reference between file-type and value-type resources.&lt;br /&gt;
* Merging the various configuration files into a single map to be referenced directly.&lt;br /&gt;
* Retire the CODE type, which isn&#039;t code at all, but is actually a one-byte file that indexes procedurally into a structure array.  This can be replaced with a ship_id integer resource.&lt;br /&gt;
* The current resource vtable implementation is pretty ugly.  We can probably fold &#039;&#039;it&#039;&#039; into the master map as well.&lt;br /&gt;
&lt;br /&gt;
Once these are done, it will be feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files.  It&#039;s not clear this is wise for 0.7.0 itself; time will tell.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21868</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21868"/>
		<updated>2008-04-06T01:02:11Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Keep user settings in the resource-map system. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Unify key configuration into the resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
# Unify Melee configuration into the resource-map.&lt;br /&gt;
# Unify file-loading with the resource-map system. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one.  &#039;&#039;Previous steps require partial progress, but not currently an explicit target.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Instead of pointing from resource numbers to files, point them to string IDs that the resource map will forward to files. &#039;&#039;Completed in Revision 2868.&#039;&#039;&lt;br /&gt;
*Have addon packs modify the resource map, not the underlying file system. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*Efficiency concerns indicate resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct. &#039;&#039;Completed in Revision 2918.&#039;&#039;&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. A lot of things have to change all at once to do this:&lt;br /&gt;
**RESOURCE changes from DWORD to const char *.&lt;br /&gt;
**Calls to MAKE_RESOURCE need to be modified to work with string resources.&lt;br /&gt;
*Retire the RES_INDEX type, merging all resource number -&amp;gt; resource name data into a single index (starcon.ls2). &#039;&#039;Completed in Revision 2958.&#039;&#039;&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
* Uniform APIs require uniform reference.  This is actually part of a different step, but part of it turned out to be necessary for sensibly dropping the indices.&lt;br /&gt;
** Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
** Uniform reference between file-type and value-type resources.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=User:Mcmartin&amp;diff=21368</id>
		<title>User:Mcmartin</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=User:Mcmartin&amp;diff=21368"/>
		<updated>2008-02-06T10:13:34Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Minimal user page.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Michael Martin is one of the core developers in the project.&lt;br /&gt;
&lt;br /&gt;
Most recently he has been working on [[Content Management in 0.7.0]].&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21367</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21367"/>
		<updated>2008-02-06T10:11:28Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Current goals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Keep user settings in the resource-map system. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Unify key configuration into the resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
# Unify Melee configuration into the resource-map.&lt;br /&gt;
# Unify file-loading with the resource-map system. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one.  &#039;&#039;Previous steps require partial progress, but not currently an explicit target.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Instead of pointing from resource numbers to files, point them to string IDs that the resource map will forward to files. &#039;&#039;Completed in Revision 2868.&#039;&#039;&lt;br /&gt;
*Have addon packs modify the resource map, not the underlying file system. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*Efficiency concerns indicate resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct. &#039;&#039;Completed in Revision 2918.&#039;&#039;&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. A lot of things have to change all at once to do this:&lt;br /&gt;
**RESOURCE changes from DWORD to const char *.&lt;br /&gt;
**Calls to MAKE_RESOURCE need to be modified to work with string resources.&lt;br /&gt;
*It really looks like the RES_INDEX type can actually be safely retired -- there is exactly one point in the entire codebase where the same resource number is intended for use in multiple indices, and it&#039;s part of the blank CODE resource.&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
* Uniform APIs require uniform reference.  This is actually part of a different step, but part of it turned out to be necessary for sensibly dropping the indices.&lt;br /&gt;
** Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
** Uniform reference between file-type and value-type resources.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management_before_0.7.0&amp;diff=21307</id>
		<title>Content Management before 0.7.0</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management_before_0.7.0&amp;diff=21307"/>
		<updated>2008-02-04T01:33:24Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Added &amp;#039;safe&amp;#039; template.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;:&#039;&#039;Note: the information contained in this page pertains to the [[The Ur-Quan Masters]] versions 0.3 through 0.6.0. The content system is currently under revision: See [[Content Management in 0.7.0]] for details.&lt;br /&gt;
&lt;br /&gt;
{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game uses a virtual file system to access the content. Directories from various locations are combined (&amp;quot;mounted&amp;quot;) to form one big file system, where files from a mounted directory are hidden if files with the same name exist on a directory mounted &amp;quot;on top&amp;quot; of it.&lt;br /&gt;
A directory to be mounted may exist as an actual directory on the operating system&#039;s file system, or as a directory within a .zip or .uqm file. An .uqm file is internally a .zip file but with another name given, so that people won&#039;t accidentally unpack them.&lt;br /&gt;
&lt;br /&gt;
If a file exists in a directory which is mounted read-only, but not in a directory mounted read-write on top of it, then writing to the file will produce a copy in the latter directory.&lt;br /&gt;
&lt;br /&gt;
Whether file name matching is case-sensitive or not depends on the file system of each layer. Files in .zip files are always matched case-sensitively, while files outside of .zip files are matched as normal for the operating system UQM is run on.&lt;br /&gt;
&lt;br /&gt;
==Content directories==&lt;br /&gt;
The following list shows which directories are mounted in the game. The later mentioned ones are mounted on top of the earlier mentioned ones.&lt;br /&gt;
{|border=1&lt;br /&gt;
!Directory!!Mounted on!!flags&lt;br /&gt;
|-&lt;br /&gt;
|[[#Default packages|default packages]], in alphabetic order||/   ||read-only&lt;br /&gt;
|-&lt;br /&gt;
|[[#Add-on packages|add-on packages]], in alphabetic order  ||/   ||read-only&lt;br /&gt;
|-&lt;br /&gt;
|[[#Content base directory|content base directory]]         ||/   ||read-only&lt;br /&gt;
|-&lt;br /&gt;
|[[#User data directory|user data directory]]               ||/   ||read-write&lt;br /&gt;
|-&lt;br /&gt;
|[[#Temporary directory|temporary directory]]               ||/tmp||read-write&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
You can see from this table that unzipped files always override zipped files. This means that using add-on packages to override a zipped base content won&#039;t work. This is one of the issues that will be addressed in a next release.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
===Content base directory===&lt;br /&gt;
This is the base directory where the content files are stored.&lt;br /&gt;
It needs to contain a file named &amp;lt;code&amp;gt;version&amp;lt;/code&amp;gt; with the UQM version number to be accepted by the game.&lt;br /&gt;
In it, you&#039;ll usually find a directory &amp;lt;code&amp;gt;packages&amp;lt;/code&amp;gt;, which contains the default packages, and indirectly the add-on packages (optionally). The add-on packages are kept in a directory &amp;lt;code&amp;gt;addons&amp;lt;/code&amp;gt; within the &amp;lt;code&amp;gt;packages&amp;lt;/code&amp;gt; directory.&lt;br /&gt;
&lt;br /&gt;
On Windows Systems the content base directory is located in the installation root directory, which can be specified by the user at installation time. Using the installation default &amp;lt;code&amp;gt;C:\Program Files\The Ur-Quan Masters\&amp;lt;/code&amp;gt;, that would place the content directory in &amp;lt;code&amp;gt;C:\Program Files\The Ur-Quan Masters\content\&amp;lt;/code&amp;gt;. The game tries the directory where it is started and the directory &amp;quot;content&amp;quot; within that dir as the content base directory.&lt;br /&gt;
&lt;br /&gt;
On Unix systems, the content directory may vary per packager. If you&#039;re building from source, you can specify the installation directory yourself. Per default, the content is stored in &amp;lt;code&amp;gt;lib/uqm/content/&amp;lt;/code&amp;gt; in the specified installation prefix, which is &amp;lt;code&amp;gt;/usr/local/&amp;lt;/code&amp;gt; per default.&lt;br /&gt;
A wrapper script supplies the content dir location to the game.&lt;br /&gt;
&lt;br /&gt;
To override the default content directory, pass something like &amp;lt;code&amp;gt;--content-dir /path/to/content&amp;lt;/code&amp;gt; to the game.&lt;br /&gt;
&lt;br /&gt;
===Default packages===&lt;br /&gt;
Default packages are .uqm files located in the directory &amp;lt;code&amp;gt;packages/&amp;lt;/code&amp;gt; in the content directory. They are mounted automatically, in alphabetic order, with the later ones overriding the earlier ones.&lt;br /&gt;
&lt;br /&gt;
===Add-on packages===&lt;br /&gt;
Add-on packages are .uqm or .zip files located in subdirectories of &amp;lt;code&amp;gt;packages/addons/&amp;lt;/code&amp;gt; in the content directory. If the &amp;lt;code&amp;gt;--addon&amp;lt;/code&amp;gt; argument is passed to the game, the game will use the succeeding argument as the name of a subdirectory in &amp;lt;code&amp;gt;packages/addons/&amp;lt;/code&amp;gt; from which additional packages will be loaded. The game will mount all the .zip/.uqm files in such a directory in alphabetic order, with the later ones overriding the earlier ones.&lt;br /&gt;
The &amp;lt;code&amp;gt;--addon&amp;lt;/code&amp;gt; argument can be supplied multiple times to include multiple add-on directories. They will be mounted in the order they are supplied, with the later ones overriding the earlier ones.&lt;br /&gt;
&lt;br /&gt;
Files in add-on packages will override files from the default packages.&lt;br /&gt;
&lt;br /&gt;
When creating add-on packages, make sure that the use of capitals in the file names matches what is expected. This is even important if a package is for use on Windows only; the matching of file names inside content files does not go through the operating system, and is case sensitive.&lt;br /&gt;
&lt;br /&gt;
===User data directory===&lt;br /&gt;
In the user data directory the user&#039;s key config, melee config, melee teams, and saved games are stored.&lt;br /&gt;
&lt;br /&gt;
On Unix systems (including Darwin/MacOS X) the user data directory is &amp;lt;code&amp;gt;~/.uqm/&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
On English Windows systems, the user data directory is the directory &amp;lt;code&amp;gt;uqm&amp;lt;/code&amp;gt; in the &amp;lt;code&amp;gt;Application Data&amp;lt;/code&amp;gt; directory for the current user. The &amp;lt;code&amp;gt;Application Data&amp;lt;/code&amp;gt; directory is usually in one of the following locations, and may be hidden:&lt;br /&gt;
; Windows 95, 98, SE without separate users : &amp;lt;code&amp;gt;C:\Windows\Application Data\&amp;lt;/code&amp;gt;&lt;br /&gt;
; Windows 95/98/SE with separate users : &amp;lt;code&amp;gt;C:\Windows\Profiles\YourName\Application Data\&amp;lt;/code&amp;gt;&lt;br /&gt;
; Windows NT/2k/XP : &amp;lt;code&amp;gt;C:\Documents and Settings\YourName\Application Data\&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
On localized versions of Windows, these locations may differ. For instance, in the German version it would be &amp;quot;Anwendungsdaten&amp;quot;, not &amp;quot;Application Data&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
===Temporary directory===&lt;br /&gt;
A temporary directory is used to store some data during the game. This was necessary in older versions of Star-Control, but on modern systems the memory involved is not worth it. It will be removed in a future version.&lt;br /&gt;
&lt;br /&gt;
The temporary directory for the game is a directory created in the operating system&#039;s default temporary directory. If an environment variable &amp;lt;code&amp;gt;TMP&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;TEMP&amp;lt;/code&amp;gt; is set, that will be where the temporary directory for the game will be created, otherwise a directory &amp;lt;code&amp;gt;/tmp/&amp;lt;/code&amp;gt; will be used if that exist. If that directory doesn&#039;t exist either, a directory is created in the current working directory.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/packages/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/packages/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21306</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21306"/>
		<updated>2008-02-04T01:32:19Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* A typical layout */  -- added Windows and Mac layouts&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{safe}}&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/PkgInfo&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Info.plist&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/version&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp&lt;br /&gt;
 /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Keep user settings in the resource-map system. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Unify key configuration into the resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
# Unify Melee configuration into the resource-map.&lt;br /&gt;
# Unify file-loading with the resource-map system. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one.  &#039;&#039;Previous steps require partial progress, but not currently an explicit target.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Instead of pointing from resource numbers to files, point them to string IDs that the resource map will forward to files. &#039;&#039;Completed in Revision 2868.&#039;&#039;&lt;br /&gt;
*Have addon packs modify the resource map, not the underlying file system. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*Efficiency concerns indicate resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct.&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. A lot of things have to change all at once to do this:&lt;br /&gt;
**RESOURCE changes from DWORD to const char *.&lt;br /&gt;
**Calls to MAKE_RESOURCE need to be modified to work with string resources.&lt;br /&gt;
*It really looks like the RES_INDEX type can actually be safely retired -- there is exactly one point in the entire codebase where the same resource number is intended for use in multiple indices, and it&#039;s part of the blank CODE resource.&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
* Uniform APIs require uniform reference.  This is actually part of a different step, but part of it turned out to be necessary for sensibly dropping the indices.&lt;br /&gt;
** Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
** Uniform reference between file-type and value-type resources.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21103</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21103"/>
		<updated>2008-01-25T03:08:50Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Other OS layouts should be similar.  TODO: Expand.&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Keep user settings in the resource-map system. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Unify key configuration into the resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
# Unify Melee configuration into the resource-map.&lt;br /&gt;
# Unify file-loading with the resource-map system. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one.  &#039;&#039;Previous steps require partial progress, but not currently an explicit target.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Instead of pointing from resource numbers to files, point them to string IDs that the resource map will forward to files. &#039;&#039;Completed in Revision 2868.&#039;&#039;&lt;br /&gt;
*Have addon packs modify the resource map, not the underlying file system. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*Efficiency concerns indicate resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct.&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. A lot of things have to change all at once to do this:&lt;br /&gt;
**RESOURCE changes from DWORD to const char *.&lt;br /&gt;
**Calls to MAKE_RESOURCE need to be modified to work with string resources.&lt;br /&gt;
*It really looks like the RES_INDEX type can actually be safely retired -- there is exactly one point in the entire codebase where the same resource number is intended for use in multiple indices, and it&#039;s part of the blank CODE resource.&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
* Uniform APIs require uniform reference.  This is actually part of a different step, but part of it turned out to be necessary for sensibly dropping the indices.&lt;br /&gt;
** Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
** Uniform reference between file-type and value-type resources.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
*Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.&lt;br /&gt;
*Ship data is *not* aliased, requiring a bunch of structure initializers that probably (though less probably than in the planet data case) should be name normalized.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21086</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21086"/>
		<updated>2008-01-23T14:28:42Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: More history, top-level goals&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Other OS layouts should be similar.  TODO: Expand.&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Top-Level Roadmap===&lt;br /&gt;
&lt;br /&gt;
This actually may migrate over time as we see what works and what doesn&#039;t, but it will at least mark where we&#039;ve been and where we think we&#039;re going.&lt;br /&gt;
&lt;br /&gt;
# Implement a generic string-based key-to-value system for doing resource lookups.  &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Keep user settings in the resource-map system. &#039;&#039;Completed in revision 1916.&#039;&#039;&lt;br /&gt;
# Drop requirement on binary resource indices by translating them to text. &#039;&#039;Completed in Revision 2003.&#039;&#039;&lt;br /&gt;
# Unify key configuration into the resource-map. &#039;&#039;Completed in revision 2705.&#039;&#039;&lt;br /&gt;
# Unify Melee configuration into the resource-map.&lt;br /&gt;
# Unify file-loading with the resource-map system. &#039;&#039;In progress.&#039;&#039;&lt;br /&gt;
# Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one.  &#039;&#039;Previous steps require partial progress, but not currently an explicit target.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Instead of pointing from resource numbers to files, point them to string IDs that the resource map will forward to files. &#039;&#039;Completed in Revision 2868.&#039;&#039;&lt;br /&gt;
*Have addon packs modify the resource map, not the underlying file system. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*Efficiency concerns indicate resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct.&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. A lot of things have to change all at once to do this:&lt;br /&gt;
**RESOURCE changes from DWORD to const char *.&lt;br /&gt;
**Calls to MAKE_RESOURCE need to be modified to work with string resources.&lt;br /&gt;
*It really looks like the RES_INDEX type can actually be safely retired -- there is exactly one point in the entire codebase where the same resource number is intended for use in multiple indices, and it&#039;s part of the blank CODE resource.&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
* Uniform APIs require uniform reference.  This is actually part of a different step, but part of it turned out to be necessary for sensibly dropping the indices.&lt;br /&gt;
** Uniform reference to file-type resources. &#039;&#039;Completed in Revision 2903.&#039;&#039; This also let us actually start using malloc and free for our memory management directly.&lt;br /&gt;
** Uniform reference between file-type and value-type resources.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
*Can we leverage this for improving save game formats?&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21085</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=21085"/>
		<updated>2008-01-23T14:00:22Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Moved the resource system milestone page to Wiki&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Other OS layouts should be similar.  TODO: Expand.&lt;br /&gt;
&lt;br /&gt;
==Current Development Status==&lt;br /&gt;
&lt;br /&gt;
The resource system (and thus the content directory) are in flux as the development team works on implemented a new resource system.  This should remove a lot of the more brittle components from the legacy system and make addons easier to add, and mods to the source easier to make work.  Detailed goals, milestones, and comments are in this section.&lt;br /&gt;
&lt;br /&gt;
===Current goals===&lt;br /&gt;
&lt;br /&gt;
The immediate goal is to shift away from .lst files (themselves text translations of the old binary .ndx files) to a string-based key-mapping system.&lt;br /&gt;
&lt;br /&gt;
*Self-contained addon packs that own their own directory names. &#039;&#039;Completed in Revision 2871.&#039;&#039;&lt;br /&gt;
*Remixes selectable from the Setup Menu, even if general Resource Management UIs don&#039;t work. &#039;&#039;Completed in Revision 2873.&#039;&#039;&lt;br /&gt;
*resmap.c should be using hashtables, not an association list. &#039;&#039;Completed in Revision 2875.&#039;&#039;&lt;br /&gt;
*Types of resources should be functions of the resource, not the name. SvdB suggests making the values be something like STRING:starcon.txt. This is probably the Right Thing, but it&#039;s not what the integer-based ID system does. This could make life interesting. &#039;&#039;Completed in Revision 2909, with both systems currently active in parallel for cross-checking.&#039;&#039;&lt;br /&gt;
*Resource names need to be modified so that resources in the same package have identical prefixes. &#039;&#039;Abandoned: Replaced with...&#039;&#039;&lt;br /&gt;
*Resource names for constructed resources -- primarily planet graphics, life forms, and the initial selection of starships -- need to be reorganized so that the resource strings are easy to construct.&lt;br /&gt;
*Switch from 32-bit integers indexed via .ls2 files into direct indices into the .rmp files. A lot of things have to change all at once to do this:&lt;br /&gt;
**RESOURCE changes from DWORD to const char *.&lt;br /&gt;
**Calls to MAKE_RESOURCE need to be modified to work with string resources.&lt;br /&gt;
*It really looks like the RES_INDEX type can actually be safely retired -- there is exactly one point in the entire codebase where the same resource number is intended for use in multiple indices, and it&#039;s part of the blank CODE resource.&lt;br /&gt;
*We lack types/handlers for presentations, voice clips, and timestamps. This should change. The easiest way to handle voice clips and timestamps is to have multiple values for the comm resource; something like CONVERSATION:comm/arilou/arilou.txt:addons/voice/arilou:addons/voice/arilou/arilou.ts.&lt;br /&gt;
&lt;br /&gt;
===Other work===&lt;br /&gt;
&lt;br /&gt;
This is a bit more nebulous since we haven&#039;t advanced far enough to see what&#039;s a good idea and what isn&#039;t.&lt;br /&gt;
&lt;br /&gt;
*Massive, cathartic violence against the content directory structure, ending in convenient subprojects. &#039;&#039;Incomplete, but started in revision 2870.&#039;&#039;&lt;br /&gt;
**Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we&#039;re moving the voice packs before actually performing the move.&lt;br /&gt;
**Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.&lt;br /&gt;
**We will require a new option (and new automatic defaults) for automatically detecting the content directory and mounting the addons directory from a separate location (So that one could individually SVN-checkout just source, just source+base content, or everything.)&lt;br /&gt;
*Let .rmp files include other ones to make uqm.rmp less monolithic.  This could also be used to automatically include addon packs (such as, say, a Cyrillic Font Pack) if necessary.&lt;br /&gt;
*The hack to make the remix packs work is kind of ugly. A more permanent fix would allow special variable expansion to map to wherever uio elected to put it, giving each extension its own space for files. Best of all would be a magic variable for &amp;quot;The home of the extension named X.&amp;quot; Implementing this would give us full namespaces and namespace imports.&lt;br /&gt;
** It&#039;s only ugly under the surface, though, and will only affect mod writers, and that rather minimally.  The users just shove packages blindly into content/addons.&lt;br /&gt;
*RES_INDEX resources are basically redundant in the new system, but there&#039;s no reason they couldn&#039;t become const char *s as well. These would go to a new SetResourcePrefix command that replaces SetResourceIndex. Then each ship can load large.graphics on its own, and can also load ship-specific resources like zapsat.large. Resource saving actually already works like this (you provide a prefix that specifies the root of the key-tree to save); we should extend loading to do the same.&lt;br /&gt;
*More generally, the resources for things like configuration can&#039;t coexist with the file resources right now, because one returns a value (say, a filename) and the other returns the contents of a file, suitably parsed. Fixing this means GetResource can&#039;t afford to assume it gets to go out to disk.&lt;br /&gt;
*online configuration of which extensions to use.&lt;br /&gt;
*It would be nice to have an offline application for building extensions.&lt;br /&gt;
*A more &amp;quot;self-aware&amp;quot; resource system should give us a much better handle on the remaining resource-related bugs.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=20514</id>
		<title>Content Management</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management&amp;diff=20514"/>
		<updated>2007-12-09T15:41:48Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Initial writeup&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
The game still uses a virtual file system as before, see [[Content Management]] for information on this.  However, starting in 0.6.4, the &amp;quot;layering&amp;quot; effect of the directory system is no longer used to index files.&lt;br /&gt;
&lt;br /&gt;
==Hey, my remixes don&#039;t work!==&lt;br /&gt;
&lt;br /&gt;
UQM 0.6.4 (SVN revision 2869) changed addon pack mechanics incompatibly.  Your remix zips are still OK, but you will need to perform these steps:&lt;br /&gt;
&lt;br /&gt;
* Move the addons directory from content/packages to content/&lt;br /&gt;
* Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.&lt;br /&gt;
* Ensure that the remix directory is, in fact, addons/remix.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
Still needs to be done.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix1.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix2.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/addons/remix/remix3.rmp&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Other OS layouts should be similar.  TODO: Expand.&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Content_Management_before_0.7.0&amp;diff=20513</id>
		<title>Content Management before 0.7.0</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Content_Management_before_0.7.0&amp;diff=20513"/>
		<updated>2007-12-09T15:32:03Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;:&#039;&#039;Note: the information contained in this page pertains to the [[The Ur-Quan Masters]] versions 0.3 through 0.6.0. The content system is currently under revision: See [[Content Management in 0.7.0]] for details.&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
The game uses a virtual file system to access the content. Directories from various locations are combined (&amp;quot;mounted&amp;quot;) to form one big file system, where files from a mounted directory are hidden if files with the same name exist on a directory mounted &amp;quot;on top&amp;quot; of it.&lt;br /&gt;
A directory to be mounted may exist as an actual directory on the operating system&#039;s file system, or as a directory within a .zip or .uqm file. An .uqm file is internally a .zip file but with another name given, so that people won&#039;t accidentally unpack them.&lt;br /&gt;
&lt;br /&gt;
If a file exists in a directory which is mounted read-only, but not in a directory mounted read-write on top of it, then writing to the file will produce a copy in the latter directory.&lt;br /&gt;
&lt;br /&gt;
Whether file name matching is case-sensitive or not depends on the file system of each layer. Files in .zip files are always matched case-sensitively, while files outside of .zip files are matched as normal for the operating system UQM is run on.&lt;br /&gt;
&lt;br /&gt;
==Content directories==&lt;br /&gt;
The following list shows which directories are mounted in the game. The later mentioned ones are mounted on top of the earlier mentioned ones.&lt;br /&gt;
{|border=1&lt;br /&gt;
!Directory!!Mounted on!!flags&lt;br /&gt;
|-&lt;br /&gt;
|[[#Default packages|default packages]], in alphabetic order||/   ||read-only&lt;br /&gt;
|-&lt;br /&gt;
|[[#Add-on packages|add-on packages]], in alphabetic order  ||/   ||read-only&lt;br /&gt;
|-&lt;br /&gt;
|[[#Content base directory|content base directory]]         ||/   ||read-only&lt;br /&gt;
|-&lt;br /&gt;
|[[#User data directory|user data directory]]               ||/   ||read-write&lt;br /&gt;
|-&lt;br /&gt;
|[[#Temporary directory|temporary directory]]               ||/tmp||read-write&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
You can see from this table that unzipped files always override zipped files. This means that using add-on packages to override a zipped base content won&#039;t work. This is one of the issues that will be addressed in a next release.&lt;br /&gt;
&lt;br /&gt;
==Detailed description==&lt;br /&gt;
&lt;br /&gt;
===Content base directory===&lt;br /&gt;
This is the base directory where the content files are stored.&lt;br /&gt;
It needs to contain a file named &amp;lt;code&amp;gt;version&amp;lt;/code&amp;gt; with the UQM version number to be accepted by the game.&lt;br /&gt;
In it, you&#039;ll usually find a directory &amp;lt;code&amp;gt;packages&amp;lt;/code&amp;gt;, which contains the default packages, and indirectly the add-on packages (optionally). The add-on packages are kept in a directory &amp;lt;code&amp;gt;addons&amp;lt;/code&amp;gt; within the &amp;lt;code&amp;gt;packages&amp;lt;/code&amp;gt; directory.&lt;br /&gt;
&lt;br /&gt;
On Windows Systems the content base directory is located in the installation root directory, which can be specified by the user at installation time. Using the installation default &amp;lt;code&amp;gt;C:\Program Files\The Ur-Quan Masters\&amp;lt;/code&amp;gt;, that would place the content directory in &amp;lt;code&amp;gt;C:\Program Files\The Ur-Quan Masters\content\&amp;lt;/code&amp;gt;. The game tries the directory where it is started and the directory &amp;quot;content&amp;quot; within that dir as the content base directory.&lt;br /&gt;
&lt;br /&gt;
On Unix systems, the content directory may vary per packager. If you&#039;re building from source, you can specify the installation directory yourself. Per default, the content is stored in &amp;lt;code&amp;gt;lib/uqm/content/&amp;lt;/code&amp;gt; in the specified installation prefix, which is &amp;lt;code&amp;gt;/usr/local/&amp;lt;/code&amp;gt; per default.&lt;br /&gt;
A wrapper script supplies the content dir location to the game.&lt;br /&gt;
&lt;br /&gt;
To override the default content directory, pass something like &amp;lt;code&amp;gt;--content-dir /path/to/content&amp;lt;/code&amp;gt; to the game.&lt;br /&gt;
&lt;br /&gt;
===Default packages===&lt;br /&gt;
Default packages are .uqm files located in the directory &amp;lt;code&amp;gt;packages/&amp;lt;/code&amp;gt; in the content directory. They are mounted automatically, in alphabetic order, with the later ones overriding the earlier ones.&lt;br /&gt;
&lt;br /&gt;
===Add-on packages===&lt;br /&gt;
Add-on packages are .uqm or .zip files located in subdirectories of &amp;lt;code&amp;gt;packages/addons/&amp;lt;/code&amp;gt; in the content directory. If the &amp;lt;code&amp;gt;--addon&amp;lt;/code&amp;gt; argument is passed to the game, the game will use the succeeding argument as the name of a subdirectory in &amp;lt;code&amp;gt;packages/addons/&amp;lt;/code&amp;gt; from which additional packages will be loaded. The game will mount all the .zip/.uqm files in such a directory in alphabetic order, with the later ones overriding the earlier ones.&lt;br /&gt;
The &amp;lt;code&amp;gt;--addon&amp;lt;/code&amp;gt; argument can be supplied multiple times to include multiple add-on directories. They will be mounted in the order they are supplied, with the later ones overriding the earlier ones.&lt;br /&gt;
&lt;br /&gt;
Files in add-on packages will override files from the default packages.&lt;br /&gt;
&lt;br /&gt;
When creating add-on packages, make sure that the use of capitals in the file names matches what is expected. This is even important if a package is for use on Windows only; the matching of file names inside content files does not go through the operating system, and is case sensitive.&lt;br /&gt;
&lt;br /&gt;
===User data directory===&lt;br /&gt;
In the user data directory the user&#039;s key config, melee config, melee teams, and saved games are stored.&lt;br /&gt;
&lt;br /&gt;
On Unix systems (including Darwin/MacOS X) the user data directory is &amp;lt;code&amp;gt;~/.uqm/&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
On English Windows systems, the user data directory is the directory &amp;lt;code&amp;gt;uqm&amp;lt;/code&amp;gt; in the &amp;lt;code&amp;gt;Application Data&amp;lt;/code&amp;gt; directory for the current user. The &amp;lt;code&amp;gt;Application Data&amp;lt;/code&amp;gt; directory is usually in one of the following locations, and may be hidden:&lt;br /&gt;
; Windows 95, 98, SE without separate users : &amp;lt;code&amp;gt;C:\Windows\Application Data\&amp;lt;/code&amp;gt;&lt;br /&gt;
; Windows 95/98/SE with separate users : &amp;lt;code&amp;gt;C:\Windows\Profiles\YourName\Application Data\&amp;lt;/code&amp;gt;&lt;br /&gt;
; Windows NT/2k/XP : &amp;lt;code&amp;gt;C:\Documents and Settings\YourName\Application Data\&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
On localized versions of Windows, these locations may differ. For instance, in the German version it would be &amp;quot;Anwendungsdaten&amp;quot;, not &amp;quot;Application Data&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
===Temporary directory===&lt;br /&gt;
A temporary directory is used to store some data during the game. This was necessary in older versions of Star-Control, but on modern systems the memory involved is not worth it. It will be removed in a future version.&lt;br /&gt;
&lt;br /&gt;
The temporary directory for the game is a directory created in the operating system&#039;s default temporary directory. If an environment variable &amp;lt;code&amp;gt;TMP&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;TEMP&amp;lt;/code&amp;gt; is set, that will be where the temporary directory for the game will be created, otherwise a directory &amp;lt;code&amp;gt;/tmp/&amp;lt;/code&amp;gt; will be used if that exist. If that directory doesn&#039;t exist either, a directory is created in the current working directory.&lt;br /&gt;
&lt;br /&gt;
==A typical layout==&lt;br /&gt;
&lt;br /&gt;
===On Mac OS X===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Mac OS X looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
/Applications/The Ur-Quan Masters/Contents/&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
Please someone add to this?&lt;br /&gt;
&lt;br /&gt;
===On Windows===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Windows looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\uqm.exe&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-content.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\addons\remix\uqm-remix-pack1.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\addons\remix\uqm-remix-pack2.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\packages\addons\remix\uqm-remix-pack3.zip&lt;br /&gt;
 C:\Program Files\The Ur-Quan Masters\content\version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===On Linux===&lt;br /&gt;
A typical The Ur-Quan Masters installation on Linux looks like this:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 /usr/local/bin/uqm        (wrapper script)&lt;br /&gt;
 /usr/local/lib/uqm/uqm    (the actual executable)&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-content.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm&lt;br /&gt;
 /usr/local/share/uqm/content/packages/addons/remix/uqm-remix-pack1.zip&lt;br /&gt;
 /usr/local/share/uqm/content/packages/addons/remix/uqm-remix-pack2.zip&lt;br /&gt;
 /usr/local/share/uqm/content/packages/addons/remix/uqm-remix-pack3.zip&lt;br /&gt;
 /usr/local/share/uqm/content/version&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:About the Star Control series]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=The_Ur-Quan_Masters_Project_FAQ&amp;diff=8629</id>
		<title>The Ur-Quan Masters Project FAQ</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=The_Ur-Quan_Masters_Project_FAQ&amp;diff=8629"/>
		<updated>2005-11-26T14:45:10Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Explanation for existence of threads, a FAQ on IRC in recent months.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Safe}}&lt;br /&gt;
&lt;br /&gt;
This is the list of frequently asked questions (with answers) for the [[The Ur-Quan Masters]] project.&lt;br /&gt;
For technical or gameplay questions, check our [[List of FAQs|other FAQs]].&lt;br /&gt;
&lt;br /&gt;
===Where did this project come from?===&lt;br /&gt;
The project started when Chris Nelson joined [[Toys For Bob]] for an internship. He would work there on making the [[3DO]] version [[Star Control II]] run on modern systems. When his internship was over, the sources were released to the public. The current development team then took over.&lt;br /&gt;
&lt;br /&gt;
===Why is this called &amp;quot;The Ur-Quan Masters&amp;quot; instead of &amp;quot;Star Control 2&amp;quot;?===&lt;br /&gt;
[[Toys For Bob]] doesn&#039;t own the trademark on the name &amp;quot;Star Control&amp;quot;, unfortunately. See [[Star Control Trademark]] for more information.&lt;br /&gt;
&lt;br /&gt;
===What are the goals for the [[The Ur-Quan Masters]] project?===&lt;br /&gt;
The goals for the [[The Ur-Quan Masters]] project are:&lt;br /&gt;
*to bring Star Control II to modern platforms, thereby making a lot of people happy&lt;br /&gt;
*to adapt the code so that people can more easily make their own spin-offs, thereby making some more people happy&lt;br /&gt;
*to make game translations easy, thereby making even more people happy&lt;br /&gt;
&lt;br /&gt;
===What operating systems does [[The Ur-Quan Masters]] run on?===&lt;br /&gt;
Version 0.3 has been tested to run on Windows 98/ME/2000/XP, Linux, FreeBSD, OpenBSD and MacOS X. It probably works fine on BeOS too (0.2 did). &lt;br /&gt;
&lt;br /&gt;
Support might be added one day for MacOS 8/9 too (but it will be much trickier due to a lack of native pre-emptive thread support, so it&#039;s more up in the air), and maybe to some other platforms where [http://www.libsdl.org/ SDL] is available.&lt;br /&gt;
&lt;br /&gt;
===Why is pre-emptive thread support necessary?===&lt;br /&gt;
The code we inherited made extensive use of threads, and eliminating this has not been a priority given the target platforms.  That said, the thread model in the code we got had nothing whatsoever to do with POSIX.  Over the course of the project, the threading code has been refactored to fold most of the game logic into a single thread, but some tasks are intrinsically simpler with threads (notably keeping audio decoding synchronized and ensuring that window-manager events are dealt with in a timely manner).  The main game logic uses the call stack to encode what mode the game is in, and where you will go when, say, popping out of a menu.  Dethreading the main code so that it can be done as a single loop would thus involve rewriting all the                  control logic into explicit state-machine code, a major task that would involve heavy modification of the inherited code.  Thus, lowering the thread count further has been pushed to &amp;quot;when there aren&#039;t way more important things to do&amp;quot;.   &lt;br /&gt;
&lt;br /&gt;
===What are the system requirements?===&lt;br /&gt;
Minimum verified system requirements are: &lt;br /&gt;
*Pentium 200 running a supported OS.&lt;br /&gt;
*64 MB of RAM (the game&#039;s footprint is around 30MB).&lt;br /&gt;
*A reasonably recent video card. The oldest cards anyone has tested on are TNT2 and Voodoo 3. For OpenGL support, your video card needs to be able to handle 512x256 or 1024x512 textures. (The Voodoo 3 can not do this.)&lt;br /&gt;
If you&#039;re running the game with default quality levels (640x480 windowed), a Pentium 450 is the current minimum tested.&lt;br /&gt;
&lt;br /&gt;
Important note: Not all features are added yet, and not all optimizations have been done yet. System requirements could go up or down in later releases.&lt;br /&gt;
&lt;br /&gt;
For some suggestions on getting the most out of your system, see [[The_Ur-Quan_Masters_Technical_FAQ#The game runs too slow. What can I do? |here]].&lt;br /&gt;
&lt;br /&gt;
===Why are the system requirements so high? The original game ran fine on a 386.===&lt;br /&gt;
There are a couple of reasons for this:&lt;br /&gt;
*We are porting from the [[3DO]] source code. The [[3DO]] version had some fancier features than the PC version. See [[Version Comparison]].&lt;br /&gt;
*The original game code was optimised for speed. We aim for portability and extensibility.&lt;br /&gt;
*Modern operating systems don&#039;t let applications do everything they want. This imposes overhead.&lt;br /&gt;
*The operating system itself requires some system resources.&lt;br /&gt;
*We are using a better compression algorithm for the audio (Ogg Vorbis), which requires more processing power, but drastically reduces your download size.&lt;br /&gt;
&lt;br /&gt;
===Under what license is the game released?===&lt;br /&gt;
The code is released under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License]. The content (the graphics, sounds, and music) will likely be released under something similar, but exactly which one hasn&#039;t been decided yet. For now, the license says &amp;quot;The content may be copied freely as part of a distribution of The Ur-Quan Masters.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
===What is the current status of the project?===&lt;br /&gt;
The code is still officially in alpha status. This is because some features are still missing. It does not mean that the game is unstable; in fact, it is more stable than many commercially released games.&lt;br /&gt;
As of version 0.4, almost all features from the PC and 3DO version are present. The largest missing feature is nameable save games. Other wanted features relate to the project goals of making the game more customisable and making translations easier.&lt;br /&gt;
&lt;br /&gt;
===When will it be released?===&lt;br /&gt;
There is no exact release date for the &amp;quot;stable release&amp;quot; (version 1.0).&lt;br /&gt;
From time to time we will release in-progress snapshots. We are all working on this in our spare time, so our progress will depend on how much time we can spare for the project. Naturally, having a few more talented coders volunteer to join our team would speed up things somewhat.&lt;br /&gt;
&lt;br /&gt;
===I want to help! What can I do? ===&lt;br /&gt;
The two biggest things you can do to help are to help us find bugs, and to nail the bugs we have. Due to the nature of the code (over 100,000 lines of not-terribly-well-documented, very tight, and very old code) program analysis skills are more useful than raw coding ability. (A strong familiarity with C is necessary to make head or tail of the game logic.) We keep a Bugzilla page with currently extant bugs.&lt;br /&gt;
&lt;br /&gt;
If you want to help, read the [http://sc2.sourceforge.net/contributing.php contributing guide], join the [http://lists.sourceforge.net/lists/listinfo/sc2-devel sc2-devel mailing list], then come to our IRC channel #sc2 at irc.freenode.net to chat with the other developers. IRC is our primary communication method when doing actual coding.&lt;br /&gt;
&lt;br /&gt;
===Why are you porting the [[3DO]] version instead of the PC one?===&lt;br /&gt;
The source code to the PC version has been lost, even to [[Toys For Bob]] itself. This isn&#039;t so terrible, though, as the 3DO version has more features than the PC one, and no media has been lost. Also, the [[3DO]]&#039;s screen resolution (320x240) matches the aspect ratios of modern systems better than the PC version&#039;s 320x200.&lt;br /&gt;
&lt;br /&gt;
===What are the differences between [[The Ur-Quan Masters]] and the PC and [[3DO]] versions of [[Star Control II]]?===&lt;br /&gt;
See the page [[Version Comparison]].&lt;br /&gt;
&lt;br /&gt;
===What features are you going to include?===&lt;br /&gt;
We intend to include the best features of the [[3DO]] version and the PC version. When there is any doubt, we offer both. The user will be able to configure which aspects of the game will match which version. The Ur-Quan Masters will also include optional new music.&lt;br /&gt;
&lt;br /&gt;
We try to be faithful to the originals; there will be no gameplay changes in the main version. There may be forks that introduce new gameplay though.&lt;br /&gt;
&lt;br /&gt;
===What about updating the music?===&lt;br /&gt;
A separate team is working on remixing the original music. It is led by [[Riku Nuottaj&amp;amp;auml;rvi]], one of the original composers. There is a separate page with more information on the [[Remixing Project]].&lt;br /&gt;
The remixed music will be available as separate add-on packs. You can still choose to use the PC or 3DO music if you like.&lt;br /&gt;
&lt;br /&gt;
===What about updating the graphics?===&lt;br /&gt;
A similar project as with the music could be started for the graphics. This would mean an optional pack with updated graphics. However, there are a couple of obstacles for this:&lt;br /&gt;
*No people have yet stepped forward to start this project.&lt;br /&gt;
*The code can still only use 8 bit graphics. This problem will be addressed at some point in the future, and it would get a higher priority if there were actually people interested in redoing the graphics.&lt;br /&gt;
&lt;br /&gt;
===What about network play?===&lt;br /&gt;
Network play is one of the most requested features. We would like to include it, but as it will take a lot of work to make the existing code work on a high-latency network (such as the internet), we have decided to put our time in more important aspects of the project for now.&lt;br /&gt;
&lt;br /&gt;
[[Category:FAQs]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Talk:Tobermoon&amp;diff=8697</id>
		<title>Talk:Tobermoon</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Talk:Tobermoon&amp;diff=8697"/>
		<updated>2004-10-12T04:56:00Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Starbase commander indicates that the Tobermoon escorted the SIS to Solbase when he&#039;s telling you to get in gear dealing with the Probes.  Where does Commander Chi fit into this?&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Never mind, I found it.  Entries on Tobermoon and Chi have been extended and clarified for full consistency.  -McMartin&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Chi&amp;diff=2381</id>
		<title>Chi</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Chi&amp;diff=2381"/>
		<updated>2004-10-12T04:54:26Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Clarifying *which* Oort cloud&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Chi&#039;&#039;&#039; was the first Officer of the [[Earth]] [[Cruiser]] [[Tobermoon]], second-in-command to Captain [[I. Burton]]. He was also Burton&#039;s fiance. After Captain Burton decided to disobey the order to evacuate the Vela scientific expedition and destroy the [[Precursor]] base, Chi was ordered to return to Earth with the Tobermoon to inform [[Star Control (Organization)|Star Control]] of Burton&#039;s decision.&lt;br /&gt;
&lt;br /&gt;
On Captain Burton&#039;s return trip to Earth, the Tobermoon was discovered drifting in Vela&#039;s Oort cloud, damaged by energy blasts that matched that of an [[Ur-Quan]] [[Dreadnought]]. No remains of the crew nor of First Officer Chi was found.&lt;br /&gt;
&lt;br /&gt;
[[Category:Minor Characters]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Tobermoon&amp;diff=2380</id>
		<title>Tobermoon</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Tobermoon&amp;diff=2380"/>
		<updated>2004-10-12T04:53:09Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The &#039;&#039;&#039;Tobermoon&#039;&#039;&#039; was an [[Earthling]] [[Cruiser]] Captained by [[I. Burton]].  It was part of the research project in the [[Vela]] system.  The Tobermoon attempted to return to [[Earth]] with news that the [[Precursor]] station there was not destroyed, but it was disabled (killing all aboard, including the acting captain [[Chi]]) in the Oort Cloud surrounding Vela.&lt;br /&gt;
&lt;br /&gt;
Once the [[SIS]] was sent to head to Earth, the Tobermoon&#039;s wreck was recovered before the push to HyperSpace.  Commander [[I. Burton]] recrewed and captained the ship herself, but she was killed in an attack by a [[Slylandro]] [[Probe]] on the Tobermoon.  The ship itself survives, and is the [[SIS]]&#039;s initial escort at the start of the game.&lt;br /&gt;
&lt;br /&gt;
[[Category:Ships (Specific)]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Talk:Tobermoon&amp;diff=2099</id>
		<title>Talk:Tobermoon</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Talk:Tobermoon&amp;diff=2099"/>
		<updated>2004-10-12T04:33:00Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Starbase commander indicates that the Tobermoon escorted the SIS to Solbase when he&#039;s telling you to get in gear dealing with the Probes.  Where does Commander Chi fit into this?&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Tobermoon&amp;diff=2097</id>
		<title>Tobermoon</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Tobermoon&amp;diff=2097"/>
		<updated>2004-10-12T03:59:19Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Reverted edit of Mcmartin, changed back to last version by Mmrnmhrm&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The &#039;&#039;&#039;Tobermoon&#039;&#039;&#039; was an [[Earthling]] [[Cruiser]] Captained by [[I. Burton]].  It was part of the research project in the [[Vela]] system.  The Tobermoon attempted to return to [[Earth]] with news that the [[Precursor]] station there was not destroyed, but it never made it home.&lt;br /&gt;
&lt;br /&gt;
[[Category:Ships (Specific)]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Tobermoon&amp;diff=2093</id>
		<title>Tobermoon</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Tobermoon&amp;diff=2093"/>
		<updated>2004-10-12T03:57:20Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Corrected history to match manual&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The &#039;&#039;&#039;Tobermoon&#039;&#039;&#039; was an [[Earthling]] [[Cruiser]] Captained by [[I. Burton]].  It was part of the research project in the [[Vela]] system.  The Tobermoon attempted to return to [[Earth]] with news that the [[Precursor]] station there was not destroyed.  Burton did not survive to give this information; she was killed in a battle with a [[Slylandro]] [[Probe]] on the way back.  The ship itself, however, survived, and is the escort ship that accompanies the [[SIS]] to Earth.&lt;br /&gt;
&lt;br /&gt;
[[Category:Ships (Specific)]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Inter-Dimensional_Fatigue&amp;diff=2100</id>
		<title>Inter-Dimensional Fatigue</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Inter-Dimensional_Fatigue&amp;diff=2100"/>
		<updated>2004-10-12T03:50:38Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Dimensional fatigue&amp;quot; (also Inter-Dimensional Fatigue, or &amp;quot;IDF&amp;quot;) is a process or force that weakens the boundaries between dimensions.  Like &amp;quot;Electromotive force,&amp;quot; it&#039;s not clear whether IDF is a force in its own right or merely some other process.  Dimensional Fatigue can be &#039;&#039;projected&#039;&#039; by devices, and occasionally occurs naturally.&lt;br /&gt;
&lt;br /&gt;
IDF research is believed to be incredibly dangerous; most races that use HyperSpace either had a patron such as the [[Arilou]] or inherited the technology from elsewhere.  The [[Chenjesu]] are naturally attuned to HyperSpace, and the [[Yehat]] achieved star travel on their own, as did the [[Humans]].  A human offshoot culture, the [[Androsynth]], continued IDF research and was destroyed entirely by the [[Orz]], and the Arilou hint that this is not coincidence.&lt;br /&gt;
&lt;br /&gt;
The Arilou &#039;&#039;may&#039;&#039; be lying about the danger involved for their own inscrutable purposes; however, it is undeniable that HyperSpace travel was not invented very many times, and that some catastrophe indeed befell the Androsynth.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=The_Ur-Quan_Masters_Project_FAQ&amp;diff=2182</id>
		<title>The Ur-Quan Masters Project FAQ</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=The_Ur-Quan_Masters_Project_FAQ&amp;diff=2182"/>
		<updated>2004-10-12T03:39:38Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* What are the system requirements? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is the list of frequently asked questions (with answers) for the [[The Ur-Quan Masters]] project.&lt;br /&gt;
For technical or gameplay questions, check our [[List of FAQs|other FAQs]].&lt;br /&gt;
&lt;br /&gt;
===Where did this project come from?===&lt;br /&gt;
The project started when Chris Nelson joined [[Toys For Bob]] for an internship. He would work there on making the [[3DO]] version [[Star Control II]] run on modern systems. When his internship was over, the sources were released to the public. The current development team then took over.&lt;br /&gt;
&lt;br /&gt;
===Why is this called &amp;quot;The Ur-Quan Masters&amp;quot; instead of &amp;quot;Star Control 2&amp;quot;?===&lt;br /&gt;
[[Toys For Bob]] doesn&#039;t own the trademark on the name &amp;quot;Star Control&amp;quot;, unfortunately. See [[Star Control Trademark]] for more information.&lt;br /&gt;
&lt;br /&gt;
===What are the goals for the [[The Ur-Quan Masters]] project?===&lt;br /&gt;
The goals for the [[The Ur-Quan Masters]] project are:&lt;br /&gt;
*to bring Star Control II to modern platforms, thereby making a lot of people happy&lt;br /&gt;
*to adapt the code so that people can more easily make their own spin-offs, thereby making some more people happy&lt;br /&gt;
*to make game translations easy, thereby making even more people happy&lt;br /&gt;
&lt;br /&gt;
===What operating systems does [[The Ur-Quan Masters]] run on?===&lt;br /&gt;
Version 0.3 has been tested to run on Windows 98/2000/XP, Linux, FreeBSD, OpenBSD and MacOS X. It probably works fine on BeOS too (0.2 did). &lt;br /&gt;
&lt;br /&gt;
Support might be added one day for MacOS 8/9 too (but it will be much trickier due to a lack of native pre-emptive thread support, so it&#039;s more up in the air), and maybe to some other platforms where [http://www.libsdl.org/ SDL] is available.&lt;br /&gt;
&lt;br /&gt;
===What are the system requirements?===&lt;br /&gt;
Minimum verified system requirements are: &lt;br /&gt;
*Pentium 200 running a supported OS.&lt;br /&gt;
*64 MB of RAM (the game&#039;s footprint is around 30MB).&lt;br /&gt;
*A reasonably recent video card. The oldest cards anyone has tested on are TNT2 and Voodoo 3. For OpenGL support, your video card needs to be able to handle 512x256 or 1024x512 textures. (The Voodoo 3 can not do this.)&lt;br /&gt;
If you&#039;re running at or near the minimum, you should play in 320x240 mode, full screen, and experiment with OpenGL mode to see whether that speeds up or slows down your game. If you&#039;re running the game with default quality levels (640x480 windowed), an Athlon 600 is the current minimum tested.&lt;br /&gt;
&lt;br /&gt;
If you are running Windows XP, you may be able to get additional speed out of the game by increasing its priority in the Task Manager.&lt;br /&gt;
&lt;br /&gt;
Important note: Not all features are added yet, and not all optimizations have been done yet. System requirements could go up or down in later releases.&lt;br /&gt;
&lt;br /&gt;
===Why are the system requirements so high? The original game ran fine on a 386.===&lt;br /&gt;
There are a couple of reasons for this:&lt;br /&gt;
*We are porting from the [[3DO]] source code. The [[3DO]] version had some fancier features than the PC version. See [[Version Comparison]].&lt;br /&gt;
*The original game code was optimised for speed. We aim for portability and extensibility.&lt;br /&gt;
*Modern operating systems don&#039;t let applications do everything they want. This imposes overhead.&lt;br /&gt;
*The operating system itself requires some system resources.&lt;br /&gt;
&lt;br /&gt;
===Under what license is the game released?===&lt;br /&gt;
The code is released under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License]]. The content (the graphics, sounds, and music) will likely be released under something similar, but exactly which one hasn&#039;t been decided yet. For now, the license says &amp;quot;The content may be copied freely as part of a distribution of The Ur-Quan Masters.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
===What is the current status of the project?===&lt;br /&gt;
The code is still officially in alpha status. This is because some features are still missing. It does not mean that the game is unstable; in fact, it is more stable than many commercially released games.&lt;br /&gt;
The most important missing feature is the &amp;quot;outtakes&amp;quot; sequence at the end of the game. While it is something which is really worth watching, the game is fully playable without it.&lt;br /&gt;
&lt;br /&gt;
===When it will be released?===&lt;br /&gt;
There is no exact release date for the &amp;quot;stable release&amp;quot; (version 1.0).&lt;br /&gt;
From time to time we will release in-progress snapshots. We are all working on this in our spare time, so our progress will depend on how much time we can spare for the project. Naturally, having a few more talented coders volunteer to join our team would speed up things somewhat.&lt;br /&gt;
&lt;br /&gt;
===I want to help! What can I do? ===&lt;br /&gt;
The two biggest things you can do to help are to help us find bugs, and to nail the bugs we have. Due to the nature of the code (over 100,000 lines of not-terribly-well-documented, very tight, and very old code) program analysis skills are more useful than raw coding ability. (A strong familiarity with C is necessary to make head or tail of the game logic.) We keep a Bugzilla page with currently extant bugs.&lt;br /&gt;
&lt;br /&gt;
If you want to help, read the [http://sc2.sourceforge.net/contributing.php contributing guide], join the [http://lists.sourceforge.net/lists/listinfo/sc2-devel sc2-devel mailing list], then come to our IRC channel #sc2 at irc.freenode.net to chat with the other developers. IRC is our primary communication method when doing actual coding.&lt;br /&gt;
&lt;br /&gt;
===Why are you porting the [[3DO]] version instead of the PC one?===&lt;br /&gt;
The source code to the PC version has been lost, even to [[Toys For Bob]] itself. This isn&#039;t so terrible, though, as the 3DO version has more features than the PC one, and no media has been lost. Also, the [[3DO]]&#039;s screen resolution (320x240) matches the aspect ratios of modern systems better than the PC version&#039;s 320x200.&lt;br /&gt;
&lt;br /&gt;
===What are the differences between [[The Ur-Quan Masters]] and the PC and [[3DO]] versions of [[Star Control II]]?===&lt;br /&gt;
See the page [[Version Comparison]].&lt;br /&gt;
&lt;br /&gt;
===What features are you going to include?===&lt;br /&gt;
We intend to include the best features of the [[3DO]] version and the PC version. When there is any doubt, we offer both. The user will be able to configure which aspects of the game will match which version.&lt;br /&gt;
Version 1.0 will be a straight port; major gameplay additions are not on our agenda until everything that was originally there actually works. Version 1.0 will also include some original media from the original artists and musicians, specifically for this project. These will be included into the release snapshots as we receive them.&lt;br /&gt;
&lt;br /&gt;
===What about updating the music?===&lt;br /&gt;
A separate team is working on remixing the original music. It is led by [[Riku Nuottaj&amp;amp;auml;rvi]], one of the original composers. There is a separate page with more information on the [[Remixing Project]].&lt;br /&gt;
The remixed music will be available as separate add-on packs. You can still choose to use the PC or 3DO music if you like.&lt;br /&gt;
&lt;br /&gt;
===What about updating the graphics?===&lt;br /&gt;
A similar project as with the music could be started for the graphics. This would mean an optional pack with updated graphics. However, there are a couple of obstacles for this:&lt;br /&gt;
*No people have yet stepped forward to start this project.&lt;br /&gt;
*The code can still only use 8 bit graphics. This problem will be addressed at some point in the future, and it would get a higher priority if there were actually people interested in redoing the graphics.&lt;br /&gt;
&lt;br /&gt;
===What about network play?===&lt;br /&gt;
Network play is one of the most requested features. We would like to include it, but as it will take a lot of work to make the existing code work on a high-latency network (such as the internet), we have decided to put our time in more important aspects of the project for now.&lt;br /&gt;
&lt;br /&gt;
[[Category:FAQs]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Chenjesu&amp;diff=541</id>
		<title>Chenjesu</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Chenjesu&amp;diff=541"/>
		<updated>2004-09-23T05:38:53Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: Linkfix&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Chenjesu are a race of silicon-based, crystalline beings native to the Sapphire World of Procyon 2.  They are photo/chemovores, and have no natural predators, nor need for prey.  They are naturally non-hostile.&lt;br /&gt;
&lt;br /&gt;
They also have natural receptors in the HyperWave band, which gave them the first inkling of the [[Ur-Quan Kzer-Za|Ur-Quan]] invasion.  They formed a military alliance with the [[Mmrnmhrm]] to form the basis of the Alliance of Free Stars.&lt;br /&gt;
&lt;br /&gt;
The Chenjesu were the first race to officially contact [[Humans|Humanity]].  Their star charts of HyperSpace form the standard that the races in this region of space use.&lt;br /&gt;
&lt;br /&gt;
The Chenjesu, while silicon-based, are not at all like the [[Taalo]] -- Chenjesu are crystalline rather than rocklike, and unlike the entirely pacifist Taalo, the Chenjesu have no qualms about unleashing awesome destructive powers against those who threaten them.  Their starship, the [[Broodhome]], possessed more raw power (and raw material) than any other Alliance ship -- even if, in general, it was not the most effective in combat.&lt;br /&gt;
&lt;br /&gt;
Images of the Chenjesu captains imply that they have limited control over electrical discharges, which they use to control their equipment.&lt;br /&gt;
&lt;br /&gt;
After the [[Sa-Matra]] was deployed against them by the Ur-Quan, they and the Mmrnmhrm requested to be shielded together on the Chenjesu homeworld.  The Ur-Quan permitted this, and the two races began to synthesize into the [[Chmmr]].&lt;br /&gt;
&lt;br /&gt;
The reasons for this are fairly clear for the Mmrnmhrm, as that race had lost the ability to reproduce on its own.  The motivations of the Chenjesu are still unclear.  The &#039;&#039;Role-playing Resource Guide&#039;&#039; indicates that the Chenjesu probably decided to do this because they felt their culture had become advanced enough to stagnate entirely, and that the modification of their species into a transChenjesu synthesis would reinvigorate their society.&lt;br /&gt;
&lt;br /&gt;
The Chenjesu got along very well with the other races in the Alliance.  In fact, they were the leaders of the Alliance, though they refused to take that title officially.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Chenjesu&amp;diff=474</id>
		<title>Chenjesu</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Chenjesu&amp;diff=474"/>
		<updated>2004-09-22T23:30:07Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Chenjesu are a race of silicon-based, crystalline beings native to the Sapphire World of Procyon 2.  They are photo/chemovores, and have no natural predators, nor need for prey.  They are naturally non-hostile.&lt;br /&gt;
&lt;br /&gt;
They also have natural receptors in the HyperWave band, which gave them the first inkling of the [[Ur Quan Kzer-Za|Ur-Quan]] invasion.  They formed a military alliance with the [[Mmrnmhrm]] to form the basis of the Alliance of Free Stars.&lt;br /&gt;
&lt;br /&gt;
The Chenjesu were the first race to officially contact [[Humans|Humanity]].  Their star charts of HyperSpace form the standard that the races in this region of space use.&lt;br /&gt;
&lt;br /&gt;
The Chenjesu, while silicon-based, are not at all like the [[Taalo]] -- Chenjesu are crystalline rather than rocklike, and unlike the entirely pacifist Taalo, the Chenjesu have no qualms about unleashing awesome destructive powers against those who threaten them.  Their starship, the [[Broodhome]], possessed more raw power (and raw material) than any other Alliance ship -- even if, in general, it was not the most effective in combat.&lt;br /&gt;
&lt;br /&gt;
Images of the Chenjesu captains imply that they have limited control over electrical discharges, which they use to control their equipment.&lt;br /&gt;
&lt;br /&gt;
After the [[Sa-Matra]] was deployed against them by the Ur-Quan, they and the Mmrnmhrm requested to be shielded together on the Chenjesu homeworld.  The Ur-Quan permitted this, and the two races began to synthesize into the [[Chmmr]].&lt;br /&gt;
&lt;br /&gt;
The reasons for this are fairly clear for the Mmrnmhrm, as that race had lost the ability to reproduce on its own.  The motivations of the Chenjesu are still unclear.  The &#039;&#039;Role-playing Resource Guide&#039;&#039; indicates that the Chenjesu probably decided to do this because they felt their culture had become advanced enough to stagnate entirely, and that the modification of their species into a transChenjesu synthesis would reinvigorate their society.&lt;br /&gt;
&lt;br /&gt;
The Chenjesu got along very well with the other races in the Alliance.  In fact, they were the leaders of the Alliance, though they refused to take that title officially.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Talbot&amp;diff=84</id>
		<title>Talbot</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Talbot&amp;diff=84"/>
		<updated>2004-08-28T02:30:56Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Officer Talbot was sent to Epsilon Gruis Ia as part of the mission to determine what happened to the [[Spathi]] after they suddenly disappeared.  He found the message from the Spathi High Council that was stuck to the [[Umgah Hyperwave Broadcaster]].&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=List_of_characters&amp;diff=23</id>
		<title>List of characters</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=List_of_characters&amp;diff=23"/>
		<updated>2004-08-28T02:29:40Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: /* Minor Characters */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Game Characters==&lt;br /&gt;
These characters actually take part in dialogs in [[The Ur-Quan Masters]].&lt;br /&gt;
*[[The Captain]]&lt;br /&gt;
*[[Fwiffo|Captain Fwiffo]]&lt;br /&gt;
*[[Katana]]&lt;br /&gt;
*[[Talana|Starbase Commander Talana]]&lt;br /&gt;
*[[Talking Pet|The Talking Pet]]&lt;br /&gt;
*[[Tanaka]]&lt;br /&gt;
*[[ZEX|Admiral ZEX]]&lt;br /&gt;
&lt;br /&gt;
==Minor Characters==&lt;br /&gt;
These characters have a small part in the game, but you never get to talk to them personally.&lt;br /&gt;
*[[Bukowski|Science officer Bukowski]]&lt;br /&gt;
*[[Chin]]&lt;br /&gt;
*[[Chu|Dr. Chu]]&lt;br /&gt;
*[[Fritz]]&lt;br /&gt;
*[[Hawkins|Junior scientist Hawkins]]&lt;br /&gt;
*[[Hodgkins|Ensign Hodgkins]]&lt;br /&gt;
*[[Hendryx|Private Hendryx]]&lt;br /&gt;
*[[Hawthorne|Ensign Hawthorne]]&lt;br /&gt;
*[[Jenkins]]&lt;br /&gt;
*[[Kilgore|Xeno-historian Kilgore]]&lt;br /&gt;
*[[Kowalski]]&lt;br /&gt;
*[[Luigi]]&lt;br /&gt;
*[[The Liebermann Triplets]]&lt;br /&gt;
*[[O&#039;Donnell]]&lt;br /&gt;
*[[Rigby|Ensign Rigby]]&lt;br /&gt;
*[[Robinson|Lieutenant Robinson]]&lt;br /&gt;
*[[Witherspoon|Ensign Witherspoon]]&lt;br /&gt;
*[[Talbot|Officer Talbot]]&lt;br /&gt;
&lt;br /&gt;
==Backstory Characters==&lt;br /&gt;
These characters are mentioned in the game or the manual, but anything they contribute to the plot takes place before the start of the game.&lt;br /&gt;
*[[I. Burton|Captain I. Burton]]&lt;br /&gt;
*[[Chi|First Officer Chi]]&lt;br /&gt;
*[[Jules Farnsworth|Professor Jules Farnsworth]]&lt;br /&gt;
*[[Kohr-Ah (Character)|Kohr-Ah]]&lt;br /&gt;
*[[Kzer-Za (Character)|Kzer-Za]]&lt;br /&gt;
*[[Jeffry L. Rand|Captain Jeffry L. Rand]]&lt;br /&gt;
*[[Tzzz-Tzer-Tzak]]&lt;br /&gt;
&lt;br /&gt;
==Fictional Characters==&lt;br /&gt;
These characters are mentioned in the game, but they do not actually exist in the [[Star Control Universe]].&lt;br /&gt;
*[[Dogar and Kazon]]&lt;br /&gt;
*[[Grand Master Planet Eaters|The Grand Master Planet Eaters]]&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Robinson&amp;diff=82</id>
		<title>Robinson</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Robinson&amp;diff=82"/>
		<updated>2004-08-28T02:29:00Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Lieutenant Robinson was sent to Epsilon Gruis Ia as part of the mission to determine what happened to the [[Spathi]] after they suddenly disappeared.  He gave the report back to [[The Captain]].&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Kilgore&amp;diff=76</id>
		<title>Kilgore</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Kilgore&amp;diff=76"/>
		<updated>2004-08-28T02:26:48Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Xeno-Historian Kilgore was sent as part of the mission investigating the [[Androsynth]] homeworld.  He was the first to identify the ruins as decisively the remains of the Androsynth civilization.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Jenkins&amp;diff=75</id>
		<title>Jenkins</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Jenkins&amp;diff=75"/>
		<updated>2004-08-28T02:24:16Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Jenkins was the pilot of the lander mission sent to investigate the [[Utwig Bomb]].  He deactivated the defensive grid surrounding it -- well, actually, he &amp;quot;just drove through it by accident, but that seemed to work.&amp;quot;&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Hendryx&amp;diff=73</id>
		<title>Hendryx</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Hendryx&amp;diff=73"/>
		<updated>2004-08-28T02:22:26Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Private Hendryx was the member of the landing team sent to to investigate the [[Aqua Helix]] that actually recovered the artifact.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Witherspoon&amp;diff=83</id>
		<title>Witherspoon</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Witherspoon&amp;diff=83"/>
		<updated>2004-08-28T02:20:36Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Along with Ensign [[Hodgkins]], Ensign Witherspoon was one of two [[Humans]] with esper potential aboard the mission to retrieve the [[Taalo Shield]].  The significance of their disorientation did not become clear until the scientists back at Earth Starbase analyzed the device.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Hodgkins&amp;diff=72</id>
		<title>Hodgkins</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Hodgkins&amp;diff=72"/>
		<updated>2004-08-28T02:20:04Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Along with Ensign [[Witherspoon]], Ensign Hodgkins was one of two [[Humans]] with esper potential aboard the mission to retrieve the [[Taalo Shield]].  The significance of their disorientation did not become clear until the scientists back at Earth Starbase analyzed the device.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Chu&amp;diff=69</id>
		<title>Chu</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Chu&amp;diff=69"/>
		<updated>2004-08-28T02:17:18Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Dr. Chu is the Xenobiologist at the Earth Starbase.  He was severely injured when the beast that [[The Captain]] captured for [[ZEX|Admiral ZEX]] took a swipe at him.  Junior Scientist [[Hawkins]] was promoted to take his place.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Hawkins&amp;diff=71</id>
		<title>Hawkins</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Hawkins&amp;diff=71"/>
		<updated>2004-08-28T02:15:46Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Junior Scientist Hawkins was hastily promoted to write the report on the beast that [[The Captain]] captured for [[ZEX|Admiral ZEX]] after it incapacited [[Chu|Dr. Chu]].&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Hawthorne&amp;diff=74</id>
		<title>Hawthorne</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Hawthorne&amp;diff=74"/>
		<updated>2004-08-28T02:12:37Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Hawthorne was the ensign aboard the mission to the [[Androsynth]] homeworld, who relieved [[Bukowski]] after [[They|&amp;quot;They&amp;quot;]] incapacitated him.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Bukowski&amp;diff=67</id>
		<title>Bukowski</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Bukowski&amp;diff=67"/>
		<updated>2004-08-28T02:11:35Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Science Officer Bukowski was sent to investigate the ruins of the [[Androsynth]] on Eta Vulpeculae II.  In the process of his investigations, he grew gradually delirious, and began ranting about the existence of [[They|&amp;quot;Them&amp;quot;]].  After &amp;quot;They&amp;quot; incapacitated him, he was relieved by Ensign [[Hawthorne]].&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
	<entry>
		<id>https://wiki.uqm.stack.nl/index.php?title=Rigby&amp;diff=81</id>
		<title>Rigby</title>
		<link rel="alternate" type="text/html" href="https://wiki.uqm.stack.nl/index.php?title=Rigby&amp;diff=81"/>
		<updated>2004-08-28T02:07:42Z</updated>

		<summary type="html">&lt;p&gt;Mcmartin: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ensign Rigby was a crew member sent to investigate the moon base.  He is a XenoTech, and believed that the transmissions coming from the base were some kind of alert or mayday broadcast.&lt;br /&gt;
&lt;br /&gt;
As it happens, they were actually simply the audio track of &amp;quot;Winky&#039;s Happy Night,&amp;quot; [[Captain Fwiffo]]&#039;s favorite [[Melnorme]] FunRom, there to make the base still appear active.&lt;/div&gt;</summary>
		<author><name>Mcmartin</name></author>
	</entry>
</feed>