[Documentation] Getting High on Vertical Terrain

[ohartenstein23]

Hi Everybody!  Based on my previous experiments with loading alternate terrains in the map generator, I've come up with some new code for placing map blocks on top of each other, similar to how the addUFO and addCraft commands work, but now with arbitrary map blocks!  This code is all accessible through a tag in the mapscripts ruleset called verticalLevels:

Code: [Select]

alienDeployments:
  - type: STR_MEDIUM_SCOUT
    height: 8
mapScripts:
  - type: DEFAULT # forest, mountain
    commands:
    - type: addUFO
    - type: addCraft
    - type: addBlock
      size: [1, 1, 8]
      verticalLevels:
      - type: ground
        size: [1, 1, 2]
        terrain: XBASE
        blocks: 20
      - type: middle
        size: [1, 1, 4]
    - type: addBlock
      size: 2
      executions: 2
    - type: fillArea

The snippet above produces the first result image I've attached below, where a forest map block sits atop the dirt fill from the base defense maps.  Speaking of base defense maps, this new code will also work for those too - I've included some examples of a base in the desert at night, generated by the ruleset attached.

The verticalLevels tag can be defined for the mapscript commands addBlock, addCraft, addUfo, and fillArea.  These definitions will supersede the blocks, groups, etc. definitions in the regular map script command in favor of their own.  Each vertical level supports definitions of the following:

• type: ground - This defines the behavior of the level and how it's handled.  "ground" is only used once and is placed at z = 0, "ceiling" is also only used once and is placed at the top if defined, "middle" is used to create filler levels in between the first two, "empty" allows for a filler level to contain no map block, "decoration" acts like middle but sets its vertical size to zero, causing the next map to be loaded directly over it, and "craft" is a marker for placing the craft/UFO in the addCraft/addUFO commands.
• groups: [6, 7, 8] - Works just like groups in regular commands, defining which groups of blocks are used in this particular level.
• blocks: 20 - Again, just like blocks in regular commands, it also overrides the groups tag.
• size: [1, 1, 4] - Perhaps the most important definition in a vertical level besides the type, this is how the engine recognizes the vertical extent of a particular level, since it is not specifically defined for most map blocks.  The size is read in as [x, y, z], with z being the important bit here. Defaults to [1, 1, 1].
• maxRepeats: 1 - For the filler levels "middle", "empty", and "decoration", defines how many times they can be used in a given map chunk.  Negative numbers remove any limit on the number of repeats.  Defaults to -1.
• terrain: XBASE - Defines which terrain this particular level will use, see the documentation for the alternate terrain commands for more info.  Defaults to the terrain from the deployment or mission.

Algorithm:
------------
Once the levels are defined in a particular command, the code populates a list of levels based on either the height of the map or the size in z defined in the command itself.  The "ground" and "ceiling" levels are added to the list first to reserve space for them.  Next, the remaining levels are looped over in the order defined by the ruleset, adding them in between the ground and ceiling to fill out the chosen size for the command, stopping when either the maxRepeats are reached for each level and there are none left, or when no more levels can be added without going over the size of the map/command.  Finally, the "ceiling" level is given an offset to place it directly on top of the last filler level chosen.  This method of filling the space in the vertical direction is why defining the specific sizes for each level is important - the code relies on those definitions to determine how high above the previous level the next should be placed.  With a size in z of 0, the next level will be placed at the same offset as the previous, often running into interesting terrain collision issues, but this can be and is leveraged by the "decoration" level to allow for say a building to be placed on various kinds of terrain based on where in the geoscape the mission occurs.  Other use examples might be adding "empty" levels to addCraft/addUFO to make them hover over the terrain, or making your base have both above and below ground portions.

Base facilities:
------------
Speaking of the base terrain, the verticalLevels tag can be placed directly on a facility definition to override the given map name and generate that particular facility's map as if it were an addBlock command.  If used for a 2x2 facility though, it will require a 20x20 map block, not the four 10x10 blocks usually defined as in the hangar.

