Bug Reports and Discussion

[MagisterCultuum]

I think that the popup in which an AI master of a human vassal demands some resource of the vassal needs to have a prerequisite that checks to make sure that there is a trade route between the player's respective capital cities. When I agree to be a vassal early in the game, at least when my master is on a separate continent and neither of us has Astronomy, I keep getting the popup over and over again. It does not make me loose the resource, but it is annoying.

 

[Red Key]

I'm very close to moving some of the terraforming spells out of python and into the SDK. Due to that I have been looking closely at what the requirements and effects of the terraforming spells are. There are a few things that are inconsistent and it would be a lot easier if they were more consistent. Here are some examples:

• Vitalize can be cast on flood plains but Spring cannot
• When Vitalize is cast on flood plains it changes the desert to a plains and the flood plains is still there
• Scrubs are the only terrain feature that is affected by spells (besides Spring's ability to remove flames which is clearly intended). Both Vitalize and Spring remove scrubs when terraforming a desert. Yet the previous point mentions that Vitalize leaves flood plains alone, and it is possible to Scorch a plains/forest and make it a desert/forest.

Here is what would be easiest to program: ignore all terrain features. This would mean Spring could be cast on flood plains, but would this make Spring too powerful? It would also mean just leaving scrubs alone.

Here are some other options:

• Prevent most terraforming spells from being used on flood plains, but use python to continue allowing Vitalize on flood plains. Don't care about any other features.
• The reverse of the previous. Use python to prevent Spring on flood plains, but most terraforming spells will make no check for flood plains or any other feature.
• When terraforming check if the feature is native to the new terrain, and remove it if is not. This would mean no desert with forests and no plains with flood plains.
• Allow Spring on flood plains, but make so it removes the flood plains. This could be done using python or I could add in a new XML tag that indicates if non-native features should be removed as the previous option describes. The XML tag would allow some terraforming spells to remove non-native features and others to ignore them.

Opinions? Final ruling from Tholal?

edit: Maybe it would have made more sense to put this in the Feature Requests thread. I'm leaning towards the option I put in bold above.
edit2: Realized the one I was leaning towards (python to prevent Spring on flood plains) would be awkward to program and removed the bold. Added another option.

 

[Tholal]

Hmmm. The terraforming spells are more messy than I had realized.

I'll think about it a bit, but at first thought, it seems like the following option would be the best choice for keeping the spells functioning exactly as they do now.

[*]Allow Spring on flood plains, but make so it removes the flood plains. This could be done using python or I could add in a new XML tag that indicates if non-native features should be removed as the previous option describes. The XML tag would allow some terraforming spells to remove non-native features and others to ignore them.

I guess the question becomes, is doing that worth the effort? Might be simpler to just delete the non-native features.

 

[Red Key]

I guess the question becomes, is doing that worth the effort? Might be simpler to just delete the non-native features.

I wouldn't mind adding another XML tag. It would just have to be a boolean tag, so it would be easy compared to the tags I added so that TerrainConversions can be specified in the XML. However, if we want all terraforming spells to remove non-native features we wouldn't need the tag, but that would change the behavior of Vitalize and Scorch.

I don't think workers can remove/chop scrubs, so maybe that is why they made sure they were removed by the spells.

 

[lfgr]

At least forest/desert is weird. I don't think it's intended.

 

[Red Key]

After giving it more thought my vote is that we allow Spring on flood plains and make so terraforming spells remove features if they don't belong on the new terrain (this is easily done by checking the TerrainBooleans that features have in the XML). Then flood plains would be removed by Spring and Vitalize, and forests would be removed by Scorch.

I am willing to add in another XML tag such as <bIgnoreFeatures> if we want to allow some terraforming spells to not remove features. Then we could keep the behavior of Vitalize and Scorch the same if we want, but I don't think it makes sense for flood plains to survive when the terrain is changed or for there to be forests in a desert.

I think part of the reason the terraforming spells are the way they are now is because there wasn't a good AI for them.

 

[Tholal]

After giving it more thought my vote is that we allow Spring on flood plains and make so terraforming spells remove features if they don't belong on the new terrain (this is easily done by checking the TerrainBooleans that features have in the XML). Then flood plains would be removed by Spring and Vitalize, and forests would be removed by Scorch.

OK. Works for me!

 

[[to_xp]Gekko]

why would you ever spring a floodplain though? sounds like a noobtrap. vitalize keeping floodplains is intended since it's a lvl3 spell.

 

[Red Key]

why would you ever spring a floodplain though? sounds like a noobtrap. vitalize keeping floodplains is intended since it's a lvl3 spell.

I wouldn't want to spring my floodplain. Although now that you mention it this does open up offensive possibilities with Spring. We might want to restrict Spring so you can only cast it within your own boundaries (Vitalize already has this restriction) or you could Spring your enemies' floodplains.

The problem with Spring is it creates a special case from a programming perspective. No other terraforming spell has a feature that prevents its casting. I can add in a tag to prevent the removal of features for spells like Vitalize if it is desired. I guess I could add in some tag like <BlockedFeature> to keep Spring the same, but it seems like a lot of work for one spell. We will be improving the terraforming AI and that should keep the AI from casting Spring on floodplains.

 

[Kiech]

Floodplains are Floodplain/Desert. Change the Desert to a plain (Floodplain/Plain) and get +1 and +1 to the square.

 

[EvaND]

About terraforming and flood plains, and since the latter cannot be bloomed, cud there be a way to remove them if so desired, so that the tile can be turned into a forrest?

 

[Red Key]

Floodplains are Floodplain/Desert. Change the Desert to a plain (Floodplain/Plain) and get +1 and +1 to the square.

About terraforming and flood plains, and since the latter cannot be bloomed, cud there be a way to remove them if so desired, so that the tile can be turned into a forrest?

I think you missed the earlier discussion. In the new system flood plains and other features will be removed by terraforming if they do not belong on the new terrain type. Features have a list of TerrainBooleans in the XML that tells what terrains the feature should be on and this list is what the code will check. For example, shrubs and flood plains only list TERRAIN_DESERT in their TerrainBooleans, so if you terraform a desert to something else these will be removed.

If this is too much of a change then we are considering adding an XML tag that would allow some spells to skip removing features. This is being done to make the terraforming spells consistent enough to move out of python and into the SDK. Currently the terraforming spells are inconsistent. For example, Vitalize removes shrubs but not flood plains.

Does Magister's mod have any new terraforming spells? I was wondering if these changes would affect his mod.

 

[lfgr]

Considering "noobtrap": If it's handled in the DLL, you could show yield changes in the Spell tooltip.

And then it should also remove invalid improvements, like lumbermill if forest is removed (with the exception of unique features).

(And another thing I noticed but forgot to mention: chopping forest next to a river does not show +1 Commerce as it should)

 

[MagisterCultuum]

Does Magister's mod have any new terraforming spells? I was wondering if these changes would affect his mod.

I don't think the change would cause any real problems for me, although I can't be completely sure until I merge my mod with the new implementation.

What are you considering terraforming spells?

High Priests of Winter have an xml-only spell that creates a Blizzard feature on the tile.

Aquilans have a passive effect that calls or creates blizzards, and Auric Ascended has a passive effect that terraforms all nearby land (using the python result of Snowfall Greater as a python prereq for a dummy spell.)


There are no new spells that change the base terrain; however, some of the existing spells have been changed slightly.

Spells now include references to the new types of hell terrain. (Otherwise, Vitalize would always be able to be cast yet never have any effect on Wastelands and Glaciers.)

None of my terraforming spells have <bInBordersOnly>1 limiting them to be used only within the caster's own territory. Instead, their python prereqs prevent the AI (not human) players from using beneficial spells in territory controlled by rival teams.

I allow Scorch to get rid of Blizzards and sea Ice (although the caster would have to have Flying to get a chance to use it on the impassible water feature). I blocked AI players with the White Hand state religion from using Scorch to get rid of Snow or Glacier terrain.


I switched Bloom to work through python instead of XML, so players who do not have FEATURE_FOREST_NEW under <MaintainFeatures> can still use the spell on tiles that have improvements which can ordinarily be built over forests anyway (Camps, Lumbermills, Yggdrasil, Tomb of Sucellus, the Seven Pines, and Nature Mana Nodes in my modmod). Frankly, I think it would make more sense for you to change the DLL so that this python workaround is not needed. (It is just annoying to have to destroy a camp in order to use bloom and then rebuild over it.)
Edit: I just remembered that I also permit Bloom to be used to make Burnt Forests turn into New Forests quicker.

 

[Red Key]

And then it should also remove invalid improvements, like lumbermill if forest is removed (with the exception of unique features).

This is actually already done in CvPlot::setFeatureType() and controlled by the bRequiresFeature tag in ImprovementInfos. Lumbermill and smoke are the only improvements using it right now.

What are you considering terraforming spells?

The only spells affected by these changes are spells that change the terrain type. I do consider spells like Bloom to be terraforming, but they aren't affected by this.

None of my terraforming spells have <bInBordersOnly>1 limiting them to be used only within the caster's own territory. Instead, their python prereqs prevent the AI (not human) players from using beneficial spells in territory controlled by rival teams.

When a better AI is implemented in the SDK then you shouldn't need to use python prereqs like this. Some of the spells in MNAI do this also.

I allow Scorch to get rid of Blizzards and sea Ice (although the caster would have to have Flying to get a chance to use it on the impassible water feature). I blocked AI players with the White Hand state religion from using Scorch to get rid of Snow or Glacier terrain.

Just a note on changing impassable features or terrain that has to do with the new choke and canal point code. If you remove an impassable feature then you will probably want to run the calculateCanalAndChokePoints() function I exposed to python in CyMap. If you don't then the AI may think that a plot is a choke or canal point when it no longer is. You would also want to run it for a few other situations like: a plot becomes impassable that previously wasn't, a plot changes from land to water or from water to land. It wouldn't be that bad if you don't though because the canal and choke values just help the AI place forts.

I switched Bloom to work through python instead of XML, so players who do not have FEATURE_FOREST_NEW under <MaintainFeatures> can still use the spell on tiles that have improvements which can ordinarily be built over forests anyway (Camps, Lumbermills, Yggdrasil, Tomb of Sucellus, the Seven Pines, and Nature Mana Nodes in my modmod). Frankly, I think it would make more sense for you to change the DLL so that this python workaround is not needed. (It is just annoying to have to destroy a camp in order to use bloom and then rebuild over it.)

Maybe Tholal could add that to the tracker...

edit: Overall I don't think the changes should cause you any problems.

 

[EvaND]

Edit: I just remembered that I also permit Bloom to be used to make Burnt Forests turn into New Forests quicker.

This sounds quite useful, any chance it can be included?
Also, ETA of the new release?

 

[Rystic]

Minor bug, not sure if has been reported/fixed, but if temporary terrain gets turned into something else, it will still revert back to what it originally was, even if the new terrain is meant to be permanent. For instance, if the Illians get the event that turns plains into tundra, then build a Temple of the Hand and convert the temporary tundra tile to snow, when the temporary tundra was meant to expire, the snow will revert to plains.

 

[Calavente]

I think you missed the earlier discussion. In the new system flood plains and other features will be removed by terraforming if they do not belong on the new terrain type. Features have a list of TerrainBooleans in the XML that tells what terrains the feature should be on and this list is what the code will check. For example, shrubs and flood plains only list TERRAIN_DESERT in their TerrainBooleans, so if you terraform a desert to something else these will be removed.

If this is too much of a change then we are considering adding an XML tag that would allow some spells to skip removing features. This is being done to make the terraforming spells consistent enough to move out of python and into the SDK. Currently the terraforming spells are inconsistent. For example, Vitalize removes shrubs but not flood plains.

Does Magister's mod have any new terraforming spells? I was wondering if these changes would affect his mod.

if you care about my opinion:
shrub/forest should be exchangeable such that "springed" shrub becomes plain forest.

For desert/floodplain : I would go either :
-spring does nothing.on floodplains
-spring brings the tile to "grassland".
-vitalize brings the tile to "plain-floodplain".

 

[Red Key]

Minor bug, not sure if has been reported/fixed, but if temporary terrain gets turned into something else, it will still revert back to what it originally was, even if the new terrain is meant to be permanent. For instance, if the Illians get the event that turns plains into tundra, then build a Temple of the Hand and convert the temporary tundra tile to snow, when the temporary tundra was meant to expire, the snow will revert to plains.

Thanks. I think Tholal already fixed it.

if you care about my opinion:
shrub/forest should be exchangeable such that "springed" shrub becomes plain forest.

For desert/floodplain : I would go either :
-spring does nothing.on floodplains

These would require an additional XML tag with the way the code is arranged now.

-spring brings the tile to "grassland".
-vitalize brings the tile to "plain-floodplain".

These could be done in python. I like the idea of spring making floodplains into grasslands. The AI wouldn't know about it and would still think it was turning the tile into a plains but I think that would be fine. If we want Vitalize to leave floodplains I think I would rather add a bIgnoreFeature tag rather than doing it in python.

 

[Red Key]

I thought of a way to prevent Spring from being cast on flood plains. I will make so the CreateFeatureType tag prevents a spell from being cast if the plot already contains the feature in the tag. Thus, by putting floodplains into the tag it will prevent Spring from changing floodplains. Also this won't make so Spring creates floodplains in other plots because the code already calls CvPlot::canHaveFeature() when checking the CreateFeatureType tag. Bloom is the only spell using this tag right now, and it wouldn't affect Bloom to make this change.