OpenXcom Forum
Modding => OpenXcom Extended => OXCE Suggestions DONE => Topic started by: ohartenstein23 on February 20, 2017, 06:26:01 pm
-
Hi Everybody! Based on my previous experiments with loading alternate terrains in the map generator (https://openxcom.org/forum/index.php/topic,5108.0.html), 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:
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.
-
As Solarius Scorch requested, I plan soon include this to my branch.
-
Please review if possible, this doesn't look like a simple thing.
-
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.
-
I will look on this before pulling in.
-
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...
-
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.
-
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....)
-
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.
-
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:
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.
alienDeployments:
- type: STR_BASE_DEFENSE
height: 6
Increases the height of the map to include the extra 4 levels from the normal outdoor terrains.
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:
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:
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.
-
I am really looking forward to seeing a farm above the base. 8)
-
:( 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)
-
:( 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.
-
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
-
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?
-
Is it possible to place the x-com craft in a middle level, like it's parked in an underground hangar?
I must say that I'd like more in-depth example of this. Is someone using this feature so I can steal check the ruleset?
-
Place ablock object on grid 0,0 level 1 and the ship will be placed on the next level up( assuming its empty), i am using this on my current map i am building.
-
Yes, the underground hangar can work, it'd look something like this:
mapScripts:
- name: STR_UNDERGROUND_HANGAR
commands:
- type: addCraft
size: [1, 1, 8] # either 8 or the height of your deployment
verticalLevels:
- type: ground
size: [1, 1, 0] # either 0 or the z-level where your craft is supposed to be
- type: craft
size: [1, 1, 4] # either 4 or the height of the craft's map
- type: ceiling
size: [1, 1, 4] # either 4 or the height of the blocks you want placed above the craft
-
Yes, the underground hangar can work, it'd look something like this:
mapScripts:
- name: STR_UNDERGROUND_HANGAR
commands:
- type: addCraft
size: [1, 1, 8] # either 8 or the height of your deployment
verticalLevels:
- type: ground
size: [1, 1, 0] # either 0 or the z-level where your craft is supposed to be
- type: craft
size: [1, 1, 4] # either 4 or the height of the craft's map
- type: ceiling
size: [1, 1, 4] # either 4 or the height of the blocks you want placed above the craft
Won't define a size like that be suited only to crafts that can fit into a 10x10 map block?
The x, y values should adapt to the size of the craft involved in the mission... I think. Even in vanilla crafts have different sizes.
-
For addCraft/addUfo commands, the x, y sizes are ignored in favor of the size of the craft, and the rest is filled with 10x10 blocks.
-
For addCraft/addUfo commands, the x, y sizes are ignored in favor of the size of the craft, and the rest is filled with 10x10 blocks.
How does addCraft work into TFTD ship/cruise terror terrains ?
-
The LZ blocks are replaced with a larger map block before the craft is loaded. This is not guaranteed to work well with verticalLevels.
-
- type: addBlock
size: [2, 2, 9]
executions: 3
verticalLevels:
- type: ground
size: [2, 2, 5]
groups: 3
blocks: [1, 2, 5, 6, 7, 8, 9, 10, 15]
maxUses: [1, 1, 1, 1, 1, 1, 1, 1, 1]
- type: ceiling
size: [2, 2, 3]
terrain: U_PLANET
groups: 0
I'm adding 2x2 map blocks of the ground terrain. The problem is that the ceiling terrain consists of 1x1 map blocks only.. With the above command no ceiling map blocks are placed over the ground 2x2 map blocks. Is there a way to "fill the area" with 1x1 map blocks or do I strictly need 2x2 ceiling blocks to cover 2x2 ground blocks? (It is not a problem for me to make some new 2x2 map blocks! I just want to know before starting doing it).
Thanks.
-
You can't mix 2x2 size blocks with 1x1 blocks in the same command.
-
Alright thanks!
-
I have a problem with the with the digTunnel command: the tunnels are not dug for the map blocks under the X-Com craft (see screenshot, places marked with red crosses shoudl be open; you can see it works for the other map blocks -green circles).
Full script:
- type: U_DIMENSION # U_BUILDING + U_PLANET using verticalLevels
commands:
- type: addCraft
size: [1, 1, 9]
verticalLevels:
- type: ground
size: [1, 1, 5] # either 0 or the z-level where your craft is supposed to be
groups: 0
- type: decoration
size: [1, 1, 0] # either 0 or the z-level where your craft is supposed to be
terrain: U_PLANET
groups: 1
- type: craft
size: [1, 1, 4] # either 4 or the height of the craft's map
- type: addBlock
#groups: 2
#executions: 1
size: [1, 1, 9]
verticalLevels:
- type: ground
size: [1, 1, 5]
groups: 2
- type: ceiling
size: [1, 1, 4]
terrain: U_PLANET
groups: 2
- type: addBlock
size: [2, 2, 9]
verticalLevels:
- type: ground
size: [2, 2, 5]
groups: 3
- type: ceiling
size: [2, 2, 4]
terrain: U_PLANET
groups: 3
- type: addBlock
size: [2, 2, 9]
executions: 3
verticalLevels:
- type: ground
size: [2, 2, 5]
groups: 3
blocks: [1, 2, 5, 6, 7, 8, 9, 10, 15]
maxUses: [1, 1, 1, 1, 1, 1, 1, 1, 1]
- type: ceiling
size: [2, 2, 4]
terrain: U_PLANET
groups: 3
maxUses: 1
- type: fillArea
size: [1, 1, 9]
verticalLevels:
- type: ground
size: [1, 1, 5]
groups: [0, 1]
freqs: [3, 1]
- type: ceiling
size: [1, 1, 4]
terrain: U_PLANET
groups: 0
- type: digTunnel
direction: both
tunnelData:
level: 1
MCDReplacements:
- type: corner
set: 11
entry: 2
- type: westWall
set: 11
entry: 1
- type: northWall
set: 11
entry: 0
- type: floor
set: 11
entry: 50
- type: digTunnel
direction: both
tunnelData:
level: 3
MCDReplacements:
- type: corner
set: 11
entry: 2
- type: westWall
set: 11
entry: 1
- type: northWall
set: 11
entry: 0
- type: floor
set: 11
entry: 50
-
This is a limitation to the way I implemented the code. Any map loaded by verticalLevels is read into the game after the script finishes, so after the tunnel digging is done. I'm in the middle of a refactor of the code to fix that and allow it to work with digTunnel. For now, I'd avoid using verticalLevels with digTunnel.
-
I remember that you introduced verticalLevels with base defence scenario...
It is similar to ufo base scenario ... therefore the issue is critical because it block your very interesting and innovative feature that required an advance maps maker to apply
In mine knowledge, Robin is the first modder that tries to use it
-
Robin is not the first, Finnik and Solarius Scorch have been attempting a similar mapscript for a while that would make use of digTunnel the way Robin wants to. The example of the base defense map is a specific case where it was defined to work. That is, the level where you are digging has to be
- The first level loaded
- Not using the terrain tag
The addCraft command adds additional complications that base defense maps did not have to account for.
However, this should all be fixed soon with the refactor. It's just somewhat slow going because I'm double-checking and comprehensively testing everything to make sure an issue like this doesn't happen again.
-
ohartenstein23 take your time, don't worry!
Moreover it isn't a big issue; in the worst case I could tweak the map blocks and open up the corridors preemptively, making the digTunnel command unneeded.
-
Hey ohartenstein23 I might *potentially* have found a bug (I say "potentially" because it could very well be my fault).
Sometimes a layer from a 2x2 map block is placed over another 2x2 map block. It only seems to happen happen for that specific 2x2 lava map block you can seen in the screens (maybe because it is the only flat 2x2 map block? Its height is still 4 like the rest but unlike them only the fist layer contains tiles). Quite strange.
I don't seem to have this anymore. Maybe some stuff wasn't properly updated somehow. Idk
-
Can you post your mapScript or the WIP mod for this?
-
here: https://mega.nz/#!Fi4A2ajC!7SB5-3kKD_DT4K-v8Nz_kbmMtdv41mqZhskkO2Aj92Q
-
This is for the alien gate assault mission, using the mapScript "U_DIMENSION", correct? I haven't been able to reproduce what you've been seeing. Can you upload either a save or come up with some instructions to reproduce it?
-
Yes, the U_DIMENSION script.
Here's a save, the block affected is in the top right corner of the map. It is still 2x2 but for once it is not the flat lava block.
I uploaded a new version of the mod with some fixes, the save is made with this version: https://mega.nz/#!YnJBhASL!WZeLvFMXjzLJus6rDgL1j2Lx0cDo9h2frEMuyDuUGwI
-
A battlescape save doesn't help to debug this since the map is already generated but the issue happens during generation : P If you can get a geoscape save just beforehand that'd be the best chance for me to figure this out, otherwise I'll have to check it out in depth later.
-
I don't have a geoscape save, it's from the New Battle mode.