Difference between revisions of "Object List file"
Jessietail (talk | contribs) |
Jessietail (talk | contribs) |
||
| Line 1: | Line 1: | ||
'''Object List''' files are configuration files used in the Windows PC version of ''[[LEGO Rock Raiders (PC game)|LEGO Rock Raiders]]'' to designate the starting locations of [[Rock Raider]]s, [[Rock Raiders buildings|buildings]], [[Rock Raiders vehicles|vehicles]], [[Rock Raiders creatures|creatures]], [[building materials]], [[web]]s, and the [[game camera]] within levels. They use the filename extension <code>.ol</code>, though they're essentially just [[Wikipedia:Text file|text files]]. Each level's Object List is linked to in that level's section in [[Lego.cfg]] using the property | '''Object List''' files are configuration files used in the Windows PC version of ''[[LEGO Rock Raiders (PC game)|LEGO Rock Raiders]]'' to designate the starting locations of [[Rock Raider]]s, [[Rock Raiders buildings|buildings]], [[Rock Raiders vehicles|vehicles]], [[Rock Raiders creatures|creatures]], [[building materials]], [[web]]s, and the [[game camera]] within levels. They use the filename extension <code>.ol</code>, though they're essentially just [[Wikipedia:Text file|text files]]. Each level's Object List is linked to in that level's section in [[Lego.cfg]] using the property <code>OListFile</code>, and is by default located within that level's folder. | ||
== Formatting == | == Formatting == | ||
Like other configuration files in ''LEGO Rock Raiders'', Object List files are written with braced sections that are human-readable. The entirety of each file's data is contained within a <code>Lego* {}</code> section. Each listed object is then given its own section with a unique name. While the section name of an object can be anything, it's typically in the format <code>Object# {}</code>, using a sequential number in place of <code>#</code>, in order to keep track of the amount of objects used in the level. | Like other configuration files in ''LEGO Rock Raiders'', Object List files are written with braced sections that are human-readable. The entirety of each file's data is contained within a <code>Lego* {}</code> section. Each listed object is then given its own section with a unique name. While the section name of an object can be anything, it's typically in the format <code>Object# {}</code>, using a sequential number in place of <code>#</code>, in order to keep track of the amount of objects used in the level.<!--Any special objects that are used in script are referred to using this name. I wasn't sure what this sentence meant so I blanked it out for now--> An Object List can have a maximum of 200 entries; going over this limit exceeds its memory pool, causing the level to crash{{Verify}}. | ||
Object Lists use the unique object TVCamera, which is not defined in Lego.cfg at all. This object is the game camera, and its position and facing angle determine where and what direction the player will be looking at upon the start of a level. If an Object List doesn't have a camera defined, one will be placed when the level has loaded, facing straight down in the center of the map{{verify}}. | |||
If there are no Rock Raiders or buildings exposed at the start of the level, the level will load, but will softlock on the first page of the level's mission briefing. | |||
=== Properties === | === Properties === | ||
| Line 19: | Line 15: | ||
==== xPos/yPos ==== | ==== xPos/yPos ==== | ||
The <code>xPos</code> and <code>yPos</code> properties set the position of an object in a level. Positions are based on the blocks designated in the [[Terrain map]], with each corner of a block being a whole number coordinate and (0,0) starting in the very top left corner of the map. Six decimal places can be used for coordinate within each block, allowing for very precise positioning of objects. Because coordinates are relative to blocks rather than based off of an absolute distance system, the actual distance between objects can change depending on what a level's <code>BlockSize</code> is set to; however, in the default game, it is always <code>40</code>. | The <code>xPos</code> and <code>yPos</code> properties set the position of an object in a level. Positions are based on the blocks designated in the [[Terrain map]], with each corner of a block being a whole number coordinate and (0,0) starting in the very top left corner of the map. Six decimal places can be used for coordinate within each block, allowing for very precise positioning of objects; however, buildings will always revert to the center of whichever block the main part of their construction is in. Because coordinates are relative to blocks rather than based off of an absolute distance system, the actual distance between objects can change depending on what a level's <code>BlockSize</code> is set to; however, in the default game, it is always <code>40</code>. | ||
==== Heading ==== | ==== Heading ==== | ||
The <code>heading</code> property defines what direction an object is facing. | The <code>heading</code> property defines what direction an object is facing. Facing angle is measured in degrees in typical compass format, with <code>0</code> facing towards the top of the map, <code>90</code> facing to the right side, <code>180</code> facing towards the bottom, and <code>270</code> facing towards the left side. Values of <code>360</code> and onward can be used, but will be read as their coterminal equivalent below 360 degrees (e.g. 540=180). Like positions, six decimal places are typically used to allow for very precise rotation; however, buildings will always revert to one of the four cardinal directions, rotating to the next one clockwise every 45.000002 degrees after the previous one. | ||
==== Driving ==== | ==== Driving ==== | ||
| Line 30: | Line 26: | ||
==== Health ==== | ==== Health ==== | ||
The <code>health</code> property designates how much health a unit has at the start of a level. Health can be set to a value over <code>100</code>, allowing units to take far more damage than should be possible. However, buildings will reset to a health of <code>100</code> when attacked by monsters or struck by thrown boulders; other forms of damage will not cause this effect. Likewise, health can be set to a negative number such as <code>-1.0</code>, which will cause that object to immediately be teleported out or destroyed when the level starts or when the cavern it's contained in is discovered. However, setting an object's health to exactly <code>0.0</code> will have no effect. | The <code>health</code> property designates how much health a unit has at the start of a level. Health can be set to a value over <code>100</code>, allowing units to take far more damage than should be possible. However, buildings will reset to a health of <code>100</code> when attacked by monsters or struck by thrown boulders; other forms of damage will not cause this effect. Likewise, health can be set to a negative number such as <code>-1.0</code>, which will cause that object to immediately be teleported out or destroyed when the level starts or when the cavern it's contained in is discovered. However, setting an object's health to exactly <code>0.0</code> will have no effect. | ||
=== Example setup === | |||
Here is an example of a complete Object List: | |||
Lego* { | Lego* { | ||
Revision as of 00:59, 18 September 2017
Object List files are configuration files used in the Windows PC version of LEGO Rock Raiders to designate the starting locations of Rock Raiders, buildings, vehicles, creatures, building materials, webs, and the game camera within levels. They use the filename extension .ol, though they're essentially just text files. Each level's Object List is linked to in that level's section in Lego.cfg using the property OListFile, and is by default located within that level's folder.
Formatting
Like other configuration files in LEGO Rock Raiders, Object List files are written with braced sections that are human-readable. The entirety of each file's data is contained within a Lego* {} section. Each listed object is then given its own section with a unique name. While the section name of an object can be anything, it's typically in the format Object# {}, using a sequential number in place of #, in order to keep track of the amount of objects used in the level. An Object List can have a maximum of 200 entries; going over this limit exceeds its memory pool, causing the level to crash[verify].
Object Lists use the unique object TVCamera, which is not defined in Lego.cfg at all. This object is the game camera, and its position and facing angle determine where and what direction the player will be looking at upon the start of a level. If an Object List doesn't have a camera defined, one will be placed when the level has loaded, facing straight down in the center of the map[verify].
If there are no Rock Raiders or buildings exposed at the start of the level, the level will load, but will softlock on the first page of the level's mission briefing.
Properties
Object List files have six properties that can be applied to each object's section. Only the first four are necessary for every object; in the default game, driving is only used in Run The Gauntlet by default, and health is not used at all.
Type
The type property is used to define what an object is. This can be set to any of the objects defined in the MiscObjects {}, VehicleTypes {}, MiniFigureTypes {}, RockMonsterTypes {}, and BuildingTypes {} sections. For example, placing a Rock Raider in a level would require the property type Pilot.
xPos/yPos
The xPos and yPos properties set the position of an object in a level. Positions are based on the blocks designated in the Terrain map, with each corner of a block being a whole number coordinate and (0,0) starting in the very top left corner of the map. Six decimal places can be used for coordinate within each block, allowing for very precise positioning of objects; however, buildings will always revert to the center of whichever block the main part of their construction is in. Because coordinates are relative to blocks rather than based off of an absolute distance system, the actual distance between objects can change depending on what a level's BlockSize is set to; however, in the default game, it is always 40.
Heading
The heading property defines what direction an object is facing. Facing angle is measured in degrees in typical compass format, with 0 facing towards the top of the map, 90 facing to the right side, 180 facing towards the bottom, and 270 facing towards the left side. Values of 360 and onward can be used, but will be read as their coterminal equivalent below 360 degrees (e.g. 540=180). Like positions, six decimal places are typically used to allow for very precise rotation; however, buildings will always revert to one of the four cardinal directions, rotating to the next one clockwise every 45.000002 degrees after the previous one.
Driving
The driving property allows an object to start the level driving another object. This property must be defined as the section name of the object intended to be driven. The position and heading of the object with this property will be ignored in favor of those of the driven object (though if the driven object lacks proper animation nulls as well as the InvisibleDriver property, the driver's motionless model may appear at its starting location despite not actually being there). If one of the objects is in a hidden cavern while the other is not or is in a separate hidden cavern, this property will be ignored entirely.
While this was intended to be used to force a Rock Raider into a vehicle, it can be applied to and point to any two objects. The results of doing this to other object types will usually be strange and sometimes result in game-crashing effects.
Health
The health property designates how much health a unit has at the start of a level. Health can be set to a value over 100, allowing units to take far more damage than should be possible. However, buildings will reset to a health of 100 when attacked by monsters or struck by thrown boulders; other forms of damage will not cause this effect. Likewise, health can be set to a negative number such as -1.0, which will cause that object to immediately be teleported out or destroyed when the level starts or when the cavern it's contained in is discovered. However, setting an object's health to exactly 0.0 will have no effect.
Example setup
Here is an example of a complete Object List:
Lego* {
Object1 {
type Toolstation
xPos 11.500000
yPos 10.500000
heading 180.000000
health 50.000000
}
Object2 {
type Pilot
xPos 12.500000
yPos 11.500000
heading 90.000000
driving Object3
}
Object3 {
type SmallDigger
xPos 12.500000
yPos 11.500000
heading 90.000000
}
Object4 {
type TVCamera
xPos 11.000000
yPos 10.000000
heading 45.000000
}
}
Which generates a Tool Store facing south at (11.5,10.5) with only 50 health points instead of 100, a Rock Raider driving a Small Digger facing east at (12.5,11.5) on the block southeast of the Tool Store, and the camera facing northeast towards the Tool Store.
Modding
Object List files are unencrypted and can easily be edited with even Notepad.
To do: write editing OL files after forums are back up
