Preserving terrain rendering across maps

[Spannerbag]

Hi,
this is probably not possible but I thought I'd ask anyway

In a new campaign I'm working on, various scenarios occur in the same general area.
Each scenario has a separate map showing different chunks of a larger area.
In most cases I've managed to keep mountain appearance consistent by judicious use of map resize.

However in one instance it makes gameplay sense (and WML coding easier!) if I use just the right hand portion (eastern side) of a map from an earlier scenario.
But in this case, no matter how I resize the map (specifically, reduce the x-dimension by removing lower x value hexes) the mountain layout rendering changes.
I'd rather not use void or shroud+impassable if possible as this doesn't make sense in-game.

When I resize the actual terrain stays the same of course, but the appearance/layout changes and I'd rather it didn't so that the player sees familiar mountain ranges.
I could use the existing full-width map but the extra terrain to the left (west) gives the player a place to go that I'd rather they didn't...

If necessary I can get around this but it will be messy in both story and code terms.

Soooo... any ideas? I appreciate I can't (easily) change the terrain layout rules but... have I missed anything?

The existing map has dimensions of x_max,y_max=38,17 (excluding border hexes) and the new map needs to lose anywhere from 7 to 21 hexes from the left.
I'm happy to resize the existing maps if that would help (there may be map dimensions that are more amenable to resizing?).

However, as I'm fighting the terrain I suspect this is not something that can easily be done

