# BASICS
# This file is designed to be copied into the mods/resources/ruins folder and be
# edited to create a new template.  It is functional as-is; you can use it as
# a placeholder for future templates after renaming it.
#
# Templates have a .tml extension and the mod will attempt to load any and
# all files with that extension if they reside in the <minecraft root>/
# mods/resources/ruins folder. Whether it does so successfully or not can be
# checked in the log file (<minecraft root>/mods/ruins_log.txt). The mod will also
# load any templates found in the biome folders within
# <minecraft root>/mods/resources/ruins.
#
# These template files are a simple text file; simply open them in your
# favorite text editor to make changes or create new ones.
#
# There are three sections to each template file:
# VARIABLES define how the template is generated.
# BLOCK RULES define how the layers are generated.
# LAYERS tells the mod how to place blocks using BLOCK RULES.
#
# You can specify a comment by placing a "#" character at the beginning of the
# line.  You technically /don't/ have to do this, since the mod only looks for
# particular line starts when loading a template, but I consider it good form 
# because it increases readability and you prevent any errant line reads.


# VARIABLES
#
# biomesToSpawnIn=<name1>,<name2>,<name3>...
# Adds the Template being loaded (regardless which folder it is in) to a Ruins Biome
# found in the Minecraft Biomelist so that <namex> matches the Biome's name.
# If you don't know a Biome's name, find it's folder. The foldername equals the
# Biome name. Case insensitive. A Template cannot be added to a Biome more than once.
# The Template is still added to the corresponding folder it was loaded from (if not already in).
# example: biomesToSpawnIn=forest,foresthills,taiga
# Optional. You can use the folders as before, or use this to save space, or both.
#
# weight=<weight>
# Weight is how much weight this template has during random generation.  When
# the mod asks for a template to place it adds up the weights of all templates
# that are currently loaded and generates a random number based off of that
# total, then checks to see what template to load.  If the mod loads five
# templates with weights 1, 5, 5, 10 and 10, the template with weight 10 has a
# 10 in 31 chance of being generated, while the template with weight 1 has a 1
# in 31 chance of being generated.  A template only has weight in its biome.
# Defaults to 1.
#
# embed_into_distance=<number of layers>
# Specifies how many layers to embed into the target blocks.  This is useful
# for creating basements or dungeons.
# Defaults to 1.
#
# acceptable_target_blocks=<blockID>,<blockID>,<etc...>
# This is a comma-delimited list of block IDs that this template can spawn on.
# Only the top layer of blocks where the template will spawn are checked.
# Optional line. Defaults to accept any block.
#
# unacceptable_target_blocks=<blockID>,<blockID>,<etc...>
# This is a comma-delimited list of block IDs that this template can NOT spawn on.
# Only the top layer of blocks where the template will spawn are checked.
# Optional line. Defaults to accept any block.
#
# dimensions=<height>,<width>,<length>
# Defines how big this template is.  Height is the number         n
# of layers that are used, not the height that sticks out         n
# above the ground.  Width is the north-south width, and       www*eee
# length is the east-west width.  For reference, north in         s
# the template is the top of the text file.                       s
# All default to 0.
#
# allowable_overhang=<overhang>
# Specifies the allowed number of blocks in the potential build site that do not have
# a surface within a reasonable distance, leaving the template "hanging" over an edge
# Defaults to 0.
#
# max_leveling=<leveling>
# Specifies the maximum surface noise / height difference, within the build site,
# that will be accepted when considering a potential build location.
# The site will then be levelled prior to spawning the template.
# If there is overhang allowed, also specifies how much "support" blocks are put
# under the template when building it overlapping a surface edge.
# Defaults to 2.
#
# leveling_buffer=<lbuffer>
# The distance around the build site that will also be levelled.  Values higher
# than 5 will use 5, since the world would otherwise be mangled pretty badly.
# Defaults to 0.
# Ruins 12.8 introduces a setting of -1, which will prevent any(!) site leveling
#
# preserve_water=<yes/no>
# If set to 1 all site checking rules will treat water as air so that the ruin
# can be generated beneath/in water.  Any rules that replace a block with air
# will respect water and not replace it.  If set to 0, water is treated like 
# any other block.
# Defaults to 0/no.
#
# preserve_lava=<yes/no>
# If set to 1 all site checking rules will treat lava as air so that the ruin
# can be generated beneath/in lava.  Any rules that replace a block with air
# will respect lava and not replace it.  If set to 0, lava is treated like 
# any other block.
# Defaults to 0/no.
#
# random_height_offset=<min>,<max>
# Specifies block range in which the Ruin will be randomly shifted up or down
# on an established valid location before actually being built.
# Defaults to 0,0/no random shifting
#
# NOTE: When using preserve_water and preserve_lava it is advised that you
# restrict the cut_in_buffer as much as possible, preferably to 0.  If it is
# more than 0 you may get some unexpected fluid dynamics if the structure
# does not spawn completely in water/lava.
#
# Ruins 13.8 adds optional variable "uniqueMinDistance" which overrides global templateInstancesMinDistance
# uniqueMinDistance=1500
# defaults to 0. values of 0 are handled as if no value was specified at all.
#
# Ruins 13.9 adds optional variable "preventRotation" which keeps a template in the specified direction
# preventRotation=1
# defaults to 0. values of 0 are handled as if no value was specified at all.
#
# Ruins 14.3 adds the optional repeatable variable "adjoining_template" which lets you spawn adjacent templates
# these will not be checked for minimal distances against ANY other ruins, make sure your spacings are big enough
# these will also not be checked for circular dependencies, you build an infinite loop, you wait it out
# these will be checked against the rules the template itself contains
# Ruins will use its spawning algorithm to determine a fitting y coordinate to the xz you provide
# adjoining templates will be randomly rotated, you can disable this in their templates if you want
# syntax: adjoining_template=<template>;<relativeX>;<allowedYdifference>;<relativeZ>[;<spawnchance>]
# <template> is the full filepath relative to the resources/ruins folder, so, working like /testruin
# <relativeX> and <relativeZ> are the relative coords from the host x,z spawnpoint to the adjoining x,z
# <allowedYdifference> states how much the computed adjoining template height may absolutely differ before aborting
# <spawnchance> is optional and does what the name implies, [0-100] values allowed
#
# Example: adjoining_template=generic/MoaiHead;-25;10;25;33
#
# Ruins 17.0 adds optional variables "spawnMinDistance" and "spawnMaxDistance"
# to specify the minimum and maximum distances (i.e., Chebyshev distance, in
# blocks, on the XZ plane), respectively, from the world spawn point this
# template may be naturally instantiated in the overworld (dimension 0). They
# have no effect on instantiation in other dimensions.
# spawnMinDistance=1000
# spawnMaxDistance=5000
# The default values are spawnMinDistance=0, spawnMaxDistance=infinity. For
# both variables, a value of 0 effectively means "no limit" and reverts to the
# corresponding default.
# These settings are overridden by globals "anySpawnMinDistance" and/or
# "anySpawnMaxDistance" when the global values are more restrictive--that is,
# the greater min distance and lesser max distance are used. Note the default
# value of anySpawnMinDistance is 32, not 0; if a spawnMinDistance less than
# that is desired, the Ruins mod configuration file will need to be changed.
# If the space between max and min distances is too narrow (namely, less than
# the length and width of the template), no instances can naturally generate.
#
# Ruins 17.2 adds three new optional variables:
#
# requiredMods=<criterion>
# Prevent installation of this template unless the list of installed mods meets the
# specified criterion--a boolean expression of one or more mod ids and operators (see
# below).
# example: requiredMods=quark+tconstruct  # requires both quark AND tinkers' construct
# Optional. Defaults to no criteria.
#
# biomeTypesToSpawnIn=<criterion>
# Adds the Template being loaded (regardless which folder it is in) to every Ruins Biome
# found in the Minecraft Biomelist for which the Biome's list of types meets the specified
# criterion--a boolean expression of one or more biome type names and operators (see below).
# example: biomeTypesToSpawnIn=DRY,COLD  # spawns in any DRY or COLD biome (or both)
# Optional. May be used in addition to, or instead of, biomesToSpawnIn.
#
# biomesToNotSpawnIn=<name1>,<name2>,<name3>...
# Excludes the Template being loaded from every Ruins Biome found in the Minecraft Biomelist
# with the specified name. Case insensitive. Note this takes precedence over
# biomeTypesToSpawnIn, but do not inhibit Biomes listed as biomesToSpawnIn, nor the Biome
# associated with the Template's folder.
# example: biomesToNotSpawnIn=ice_flats,ice_mountains
# Optional. Only relevant if biomeTypesToSpawnIn is specified.
#
# In both requiredMods and biomeTypesToSpawnIn, some rudimentary boolean operations are
# allowed by concatenating multiple type names separated by + (and) or - (and not). So, for
# example:
# biomeTypesToSpawnIn=forest-cold,jungle+hills
# This adds the template to all biomes that are of type forest AND NOT cold, or are of both
# jungle AND hills. Order doesn't matter, so the following is equivalent:
# biomeTypesToSpawnIn=hills+jungle,-cold+forest
# If all the types are exclusions, all non-excluded types are added. Thus, "-nether-end"
# means every biome that isn't of type nether or end. The comma serves as an "or" operator
# and is of lower precedence than + and -; parentheses may be used to further control the
# order of evaluation.
#

