Content Management

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.

Introduction

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.

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.

Detailed description

Still needs to be done.

A typical layout

On Windows

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.6.0-content.uqm
C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-3domusic.uqm
C:\Program Files\The Ur-Quan Masters\content\packages\uqm-0.6.0-voice.uqm
C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack1.zip
C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack2.zip
C:\Program Files\The Ur-Quan Masters\content\addons\remix\uqm-remix-pack3.zip
C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix1.rmp
C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix2.rmp
C:\Program Files\The Ur-Quan Masters\content\addons\remix\remix3.rmp
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.6.0-content.uqm
/Applications/The Ur-Quan Masters/Contents/Resources/content/packages/uqm-0.6.0-voice.uqm
/Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip
/Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip
/Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/uqm-remix-pack1.zip
/Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix1.rmp
/Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix2.rmp
/Applications/The Ur-Quan Masters/Contents/Resources/content/addons/remix/remix3.rmp

On Linux

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.6.0-content.uqm
/usr/local/share/uqm/content/packages/uqm-0.6.0-3domusic.uqm
/usr/local/share/uqm/content/packages/uqm-0.6.0-voice.uqm
/usr/local/share/uqm/content/addons/remix/uqm-remix-pack1.zip
/usr/local/share/uqm/content/addons/remix/uqm-remix-pack2.zip
/usr/local/share/uqm/content/addons/remix/uqm-remix-pack3.zip
/usr/local/share/uqm/content/addons/remix/remix1.rmp
/usr/local/share/uqm/content/addons/remix/remix2.rmp
/usr/local/share/uqm/content/addons/remix/remix3.rmp
/usr/local/share/uqm/content/version

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.

Top-Level Roadmap

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. In progress.
Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. In progress, but largely blocked on the previous step.

Current goals

The ResMap resource system has broken the "resource = specific file" 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.

Uniform reference to file-type resources. Completed in Revision 2903. This also let us actually start using malloc and free for our memory management directly.
Retire the RES_INDEX type, merging all resource number -> resource name data into a single index. Completed in Revision 2958.
Split out STRTAB (which are text) from BINTAB (the .ct and .xlt files). They share a load function at present, very uncomfortably. Completed in Revision 2968.
The current resource vtable implementation is pretty ugly. We can probably fold it into the master map as well. Completed in Revision 2969.
The resource vtable should not automatically assume its value is a file, but should instead have a separate parse step. Completed in version 2970.
- Retire the CODE type, which isn'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. Completed in Revision 2971.
- Treat UNKNOWNRES - that is, an illegal or absent resource type - as if it were essentially a STRING. Completed in Revision 2971.
- INT32 integral value type. Completed in Revision 2973, but will remain unused until configuration is merged or hardcoded data is removed.
- STRING value type. Completed in Revision 2973, but will remain unused until configuration is merged or hardcoded data is removed.
- BOOLEAN value type. Completed in Revision 2973, but will remain unused until configuration is merged or hardcoded data is removed.
- CONVERSATION value type, with subvalues for phrases, voice directory, and timestamps. Completed in Revision 2978.
- Value types for the 3DO videos.

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.

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.

Keep user settings in a resource-map. Completed in Revision 1916.
Keep key configuration in a resource-map. Completed in Revision 2705.
Keep Melee configuration in a resource-map.
Allow loads of resource files to be placed into isolated submaps to keep values separated.
- 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.
Merge all three into the main resource map.
- Old user configurations will be all of type UNKNOWNRES and be located in the wrong place. This will make auto-migration possible.

Other work

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.
- Note that an SVN update following an SVN move will redownload all content, so we should be very sure about where we're moving the voice packs before actually performing the move.
- Doing this right really requires at least resource support for voice clips and timestamps. Rehardcoding voice data locations might work as a stopgap.
- 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.)
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.
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.