This page is guaranteed to be spoiler free. It is safe for you to read this page even if you have not completed playing The Ur-Quan Masters. Links you follow from this page do not share this guarantee unless they also include this text.
The game still uses a virtual file system as before: see Content Management for information on this. However, starting in 0.6.4, the "layering" effect of the directory system is no longer used to index files for the purposes of regular addons. The concept of addon shadow packages was introduced in 0.6.6 as a stop-gap since the resource system is not yet finished.
Hey, my remixes don't work!
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:
- Move the addons directory from content/packages to content/
- Download the appropriate .rmp files from http://sc2.sourceforge.net/remix-rmp/ and put them in the same directory as the remix zips.
- Ensure that the remix directory is, in fact, addons/remix.
Still needs to be done.
A typical layout
A typical The Ur-Quan Masters installation on Windows looks like this:
C:\Program Files\The Ur-Quan Masters\uqm.exe C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.7.0-content.uqm C:\Program Files\The Ur-Quan Masters\content\addons\uqm-0.7.0-3domusic.uqm C:\Program Files\The Ur-Quan Masters\content\addons\uqm-0.7.0-voice.uqm C:\Program Files\The Ur-Quan Masters\content\addons\uqm-remix-disc1.uqm C:\Program Files\The Ur-Quan Masters\content\addons\uqm-remix-disc2.uqm C:\Program Files\The Ur-Quan Masters\content\addons\uqm-remix-disc3.uqm C:\Program Files\The Ur-Quan Masters\content\version
On Mac OS X
A typical The Ur-Quan Masters installation on Mac OS X looks like this:
/Applications/The Ur-Quan Masters/Contents/PkgInfo /Applications/The Ur-Quan Masters/Contents/Info.plist /Applications/The Ur-Quan Masters/Contents/Frameworks/Ogg.framework /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL_image.framework /Applications/The Ur-Quan Masters/Contents/Frameworks/SDL.framework /Applications/The Ur-Quan Masters/Contents/Frameworks/Vorbis.framework /Applications/The Ur-Quan Masters/Contents/MacOS/The Ur-Quan Masters /Applications/The Ur-Quan Masters/Contents/Resources/The Ur-Quan Masters.icns /Applications/The Ur-Quan Masters/Contents/Resources/content/version /Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.7.0-content.uqm /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/uqm-0.7.0-voice.uqm /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/uqm-remix-disc1.uqm /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/uqm-remix-disc2.uqm /Applications/The Ur-Quan Masters/Contents/Resources/content/addons/uqm-remix-disc3.uqm
A typical The Ur-Quan Masters installation on Linux looks like this:
/usr/local/bin/uqm (wrapper script) /usr/local/lib/uqm/uqm (the actual executable) /usr/local/share/uqm/content/packages/uqm-0.7.0-content.uqm /usr/local/share/uqm/content/addons/uqm-0.7.0-3domusic.uqm /usr/local/share/uqm/content/addons/uqm-0.7.0-voice.uqm /usr/local/share/uqm/content/addons/uqm-remix-disc1.uqm /usr/local/share/uqm/content/addons/uqm-remix-disc2.uqm /usr/local/share/uqm/content/addons/uqm-remix-disc3.uqm /usr/local/share/uqm/content/version
The following list shows which directories are mounted in the game in 0.7. The later mentioned ones are mounted on top of the earlier mentioned ones.
|default packages, in alphabetic order||/||read-only|
|add-on packages, in alphabetic order||/addons/[name]||read-only|
|content base directory||/||read-only|
|add-on shadow packages, in specified order||/||read-only|
|user data directory||/||read-write|
Note that addon packages are now mounted in their own tree branches, with one exception. The only way to override (or shadow) the content is with an add-on shadow package. This is necessary in cases like extending fonts or supplying different menu keys because the resource system is not yet finished.
This is better illustrated with an example:
Where russian.zip contains:
russian.rmp comm/commander.txt comm/arilou.txt [etc., files with layout of author's choosing]
and is mounted like so:
/addons/lang-russian/russian.rmp /addons/lang-russian/comm/commander.txt /addons/lang-russian/comm/arilou.txt [etc.]
And russian-shadow.zip contains:
base/fonts/micro.fon/ base/fonts/player.fon/ [etc.]
and is mounted like so:
/base/fonts/micro.fon/ /base/fonts/player.fon/ [etc.]
Addon shadow-content directory must contain .zip (or .uqm) files. Only zipped files will be mounted under the root directory. This means that in order to create a single zipped addon file with shadow content, you have to put a zip inside a zip. In that case, it may be a good idea to zip the shadow content with method store (no compression) in order to improve the in-game performance. A single russian.zip package would then look like this:
shadow-content/russian-shadow.zip russian.rmp comm/commander.txt comm/arilou.txt [etc., files with layout of author's choosing]
Current Development Status
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.
This actually may migrate over time as we see what works and what doesn't, but it will at least mark where we've been and where we think we're going.
- Implement a generic string-based key-to-value system for doing resource lookups. Completed in Revision 1916.
- Drop requirement on binary resource indices by translating them to text. Completed in Revision 2003.
- Replace the integer-based resource system with string-based key mappings that are easier to extend. Completed in Revision 2963.
- Rework resource types to allow for a wider range of resources. Migrate all 3DO content into standalone addon packs. Completed in Revision 3104.
- Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. In progress.
It's now feasible to start moving hardcoded data like the starship constants and the starmap itself into .rmp files. It's not clear how much of this is wise for 0.7.0 itself, but we should probably do at least a little to gather interest.
- Keep user settings in a resource-map. Completed in Revision 1916.
- Keep key configuration in a resource-map. Completed in Revision 2705.
- Allow loads of resource files to be placed into isolated submaps to keep values separated. Completed in Revision 3105.
- Allow saves to strip some or all of the common prefix to save only the "submap" component. Completed in Revision 3105.
- Merge user settings and key configuration into the main resource map, eliminating the now-redundant mapres.c routines. Completed in Revision 3108.
- Turn melee data (teams, current situation) into resource maps like the other two.
This is a bit more nebulous since we haven't advanced far enough to see what's a good idea and what isn't.
- Massive, cathartic violence against the content directory structure, ending in convenient subprojects. Incomplete, but started in revision 2870.
- 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.
- At the moment we just load all .rmp files in any given directory. This may be good enough.
- 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 "The home of the extension named X." Implementing this would give us full namespaces and namespace imports.
- It'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.
- Online configuration of which extensions to use.
- It would be nice to have an offline application for building extensions.
- A more "self-aware" resource system should give us a much better handle on the remaining resource-related bugs.
- Can we leverage this for improving save game formats?
- Planet data is aliased in #defines and structure initializers when it should probably be in the resource map.
- 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.