weight=5
embed_into_distance=1
acceptable_target_blocks=stone,grass,dirt,sand,gravel,clay
dimensions=4,7,5
allowable_overhang=0
max_leveling=2
leveling_buffer=0
preserve_water=0
preserve_lava=0


# BLOCK RULES
# Each rule must be formatted carefully:
# rule<number>=<condition>,<chance to appear>,<list of blocks>
#
# rule<number>
# The mod does not care what you call these and will number the rules in the
# order they are loaded (sequentially from 1), so long as the line start with
# "rule".  I suggest using "rule#" as a mnemonic, such as "rule1", "rule2",
# "rule12", etc...  Once the templates are loaded, the first rule in the list
# becomes rule #1 for the purposes of building a layer, the second becomes rule
# #2, and so on.
#
# By default, the mod uses a special rule, 0, which defines the Air block with
# a 100% spawnrate and no conditional.  You can use this rule in the layers to
# "blank out" certain areas (providing space for mobs, for instance).  Note,
# however, that rule0 may be redefined as something else by the template author.
#
# <condition>
# A conditional to the block being placed, aside from randomness.
# 0 = Normal, spawns first
# ±1 = Checks block under, spawns delayed
# ±2 = Checks block adjacent, spawns delayed
# ±3 = Checks block above, spawns last
# 7 = Spawns last
# Where the negative cases for 1,2,3 denote NOT. In other words, 2 means the block will only spawn 
# if there is a block next to it, while -2 will NOT spawn if there are any blocks next to it.
#
# Adjacent in this case is not diagonal, only along the cardinal directions.
#
# Adjacent blocks are processed after 0 and 1 conditionals have been placed,
# and "under blocks" are processed after all other blocks have been placed.
# Please note that these blocks are still processed in an order dependent on
# the rotation of the site.  For a normal, north-facing site, the block rules
# are processed for each line from the left and from the bottom template to the
# top.
#
# DO NOT CHAIN CONDITIONS. That results in undefined behaviour.
#
# <chance to appear>
# The chance that this block will appear, out of 100, depending on whether the
# condition above is met.
#
# <list of blocks>
# A comma-delimited set of minecraft blockIDs.  This will determine what block
# will actually spawn in the location.  Each blockID is given the same weight,
# so you can skew the odds of a certain blockID appearing by adding it multiple
# times.  You can specify block metadata by adding a "-<metadata>" after the
# blockID.  For instance, to place a cobblestone stairs block ascending to the
# east, use stone_stairs-3.  To place a wood half-block (slab), use stone_slab-2.
#
# You can find a list of blockIDs and commonly-used metadata via Google.
# There is also one included, idmappings.txt
#
#
# Example 1: rule1=0,100,0,cobblestone,mossy_cobblestone
# This spawns either air, cobblestone, or a mossy cobblestone 100% of the time.
#
# Example 2: rule1=1,50,mossy_cobblestone
# This spawns a mossy cobblestone 50% of the time but only if another block
# is underneath it.
#
# Example 3: rule1=2,100,stone_slab-2,planks
# This spawns either a stone slab or a plank block, but only if there is an
# adjacent block on the same level.
#
# Example 4: rule1=0,100,torch-5
# This spawns a torch standing on the ground.
#
# Example 5: rule1=0,25,MediumChest
# This spawns a Medium Chest (see above) 25% of the time.
#
# Example 6: rule1=0,50,MobSpawner:Villager
# This spawns a Mob Spawner with Entity Id "Villager" 50% of the time
# Entity Id's are case sensitive! Mod added Mobs are allowed. Use a tool like Simply Hax to get correct Entity Id's
#
# Ruins 9.0 exposes minecraft ChestGenHook for your meddling. Usage:
#
# Example 7: rule1=0,100,ChestGenHook:chests/simple_dungeon:10
# This spawns a chest and tells the Minecraft generator to fill it with "10" itemstacks of the "chests/simple_dungeon" loot preset.
# This might include extremely powerful items added by mods. Note: The algorithm spreads out the itemstacks, it might be more than 10
# items in this particular case, e.g. 5 pieces of bread count as 1 itemstack, yet will be spread out over 5 slots.
#
#	see http://minecraft.gamepedia.com/Loot_table#List_of_loot_tables for possible loot tables (as of MC 1.9)
#
#	As of 10.6, all chest rules can also append a metadata/rotation int similar to a chest block ID
#	example: rule1=0,100,ChestGenHook:chests/simple_dungeon:10-5
#	for a chest filled with dungeon chest loot and rotated to meta 5.
#
#
# Ruins 10.3 adds Command Block Support. Usage:
# Example 8: rule1=0,100,CommandBlock:command:sender
# command being the Command string to be executed and sender being the Command sender (a player name, Rcon...)
# you can provide several alternative command blocks seperated by commata, however you may not mix command blocks and other blocks in one rule
#
# Ruins 12.1 adds Standing Signs. Usage:
# Example 9: rule1=0,100,StandingSign:a|b|c|d-4
# a,b,c,d are the 4 Strings/lines you can write on a sign. The metadata/rotation of the sign is affixed as usual.
#
# Ruins 12.2 adds IInventory block support. Usage: IInventory;<blockName>;<itemList>-<blockrotation>
# where <blockName> is the registry name of the Block that sports an inventory
# where <itemList> is a list of elements seperated by '+', each element is a block or item registry name
# optionally followed by #stacksize OR #stacksize#metadata OR #stacksize#metadata#inventoryslot
# Example 10: rule1=0,100,IInventory;chest;red_flower+arrow#10+wool#3#15-5
# this spawns a chest rotated to 5, which will contain a single red flower, 10 arrows, and 3 wool of color red (meta 15)
# Example 11: rule1=0,100,IInventory;dispenser;arrow#10+snowball#20+egg#3-1
# this spawns a dispenser rotated to 1, with 10 arrows 20 snowballs and 3 eggs
# you may use this for items added by mods. names not found in the registry will simply be skipped over.
# you may also use this for container blocks added by mods. invalid anythings should be skipped.
# the Ruins Parser will do this for you when you parse an IInventory block. Empty chests get hooked with dungeon loot
# automatically. If you want to prevent this, either edit the template afterwards or place some dirt in the chest.
# if you specify the same slot index multiple times, only the first itemstack gets put in
#
# Ruins 15.0 adds ChestGenHook (see above) as valid <itemList> entry for IInventory rules
# Example: rule1=0,100,IInventory;dispenser;ChestGenHook:dungeonChest:5-1
#
# Ruins 14.3 adds the -addbonemeal flag to use on IGrowable blocks such as saplings or most plants
# simply append -addbonemeal to a block which is an IGrowable (and only those!)
# note this overrides certain checks done before hand application of bonemeal, such as darkness checks for shrooms
# also note /undo does NOT take growing things into account when cleaning up your shenanigans
# below example is for oak and dark oak saplings
# Example 12: rule1=0,100,0,sapling-addbonemeal,sapling-5-addbonemeal
#
# Ruins 14.9 adds support for item NBT data. the json nbt string replaces 'stacksize' in the format, as nbt capable items are never stackable
# Example 13: rule1=0,100,IInventory;minecraft:chest;minecraft:diamond_sword#{RepairCost:2,display:{Name:"Choppa"}}#0#0
#
# Ruins 15.0 adds support for tile entity NBT data. This is best achieved by adding the blockname to the global "teblock" variable in ruins.txt
# Usage: teBlock;<blockName>;<nbttag json>-<blockrotation>
# Example: rule1=0,100,teBlock;minecraft:trapped_chest;{x:-156,y:65,z:72,Items:[0:{Slot:12b,id:5s,Count:1b,Damage:0s},1:{Slot:13b,id:24s,Count:1b,Damage:1s}],id:"Chest"}-2
# Note: "Chain" and "Repeat" Command Blocks are classified as such by default
#
# Ruins 16.8 modifies the rule syntax a bit to add some new features (variants and variant groups, in particular). None
# of these changes should break or alter the behavior of existing template files, except perhaps in pathological cases
# exploiting undocumented or unintentional aspects of rule parsing.
#
# * Block Weighting: Instead of repeating block IDs in a rule to manipulate their probabilities of occurrence, weight
# factors may now be used. This can make rules shorter and, in certain circumstances, more efficient. Apply a weight to
# any block in a rule by preceding it with a prefix of the form "n*"; this is functionally equivalent to repeating the
# same block n times. Valid values for n are integers between 1 and 99999, inclusive. For example, the following rules
# are essentially identical, each producing blocks of dirt, mossy_cobblestone, and gravel with the same likelihood:
#     rule1=0,100,dirt,dirt,mossy_cobblestone,dirt,gravel,dirt,mossy_cobblestone,mossy_cobblestone,dirt
#     rule2=0,100,5*dirt,gravel,3*mossy_cobblestone
# Weights are optional. If no weight is specified for a block in a rule, a weight of 1 is assumed.
#
# * Rule Variants: Consider a platform composed of many instances of the following rule3:
#     rule3=0,100,stone,dirt,cobblestone
# Each generated structure will have a different random assortment of stone, dirt, and cobblestone blocks. Suppose,
# though, what you really want is each platform to be a single, randomly chosen material--either all stone, or all
# dirt, or all cobblestone. You can't do that with a regular rule, since a different material choice is made per block.
# You could do it with three separate templates, of course, but now there's another way. For example:
#     rule4=0,100,stone
#     ^0,100,dirt
#     ^0,100,cobblestone
# Note "ruleXXX=" is replaced by "^" to indicate a line is a variant of the preceding rule, not a separate rule itself.
# Each time a structure with such a rule is generated, one of these variants is randomly chosen to apply to that entire
# structure wherever the corresponding number appears in the layer specifications.
#
# * Rule Variant Weighting: Weights can be applied to rule variants to adjust the probability with which they are
# selected. As with block weighting, a prefix of the form "n*" is placed at the beginning of the variant (i.e., just
# after the = or ^) to assign it a weight. For example, you can use this rule for the windows in your structure:
#     rule6=3*0,100,2*stained_glass-14
#     ^0,100,stained_glass-4
#     ^5*0,100,stained_glass-11
# Most of your generated structures will have blue windows (stained_glass-11, with a weight of 5), a little more than
# half as many will have red windows (stained_glass-14, with a weight of 3), and only a precious few will have yellow
# ones (stained_glass-4, with a weight of 1, the default when none is specified).
#
# * Grouped Rule Variants: With variants, it may be desirable to coordinate several different rules to guarantee
# selections are only made in particular combinations. A named rule specification using ^ instead of = creates a new
# rule whose variant choice depends on that of the preceding rule. For example, make a small pillar with the following
# rule7 at the base and rule8 stacked above it:
#     rule7=0,100,redstone_block
#     ^0,100,gold_block
#     ^0,100,lapis_block
#     rule8^0,100,stained_glass-14
#     ^0,100,stained_glass-4
#     ^0,100,stained_glass-11
# When a structure chooses variant #1 of rule7, it will always choose variant #1 of rule8 as well, so pillars with
# redstone at the base will have red glass (stained_glass-14) on top. Similarly, gold blocks (rule7, variant #2) will
# be matched with yellow glass (rule8, variant #2) and lapis (rule7, variant #3) with blue (rule8, variant #3).
# 
# * Rule Variant Group Duplication: Suppose you have a structure with three fancy pillars, as described in the previous
# example. You could make three stacks of rules7 and 8. Different structures would have different kinds of pillars, but
# all three pillars of any one structure would be of the same type. To get variation within the same structure, you're
# going to need a separate group of rules for each pillar--one using rule7 and 8, one using 9 and 10, and one using 11
# and 12:
#     rule9=0,100,redstone_block
#     ^0,100,gold_block
#     ^0,100,lapis_block
#     rule10^0,100,stained_glass-14
#     ^0,100,stained_glass-4
#     ^0,100,stained_glass-11
#     rule11=0,100,redstone_block
#     ^0,100,gold_block
#     ^0,100,lapis_block
#     rule12^0,100,stained_glass-14
#     ^0,100,stained_glass-4
#     ^0,100,stained_glass-11
# Note these rule groups are identical except for their names, and there's an easier way. By putting a repeat count of
# the form "n*" in front of the first rule name in a variant group (the one with an =), that many identical groups are
# automatically created. This is a bit tricky, because it does create new rules, which affects the way rules are
# numbered. To continue the example, rule7 could be changed slightly to take advantage of this feature:
#     3*rule7=0,100,redstone_block
#     ^0,100,gold_block
#     ^0,100,lapis_block
#     rule8^0,100,stained_glass-14
#     ^0,100,stained_glass-4
#     ^0,100,stained_glass-11
# This creates rule7 and 8 as before, but also creates rule9, 10, 11, and 12 for you, exactly as though these lines had
# been cut and pasted into the template file 3 times. Note rule names are irrelevant--rules are assigned numbers based
# on their ordinal position in the template (the first rule is 1, the second 2, and so on, regardless of their names).
#
# * Alternate Rule 0: By default, rule 0 is an air block. You can now change it to something else by putting an unnamed
# rule at the top of your rule list:
#     =0,100,stained_glass-7,stained_glass-8
# It has to appear before any other rule. It cannot be a variant of a preceding rule (since there isn't one--it has to
# start with = instead of ^), but it can be followed by variants and/or grouped variant rules. It cannot have a repeat
# count.
#
# Ruins 16.9 added the following features:
#
# * New Background/Foreground Blocks: The classic rule0 is a special air block that respects the template's settings of
# preserve_water and preserve_lava. Not quite an air block, not quite a preserveBlock; there was no way to include such
# a block in other rules. Now there is, with the new background block:
#     rule19=0,100,stone,cobblestone,2*?air,gravel
# Any blocks can be made into background blocks by adding a "?" prefix before their names; the resultant background
# blocks will not replace air, blocks with hardcoded preservation (currently snow layers, webs, and plants), or any
# blocks protected by preserve_water or preserve_lava, if set. A "!" prefix does the opposite, creating a foreground
# block which ONLY replaces air and preserved blocks. Incidentally, the existing site leveling algorithm effectively
# uses background and foreground blocks for "flattening bumps" and "filling holes," respectively; these can now be
# explicitly used for greater control over how a structure blends into its surroundings.
#
# * rule0 used for Conditional Placeholder and Site Leveling: Previously, air blocks were used as placeholders to fill
# in for conditional rules before their conditions could be evaluated. Air blocks were also used to level the base of a
# structure site. This was problematic for partially or entirely submerged structures, leading to unsightly air
# pockets. Now rule0 is used instead. Consider using background water as an alternate rule0 for such templates:
#     preserve_water=1
#     =0,100,?water
# Similarly, a background lava rule0 might be used in more hellish climes.
#

