No way to turn off out-of-season orchards except by resetting map

[jrvjrv]

Steps to reproduce:

1. pick a map (board 35 is a good one)
2. Terrain SSRs
3. Check checkbox for "Out of Season"
4. apply, done, ok
5. potato masher, pick new boards, terrain ssrs
6. checkbox for "Out of Season" is not checked. Apply here does not return regular orchards. Checking and unchecking the checkbox does not return regular orchards.

The only way to return regular orchards seems to be to use the "reset" button. While that is correct behavior for the "reset" button, it seems a little heavy-handed to have to remove all terrain ssrs just to get orchards back to their original state.

[derimmer]

So we agree that the Reset button is working as designed.

You don't care for that design. Fair enough.

How would you like to be able to Reset individual Terrain Transformations applied via the TerrainSSR panel?

At present, afaik VASL has no knowledge of what Terrain Transformations have been applied. Reset does not undo anything, it just goes and gets a clean version of the board(s). In order to be able to pick-and-choose which Terrain Transformations to reset, we would have to first track which ones have been applied. Then we would need to display those to the user and allow them to select which to undo. Then we would have to undo the changes, both visually and to los data. In some cases, the order that Terrain Transformations are applied affects the outcome (this is NOT good but it is what it is), and we would have to be able to sort that out.

I don't mean to be negative here. I think how the TerrainSSR panel works could certainly be improved and am certainly open to discussion about how.

[geezer09]

I don’t quite understand the issue. Why would the user make orchards out of season and then change it back. Is the only reason because he made a mistake? If so, users are generally fine with paying minor consequences for making minor mistakes, so this doesn't seem to deserve too much attention, especially since i might require an overhaul of the entire SSRS code.

Or is the issue that no terrain ssrs should be implemented until all map boards are loaded? In that case perhaps a simple reminder could be sufficient?

[jrvjrv]

I had assumed that the dropdowns for grain and terrain (eto, pto light-jungle, pto dense-jungle and dto worked correctly. As it turns out they do not either. If I apply dto I get brown terrain. If I then apply pto dense-jungle open ground remains brown but I get palm trees, widened woods hexes and no roads, i.e. a mixture of dto and pto dense-jungle. I will wildly guess that the terrain transformations will add more (and more) terrain overlays that support terrain changes but once applied they can only be removed by "reset."

There must be some knowledge of something about the terrain ssrs applied because the map is drawn & saved as per the terrain ssrs that have been applied. In the BoardMetadata.xml file in the section the overlays for different rules are found. If DTO is applied I sort of expect that not only are the overlaySSRules overlays that apply to dto applied, but also the overlaySSRules overlays that are not part of dto are removed. I don't think the overlays given in overlaySSRules can be added except as part of a selection of terrain dropdown on terrain transformations, vasl would not be wiping out something the user did independently of that dropdown.

That might require initializing the dialog with the current values, and that may be difficult. I can't comment on the degree of difficulty, only that the behavior is not what I would have expected.

Going beyond this, if I load board 12 and apply rowhouse bars become stone/wood, then apply rowhouse bars become open ground, this works. But if I apply rowhouse bars become open ground then apply rowhouse bars become stone/wood, the bars remain open ground. There is of course no way to go back to having rowhouse bars. It seems some sort of hierarchy exists for the terrain ssrs. That is also unexpected behavior for me.

In any case I am noting the apparent misbehaviors. The vasl team is within its rights to put the bug as low priority or mark the bug as "won't fix" because of the difficulty.

[geezer09]

Alot of the problems you mentioned can be found in the dist\boardData\SSRControls file which is in xml format( I hate XML!!) that lays out all these transformations. It seems like @tqrtuomo has been the sole author of this file so it would be nice to get some input from him.

Here is an example of where we get a problem when switching from one Terrain transformation to another, applying light jungle and dense jungle will trigger the noRoads rule, but there should be probably an entry in the "Normal" so that applying ETO will trigger it to bring back the roads. The problem that I see is that althoug many boards have a NoRoads.gif image that allows to remove the roads from a map, i don'yt think there is such a thing as a NormalRoads.gif to fill the roads back. Reset might be the only option ...

edit: I had to modify the text below cause github dosent like to display xml tags apparently

Menu name="Roads">
Source/>
entry name="Normal"/>
entry name="All Paved" rule="AllPaved" text="all roads are paved"/>
entry name="All Dirt" rule="AllDirt" text="all roads are dirt"/>
entry name="No Roads" rule="NoRoads" text="no roads exist">
Target sourceName="Terrain">
activate sourceProperty="PTO light jungle"/>
activate sourceProperty="PTO dense jungle"/>
/Target>
/entry>

[derimmer]

At this point in VASL development, it is IMHO, wildly optimistic to expect that terrain transformations will work completely and consistently. They simply do not.

20+ years of coding by an ever changing bunch of people, with no plan or guidance, different skills sets and coding preferences, all working to fix the current bug and move on to the next issue. An ever changing array of boards, again designed by different people will no requirement for consistent practices across the spectrum. We use underlays, we use overlays, we use shaders, we use color-swapping at the pixel level.

Yes we have the dist\boardData\SSRControls file. But we also have SSRControls files in many bdXX zip files which add new transformations, and probably change existing ones resulting in inconsistent behaviour.

What is helpful is to note inconsistencies and outright bugs when we find them. The PTO issues that @jrvjrv raised are already logged as issues along with others.

I don't think we should continue to fix them piecemeal.

[derimmer]

I don’t quite understand the issue. Why would the user make orchards out of season and then change it back. Is the only reason because he made a mistake? If so, users are generally fine with paying minor consequences for making minor mistakes, so this doesn't seem to deserve too much attention, especially since i might require an overhaul of the entire SSRS code.

Or is the issue that no terrain ssrs should be implemented until all map boards are loaded? In that case perhaps a simple reminder could be sufficient?

I don't see that the second comment should be true. There is no reason for proceeding that way that I am aware of.