Location filter edge case

[Spannerbag]

Hi,
Just posting to check I've not missed an elegant solution to my problem.

I want to identify units adjacent to an array of stored locations (that vary every turn).
My code works fine most cases.
However this array includes border hexes and it is possible for a unit to be adjacent to only border hexes and even with include_borders=yes I can't find a (straightforward) way to identify these.

I'm assuming that because these hexes are border hexes they are excluded from being the "source" of a location filter.

An example: here the location array contains:

Code: Select all

[0]   terrain=Gll^Fds   x=0   y=1
[1]   terrain=Gll^Fds   x=1   y=1
[2]   terrain=Gll^Fds   x=2   y=0
[3]   terrain=Gll^Fds   x=3   y=0

Here's a visual to clarify.
The snow indicates the array locations above and the lava the problematic location.

LFedge.jpg (120.3 KiB) Viewed 1287 times

Units at 1,2 and 2,1 are caught by location filters, however a unit at 3,1 isn't because that is only adjacent to border hexes.

If it helps, these locations (the snow) have [item] name= (including the border hexes) if there is any way to use those labels?
Also the locations will always be diagonals that start and end on border hexes as per the visual above.

I can see possible rather arcane ways to do this (probably involving a few radius statements) but want to be sure I'm not missing something obvious before setting off...

Happy with solutions involving WFL, lua etc.

If this isn't possible using normal methods that would be useful to know too.

Thanks in advance.
Cheers!
-- Spannerbag

[white_haired_uncle]

I *think* what you're saying is that 1,2 and 2,1 filter, because they are adjacent to "[1] terrain=Gll^Fds x=1 y=1", but 3,1 does not, even though it is (in theory) adjacent to "[2] terrain=Gll^Fds x=2 y=0", and your theory is that this is because 2,0 is not on the map???

I look at the actual code might help.

P.S. "I can't find a (straightforward) way to identify these." Perhaps [store_map_dimensions] would help?

P.P.S. If you're if you're looking at a unit and asking 'is this location/terrain' adjacent to me, and it's failing because the location in question is not on the map, perhaps you could invert your filter and look at the location and ask 'is this unit adjacent to me' since the unit *will* be on the map (assuming it's not on the recall, or dead, etc, I'm assuming you have or can ensure this).

[Spannerbag]

I *think* what you're saying is that 1,2 and 2,1 filter, because they are adjacent to "[1] terrain=Gll^Fds x=1 y=1", but 3,1 does not, even though it is (in theory) adjacent to "[2] terrain=Gll^Fds x=2 y=0", and your theory is that this is because 2,0 is not on the map???

I look at the actual code might help.

P.S. "I can't find a (straightforward) way to identify these." Perhaps [store_map_dimensions] would help?

P.P.S. If you're if you're looking at a unit and asking 'is this location/terrain' adjacent to me, and it's failing because the location in question is not on the map, perhaps you could invert your filter and look at the location and ask 'is this unit adjacent to me' since the unit *will* be on the map (assuming it's not on the recall, or dead, etc, I'm assuming you have or can ensure this).

Good ideas.
As well as the unit moving to that hex, the terrain can also change.
So in the visual the snow hexes "move" each turn.
The actual filtering is done in a custom event (so no $unit) and is required inside a [filter] so it might be possible to flip it around with [filter_location].
Also I can't set [primary_unit] because the event fires in new turn or turn end contexts and handles multiple units simultaneously. I could, I suppose, store the units and loop through but I'd rather keep that as a least resort.
I've tried various iterations of filtering but you've given me another avenue to try, thanks.
FWIW the current version that sits inside the [filter] is:

Code: Select all

[filter_location]
  [and]
    [not]
      find_in=fa
    [/not]
    [not]
      find_in=fb
    [/not]
    [not]
      find_in=fc
    [/not]
  [/and]
  [and]
    [and]
      find_in=fa
      radius=1
    [/and]
    [or]
      find_in=fb
      radius=1
    [/or]
    [or]
      find_in=fc
      radius=1
    [/or]
  [/and]
  include_borders=yes
[/filter_location]

However I just need to fix it so it works for one array and then I can apply that to all of them, i.e. get this working:

Code: Select all

[filter_location]
  [not]
    find_in=fa
  [/not]
  [and]
    find_in=fa
    radius=1
  [/and]
  include_borders=yes
[/filter_location]

I will experiment with the second [and] block.

Thanks again for teh suggestions, much appreciated.

Cheers!
-- Spannerbag

[white_haired_uncle]

The way the wiki describes include_borders and [and]/[not] could be read to mean you'd need to do this:

Code: Select all

[filter_location]
  [not]
    find_in=fa
    include_borders=yes
  [/not]
  [and]
    find_in=fa
    radius=1
    include_borders=yes
  [/and]
[/filter_location]

Or more likely:

Code: Select all

[filter_location]
  [not]
    find_in=fa
    include_borders=yes
  [/not]
  [and]
    find_in=fa
    radius=1
    include_borders=yes
  [/and]
  include_borders=yes
[/filter_location]

[Spannerbag]

Tried this, didn't work:

Code: Select all

[filter_location]
  [not]
    find_in=fa
  [/not]
    [not]
      find_in=fb
    [/not]
    [not]
      find_in=fc
    [/not]
  [/and]
  [filter_adjacent_location]
    find_in=fa
    [or]
    find_in=fb
    [/or]
    [or]
    find_in=fc
    [/or]
    include_borders=yes
  [/filter_adjacent_location]
  include_borders=yes
[/filter_location]

TBH I don't think:

Code: Select all

[filter_location]
  [not]
    find_in=fa
    include_borders=yes
  [/not]
...

Adds anything because this refers to the unit's position which must be on-map and not in a border hex.
But I'll try it anyway.

Assuming that doesn't work, I've thought of a horrible bodge that should work but it is truly ugly and hacky:
if y=1 then instead of unit's location (x,y) test (x-1),y
Oh well, don't suppose just one more will hurt...

Not quite sure how I'm going to implement this yet...

Thanks for your ideas and suggestions, will try them.

Cheers!
-- Spannerbag

[Spannerbag]

@white_haired_uncle

Thanks again for your ideas and suggestions.
An even uglier variant of my x-1 idea worked (these hacks only work because I can make assumptions based on map terrain).
Haven't fully tested it yet but looks hopeful.

Have to drop it for now (rl ) but please let me know if you're interested and when it's fully tested I'll drop the code here eventually (maybe a few days, hopefully I'll remember ).

Unfortunately it's not that useful as a general case/example because the logic my ugly hack relies heavily on the specifics of the map and scenario.

Cheers!
-- Spannerbag