terrainimpassable and invisibility

[davidlallen]

In Dune Wars, we would like to give some special abilities to the Fremen, desert warriors who get a huge advantage in desert terrain.

1. Ability to pass otherwise impassable terrain. I can do this with the TerrainPassable field in xml. But that means every Fremen unit needs to be a UU. I would prefer to do this with a promotion. Has anybody already added sdk code to make this a promotion?

2. Ability to be invisible on certain terrain types. I have "heard" this is possible in Fall Further. Is the sdk code to allow this available separately, or is there a separate mod-mod to allow this?

 

[xienwolf]

All of Fall Further's DLL code is available through the Modder's Guide thread in our forums for the last major release, and then changes are included with patch downloads from there in.

The way in which we allow invisibility on certain types of terrain is through a method of allowing promotions to be automatically acquired when prerequisites are met for the promotion. It would be a relatively hefty code merge to snag all of the promotion fields we have added that make this completely worthwhile, but it really does revolutionize what you can accomplish with pure XML (The primary fields which change how the world works would be AutoAcquire, MustMaintain and EffectPromotion tags, but without all of the other prereq fields it doesn't allow you quite as hefty of freedom to define when/what happens, and without all the other effects promotions can do to a unit you lose a lot of the "what to do once you do it" capability).

 

[davidlallen]

I am sure FF has thousands of changes. Is there a way to tell which set of changes may be related to this particular feature?

Does it hook onUnitMoved to apply and remove the promotion? Does that impact the runtime?

 

[Deliverator]

I've said before it would be great if we could have all the Promotion possibilities that have been added to Fall Further. It seems like absolutely massive task though. It would be great if the non-FFH2 specific stuff was available as an easier to merge modcomp, but that would be a big amount of work too.

 

[xienwolf]

Aye, there is much I have added which I would love to provide for base BtS users to enjoy as well, but I still have massive plans for the DLL and a lack of time to do those, let alone back-port all of my current work


Unfortunately it isn't too easy to pull individual features from my code unless you are fairly comfortable in the DLL to begin with. Initially I labeled everything seperately, but it didn't take long for me to have so many total modifications that the seperate labels were taking up more space than the code itself, so I began combining the basic aspects (load from XML, display Text, Access Variables, Declare functions...) and only labelled the functional pieces. Now I tend to just use a generic label for even that stuff

I was paranoid that the AutoAcquire harmed the speed of the mod, because FfH is already fairly slow, and modmods of it tend to be REALLY slow. But we ran some profiling on the system and found it wasn't much of a hit at all. In most cases there was already a loop over all promotions where I linked it in. Though these loops in some cases only existed already in FfH, so in BtS it might be a bit more of an impact, but it still isn't a significant one.

 

[davidlallen]

Can you offer me any pointers inside the cpp where I would go messing around with terrain specific invisibility?

 

[xienwolf]

If you want to set that up as specifically invisiblity on a type of terrain, then you would load a mixed array into Unit or Promotion infos. It would contain Terrains and invisbility types, storing the integer of your invis type in an array of size TerrainInfos. Then you would link a check for this invis type in CvUnit::getInvisibleType() probably. It would REALLY help if you enable multiple invisible types on units, which is one thing I do that might not be too hard to extract.

Hrm.. actually this setup would only allow you to have a single invis type on each terrain, so you would be better off doing a double array which is both Terrain and Invisible size, storing a boolean.

So you would load from something along the lines of:

<TerrainInvisibles>
   <TerrainInvisible>
      <TerrainType>TERRAIN_PLAINS</TerrainType>
      <InvisibleType>INVISIBLE_SUBMARINE</InvisibleType>
   </TerrainInvisible>
   <TerrainInvisible>
      <TerrainType>TERRAIN_PLAINS</TerrainType>
      <InvisibleType>INVISIBLE_LAND</InvisibleType>
   </TerrainInvisible>
<TerrainInvisibles>

If you do it the second way I mentioned, this entry would result in being Invisible_Land on any plains. Do it the second way I think of and you will have the unit be both Invisible Sub and Land, meaning that to be seen he has to be spotted by someone (or a pair of someones) who can see both invis types.


Loading a double array would be tricky, if you want to go that route I can help you out quite a bit starting next weekend. It will be VERY worth your time to go that route, so till then you could try to import my changes to allow multiple invisible types per unit, as you will require that as a base anyway.

Keyword for the functional bits of the multiple invisible change would be

/** CandyMan

Though there are many changes which you will find under "New Tag Defs" as well, but those can be found by searching for the functions required by CandyMan for the most part.