I have a hex grid, but on each hex are 12 triangular pieces (think pizza slices on a hexagonal pizza).
I want a command given to one slice to also be given to the adjacent slice in the adjacent hex.
To complicate things, the “pizza” may be rotated during setup, so which slice will end up next to which slice is unknowable, and they all use the same key command.
I think I would normally set a GP to match the location of the current piece, use a carefully tailored pixel range on a GKC, and have a trigger condition that current location not match the GP to make sure only a slice in a different hex is triggered.
However, IIRC on a hex grid, the range becomes hexes.
My first thought is that you should be able to determine which hex is adjacent based on the rotation of the piece, so have the GKC trigger at range 1, but have each triggered piece check if it’s in the correct hex and at the correct rotation to be adjacent.
Well, I guess each slice knows its position in the pizza. Say they are numbered 1 to 12, counterclockwise, so that 1 and 2 are towards the top right, 3 and 4 towards the top, 5 and 6 towards the top left etc. These positional numbers are in a CP or DP on each slice.
Then, say that the command is given to slice number 5, it knows it should just issue a GKC for pizza slice 12 in the hex towards the top left of the current one. If given to pizza slice 9 instead it should GKC slice 4 of the hex right below of the current one etc. (This all assumes default hexes, but the same logic could be applied to inverted ones.)
Some logic to figure out the name of the relevant adjacent hex relative to the current one would be needed, which can just be based on the gridnumbering, hopefully.
Looks feasible. I did not consider that since each slice retains the rotation of the hex parent piece, I can figure out which hex is adjacent.
OK, so source piece checks Facing and gridLocation, somehow figures out target hex (I can probably figure that out). Sends 6 possible GKCs depending on hex to hex relative positions.
Target hex pieces all check Facing against the 1 of 6 GKCs received.
Can $row$ and $column$ be used to calculate the target hex? I don’t see them mentioned in lists of piece properties.
Say a slice is at 1 o’clock and Facing=1, so no rotation, on hex 2-2. According to my grid, the target hex is 1-3 so would a 1st GKC (the one always used to target hex at 1 o’clock) directed at pieces {gridLocation==row-1+"-"+column+1} work? If facing were 2, the target hex would be 2-3, and a 2nd GKC used instead.
When Facing=1 for pieces in the target hex, only the piece at 8 o’clock in 1-3 will trigger on 1st GKC. If Facing=2, only the piece formerly at 5 o’clock triggers on 1st GKC… and so on.
I don’t think $row$ and $column$ can be used that way, but you could use Java string functions to extract the row and column from the $LocationName$ property (assuming your gridLocation is formatted as “-”):
Row CP = LocationName.substring(0,LocationName.indexOf("-"))
Column CP = LocationName.substring(LocationName.indexOf("-")+1)
If you create CPs on each slice called “Row” and “Column”, as above, then you can target your GKC at pieces with
{LocationName==($Row$-1)+"-"+($Column$+1)}
(assuming the same example you presented of slice at 1 o-clock and Facing=1 on hex 2-2).
Actually, come to think of it,
{Row==$Row$-1 && Column==$Column$+1}
would work, too.
Again, I’m assuming that your gridLocations are set to be row first, numeric row & column, with “-” as a separator.
Thanks, I figured that out. I would still like to know how LocationName.substring(LocationName.indexOf("-")+1) works, what substring, indexOf and the +1 are doing there.
Well, no, I think just one GKC would be the case. The original piece (=clicked on) would need to figure out which other hex and pizza slice to call. Why split the work and repeat the hex check on 6 pieces with 5 deciding they are not involved?
I am pizza slice 5 on hex 03-07 (meaning row 3, column 7), then let’s call slice 12 on hex 02-06.
I am pizza slice 9 on hex 03-07, then let’s call slice 4 on hex 05-07
…
A calculated property to figure out target slice and another one to figure out target hex.
Anyway, glad you find this helpful.
P.S. Ok, if your pizzas also rotate, then a calculated property should figure out absolute pizza slice number (to a fixed position) and use that for everything.
LocationName is the automatic property giving the piece’s current location. Substring(x,y) gives the portion of the string beginning at character index x (the first character is 0), ending at character y-1; substring(x) returns the portion of the string starting at index x to the end of the string. IndexOf(“x”) returns where in the string the first instance of “x” is.
So, LocationName.substring(0, LocationName.indexOf("-")) returns the portion of the Location up to, but not including, the first dash ("-"), while LocationName.substring(LocationName.indexOf("-")+1) returns the portion of the Location after, but not including, the first dash.
The column offset varies by row for 4 of the 6 GKC destinations, so I used $Row$=~ ? : to vary the GKC destination. Is there some concise way to do (($Row$==even number) ? : )?
All the hex_Facing HexSlice combinations are to cover the possible rotations of the destination piece, while the triggers to determine which GKC to use cover the possible rotations of the source piece. There are only two possible GKCs to actually send - a or b - to differentiate between the 1 o’clock slice or the 2 o’clock slice on one face of the hexagon, for example. a must trigger b, and vice versa, because of rotational symmetry, not mirrored.
The last hiccup was the GKC destination piece triggering a GKC back to the source pieces, but that should be easy to fix.
Thanks for the help! If there are ways to tidy up and trim down what I have, I would also appreciate further tips.
A quick way to determine if a number is even is to check if the modulo (remainder) when divided by 2 is zero:
$Row$ % 2 == 0
. If the number is odd, the result will be 1.