Content Management

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.

1. Implement a generic string-based key-to-value system for doing resource lookups. Completed in Revision 1916.
2. Drop requirement on binary resource indices by translating them to text. Completed in Revision 2003.
3. Replace the integer-based resource system with string-based key mappings that are easier to extend. Completed in Revision 2963.
4. Rework resource types to allow for a wider range of resources. In progress, but only refactoring, cleanup, and testing remains.
5. Uniform API for all uses of the resource-map system, merging about six redundant subsystems into one. In progress.

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.
• 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's type before actually loading it. Completed in Revision 3099.
• 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. Completed in Revision 3101.
    • Rewrite the presentation code to more uniformly handle 3DO videos vs. String-based presentations. Completed in Revision 3101.

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.
• 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.