I would like to drop a terrain overlay on the next free hex.

[Wussel]

I would like to know how to drop a terrain overlay inside a death event on the next field, which does not have an terrain overlay already.

How do I filter for "has no terrain overlay already"? How do I find a hex most close to the original starting hex?

Reason: Some of the existing terrain overlays should not get replaced. Say: Standing on a wooden bridge, I wood prefer the overlay being put in a water field next to it.

Any ideas?

[zookeeper]

For starters, I'd think terrain=*^* would be a SLF that would match locations that have an overlay terrain.

[Shiki]

If I'm not mistaken it would fit any terrain, including the ones without overlay.
But only * should not match the ones with an overlay.

[zookeeper]

If I'm not mistaken it would fit any terrain, including the ones without overlay.

Yeah, you're right.

But only * should not match the ones with an overlay.

It does.

In fact, I can't seem to find any way to write a SLF that matches only locations with an overlay terrain. I tried all sorts of different combinations, but nothing worked.

Of course in this case maybe one can just use terrain=*^B*,*^V*,*^F* and so on to match all the overlay terrains that need to be considered, or alternatively use [store_locations] and then [if][variable]contains= to check whether the terrain string of a given location contains a ^ or not.

[Shiki]

I remember I needed to use things like W*^* instead of W* to match water lilies in an animation with terrain_type=

I wonder if this would match anything

Code: Select all

[not]
    terrain=*
[not]

[Samonella]

I remember I needed to use things like W*^* instead of W* to match water lilies in an animation with terrain_type=

I remember doing this as well, pretty sure it didn't work otherwise. But I just double checked in 13.8 and zookeeper is right, *^* matches terrains with no overlay. Perhaps it was accidentally changed recently?

I wonder if this would match anything

Well, it definitely shouldn't?

EDIT wow i need to read closer, zookeeper already suggested this:

Spoiler:

It's not a pretty solution, but I imagine you could do something like this:

Code: Select all

[store_locations]
    x,y=<whatever>
    variable=location
[/store_locations]
{IF_VAR location.terrain contains "^" (
    [else]
        < whatever >
    [/else]
)}

so the OP would need to loop through an array of acceptably close locations, checking until you find one without an overlay... if you can't find one, either give up and replace an overlay, or expand your radius of acceptable locations and loop again...

[zookeeper]

I remember I needed to use things like W*^* instead of W* to match water lilies in an animation with terrain_type=

I remember doing this as well, pretty sure it didn't work otherwise. But I just double checked in 13.8 and zookeeper is right, *^* matches terrains with no overlay. Perhaps it was accidentally changed recently?

It's the same in 1.12 and even 1.10.

But you are right in that to match for example lilies, W* won't work but W*^* does. Apparently, things are different if you start the string with a *; while terrain=W* excludes locations with an overlay, terrain=* includes them. So you can only check whether a location with a known base terrain such as W* has an overlay.

[Samonella]

But you are right in that to match for example lilies, W* won't work but W*^* does. Apparently, things are different if you start the string with a *; while terrain=W* excludes locations with an overlay, terrain=* includes them. So you can only check whether a location with a known base terrain such as W* has an overlay.

So let me get this straight:

* matches everything
*^* matches everything
G* matches Gs but not Gs^Fds
G*^* matches both Gs and Gs^Fds

. . .

And no one knows any particular reason for it to be this way..?

[zookeeper]

* matches everything
*^* matches everything
G* matches Gs but not Gs^Fds
G*^* matches both Gs and Gs^Fds

Yeah, so it seems.

And no one knows any particular reason for it to be this way..?

Well, as said it seems to have been this way for a really long time, probably ever since overlay terrains were first implemented. I doubt anyone specifically remembers anymore why both * and *^* match everything, if there ever was a specific reason.

Now, * matching everything seems very reasonable. After all, it'd be really inconvenient if every time you wanted to match everything you had to instead use *,*^* or something similar. As to *^*, it does seem like a bug to me that it matches terrains without overlays. It's entirely possible that it just hasn't been widely noticed before.

Whether for example G* should match Gs^Fds might be a more complicated question, mostly because changing that might break a huge amount of content. There might even be some kind of good reason why it doesn't, although the reason could also be for example just to allow the matching to work a lot faster, or something like that.

