OpenXcom Forum
Modding => OpenXcom Extended => OXCE Suggestions DONE => Topic started by: ohartenstein23 on December 03, 2016, 08:58:36 pm
-
Hi Everyone!
1/ I've been working on another coding project for the OXCE+ version of the engine, and just got a new feature working: using map scripts to add map blocks from other terrains. This allows you to do things like adding some forest to a simple farmland ufo mission, like in the screenshot I've attached. The original intent was to start adding support for having an above-ground portion to base defense maps, but it turned into making more general tools for this purpose. Map scripts can be given an optional command terrain:, which allows you to pull in a map block from any defined terrain. This works for addBlock, addLine, addCraft, addUFO, and fillArea.
For the example of the farm/forest hybrid map, the script looks like this:
mapScripts:
- type: FARM
commands:
- type: addUFO
- type: addCraft
- type: addBlock
terrain: FOREST
size: 2
executions: 2
- type: fillArea
blocks: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]
maxUses: [3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3]
2/ The second part of the new code is adding special 'filler' terrains for base defense missions. In globe.rul, where terrain: is defined by geoscape texture, I've added the possibility to define baseTerrain: in the exact same way - these are to replace the nondescript dirt fill-in with whatever you want. Maybe you want your base to be placed right next to a charming little farm? Or have snow cover in the arctic? The commands I described above will do this with the base squares not filled with facilities by setting the terrain: in the command to "baseTerrain" as in the script example below. I also added an option baseDefenseMapFromLocation to seed the RNG for generating the base defense maps from the latitude and longitude of the base, so your bases won't have an overactive ground crew completely redoing the landscaping in-between every time your base is attacked.
Edit by Meridian: baseDefenseMapFromLocation seems to be mandatory, not optional, for "baseTerrain" to work
terrains:
- name: XBASE_FILL
mapDataSets:
- FOREST
mapBlocks:
- name: XBASE_FOREST00
width: 10
length: 10
- name: XBASE_FOREST01
width: 10
length: 10
- name: XBASE_FOREST02
width: 10
length: 10
- name: XBASE_FOREST03
width: 10
length: 10
- name: XBASE_FOREST04
width: 10
length: 10
- type: XBASE
commands:
- type: digTunnel
direction: both
tunnelData:
level: 0
MCDReplacements:
- type: westWall
set: 1
entry: 13
- type: northWall
set: 1
entry: 14
- type: fillArea
terrain: baseTerrain
globe:
textures:
- id: 0
terrain:
- name: FOREST
area: [0, 360, -90, 0]
- name: JUNGLE
area: [0, 360, 0, 90]
baseTerrain:
- name: XBASE_FILL
- id: 1
terrain:
- name: CULTA
baseTerrain:
- name: XBASE_FILL
#... etc, adding baseTerrain for each texture id: ...
The second attached image shows an example of this at work, though it's not as nice since I messed up making/editing the maps.
Note: This code has been included in Yankes' OXCE and Meridian's OXCE+ executables, see their threads for source code and .exe's!
-
It looks simple and yet powerful. When you consider this finished I will grab it to my branch.
-
I'll be doing some cleanup today and tomorrow, it should be ready sometime tomorrow.
-
Interesting tools :)
The funcionalities allowed by addBlockFromTerrain and fillAreaFromTerrain can be already done with the 'addUFO' command to mix terrains, but with this I think you've just made it even easier to overcome the 256 MCD entries limit of the map block files when designing terrains. But it will require terrains specifically designed to make full use of this function.
As for 'baseTerrain' I have wished for something different but with a similar objective: being able to determine Base Defense terrain depending on the globe texture, as the current nightlies allow for alien bases.
In short, there would be the vanilla Base Defense + modded terrains that could be used for base defense, depending on the base's location on the globe. Since each texture would have alienDeployments assigned to it, you could have the vanilla underground base, or a version of it with a ground level, or even a base fully on the surface.
-
@Yankes: Here's the branch I created from OXCE+ 3.5 that contains this code. (https://github.com/ohartenstein23/OpenXcom/tree/oxce3.5-plus-proto-basedefensemaps)
@Hobbes: It wouldn't be too hard to make baseTerrain also change the facilities maps, and that's eventually my goal, but by a different method. My next experiment is figuring out how to load one map on top of another (possible allowing for vertical maps), in particular, to allow for having a standard base defense terrain (maps by facility) and decorate them with some sparse maps overlaid on them taken from globe location. I can take a look into having completely new terrain by globe texture too, but this is all further down the road.
-
My next experiment is figuring out how to load one map on top of another (possible allowing for vertical maps), in particular, to allow for having a standard base defense terrain (maps by facility) and decorate them with some sparse maps overlaid on them taken from globe location.
Unless you redesign the XBase terrain, or at least some map blocks of it, it will be impossible (or almost) for the ground maps to be used other than for decoration since there will be no access between the ground and underground levels. And with no access you'll need to remove all the .RMP nodes from the ground levels otherwise aliens will spawn above ground and you won't be able to reach their locations.
-
Aye, using all of this for base defense maps would require significant rework of the XBASE terrain, I just wanted to lay the groundwork in mapScript commands, so that modders can make use of these things.
I have plans to use this for other things (a mod with no underground facilities), but to use in vanilla, I'd add a surface level to all the XBASE maps, including making hangars open-air and making the access lift the way to get to ground level, plus nodes to encourage any accidentally-surface-spawned aliens to make their way below ground.
-
@Yankes: Here's the branch I created from OXCE+ 3.5 that contains this code. (https://github.com/ohartenstein23/OpenXcom/tree/oxce3.5-plus-proto-basedefensemaps)
Could you squash this commits? I prefer if all required changes for some feature are in one commit, 1 commit == 1 feature. This will simplify cherry picking.
-
Sure, the branch has been updated with the squashed commits.
-
One last request, I have txt file: https://github.com/ohartenstein23/OpenXcom/blob/3f2d577c4e95e088a948a66151e2fe454cd8543a/Extended.txt#L548
And I would like if you add description of your new functionality there. I use this file to crate documentation for mod page and my topic.
-
https://github.com/ohartenstein23/OpenXcom/commit/c9b3a34003d9cf0b109c841b0810fabc232f8ce9
Here's some documentation on what I added in these features.
-
Aye, using all of this for base defense maps would require significant rework of the XBASE terrain, I just wanted to lay the groundwork in mapScript commands, so that modders can make use of these things.
I have plans to use this for other things (a mod with no underground facilities), but to use in vanilla, I'd add a surface level to all the XBASE maps, including making hangars open-air and making the access lift the way to get to ground level, plus nodes to encourage any accidentally-surface-spawned aliens to make their way below ground.
Well, there's already a terrain developed for UFO2000 called XBase+ that you might be interested:
(https://dl.dropboxusercontent.com/u/18824603/Area%2051/snapshot_7.png)
It adds two extra levels and the top and adapts most XBase maps so that the aliens can have multiple entry points. The only downside of it is that it currently doesn't have any .RMP files, but it would be just a matter of adapting the vanilla ones.
-
Thanks Hobbes, I'll take a look at it. That is the kind of aesthetic I have in mind as a goal for making these map script commands, but as you said earlier, with the ability to surpass the 256 MCD limit without abusing addUfo.
-
Hey Yankes, what would you think about rolling the terrain definition into the regular addBlock/fillBlock commands? I have some ideas for other mapscript features, and I think it might be easier to have them be options for already implemented commands than to make a new one for each feature.
-
Hey Yankes, what would you think about rolling the terrain definition into the regular addBlock/fillBlock commands? I have some ideas for other mapscript features, and I think it might be easier to have them be options for already implemented commands than to make a new one for each feature.
One question how normal OXC will behave if encounter that command? Can this be ignored without any crash?
I checked current solution, and I see that it will crash when OXC try load your command.
It would be better if it could will be safely ignored by normal version or older OXCE.
-
Yes, I plan on having default handling that would make it ignore the terrain: definition for normal maps or bad definitions.
Did the log print a message like "Map generator encountered an error: invalid terrain for adding block from alternate terrain." for the crash? I put in that error when the command is given the name of a terrain that doesn't exist, or doesn't load a terrain... I think I'll have it load the normal terrain when none is defined.
Edit: How did you use the command? Would you mind posting the ruleset you used to try it?
More edit: For moving the alternate terrain handling into addBlock/fillArea, I would have the code check if there's a valid definition of "terrain:" in the command, and load the map from that if there is. If there is no definition, or you put "terrain: default" in the ruleset, it pulls the map blocks from the same terrain as the rest of the map.
-
Yes, I plan on having default handling that would make it ignore the terrain: definition for normal maps or bad definitions.
Did the log print a message like "Map generator encountered an error: invalid terrain for adding block from alternate terrain." for the crash? I put in that error when the command is given the name of a terrain that doesn't exist, or doesn't load a terrain... I think I'll have it load the normal terrain when none is defined.
Edit: How did you use the command? Would you mind posting the ruleset you used to try it?
More edit: For moving the alternate terrain handling into addBlock/fillArea, I would have the code check if there's a valid definition of "terrain:" in the command, and load the map from that if there is. If there is no definition, or you put "terrain: default" in the ruleset, it pulls the map blocks from the same terrain as the rest of the map.
Other way around, I not ask you to handle default values or invalid data but to define new rulesets in way that OXC will still run. Of corse it not possible to always do this, but at least most typical cases should work.
Exception that stop loading of ruleses is "crash" because you can run game after that.
In case of your `addBlock`. If you add new property inside command then OXC will ignore if it have unique name. Consider something like that:
mapScripts:
- type: CULTA
commands:
- #normal commands
commandsTerrain:
FOREST:
- #commands for forest tileset
DESERT:
- #commands for desert tileset
When OXC loads this it will ignore `commandsTerrain` and use rest as if it was normal map script.
-
I'm not sure exactly what you mean. Do you mean writing the rulesets such that loading a script with the new features into an older version just ignores the new stuff? My idea is this:
mapScripts:
- type: CULTA
commands:
- type: addBlock # this one is loaded normally
- type: addBlock
terrain: FOREST # adds a block from FOREST terrain when loaded by OXCE, otherwise it is ignored by OXC
-
Yes, this is goal. Your example follow this too but there is danger that in this one command is big dependency between `terrain` and rest of values in it.
I do not do lot of stuff in map script to say how serve it will be, maybe small glitches or game simply refuse to load? I would like to avoid latter.
-
Without the terrain: in my (hypothetical) version of addBlock, it will simply load a map block from the regular terrain. The addBlock command also isn't critical if it fails to place a map block, it simply moves to the next command in the list. It won't cause a crash on map generation if terrain: is lacking, if that's what you're getting at. It also shouldn't cause a glitched-out map, unless the ruleset for the extended version of the script you're writing heavily relies on the new commands, in which case it shouldn't be run in OXC in the first place.
-
It also shouldn't cause a glitched-out map, unless the ruleset for the extended version of the script you're writing heavily relies on the new commands, in which case it shouldn't be run in OXC in the first place.
Some thing like thins is acceptable, as you can't make omelettes without breaking some eggs :)
I think you could recreate your commit as you probably change how it work.
-
I've reworked the map script commands to now include terrain: as an option for addBlock, addLine, addCraft, addUFO, and fillArea, rather than having separate commands. See my first post for a link to the new windows executable and a link to my GitHub branch for this edit.
-
I've reworked the map script commands to now include terrain: as an option for addBlock, addLine, addCraft, addUFO, and fillArea, rather than having separate commands. See my first post for a link to the new windows executable and a link to my GitHub branch for this edit.
I find some merge bug in your last commit:
https://github.com/ohartenstein23/OpenXcom/commit/02143e9983e3803726ba761b5f584da4339f3235#diff-8817a4e728e82fd5808cc76936f5488eR3372
this probably should not be included in there.
-
Oh, yeah. I took that out of my working version to prevent merge bugs, but then I did a rebase and forgot that was part of the commit. I'll fix it in a bit.
-
https://github.com/ohartenstein23/OpenXcom/commit/02143e9983e3803726ba761b5f584da4339f3235#diff-7ad296375f2bbbfa7c2e5aa1bb532474L2034
this break probably should be still there.
[ps]
and what bug that previous line cause?
-
Oh, I didn't realize I deleted that break, I'll be adding it back in. Thanks for checking it over!
The previous line doesn't cause a bug, I just changed to my local variable terrain which is what allows for the alternate terrain loading, it's equal to _terrain if you don't define an alternate in the ruleset.
Edit: Okay, fixed, amended to the commit, and pushed to GitHub: https://github.com/ohartenstein23/OpenXcom/commit/429382220bae8cab466ee5c1f9b62a9d996f5324
-
Oh, I didn't realize I deleted that break, I'll be adding it back in. Thanks for checking it over!
The previous line doesn't cause a bug, I just changed to my local variable terrain which is what allows for the alternate terrain loading, it's equal to _terrain if you don't define an alternate in the ruleset.
I maybe state is incorrectly, I was referring to `!unit->isOut() &&` in my question.
-
Oh sorry, that bug. That was the 2x2 unit death bug that you fixed a few days back.
-
+100
Your efforts could revive and enhance the openxcom modding scene breaking the MCD limits
Thank you very much
-
This code has now been included in both Yankes' OXCE and Meridian's OXCE+! Thanks guys!
-
Congrats Oheartenstein! I know how much trouble it was, so kudos for doing it. I will certainly make good use of this feature. :)
-
As for 'baseTerrain' I have wished for something different but with a similar objective: being able to determine Base Defense terrain depending on the globe texture, as the current nightlies allow for alien bases.
In short, there would be the vanilla Base Defense + modded terrains that could be used for base defense, depending on the base's location on the globe. Since each texture would have alienDeployments assigned to it, you could have the vanilla underground base, or a version of it with a ground level, or even a base fully on the surface.
An other complementary idea could be that when the base defense counter attack level is more (a comparison level as to establish) than alien ship attack force, it could be generate an other base defence terrain on the surface with maps such as XBase+ without underground levels, but with some bunker for spawn xcom unit, mixed with a terrain depending on the globe texture. A landing/crashed specific attacking alien ship could be an other option.
-
This whole thread looks to be tackling the exact problem i just ran smack into...maps seam to be limited to 2 tilesets? not sure how the rules play out but tiles from the third tileset ina map dont seam to survive translation to the battlespace.
-
You can have as many tilesets as you want, provided that the total number of tiles does not exceed 256.
You can somewhat circumvent this problem by putting destroyed tiles (not used for map construction) to the end of the last tileset.