unindent MarathonData
parent
85a4d3c990
commit
0a4e32c794
170
MarathonData.md
170
MarathonData.md
|
@ -1,17 +1,17 @@
|
|||
# LICENSING ###################################################################
|
||||
|
||||
To the extent possible under law, I, Alison Sanderson, have waived all
|
||||
copyright and related or neighboring rights to this Document as described
|
||||
by the Creative Commons Zero license linked below.
|
||||
copyright and related or neighboring rights to this Document as described by
|
||||
the Creative Commons Zero license linked below.
|
||||
|
||||
<http://creativecommons.org/publicdomain/zero/1.0/>
|
||||
|
||||
All of the information in this Document is original research. Marathon and
|
||||
Forge are owned by Bungie, Inc. QuickDraw, QuickTime and Macintosh are owned
|
||||
by Apple. Aleph One (also referred to as A1 in this Document) is owned by
|
||||
Bungie, Inc. et al. Igni Ferroque, Ferro, and Atque are owned by Gregory
|
||||
Smith (treellama.) Maraiah is owned by Project Golan. Any other copyrights
|
||||
belong to their respective owners.
|
||||
Forge are owned by Bungie, Inc. QuickDraw, QuickTime and Macintosh are owned by
|
||||
Apple. Aleph One (also referred to as A1 in this Document) is owned by Bungie,
|
||||
Inc. et al. Igni Ferroque, Ferro, and Atque are owned by Gregory Smith
|
||||
(treellama.) Maraiah is owned by Project Golan. Any other copyrights belong to
|
||||
their respective owners.
|
||||
|
||||
# CONTENTS ####################################################################
|
||||
|
||||
|
@ -31,32 +31,32 @@
|
|||
|
||||
# TERMINAL CODE ###############################################################
|
||||
|
||||
The terminal definition format is extremely straightforward.
|
||||
Terminal commands begin lines and are in the format:
|
||||
The terminal definition format is extremely straightforward. Terminal commands
|
||||
begin lines and are in the format:
|
||||
|
||||
```
|
||||
#COMMAND_NAME parameters
|
||||
```
|
||||
|
||||
In Forge and Maraiah, commands need not be uppercase.
|
||||
Atque does require all commands to be uppercase.
|
||||
In Forge and Maraiah, commands need not be uppercase. Atque does require all
|
||||
commands to be uppercase.
|
||||
|
||||
Comments also begin lines (they can't be after the beginning of one) and
|
||||
will disable any text proceeding them. They are formed like:
|
||||
Comments also begin lines (they can't be after the beginning of one) and will
|
||||
disable any text proceeding them. They are formed like:
|
||||
|
||||
```
|
||||
; comment content here
|
||||
```
|
||||
|
||||
Terminals are numbered, and this is used in the map to determine which
|
||||
terminal to display when a computer is used.
|
||||
Terminals are numbered, and this is used in the map to determine which terminal
|
||||
to display when a computer is used.
|
||||
|
||||
## Blocks ##
|
||||
|
||||
### Terminal Blocks ###
|
||||
|
||||
The number for the terminal being currently defined is set with
|
||||
the `#TERMINAL` and `#ENDTERMINAL` commands. These are formed as:
|
||||
The number for the terminal being currently defined is set with the `#TERMINAL`
|
||||
and `#ENDTERMINAL` commands. These are formed as:
|
||||
|
||||
```
|
||||
#TERMINAL number
|
||||
|
@ -75,8 +75,8 @@
|
|||
|
||||
### Sections ###
|
||||
|
||||
There are four possible sections in a terminal, which are between
|
||||
the `#TERMINAL` and `#ENDTERMINAL` blocks:
|
||||
There are four possible sections in a terminal, which are between the
|
||||
`#TERMINAL` and `#ENDTERMINAL` blocks:
|
||||
|
||||
```
|
||||
#UNFINISHED
|
||||
|
@ -85,8 +85,8 @@
|
|||
#SUCCESS
|
||||
```
|
||||
|
||||
These all mark the start of where the terminal will display, depending on
|
||||
the current status of your mission.
|
||||
These all mark the start of where the terminal will display, depending on the
|
||||
current status of your mission.
|
||||
|
||||
| Name | Will display when |
|
||||
| ---- | ----------------- |
|
||||
|
@ -101,18 +101,17 @@
|
|||
#END
|
||||
```
|
||||
|
||||
Between sections may be any amount of regular commands.
|
||||
There are two kinds of these normal commands: Text commands, and interactive
|
||||
commands.
|
||||
Between sections may be any amount of regular commands. There are two kinds of
|
||||
these normal commands: Text commands, and interactive commands.
|
||||
|
||||
## Text Commands ##
|
||||
|
||||
All text commands may have (but do not require) text following them,
|
||||
which may be formatted.
|
||||
All text commands may have (but do not require) text following them, which may
|
||||
be formatted.
|
||||
|
||||
Line breaks will break in-game, but unbroken lines will automatically wrap.
|
||||
It is generally best to just put all of your text onto one line, even if
|
||||
this destroys your sanity. Use a text editor with line wrapping for this.
|
||||
Line breaks will break in-game, but unbroken lines will automatically wrap. It
|
||||
is generally best to just put all of your text onto one line, even if this
|
||||
destroys your sanity. Use a text editor with line wrapping for this.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -170,10 +169,10 @@
|
|||
* Display 45 characters per line, and display up to 22 lines on one page.
|
||||
* Display text aligned to the left on the right side of the screen.
|
||||
|
||||
If alignment is specified as RIGHT, text is aligned to the right
|
||||
on the left of the screen. If alignment is specified as CENTER, no text may
|
||||
be displayed, only an image. If no alignment is specified, it will default
|
||||
to an image on the left and text on the right.
|
||||
If alignment is specified as RIGHT, text is aligned to the right on the left of
|
||||
the screen. If alignment is specified as CENTER, no text may be displayed, only
|
||||
an image. If no alignment is specified, it will default to an image on the left
|
||||
and text on the right.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -193,8 +192,8 @@
|
|||
|
||||
`#LOGON` and `#LOGOFF` are generally used first and last in a terminal.
|
||||
|
||||
These two display a PICT in the middle of the screen and text below the
|
||||
image if you supply it. They both do things to the screen borders.
|
||||
These two display a PICT in the middle of the screen and text below the image
|
||||
if you supply it. They both do things to the screen borders.
|
||||
|
||||
They will:
|
||||
* Automatically continue, an input will interrupt it.
|
||||
|
@ -240,13 +239,12 @@
|
|||
|
||||
`#CHECKPOINT` may only be used in M1, unless you're using Aleph One 1.1+.
|
||||
|
||||
This shows a map centered on the specified goal point, with the goal
|
||||
circled, on the left of the screen.
|
||||
This shows a map centered on the specified goal point, with the goal circled,
|
||||
on the left of the screen.
|
||||
|
||||
The map will only show polygons connected to the polygon the goal is in,
|
||||
so if you have a separated area where the goal point is, it will only
|
||||
display that. It will also not display secret areas and any polygons
|
||||
proceding them.
|
||||
The map will only show polygons connected to the polygon the goal is in, so if
|
||||
you have a separated area where the goal point is, it will only display that.
|
||||
It will also not display secret areas and any polygons proceding them.
|
||||
|
||||
It will:
|
||||
* Wait for input before proceeding.
|
||||
|
@ -266,13 +264,13 @@
|
|||
#BRIEFING level_number
|
||||
```
|
||||
|
||||
BRIEFING may only be used in Marathon 1. It is identical to INFORMATION,
|
||||
but after you're done reading, it will teleport you to the specified level.
|
||||
BRIEFING may only be used in Marathon 1. It is identical to INFORMATION, but
|
||||
after you're done reading, it will teleport you to the specified level.
|
||||
|
||||
## Interactive Commands ##
|
||||
|
||||
Interactive commands are all actions carried out by the game that
|
||||
do not all effect the active terminal.
|
||||
Interactive commands are all actions carried out by the game that do not all
|
||||
effect the active terminal.
|
||||
|
||||
### Interactive Command Overview ###
|
||||
|
||||
|
@ -292,8 +290,8 @@
|
|||
#INTERLEVEL TELEPORT level_number
|
||||
```
|
||||
|
||||
`#INTERLEVEL TELEPORT` exits the terminal and teleports you to the
|
||||
specified level. If the level number is "256", this ends the game.
|
||||
`#INTERLEVEL TELEPORT` exits the terminal and teleports you to the specified
|
||||
level. If the level number is "256", this ends the game.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -307,8 +305,8 @@
|
|||
#INTRALEVEL TELEPORT polygon_tag
|
||||
```
|
||||
|
||||
`#INTRALEVEL TELEPORT` exits the terminal and teleports you to the centroid
|
||||
of the specified polygon within the map.
|
||||
`#INTRALEVEL TELEPORT` exits the terminal and teleports you to the centroid of
|
||||
the specified polygon within the map.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -336,8 +334,7 @@
|
|||
#SOUND sound_number
|
||||
```
|
||||
|
||||
`#SOUND` plays the specified sound from the Sounds file or from the
|
||||
Scenario/Map file.
|
||||
`#SOUND` plays the specified sound from the Sounds file or from the Scenario.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -379,7 +376,7 @@
|
|||
| `LITE` | Array of Lights |
|
||||
| `NOTE` | Not analyzed (annotations) |
|
||||
| `OBJS` | Array of Objects |
|
||||
| `p'th` | No test data (' is $8C) (guardpaths) |
|
||||
| `påth` | No test data (å is $8C) (guardpaths) |
|
||||
| `Minf` | Static Map Info |
|
||||
| `plac` | Not analyzed (item placement) |
|
||||
| `door` | No test data (extra door data) |
|
||||
|
@ -396,10 +393,10 @@
|
|||
|
||||
Map files can be identified by the Minf chunk.
|
||||
|
||||
Map files will always have either a PNTS or EPNT chunk, depending on what
|
||||
the map (and editor) use. PNTS are plain and have no more information than
|
||||
the actual position, while EPNT has flags and some extra stuff to help the
|
||||
engine load quicker (not that it needs it.)
|
||||
Map files will always have either a PNTS or EPNT chunk, depending on what the
|
||||
map (and editor) use. PNTS are plain and have no more information than the
|
||||
actual position, while EPNT has flags and some extra stuff to help the engine
|
||||
load quicker (not that it needs it.)
|
||||
|
||||
### Marathon 1 Scenarios (`.scen`) ###
|
||||
|
||||
|
@ -471,10 +468,9 @@
|
|||
|
||||
### Wad Header ###
|
||||
|
||||
The Wad header is always at the very beginning of the file, except when
|
||||
it's a MacBin file or an AppleSingle file, in which case it's at the start
|
||||
of the resource fork. You'll have to account for that yourself. An example
|
||||
of a proper header loader that handles both is attached.
|
||||
The Wad header is always at the very beginning of the file, except when it's a
|
||||
MacBin file or an AppleSingle file, in which case it's at the start of the
|
||||
resource fork. You'll have to account for that yourself.
|
||||
|
||||
The Wad Header is 128 bytes.
|
||||
|
||||
|
@ -495,9 +491,9 @@
|
|||
| u16 | Size of chunks | ChunkSize |
|
||||
| u16 | Size of directory entries | EntrySize |
|
||||
|
||||
ChunkSize and EntrySize may be zero, in which case it will default to
|
||||
16 and 10 respectively. They exist for forward compatibility with Wad
|
||||
patching, although are actually pointless and serve no practical purpose.
|
||||
ChunkSize and EntrySize may be zero, in which case it will default to 16 and 10
|
||||
respectively. They exist for forward compatibility with Wad patching, although
|
||||
are actually pointless and serve no practical purpose.
|
||||
|
||||
If WadVer is greater than or equal to VerOver:
|
||||
|
||||
|
@ -507,9 +503,9 @@
|
|||
|
||||
### Directory Entry ###
|
||||
|
||||
Following this structure is AppData bytes (N), supposed to be used by
|
||||
editor applications for storing arbitrary extra data, and will be ignored by
|
||||
the engine.
|
||||
Following this structure is AppData bytes (N), supposed to be used by editor
|
||||
applications for storing arbitrary extra data, and will be ignored by the
|
||||
engine.
|
||||
|
||||
Directory Entry is 8 bytes if WadVer is VerBase, or EntrySize+AppData bytes.
|
||||
|
||||
|
@ -527,9 +523,9 @@
|
|||
|
||||
### Chunk ###
|
||||
|
||||
Most Wad entries are made up of tagged data formats, the engine assumes
|
||||
this for every entry and so every entry has at least one chunk.
|
||||
These are similar to IFF or PNG chunks.
|
||||
Most Wad entries are made up of tagged data formats, the engine assumes this
|
||||
for every entry and so every entry has at least one chunk. These are similar to
|
||||
IFF or PNG chunks.
|
||||
|
||||
Chunk is 12 bytes if WadVer is VerBase, or ChunkSize bytes.
|
||||
|
||||
|
@ -729,9 +725,9 @@
|
|||
| u8[66] | Level name | Name |
|
||||
| u32 | Entry point flags | EntryFlags |
|
||||
|
||||
The level name was intended to be 65 bytes, but one padding byte was left
|
||||
over, so the real length is 66 bytes. It is unknown why the entry point
|
||||
flags are stored in a 32-bit integer when they can fit in 8 bits.
|
||||
The level name was intended to be 65 bytes, but one padding byte was left over,
|
||||
so the real length is 66 bytes. It is unknown why the entry point flags are
|
||||
stored in a 32-bit integer when they can fit in 8 bits.
|
||||
|
||||
## Terminal ##
|
||||
|
||||
|
@ -789,10 +785,10 @@
|
|||
|
||||
### Picture Resource ###
|
||||
|
||||
Pictures are formed with a header and then a variable number of operations.
|
||||
In other words, a small state machine is used to form an image through
|
||||
effects and various fill instructions. QuickDraw is horrifying. This is the
|
||||
native image format. It's a fucking metafile.
|
||||
Pictures are formed with a header and then a variable number of operations. In
|
||||
other words, a small state machine is used to form an image through effects and
|
||||
various fill instructions. QuickDraw is horrifying. This is the native image
|
||||
format. It's a fucking metafile.
|
||||
|
||||
* Picture Header
|
||||
* Picture Opcodes
|
||||
|
@ -924,19 +920,19 @@
|
|||
|
||||
# ENUMERATIONS ################################################################
|
||||
|
||||
Here is a list of names and descriptions for enumerations used throughout
|
||||
this document. The names may not match those used in the original engine
|
||||
and are re-named for clarity of purpose.
|
||||
Here is a list of names and descriptions for enumerations used throughout this
|
||||
document. The names may not match those used in the original engine and are
|
||||
re-named for clarity of purpose.
|
||||
|
||||
### Picture Opcode ###
|
||||
|
||||
Operations used in QuickDraw images. Aleph One ignores most of these, so
|
||||
it's only necessary to document what's ignored and how to process CopyBits.
|
||||
(If you're interested in the QuickDraw format, Apple has legacy documents
|
||||
still available on the Internet.)
|
||||
Operations used in QuickDraw images. Aleph One ignores most of these, so it's
|
||||
only necessary to document what's ignored and how to process CopyBits. (If
|
||||
you're interested in the QuickDraw format, Apple has legacy documents still
|
||||
available on the Internet.)
|
||||
|
||||
Opcodes `$0100` through `$7FFF` are skipped by seeking forward by
|
||||
the most significant byte's value times two.
|
||||
Opcodes `$0100` through `$7FFF` are skipped by seeking forward by the most
|
||||
significant byte's value times two.
|
||||
|
||||
Opcodes `$8000` through `$8100` are reserved and therefore ignored.
|
||||
|
||||
|
@ -1068,8 +1064,8 @@
|
|||
| 4 | First texture for ceiling panel, second for floor | Split |
|
||||
|
||||
"Panel" here refers to a pertrusion inbetween two polygons. These would be
|
||||
mapped to upper/lower textures in Doom for instance. Even the source code
|
||||
for Marathon 2 itself acknowledges how redundant this enumeration is.
|
||||
mapped to upper/lower textures in Doom for instance. Even the source code for
|
||||
Marathon 2 itself acknowledges how redundant this enumeration is.
|
||||
|
||||
### Saved Object Group ###
|
||||
|
||||
|
|
Loading…
Reference in New Issue