HUD modifications may range from simple name changes for weapons/items to complete overhauls with little or no similarity to the original Marathon Infinity HUD.

Here is a list of the various bits and pieces that go to make up the HUD:

ResEdit:

CLUT

Resource ID130 contains a number of entries, some of which are used for the HUD display (however, I've included them all here for convenience):

Bear in mind that you should probably try to use colors from the standard Marathon Infinity palette to ensure consistent results on 8-bit displays.

STR#

nrct

This defines where main controls screen buttons and HUD items go. [Credit to Mike Trinder for figuring this one out.] There is only one resource (#128) with 18 entries. Rectangles 1 to 7 define the HUD layout (Rectangles 8-18 define the Main Controls screen buttons). Each defines a rectangle (with exception of #4) with coordinates listed in order of TOP, LEFT, BOTTOM, RIGHT:

Notes on nrct entries:

1. #4 (motion detector) is an exception to the rule: only the TOP-LEFT coordinates are defined; since height and width are fixed anyway, BOTTOM and RIGHT coords are not defined. [Note that this causes an 'invalid rectangle' warning to show in ResEdit, but don't worry about this.]
2. In all Rectangles the top and left values are inclusive, but the bottom and right ones are exclusive (i.e. they aren't part of the 'active' area).
3. For the net player name (#1), only the text box position is defined - the graphic that appears behind it (and blanks the text every time you switch to a different net player's view) is fixed in position (although not in size). The inability to move the graphic's position does limit how much you can move the net player name about (though it's obviously not relevant in solo-only projects).
4. For oxygen and shield bars, if you alter their dimensions in the nrct resource, you must remember to replace the relevant bitmaps in the Shapes file Interface collection with appropriately sized versions, otherwise you'll get ugly artifacts drawn on screen (still, not as bad as Marathon 2/Win, where the drawing routines are less robust and crash hard if you get the sizes wrong). Both length and height of each bar is entirely arbitrary - you can make them any size you like (although there's no way to make the bars run vertical, Marathon 1-style, in case you were wondering:). Bear in mind that an energy bar equals 150 steps, an oxygen bar is 10800 steps (depletes 1 unit/tick for 6 minutes), so the engine will scale this as best it can for the length of your bars.
5. The inventory list can be made any size desired, but note that it can't be scrolled by the player; if you make it too short to display the list for a full load of armaments then some of your weapons info will end up off-screen and unreadable (unlikely to be popular with players).
6. The weapon-in-use rect effectively serves to blank that part of the display every time you switch weapons. Note that the various bits which appear in this area (weapon graphic, ammo readout, weapon name) do not have to appear within this rectangle; however, anything which falls outside won't be automatically cleared when you switch weapons (so unless you've got a particularly cunning design worked out, this will probably mean you get all sorts of ugly leftover bits of graphic/text left strewn across your HUD).
7. Note that the positions of weapon graphic, ammo readout, weapon name are independent to the position of the weapon-in-use rect , so if you move one then you really need to move everything else too. Their positions/sizes are defined within the main app, and can be altered via Fux (see below).
8. Avoid overlapping Rectangles as this may lead to unpredictable side-effects.

(Editors note: With apologies to HAS and Mike Trinder, the above table makes me crazy trying to grok it. While it is true that the data in the nrct resource is presented as shown above it helps to get a handle on the areas plotted via XY coordinates. I am too used to working with the XY coordinate system and for those of you who have similar disgusting needs, below is the same information in the XY coordinate system. - gls 09/26/2000)

Notes for the above table:

1. The coordinates of Item 4 does not describe a rectangle. Instead, "17" describes only the X component of the far left edge of the "changeable portion" of the Motion Detector and "338" describes only the Y component of the far upper edge of the "changeable portion of the Motion Detector.
2. Please be aware that these XY coordinates are not plotted from the Images File HUD graphic alone, you MUST factor in the entire screen in order for these coordinates to be accurate. Take a screen shot of Marathon 2/Infinity and take your cues from that, the X,Y coordinates line up exactly.
3. The original 8 notes given above by HAS still apply here. (gls - 09/28/2000)

finf

[Credit to Mike Trinder again for figuring this one out too.] This is another standard Mac resource for listing a series of Font Number, Style and Size parameters. Note that all entries are shown in 2-byte hexadecimal (e.g. $000A, $0016) though you can type them in in decimal ok as long as you remember not to include the '$' (which denotes 'hexadecimal').

Only hard thing is the font numbering system: this is easy for the apple defined fonts, but for commercial fonts things are more complex as the ID's can change dynamically to resolve conflicts. What you want is what is known as the family ID - a few easy ones are:

ID Font Family

$0000 - system font (not necessarily Chicago:)
$0001 - application font (not necessarily Geneva either),
$0003 - Geneva
$0004 - Monaco
$0014 - Times
$0015 - Helvetica
$0016 - Courier

(The Family ID is the second entry in the FOND resource. within the screen/TrueType font's resource fork.)

Basic styles are as follows:

$0000 - plain
$0001 - bold
$0002 - italic
$0004 - underlined

These can be combined, e.g. $0007 = bold+italic+underlined

The finf resource has either 2 or 3 entries, depending on which version of Marathon Infinity you have (v1.5 has an additional entry ID129). Not all have been identified, but here are the ones that have.

ID128 has 7 entries:

1. $0004, $0001, $0009 = Monaco, Bold, 9 point. This is the Weapon/Inventory list text, but not the number of each item that you are holding. changing font/style/size is OK, and even changes the dark green background that the list title is drawn on.
2. $0004, $0001, $0009 = Monaco, Bold, 9 point. This is the description below the weapon graphic. It is not clipped the weapon graphic rect in the nrct resource, so make sure the text doesn't go outside the nrct (or make the rect bigger) or you will leave green pixels lying about.
3. $0004, $0001, $0009 = Monaco, Bold, 9 point. (?) (Not sure, but could be the Net Name. Not tested as no-one about to play against.)
4. $0004, $0000, $0009 = Monaco, Plain, 9 point. Weapon/Inventory list numbers.
5. $0016, $0000, $000C = Courier,Plain, 12 point. Terminal text. Style affects the top and bottom status bar text, but the inherent styles of the terminal text override. Size is respected... 9 point looked lovely. [Mike T reported having some hangs and the like as the level was loading when terminal text was changed to Geneva ($0003) instead of courier. I've changed it to both Geneva and Charcoal without trouble, although in any case this is the sort of thing that should be tested thoroughly before use. BTW, it looked pretty good in Charcoal (I used an embedded copy, which would be a good idea if I distributed the mod because Charcoal isn't present on pre-OS8 systems).]
6. $0016, $0001, $000E = Courier, Bold, 14 point. (?)
7. $0004, $0000, $0009 = Monaco, Plain, 9 point. (?)

If you decide to change the fonts used then make sure you know what you are doing. Geneva, Monaco, Times, Helvetica and Courier are pretty much standard on all Macs, so are safe bets. If you decide to change to anything else, however, then you must supply the relevant font with the game in some way (note that shareware/commercial fonts may have restrictions on how they may be used, so shipping copies of fonts used with your scenario may not be legal) - you cannot assume that other folks will have the same fonts as you. A common mistake made by folks creating fancy readmes, etc. using all sorts of custom fonts used is that they forget that other folks may not have those same fonts on their systems (hence the not unusual experience of opening a DocMaker manual only to be told that 'fonts x,y and z cannot be found' and finding that the doc's layout is messed up as a result, and certainly not as the original author intended it).

Shipping fonts that have to be installed by the user into their Fonts folder is not generally a good idea (not everyone likes to have their Fonts folder stuffed full of fonts that aren't theirs). There does seem to be a way around this, however; fonts may be merged into the Marathon app itself. The Marathon app will then see and use these fonts (overriding any external fonts in the process), and you'll only need to include those fonts used by the game itself. If using Postscript fonts, then you should ensure you have a screen [bitmap] font of the appropriate size (screen fonts are fixed in size and do not scale smoothly); you do not include the printer font, obviously. For either type (screen and/or TrueType) of font, it's a simple matter of copying the contents into the Marathon Infinity app using ResEdit, and then altering the finf to suit. Again, bear in mind any restrictions placed on the use of a font in its license; just because a font is embedded into an application doesn't mean the license doesn't still apply.

Note that it is possible to edit screen fonts directly in ResEdit to some extent (i.e. modify their bitmaps - note that the Pfhorathon HUD used a modified Courier screen font where I replaced the letter forms with something a bit more 'alien' for effect). However, for most font editing you really do need the proper tools.

One other thing: although there shouldn't be any technical problems with using just about any font, you should be careful to pick one that will be readable at small sizes. Most fonts are designed for print rather than screen use and won't be clear and easy to read on-screen. It has to be said that this is one of the major advantages of Geneva/Monaco et al - they may not look all that exciting, but they remain very readable even at small sizes, unlike many others. Highly stylized fonts are usually a dead loss, however, and should be avoided. If you wish, and are able, to create your own custom screen fonts then good luck to you, otherwise take care as to what you use.

Fux!:

Fux allows you to modify the placement of the weapon-in-use items: weapon graphic, ammo readout(s) and weapon name. You'll find all the relevant settings under 'Weapons'. See the Fux readme for details on the various fields - it is fairly self-explanatory. This is of particular use if you alter a weapon's ammo capacity (so that you can have a suitable readout), or if you move the position of the entire weapon-in-hand rectangle (in which case you'll also want to move its contents).

Notes: for widths and heights of arrays, the height equals the height of the relevant bitmap (= 1 row), whilst the width equals the width of one division (= 1 column, = 1 ammo round). If you change these values, don't forget to alter the bitmaps to suit too.

If you wish to add additional array bitmaps to the Shapes file Interface collection (e.g. you change fusion pistol and/or flamethrower to use array readouts for ammo) then you can add them to the end of the collection. However, to make the Marathon Infinity engine load them, you'll need to assign additional Frames (see the section on adding additional textures (coming soon) for more info).

Other notes:

HUD modifications can go a long way to changing the look of the standard Marathon Infinity engine. For some good examples, check out the Muerte Machine, Pfhorathon and Wheels projects - these are some of the more radical HUD alterations around. But even for more minor alterations, such as altering the weapon display and inventory to reflect some changes to weapon types/behavior, it is well worth doing. The above info pretty much covers everything, so it shouldn't be too hard for others to follow, but as with all mods, remember to test really thoroughly (and under a wide variety of conditions/systems) to ensure that all is well with the changes before distribution.