Any help/suggestions gratefully received (including You can't do this!),
cheers!
-- Spannerbag

[Celtic_Minstrel]

I'm not quite sure how the terrain graphics work, but I suspect they have a repeating pattern of sorts. If that's the case, it should be possible to reproduce the exact same mountain layout at two different map locations. However, I'm not confident in this and could just be wrong.

Roughly where are the mountains on the existing map?

In the worst case, if you can't figure out a way to make the mountain layout the same on a smaller map, you could blank out the left half of the map with "off-map / void" terrain or something similar. That's not an ideal solution, since the minimap will then be half dark, but it would at least avoid allowing the player to go there.

[Spannerbag]

Roughly where are the mountains on the existing map?

Middle (ish). (Btw had a similar problem when seasons changed and Ms->Mm. Again the rendering changed.)
I might try experimenting with maps with dimensions that are multiples of (maybe) hex-friendly numbers such as 3, 4 or 6...

In the worst case, if you can't figure out a way to make the mountain layout the same on a smaller map, you could blank out the left half of the map with "off-map / void" terrain or something similar. That's not an ideal solution, since the minimap will then be half dark, but it would at least avoid allowing the player to go there.

True, but rather hoping to avoid that

Current thinking is to use enter_hex or moveto to undo movement with dialogue to explain wtf is happening... klunky, but would do if all else fails...

Thanks for replying!

Cheers,
-- Spannerbag

[gnombat]

There are some mainline scenarios that have this issue - for example, the first and last scenarios of Dead Water:

First scenario

Last scenario

[Spannerbag]

There are some mainline scenarios that have this issue - for example, the first and last scenarios of Dead Water:

Not looked into it but if the map dimensions are the same in both scenarios I reckon the different mountain rendering could be the terrain differences between these maps?
First scenario map seems to have 2 hexes of impassable mountains south of the stone village whereas last scenario has 3?
Also last scenario has a snowy hills hex south west of stone village where first has mountain?

But, I take your point, this must happen elsewhere as well

After mulling things over I decided to change the storyline and work around the issue.
It means re-jigging a few things but at least it'll be consistent, use the full size map and allow the player to go where they want.
Ho hum, time to rewrite previous scenarios (again! )

Cheers!
-- Spannerbag

[gnombat]

Not looked into it but if the map dimensions are the same in both scenarios I reckon the different mountain rendering could be the terrain differences between these maps?
First scenario map seems to have 2 hexes of impassable mountains south of the stone village whereas last scenario has 3?
Also last scenario has a snowy hills hex south west of stone village where first has mountain?

Actually, the map dimensions are not the same - the map in the last scenario is larger, with a bunch of additional hexes added to the left side of the map (not shown in the screenshots above). I think that is causing the all the terrain on the entire map to be rendered differently. (But there are a few hexes changed in the last scenario, like the ones you pointed out above, so that could be having some effect too.)

[Celtic_Minstrel]

Roughly where are the mountains on the existing map?

Middle (ish).

Sorry I wasn't clear, but I was looking for some actual coordinates.

[Spannerbag]

Roughly where are the mountains on the existing map?

Middle (ish).

Sorry I wasn't clear, but I was looking for some actual coordinates.

Ah. Ooops.

OK, here's the original map, first without co-ordinates for clarity as it's fairly wide...

Then with co-ordinates..

Lastly, this is what happens when I resize to lose the left hand half of the map (reduce x by 20).
Specifically the range around 28,3/29,4/30,4 (before resize) changes after resize which is a pity because that's where the player's attention will likely be as stuff may happen around there in various incarnations of this map in different scenarios...

Like I said at the top, this is probably impossible - or very unwise - as I'm trying to stop the map system doing what it wants to...

Cheers!
-- Spannerbag

[Celtic_Minstrel]

Yeah, I see it.

I imagine there's some way to get the effect you need, but it would require me to investigate just how the mountain macros work, which I don't really have time for right now. If you've decided to just dodge the issue altogether, then I won't worry too much about it, but I do think your concern generally makes sense.

[Spannerbag]

Yeah, I see it.

I imagine there's some way to get the effect you need, but it would require me to investigate just how the mountain macros work, which I don't really have time for right now. If you've decided to just dodge the issue altogether, then I won't worry too much about it, but I do think your concern generally makes sense.

Yeah, I've had this niggle a few times but have always worked around it.
I appreciate the work that has gone into the terrain/map subsystem and it generally melds the various terrains together well (I have seen slight anomalies where snowy mountains meet non-snowy terrain and I've noticed units occasionally appearing behind/under snowy mountains so the rendering isn't perfect but mostly it works very well - it's certainly excellent value for money! ).
I suspect the design assumes maps will be used in isolation and mostly that's the case, it's just awkward s*ds like me that want to slice up the same chunk of terrain into different (but visually consistent) maps.
I have dipped a toe into terrain logic and know enough to avoid it wherever possible. I have created (single hex) custom terrain and generally get by.

[off_topic]
One issue I need to bottom out when I have time - hah! - is to investigate why custom terrain prevents me using terrain overlays. I did this no problem in my previous campaign but here the system complains thusly:

Since the areas being replaced were quite large I decided to use [replace_map] instead, which works perfectly with my custom terrain every time
It does mean in some scenarios the map changes every turn and has additional terrain mods applied as well but gameplay doesn't seem impacted.

I would have reported this as a possible bug but managed to rollover the logs, losing the relevant entries. Most of the places where I might use overlays are now done as separate maps so I'll look into this if it's an issue on 1.15 - which I suspect will be stable by the time I've finished this!)

Edit: forgot to mention that my custom terrains are all overlays and none exceed 4 characters.
[/off_topic]

Cheers!
-- Spannerbag

[beetlenaut]

Terrain graphics can be of arbitrary size and shape, so you can make one terrain graphics tile that holds the whole island in your scenario. If you attach it to a custom tile at the bottom of the map, it will get drawn over top all the other terrains (because it is "in front"). You could make it out of a screenshot of the previous scenario. I assume that using a large enough image will cause a performance problem, but I have seen very large images in UMC without noticing a problem. I did this in SotA a few times too if you want to look at some examples.

[Spannerbag]

Terrain graphics can be of arbitrary size and shape, so you can make one terrain graphics tile that holds the whole island in your scenario. If you attach it to a custom tile at the bottom of the map, it will get drawn over top all the other terrains (because it is "in front"). You could make it out of a screenshot of the previous scenario. I assume that using a large enough image will cause a performance problem, but I have seen very large images in UMC without noticing a problem. I did this in SotA a few times too if you want to look at some examples.

Thanks for that, will take a look. Would this be essentially an overlay "at a greater height" as it were, so regular overlays would be "underneath" and still work?
It's Sod's Law but the region where I'd like to retain visual consistency with previous scenarios is also where significant terrain changes will occur...
Anyway, I'll take a look at SotA - though multi-hex terrain logic makes my head hurt!

Thanks for the suggestion!

Cheers,
-- Spannerbag

[Soliton]

[off_topic]
One issue I need to bottom out when I have time - hah! - is to investigate why custom terrain prevents me using terrain overlays. I did this no problem in my previous campaign but here the system complains thusly:
[/off_topic]

You can see in the error message that the terrain wesnoth reads is literally ~add-ons/LSB/maps/ws2.map. Presumably the preprocessor was supposed to substitute the contents of that map file but there is a syntax mistake.

[beetlenaut]

Would this be essentially an overlay "at a greater height" as it were, so regular overlays would be "underneath" and still work?

Yes. It would be a purely visual effect.

[Spannerbag]

[off_topic]
One issue I need to bottom out when I have time - hah! - is to investigate why custom terrain prevents me using terrain overlays. I did this no problem in my previous campaign but here the system complains thusly:
[/off_topic]

You can see in the error message that the terrain wesnoth reads is literally ~add-ons/LSB/maps/ws2.map. Presumably the preprocessor was supposed to substitute the contents of that map file but there is a syntax mistake.

Umm, LSB is a valid directory and the path ~add-ons/LSB/maps exists, I didn't mean ~add-ons/{LSB}/maps if that's what you're thinking? When I get chance I do intend to investigate further (and not lose the logs this time). I also agree I'm doing something wrong as the terrain works fine with [terrain_mask] in my previous UMC. If you meant something else could you please clarify as in that case I'm not sure what you mean?

Also the error implies (to me at least) that the map file was found, the contents inspected and the engine found a terrain code it didn't like?

Thanks for the comment, all help is gratefully appreciated!

Cheers!
-- Spannerbag