=0,100,?air
rule1=0,100,preserveBlock
rule2=0,80,2*brick_block,dirt,stone,gravel
rule3=0,100,brick_block
rule4=2*0,100,log-0
^0,100,log-2
^0,100,log-1
rule5^2*0,90,planks-0
^0,80,planks-2
^0,70,planks-1


# LAYERS
# Each layer is a comma-delimited list of rules, one for each block.  There
# must be as many layers as the height, and each layer must have "layer" before
# the rules and end with "endlayer".  There are as many rows as the length, and
# as many rules as the width.  If you want the block blanked out use 0, which
# represents the background Air-block rule by default (but may be redefined).


layer
2,2,2,2,2
2,1,1,1,2
4,1,1,1,4
4,1,1,1,4
4,1,1,1,4
2,1,1,1,2
2,2,2,2,2
endlayer

layer
3,3,3,3,3
3,0,0,0,3
5,0,0,0,5
5,0,0,0,5
5,0,0,0,5
3,0,0,0,3
3,3,3,3,3
endlayer

layer
3,3,3,3,3
3,0,0,0,3
5,0,0,0,5
5,0,0,0,5
5,0,0,0,5
3,0,0,0,3
3,3,3,3,3
endlayer

layer
3,3,3,3,3
3,0,0,0,3
4,0,0,0,4
4,5,5,5,4
4,0,0,0,4
3,0,0,0,3
3,3,3,3,3
endlayer