Edit 171110: This is an official part of OXCE, so the links for my repository are deprecated.  This post will remain for documentation.

[Yankes]

As Solarius Scorch requested, I plan soon include this to my branch.

[Meridian]

Please review if possible, this doesn't look like a simple thing.

[ohartenstein23]

Yes, more sets of eyes reviewing this code would be nice.  Solarius and I have both tested it pretty extensively, but I want to make sure I'm not introducing any new nasty bugs.

[Yankes]

I will look on this before pulling in.

[mrcalzon02]

holy mother of base building batman! it worked? wow! was it ever folded into openxcom exteneded,
-so you just stacked normal map generation on top of the base? how is the base map layout built anyway? i need to do some learning...

[ohartenstein23]

Yes, this has been in extended for longer than six months, just no modder has taken up the challenge of building above ground base maps yet.

Base map generation uses special code, where map blocks are placed according to the location of the facilities first, using precisely whichever block the facility calls in its definition. Then, the rest of the empty base squares are filled with a normal map script. Part of my code is simply a different way of choosing the map blocks for the facilities, such that either random or specific blocks can be chosen, similar to standard map scripts. If you're interested, I can give you a better sample ruleset and an explanation of what I envisioned for above-ground bases.

[mrcalzon02]

i'm currently poking a quick and dirty method of simplely added two more levels to the XBASE maps and adding the Forest tileset to them. but at current it looks like doing so would require going through each map and reworking all the patrol/ai/spawn nodes.four each room.. if i hit to many roadblocks this way i will mostly likely hop over to trying your method...(i also have not tested in game yet....)

[Solarius Scorch]

If you simply add another tileset to the X-Com base, you will go beyond the capabilities of the engine. You can only have 256 tiles per terrain (not counting destroyed tiles as long as they are at the end of the last tileset - only applies to tiles you directly use for building in MapView). That's partially why this feature was necessary.

Pity it still won't allow separate surface buildings, irrelevant from underground buildings below them... I've always wanted a two-level base, where you can switch between surface and underground in the base view.

[ohartenstein23]

i'm currently poking a quick and dirty method of simplely added two more levels to the XBASE maps and adding the Forest tileset to them. but at current it looks like doing so would require going through each map and reworking all the patrol/ai/spawn nodes.four each room.. if i hit to many roadblocks this way i will mostly likely hop over to trying your method...(i also have not tested in game yet....)

As Solarius said, each individual map block is limited by the 256 tiles per terrain, this code (and the vertical terrain code) aims to remove this limitation on a map-wide scale by allowing multiple terrains to be used. The way this code is written you do not have to add extra tilesets to the base terrain itself, you can use the mapscripts to put forest terrain in the places where facilities aren't and on the levels above the facilities.  It also doesn't necessarily need to be forest terrain - I wanted the code to respect where in the globe you put your base, so it can pick the above ground terrain and seed the RNG map block choice by base location, so bases will feel more unique to their location.

Some of the features you should know about are in the baseTesting.rul file attached to my OP, here's a bit more explanation of them:

Code: [Select]

baseDefenseMapFromLocation: 1
globe:
  textures:
    - id: 0
      terrain:
        - name: FOREST
          area: [0, 360, -90, 0]
        - name: JUNGLE
          area: [0, 360, 0, 90]
      baseTerrain:
        - name: FOREST
          area: [0, 360, -90, 0]
        - name: JUNGLE
          area: [0, 360, 0, 90]
...
The first ruleset parameter tells the engine to pass the terrain from the globe on to the mapscript for map generation, specifically whatever terrain is defined by baseTerrain.

Code: [Select]

alienDeployments:
  - type: STR_BASE_DEFENSE
    height: 6
Increases the height of the map to include the extra 4 levels from the normal outdoor terrains.

Code: [Select]

facilities:
  - type: STR_LIVING_QUARTERS
    verticalLevels:
    - type: ground
      size: [1, 1, 2]
      blocks: 1
    - type: ceiling
      size: [1, 1, 4]
      terrain: baseTerrain