[Sapient]

Based on what seems to be the intended behavior, the wild-matching behavior does not carry over past ^, therefore whatever letters exist on the other side of ^ should not be considered as matched by "*".

In other words, "*" should only match terrains without overlays.

It is a bug in my opinion.

However, I'm not sure if fixing it might break anything.

[zookeeper]

Based on what seems to be the intended behavior, the wild-matching behavior does not carry over past ^, therefore whatever letters exist on the other side of ^ should not be considered as matched by "*".

In other words, "*" should only match terrains without overlays.

It is a bug in my opinion.

However, I'm not sure if fixing it might break anything.

Firstly, I think making "*^*" only match terrains with overlays would be reasonably safe. There seems to be only a handful of add-ons where something might break because of that. It's also equally much a bug according to your description, and should be fixed regardless.

As for "*", it would technically make sense if it didn't match terrains with overlays, but I do still think it's a reasonable and pretty intuitive exception (whether originally intended or not), because as said, having to use "*,*^*" whenever you want to just match everything would be rather awkward. It'd also seem likely to break a lot of stuff, for example in cases where a macro argument expects a terrain type filter and then * is passed all the time as the "I don't care" value. Needless to say, running a search for a lone * doesn't produce very helpful results.

So, I'd suggest leaving "*" be and just making "*^*" only match terrains with overlays. If it's technically feasible to pick-and-choose, that is. And also if it can be done so that the behaviour of "G*^*" won't change, because that would again surely break a lot of stuff.

Maybe what we need is to add a new special character to denote a mandatory caret? For example "G*¤*" would match only G* with an overlay, "*¤*" would match anything with an overlay, and current behaviour of filters using ^ wouldn't change. Probably not, though.

[Sapient]

The caret is not part of the match, it is just a delimiter. So "G*" is the same as "G*^", which means base terrain starts with G, overlay equals empty string. Likewise "*" is the same as "*^", which should mean base terrain anything, overlay equals empty string (however, due to bug, both variants match anything). If you want to pass a match-anything argument to a terrain macro then it should be *^*.

[zookeeper]

I'm not sure what your point is. Aren't you just describing the current behaviour?

[Samonella]

The caret is not part of the match, it is just a delimiter. So "G*" is the same as "G*^", which means base terrain starts with G, overlay equals empty string. Likewise "*" is the same as "*^", which should mean base terrain anything, overlay equals empty string (however, due to bug, both variants match anything). If you want to pass a match-anything argument to a terrain macro then it should be *^*.

So if i understand right, Sapient is suggesting this:

• * matches terrains with no overlay
• *^* matches everything
• G* matches Gs but not Gs^Fds
• G*^* matches Gs and Gs^Fds

The logic being that the base terrain and overlay terrain are two separate strings; putting a wildcard in one says nothing about the other.

So, I'd suggest leaving "*" be and just making "*^*" only match terrains with overlays. If it's technically feasible to pick-and-choose, that is. And also if it can be done so that the behaviour of "G*^*" won't change, because that would again surely break a lot of stuff.

This would fix the current problem, that it it's impossible to filter for any terrain with/without overlay, but it would leave the system pretty inconsistent with itself: *^* requires an overlay but G*^* does not; * allows an overlay but G* does not.

For what it's worth, I'd side with Sapient. That system solves the current problem, and is consistent with itself. I also think it wouldn't break much code; how often would you filter for all terrains? Even if a macro required a SLF, how often would you want such a macro to affect every hex on the map? And even if you did, why type terrain=* instead of () to just leave the filter empty?
The only drawback is that beginning umc-ers would often find it hard to understand why * doesn't match everything.

EDIT: wait, changing this would affect [terrain_graphics], wouldn't it? I don't know a lot about those, but changing the behavior of * might be a very bad idea after all.

[zookeeper]

EDIT: wait, changing this would affect [terrain_graphics], wouldn't it? I don't know a lot about those, but changing the behavior of * might be a very bad idea after all.

Terrain graphics are slightly different, in that there for example G* does match Gs^Fds. And that rather makes sense, because it'd be awkward if you had to specifically account for the possibility of an overlay terrain whenever you wrote graphics rules for a base terrain.

I'm not exactly sure where and how that difference is implemented, though, or whether there are other exceptions.