Difference between revisions of "Object List file"

From RRU Knowledge Base
(Created page with "{{WIP}} '''Object List''' files are configuration files used in the Windows PC version of ''LEGO Rock Raiders'' to designate the locations of o...")
 
m
 
(38 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{WIP}}
'''Object List''' files are configuration files used in ''[[LEGO Rock Raiders (video game)#Windows version|LEGO Rock Raiders]]'' for Windows to designate the starting locations of [[Rock Raider]]s, [[Rock Raider buildings|buildings]], [[Rock Raider vehicles|vehicles]], [[Rock Raider creatures|creatures]], [[building materials]], [[spider web]]s, and the [[game camera]] within [[LEGO Rock Raiders missions|missions]]. They use the filename extension <code>.ol</code>, though they are essentially just [[Wikipedia:Text file|text files]]. Each mission's Object List file is linked to in that mission's section in [[Lego.cfg]] using the property <code>OListFile</code>, and is by default located within that level's folder.
'''Object List''' files are configuration files used in the Windows PC version of ''[[LEGO Rock Raiders (PC game)|LEGO Rock Raiders]]'' to designate the locations of objects within levels. They use the filename extension <code>.ol</code>, though any extension can be used as long as the file's actual formatting remains the same. Each level has its own Object List file, located in its folder by default and defined in each level's section in [[Lego.cfg]] using the line<!--or code or flag or what? dunno what the correct terminology is--> <tt>OListFile</tt>.


==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 {{block|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 {{block|Object#}}, using a sequential number in place of <code>#</code>, 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}}.


One of several [[Level Files]] located in a Mission's level folder, the '''OL File''' designates the locations of [[Objects]], such as [[Rock Raiders buildings|Buildings]], [[Rock Raiders vehicles|vehicles]], [[The Rock Raider|Rock Raiders]], [[Rock Raiders creatures|creatures]], and the [[Camera]].  It is unencrypted and easily editable in notepad or more preferably using the [[RRU Level Editor]]. Each entry in the OL File designates the coordinates and facing angle of a certain object.  Buildings are often placed with the main part of the construction in the center of a square (ex: 7.5, 8.5), with the [[Power Path]] part of the construction pointing towards the facing angle.  The facing angle or heading is in degrees in typical compass format, with 0 degrees pointing to the top of the map, and 90 degrees pointing to the right side of the map.  The maximum number of objects that can be present in the OL file at a time is 200 (anymore would exceed its memory pool, causing the level to crash).  While the allotted name of the object in the can be anything, it typically is in the format "Object#" using a number "#" to keep track of the amount of Objects used.  Any special objects that are used in script are referred to using this allotted name.
Object List files use the unique object <code>TVCamera</code>, 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 in the center of the map when the level loads.


Typical Ol File Format:
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 <code>type</code>, <code>xPos</code>, <code>yPos</code>, and <code>heading</code> are necessary. In the default game, <code>driving</code> is only used in [[Run The Gauntlet]], and <code>health</code> is not used at all.
All numeric properties can use six decimal places, allowing for very precise placement. However, buildings will ignore these, reverting to being placed in the center of whichever block the main part of their construction is in, and facing whichever cardinal direction their designated angle is closest to.
===Type===
The <code>type</code> property is used to define what an object is. This can be set to any of the objects defined in the {{block|VehicleTypes}}, {{block|MiniFigureTypes}}, {{block|RockMonsterTypes}}, and {{block|BuildingTypes}} sections, and some in the {{block|MiscObjects}} section. For example, placing a Rock Raider in a level would require the property <code>type Pilot</code>.
The majority of objects from the {{block|MiscObjects}} section can't be placed with an Object List; doing so will either crash the game upon loading a level, or cause the game to close without an error message. Only the following objects from this section can be placed with an Object List:
* <code>Boulder</code> - The model for the boulder thrown by monsters; since it gets its texture from whatever [[Rock types|type of wall]] it was scooped out of, it will appear untextured
* <code>Pusher</code> - The looping animation for the beam fired from a [[pusher beam]]
* <code>Freezer</code> - The looping animation for the beam fired from a [[freezer beam]]
* <code>LaserShot</code> - The looping animation for the beam fired from a [[laser beam]]
* <code>Crystal</code> - An [[energy crystal]]
* <code>Dynamite</code> - [[dynamite]]
* <code>Ore</code> - A piece of [[ore]]
* <code>ProcessedOre</code> - A [[building stud]]
* <code>Barrier</code> - An unextended [[barrier]]
* <code>ElectricFence</code> - An [[electric fence]]
* <code>SpiderWeb</code> - A [[spider web]]
* <code>OohScary</code> - An active [[sonic blaster]]. Strangely, an inactive Sonic Blaster can't be placed, unlike with dynamite.
===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 in-game 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. 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===
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).
===Driving===
The <code>driving</code> 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. 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.<!--However, other object types will move with the vehicle, albeit in their default standing animations. Creatures may actively struggle against the movement of their own vehicles, though ones that can damage vehicles never try to. Buildings mounted on vehicles will create Power Paths where they spawn.-->
===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. 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. Strangely, setting an object's health to exactly <code>0.0</code> will cause this property to be ignored entirely.
==Example setup==
Here is an example of a complete Object List file:
  Lego* {
  Lego* {
   
   
  Object1 {
  Object1 {
  type [ObjectName]
  type Toolstation
  xPos [X-Coordinate Location]
  xPos 11.500000
  yPos [Y-Coordinate Location]
  yPos 10.500000
  heading [Facing Angle]
  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
  }
  }
   
   
  }
  }
Where <tt>ObjectName</tt> is an object as it is defined in the <tt>ObjectNames</tt> or <tt>MiscObjects</tt> lists in the Main LEGO Config file<!--, <tt>X/Y-Coordinate Location</tt> is its coordinates on the [[Map file]], and <tt>Facing Angle</tt> is its angle between 0 and 360 clockwise-->.
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.


If an object list is missing a camera, the game will crash on startup. If an object list has a camera but lacks any exposed units, the game will run up to Chief's briefing in that level, where it will softlock.
==Modding==
Object List files are not compiled and can easily be edited with even [[Wikipedia:Microsoft Notepad|Notepad]].


<br><br><br>[[Category:Modding|OL file]][[Category:Game Files]]
[[Category:File formats in LEGO Rock Raiders for Windows]]
[[Category:Documentations]]

Latest revision as of 20:54, 18 December 2018

Object List files are configuration files used in LEGO Rock Raiders for Windows to designate the starting locations of Rock Raiders, buildings, vehicles, creatures, building materials, spider webs, and the game camera within missions. They use the filename extension .ol, though they are essentially just text files. Each mission's Object List file is linked to in that mission'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 List files 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 in the center of the map when the level loads.

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 type, xPos, yPos, and heading are necessary. In the default game, driving is only used in Run The Gauntlet, and health is not used at all.

All numeric properties can use six decimal places, allowing for very precise placement. However, buildings will ignore these, reverting to being placed in the center of whichever block the main part of their construction is in, and facing whichever cardinal direction their designated angle is closest to.

Type

The type property is used to define what an object is. This can be set to any of the objects defined in the VehicleTypes {}, MiniFigureTypes {}, RockMonsterTypes {}, and BuildingTypes {} sections, and some in the MiscObjects {} section. For example, placing a Rock Raider in a level would require the property type Pilot.

The majority of objects from the MiscObjects {} section can't be placed with an Object List; doing so will either crash the game upon loading a level, or cause the game to close without an error message. Only the following objects from this section can be placed with an Object List:

  • Boulder - The model for the boulder thrown by monsters; since it gets its texture from whatever type of wall it was scooped out of, it will appear untextured
  • Pusher - The looping animation for the beam fired from a pusher beam
  • Freezer - The looping animation for the beam fired from a freezer beam
  • LaserShot - The looping animation for the beam fired from a laser beam
  • Crystal - An energy crystal
  • Dynamite - dynamite
  • Ore - A piece of ore
  • ProcessedOre - A building stud
  • Barrier - An unextended barrier
  • ElectricFence - An electric fence
  • SpiderWeb - A spider web
  • OohScary - An active sonic blaster. Strangely, an inactive Sonic Blaster can't be placed, unlike with dynamite.

xPos/yPos

The xPos and yPos properties set the position of an object in a level. Positions are based on the in-game 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. 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).

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. 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. 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. Strangely, setting an object's health to exactly 0.0 will cause this property to be ignored entirely.

Example setup

Here is an example of a complete Object List file:

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 not compiled and can easily be edited with even Notepad.