This is where the maps come into play.  Vertical levels overrides the default map definition for each facility, instead reading this data like a bit of mapscript for each facility.  For the living quarters, the first level (here, the underground portion) is the first mapblock from the XBASE terrain definition, the living quarters facility map.  The second part of the verticalLevels tells the map generator to pick a random 10x10 map block from the terrain on which the base is located (defined by baseTerrain in the globe ruleset).  You can make this facility-specific by adding blocks to this level and picking the terrain.  For example, if you made a new terrain for your surface base facilities, called XBASE_SURFACE, and the first map in the terrain definition is the living quarters, you could specify this by the following ruleset:

Code: [Select]

facilities:
  - type: STR_LIVING_QUARTERS
    verticalLevels:
    - type: ground
      size: [1, 1, 2]
      blocks: 1
    - type: ceiling
      size: [1, 1, 4]
      terrain: XBASE_SURFACE
      blocks: 1

If you want it to further add in features from the terrain (trees in forest, sand in desert, etc.), you could make a few maps that would fit around the above ground facilities to add these decorations.  For example, in the map you showed us above, you would split that block into 2 or 3 maps, depending on how you wanted to define it.  The facility, including the below ground portion, the grey tiles around the border on the surface, and the little bunkroom, but not the ground around it, would be the first map, defined on the XBASE terrain, would be the first map.  The second map would be the grass and trees, with a hole for the bunkroom; you'd add this block to the FOREST terrain, maybe give it a special group to specify that it's only for base defense maps.  The facilties ruleset would then look like this:

Code: [Select]

facilities:
  - type: STR_LIVING_QUARTERS
    verticalLevels:
    - type: ground
      size: [1, 1, 2]
      blocks: 1
    - type: ceiling
      size: [1, 1, 4]
      terrain: baseTerrain # Base is in the forest, it'll automatically look for that terrain
      blocks: 20 # Or whatever number in the list your new mapblock is
      groups: 10 # If you want to make a generic set of mapblocks with 'holes' in them for the facilties

@Solarius Scorch: see the attachment.

[Solarius Scorch]

I am really looking forward to seeing a farm above the base.

[mrcalzon02]

map limits. well! seams you guys have something in the works the looks way better then what i had going, wait! this means i could just design a bunch of Surface base features and maps to use with your scripts Once i figure out Linking data in a way that works (i seam to be a derp having issues.) i will work on some 2 tall "surface base" stuff, Hidden base type stuff  and guard towers or the like.(still need to figure out elevators)

[ohartenstein23]

map limits. well! seams you guys have something in the works the looks way better then what i had going, wait! this means i could just design a bunch of Surface base features and maps to use with your scripts Once i figure out Linking data in a way that works (i seam to be a derp having issues.) i will work on some 2 tall "surface base" stuff, Hidden base type stuff  and guard towers or the like.(still need to figure out elevators)

If you make some map assets, I can help write the ruleset to get it working with this code.  Also, don't feel like you need to be limited to only 2 more levels above the base - most surface maps are 4 levels, and the game can run more than that.  For the elevators, you're mostly going to be stuck with the gravity lift-style used in alien bases - TFTD made it work on the infamous cruise ships.

[Hobbes]

If you simply add another tileset to the X-Com base, you will go beyond the capabilities of the engine. You can only have 256 tiles per terrain

A clarification: you can only have 256 tiles assigned to each .MAP file, which is the practical limit for map editing

But a terrain can have more than 256 tiles assigned to it - either by moving the destroyed tiles to the end of the last tileset loaded so that they aren't required for map editing, or through using the addUFO command

[mrcalzon02]

lol Thanks for the details Hobbes, im a noob, so putting all of those methods into practice? not so easy. maybe someday. I figure i will just go about designing some base tiles, ill make sure to upload what i workup. i feel like i should work in one direction with the maps, secret-base(1.civilian/hidden stuff) or (2.military-base) surface designs. one the other or both guys?