Star System troubles

[Atarlost]

The <Lookup> tag seems to be doing all of the heavy lifting in star system generation in 1.2 (at least nothing else is placing any planet scale objects), but I can't find any documentation of it nor can I find the tables themselves.

[digdug]

it seems that all those lookups are actually calling a table called <SystemPartTable unid="&tbBasicSystemParts;"> which is contained in universeCompatibility.xml


SystemPartTable has various sub-tables for spawning groups of spaceObjects.

<AsteroidSmall>
<Table>
<Station chance="90" type="&stSmallAsteroid;"/>
<Station chance="10" type="&stOreSmallAsteroid;"/>
</Table>
</AsteroidSmall>

and it seems that the sub-tables can self-reference tbBasicSystemParts by calling other sub-tables.
such as <AsteroidBelt> calls <AsteroidSmall>:

<AsteroidBelt>
<Group>
<Siblings count="500" distribution="4d40-82">
<Lookup table="AsteroidSmall"/>
</Siblings>

<Siblings count="50" distribution="4d20-42">
<Lookup table="AsteroidMedium"/>
</Siblings>

<Siblings count="1d6+6" radiusInc="4d40-82" angle="minSeparation:10">
<Label attributes="asteroids,asteroidbelt"/>
</Siblings>
</Group>
</AsteroidBelt>

[george moromisato]

Short answer: System definition has gotten really complicated, so if you tell me what you are trying to do, I might be able to point you in the most efficient direction. Just post a reply and I can hopefully explain further.

Longer overview:

StdSystems.xml: This file defines the actual system types for systems in Human Space. The purpose of these definitions is to combine the physical system definition (stars, planets, and asteroids) with actual encounters (appropriate to Human Space). At the top of each system definition you'll see something like:

Code: Select all

<Lookup table="YellowStarSystem"/>

The lookup above defines the physical system, which is actually contained in...

StarSystems.xml: This file defines the physical properties of the system (stars, planets, asteroids). For example, you'll find a definition of "YellowStarSystem" which places stars, planets, and asteroids.

Near the top you'll see a set of tables with AddTerritory directives. These define regions in the system with particular attributes. For example, it might define an inner zone (within 370 light-seconds of the star) with the attributes, "innerSystem, metallicComp, moltenZone". These attributes control the types of asteroids that you'll find in the zone.

Later down you'll see the traditional Orbitals, which define the planets and asteroid belts in the system. These are lookups to other definitions.

NOTE: At the top of StarSystems.xml there is an extensive comment which tries to describe what's going on.

Worlds.xml: This file contains the definitions for various planets. For example, in YellowStarSystem there is a reference to DesertPrimary which is defined in Worlds.xml.

DesertPrimary is yet another Lookup, but with a twist:

Code: Select all

<DesertPrimary>
	<Lookup table="StandardTerrestrialMorphology">
		<_PlanetType>
			<Station type="&stDesertTerrestrialSizeH;" showOrbit="true"/>
		</_PlanetType>
		<_PlanetLabel>
			<Label attributes="desert, planet, planetary, terrestrial"/>
		</_PlanetLabel>
	</Lookup>
</DesertPrimary>

Notice how the Lookup tag has children! These are actually parameters that can be used inside the definition of StandardTerrestrialMorphology. We are essentially passing parameters to the Lookup. We define two parameters _PlanetType, which is the actual (concrete) planet that we want to create here, and _PlanetLabel, which is the set of attributes that we want for a label (this controls the encounters that will be found around the planet).

StandardTerrestrialMorphology is what I call a morphology. A morphology is a definition that places objects in a particular shape or arrangement, and that takes parameters specifying what objects it needs to place. Think of a morphology as a subroutine that places whatever you tell it in a certain arrangement. For example, there are morphology definitions for asteroid belts, which scatter objects as asteroids.

Morphologies are defined in...

Groups.xml: This defines various morphologies including StandardTerrestrialMorphology. If you look at its definition, you can see:

Code: Select all

<StandardTerrestrialMorphology>
	<!-- A planet (the type is an input to the table) -->
	<Lookup table="_PlanetType"/>
	...
</StandardTerrestrialMorphology>

Notice the Lookup to the _PlanetType table. This is the parameter that we defined above (in DesertPrimary).

Below you'll also see tables that have a probability of creating a moon or associated asteroids. For example, there is a reference to "AsteroidCompanion"

The definition of AsteroidCompanion places a random asteroid. If you look at the definition (also in Groups.xml) you'll see that it refers to a table called "LocationDefinition" and passes it another set of tables.

The purpose of LocationDefinition is to choose asteroids appropriate to the location. For example, if we're placing an asteroid in the inner system in a volcanic region, we're going to pick volcanic asteroids. Conversely, in the outer system, we might pick ice asteroids. The way we do this is by checking the attributes that are set at the current position. Remember the AddTerritory directive? LocationDefinition will look at the attributes set by AddTerritory to determine what asteroids should appears. For example:

Code: Select all

<LocationDefinition>
	<LocationCriteriaTable>

		<!-- MOLTEN ZONE (inner metallic) -->

		<Variant criteria="*moltenZone"	variant="inner">
			<Table>
				<Variant chance="0" 		variant="ice">
					<Lookup table="_Morphology"/>
				</Variant>
				<Variant chance="40"		variant="metallic">
					<Lookup table="_Morphology"/>
				</Variant>
				<Variant chance="0" 		variant="primordial">
					<Lookup table="_Morphology"/>
				</Variant>
				<Variant chance="20"		variant="rocky">
					<Lookup table="_Morphology"/>
				</Variant>
				<Variant chance="40"		variant="volcanic">
					<Lookup table="_Morphology"/>
				</Variant>
			</Table>
		</Variant>
		...

</LocationDefinition>

The LocationCriteriaTable element is basically a switch statement and the Variant elements are cases. The first one is basically saying, if the current position has the "moltenZone" attribute, then follow these steps. [You'll see that YellowStarSystem defines moltenZone as the inner part of the system (though it's random).]

Inside the case statement we have a table of variants. The variant="..." statement DEFINES the given keyword for its children. The child in question is another lookup, this time to _Morphology. Again, this is a parameter passed in by the caller of LocationDefinition. If you look back to AsteroidCompanion, you'll see that it define _Morphology as a table the refers to VariantSizeB, VariantSizeC, etc. Let's look at those.

VariantSizeX definitions are used to define asteroids of various sizes (A is the smallest). If you look at the definition for VariantSizeB, for example, you'll see a set of VariantTable elements. These tables switch on the variant definitions set inside LocationDefinition. Depending on which variant is active, we end up with a specific call to RandomStation.

RandomStation, in this case, picks a random asteroid with the appropriate attributes (ice, inner, whatever).

The result of this (possibly overcomplicated) system is that we are able to place asteroids and planets according to general rules and guidelines instead of explicitly (as in the past), which allows (hopefully) for more randomness.

Finally, if you look at specific files like Ice.xml or Metallic.xml you'll see the actual definition for asteroids (and planets) of various sizes. These are randomly chosen in the RandomStation directive above according to criteria.

[digdug]

woah! this is really cool !
looks like I totally underestimated the new system

[Arisaya]

Well, that was certainly helpful, good thing I saw this, since I will be needing to mess around with these systems soon..