ZooMan2
Warlord
I think you're right - haven't gotten that far in my first game with this mod yet - good catch.
[SDK] Mountains: back to service
- Thread starter NeverMind
- Start date
I think you're right - haven't gotten that far in my first game with this mod yet - good catch.
BobTheBull
Warlord
betto:
I have merged Mountains with RoM2 SDK, but have not finished making it fully functional. I also made Mountains modular and now have to integrate the xml with RoM xml. When I am done I will post it here.
wolfsruhm:
If I am not mistaken, BUG/BUFFY have their own GameCoredll file, so you would have to merge their SDK files with Mountains SDK (use WinMerge) and then compile the new dll. This should not be that difficult, as the SDK changes for Mountains are not that numerous or complicated.
ZooMan2:
Yes, if you make the change you indicated quarries will work on mountains. I have tested this; mines also.
I have merged Mountains with RoM2 SDK, but have not finished making it fully functional. I also made Mountains modular and now have to integrate the xml with RoM xml. When I am done I will post it here.
wolfsruhm:
If I am not mistaken, BUG/BUFFY have their own GameCoredll file, so you would have to merge their SDK files with Mountains SDK (use WinMerge) and then compile the new dll. This should not be that difficult, as the SDK changes for Mountains are not that numerous or complicated.
ZooMan2:
Yes, if you make the change you indicated quarries will work on mountains. I have tested this; mines also.
Afforess
The White Wizard
I have already merged Mountains Mod with RoM SDK. I did it a few weeks ago, check my signature. (I shortened it to Mountains Mod)
ahhhh, ok. well i've got the programm now, though i'm rather new into sdk-editing(well i know a bit c++ so i might handle this with a few days getting inside ^^) or dll-merging(especially the last) i'm not sure what next. simply taking both dlls and 'erge' them together or do i need to do more
Afforess
The White Wizard
How would I change this modcomp so that I could set a specific tech that unlocks movement through mountains? I tried just using terrain impassibles in the XML, but that doesn't work.
Afforess
The White Wizard
Just an FYI to anyone who used this modcomp. EmperorFool and I got it to work so that players need to research a specific tech (in my case, Mountaineering) to move over mountains, but can still receive yields from the mountains without that tech. I would post the changes, but my SDK is quite a mess, but well commented. If you want these changes, go to my "Afforess's Addons" page for RoM, and download my Sources. Everything related to this modcomp, including my changes are commented "afforess" and "Mountains Mod."
Deliverator
Graphical Hackificator
Has anyone found a way around the problem that when building cities on peaks the buildings appear in a ring around the tile rather than actually on the peak itself?
This might not be a problem for those with vanilla shaped hills, but for mods with flattened peaks like Dune Wars and Planetfall it really doesn't look right. See here and here for a couple of demonstration screenshots.
This might not be a problem for those with vanilla shaped hills, but for mods with flattened peaks like Dune Wars and Planetfall it really doesn't look right. See here and here for a couple of demonstration screenshots.
davidlallen
Deity
We have used this modcomp in Dune Wars. It is not doing quite what we expected, or perhaps, we are trying to do things it was not designed for.
1. We would like *some* improvements but not all, to be buildable on peak. For example, a windmill should be buildable on grass or peak, while a solar farm should be buildable on grass and *not* buildable on peak. We define windmill with TerrainMakesValid=TERRAIN_GRASS and bPeakMakesValid=1. We define solar farm with TerrainMakesValid=TERRAIN_GRASS and bPeakMakesValid=0. But, both are still buildable on some peaks. This is because the ...MakesValid conditions are OR'd. So if there is grass terrain at peak altitude, the game allows building the solar farm. We also need separate control over peaks and hills, so we cannot use the RequiresFlatlands flag; solar farms should be buildable on hill but not peak.
Is there a way to prevent improvements from being built on peak, regardless of the underlying terrain type?
2. We would like *most* units to move through peaks, but not all. For example, tanks should not be allowed to move through peaks. We have used TerrainImpassable on the unit, but it is ignored. I suspect this is because peak is an altitude, not a terrain type. For example, in vanilla xml, units have a TerrainAttacks field but also a HillsAttack field. This implies we need a separate check of terrain type and terrain altitude.
Is there a way to prevent some units from moving through peaks?
EDIT: I have looked into the sdk functions and I think there is no way to do either of these, without more addition. I will try:
CvPlot::canHaveImprovement will check a new improvement xml tag, bPeakMakesInvalid
CvUnit::canMoveInto will check a new unit xml tag, bPeakImpassable
1. We would like *some* improvements but not all, to be buildable on peak. For example, a windmill should be buildable on grass or peak, while a solar farm should be buildable on grass and *not* buildable on peak. We define windmill with TerrainMakesValid=TERRAIN_GRASS and bPeakMakesValid=1. We define solar farm with TerrainMakesValid=TERRAIN_GRASS and bPeakMakesValid=0. But, both are still buildable on some peaks. This is because the ...MakesValid conditions are OR'd. So if there is grass terrain at peak altitude, the game allows building the solar farm. We also need separate control over peaks and hills, so we cannot use the RequiresFlatlands flag; solar farms should be buildable on hill but not peak.
Is there a way to prevent improvements from being built on peak, regardless of the underlying terrain type?
2. We would like *most* units to move through peaks, but not all. For example, tanks should not be allowed to move through peaks. We have used TerrainImpassable on the unit, but it is ignored. I suspect this is because peak is an altitude, not a terrain type. For example, in vanilla xml, units have a TerrainAttacks field but also a HillsAttack field. This implies we need a separate check of terrain type and terrain altitude.
Is there a way to prevent some units from moving through peaks?
EDIT: I have looked into the sdk functions and I think there is no way to do either of these, without more addition. I will try:
CvPlot::canHaveImprovement will check a new improvement xml tag, bPeakMakesInvalid
CvUnit::canMoveInto will check a new unit xml tag, bPeakImpassable
davidlallen
Deity
By definition, BUG is for *unaltered* gameplay, so I do not think the BUG team will want to merge this into BUG.
davidlallen said:
This is working in Dune Wars 1.6.1. It was easy to clone the behavior of bPeakMakesValid and change the logic of canHaveImprovement. I have not had a chance to try making the bPeakImpassable change.
arkguy
Warlord
Does this mod require Patch v3.19? I have v3.17 and it gives me an error message both with and without that patch and doesn't engage the game.
Well... the first line.. in the first post... The real question here is why don't you have v3.19 installed? Besides outdated mods everything uses 3.19.
arkguy
Warlord
Because I can't get it down loaded do the the time it takes to down the file. High speed internet service isn't available in my area and I keep getting time out and disconnected before the down load is complete. After 4 1/2 hours it was only 24% done.
it seems to have corrupted a file or something as even after delete it the BTS now won't work either so looks like I'll have to delete and reload the game again.
it seems to have corrupted a file or something as even after delete it the BTS now won't work either so looks like I'll have to delete and reload the game again.
Similar threads
[REFERENCE]
How Unit/Tile Visibility Works in BTS 3.19
