Hex grid, every hex already has a terrain-specific hex-shaped piece in it.
Zone of control from a piece extends 2-3 hexes away from the piece, but only along some types of terrain - not water.
To visualise this for the player, I’m trying to set up a command to view/clear the zoc. Something isn’t working, but I’m not sure what.
The view zoc command is simply a GKC zoccomm with a fixed range of 1, looking for a property zoc==0
Each applicable terrain piece has the following traits from bottom up:
DP zoc = 0, with a key command zocprop+1 to increment
AoE with a range of 0 toggled by key zoc
Trigger when zoc==0, triggers zoc, zocprop+1, zoccomm1
GKC activated by zoccomm1, sends zoctrig1 to property zoc==0 at range 1
Trigger when zoc==0, triggers zoc, zocprop+1, zoccomm2
GKC activated by zoccomm2, sends zoctrig2 to property zoc==0 at range 1
Trigger when zoc==0, triggers zoc
This should(?) propagate the command 3 hexes along only the correct terrain, along lines of terrain that haven’t already been triggered, but nothing happens.
I think your going to find a big headache here. I did hex specific pieces once - wasnt worth it.
How do you control the formula? On what axis? Perhaps 2 are true but 4 are not (if you are using hexes…). It becomes very complex. How do you tell/ show this. Area of effect would be the one thing that comes to my mind as a visual display tool if it matches your formula criteria
OK, odd thing: I have kind of got this working, using exactly the traits I posted above, and it works better as 2 hexes than 3 (which is fine), but the command propagates in some odd inexplicable patterns.
Each of those red zones should extend from 2 hexes from the white-bordered pieces, excluding water, but sometimes only extends one hex. The terrain is all from the same prototype and should function identically.
Is there some command propagation limit going on? But if so, the tiny 3-hex zone on the bottom right makes no sense.
Two other zones hemmed in by water worked fine, while all the other mostly open zones are missing hexes.
I just can’t think of any way to explain this behaviour.
The algorithm you’ve roughly described “should work” in general terms. Which means that there’s probably something minor wrong in the details of your implementation, or how “range” is being calculated.
Well, “no way I can conceive” is actually a pretty standard mental state in debugging code, right before the part where I actually find the bug.
The best approach is probably to put in a whole lot of Report traits that show the “progress” of one of these – who thinks it’s sending a GCK, what GCK does it think it’s sending, who thinks it’s receiving a GCK, what does it think the state is when it receives it, etc, etc, etc.
First GKC at range 1
Hex 1 at range 1 completes the trigger, does AoE, sends the second GKC, hexes at range 1 from hex 1 do AoE.
Hex 2 at range 1 is one of the hexes already triggered by the second GKC above, so is no longer a valid target for the first GKC.
This would explain most of the patterns above, and maybe even the tiny 3-hex result if the origin hex somehow triggered first.
Thanks for the nudge. I’m too quick to assume Vassal is buggy.
The solution is not to have conditions for the GKCs or triggers at all, and to not use zocprop as described. You do need a DP to prevent AoE from being turned off once it is on, but that’s all it is for.
