Are there any properties one can use from the Area of Effect or Movement Trail traits?
I am looking for something I can use to determine how many hexes a unit has moved. I guess sort of like using mod(oldx-newx) or similar. AofE knows how to use the hex grid, Movement Trail knows the start and end point, plus any intervening stops. The Map LoS feature can give a whole bunch of properties, of which ‘$Range$’ or draw range appear to be promising, but not that applicable for my purposes as LoS is a map orientated feature where I want a game piece orientated feature.
Or is there something I’m really missing?
Overall aim for this! To automate an aircraft feature, specifically CAP (combat air patrol). An aircraft flies from 1 hex to another hex to provide CAP. A house rule is that this aircraft can provide CAP for the hex it is in + any other hex within range. Range = (aircraft’s movement allowance - the number of hexes moved to get to the CAP hex) divided by 2 (rounding down or Math.floor)
I don’t think so, but I would like to be wrong. Especially for Movement Trail.
The best way I can think to do this is to have a Dynamic Property on each piece that is triggered at the start of every turn (and when the piece is initially placed on the board), saving the current LocationName to the DP. Then, you can compare the current LocationName to the saved one later in the turn to determine how far the piece has moved this turn (I’m sure Google can find you a formula to determine distance between 2 hexes).
Edit: this doesn’t work properly if the aircraft doesn’t take the most efficient route from its starting hex to its current hex, unfortunately…that would be more complicated to account for. Although, actually, I guess you could have another DP that stored the total hexes moved so far this turn (again, reset at the start of the turn), and update that total every time the piece moves (via the “keystroke to send when piece ends movement on this map” option), so now the first DP would be the previous location moved to, not necessarily the starting hex.
Starting to sound complex. One would also need to include consideration for map changes as well. The Main Maps contain up to 6 separate maps, of which a max of 5 can be used for a game.
I’ll have a look see first though.
There is a lot of stuff out there, but we need to keep it as simple as possible. I really cannot see how I can the x,y,z stuff for the hex grid. Vassal gives pixel coordinates for LocationX/Y and OldX/Y. I have come up with the following equation to work out how many hexes a counter has moved.
(Math.ceil((float)(Math.sqrt((Math.pow((CurrentX-OldX)/207,2))+(Math.pow((CurrentY-OldY)/169,2)))-0.0)))
It does screw up a couple of data points, in particular at longer ranges at some particular offset angle. Just cannot get this equation to reach 12 for 4 hexes (only gets to 11). Still, I’m happy to take that small error hit. I haven’t used int at the start as this computed number is being subtracted from another number called range and divided by 2. I’ll do the int(Math.round((float)(stuff))) then.
In any event, I’m more than happy for someone with better math/calculus skills to help me get a much more accurate equation(s) to use.
I believe this page on hexagonal grids has all the formulas you need to get a truly accurate answer (requires transforming hex coordinates to cube coordinates then taking the max of the distance in each of the 3 “dimensions” and halving it), but it would be a pain to implement.
Also, I totally forgot OldLocationName is an automatically calculated property, so you don’t necessarily need the extra DP to store the last location. My bad!
Edit: Oops, conflated the 2 different distance formulas–correction above.
Visited that page before I started to develop the equation. I may be an engineer, but I got lost quickly. I have posed the question to the site owner for some help. Basically, how do I take 2 X/Y pixel coords and get them to be 3D? Or better yet, what tweaking do I need to do with the 2D coords. Will ADFUR
This is not something that will be easy to in a single expression. In Vassal I used the Java implementations supplied by that site for different hex coord types, conversion and range calculating.
If you can follow Java, you can see how this is done in HexGrid.range(). It might be possible to untangle the code into a single expression, but it will be hugely complex.
Yeah, I don’t think a single expression is really practical. If I was trying to do this, I would add multiple DPs to hold the intermediate results, each with part of the equation. E.g., OldQ, OldR, OldS, NewQ, NewR, NewS would hold the transformed coordinates of your 2 hexes (using the appropriate Offset to Cube function: odd-r, even-r, odd-q, or even-q), and then you could use {Math.max(Math.abs(OldQ - NewQ), Math.max(Math.abs(OldR - NewR), Math.abs(OldS - NewS)))} to get the distance.
Edit: I’m not sure if BeanShell allows bitwise-and (the & operator), but as long your hex coordinates are never negative, you can use % 2 instead of &1.
In the Vassal calcs, I treat the raw column and row numbers a odd-q Offset Coordinates , converting them both to Cubic co-ordinates, then the range us given by the formula you supply.
A further complication is that the Hex Grid numbering reported by $GridLocation$ or $row$/$column$ are not the raw (base) row and column, they have already been manipulated depending on the left/right, up/down, odd/even offset scheme selected for the specific Hex gridnumbering. Theoretically, the results should be the same.
Tis all too complicated. Amit did respond to my plea, but not that much help there. Vassal is just too obtuse.
Now if Vassal did have a fully integrated spreadsheet, things would be really different.
None of this ‘Math.function’ crap. Make a table for the hex range and just use V/H lookup functions to get values. F’n easy.
That crappy equation I posted earlier on - (Math.ceil((float)(Math.sqrt((Math.pow((CurrentX-OldX)/207,2))+(Math.pow((CurrentY-OldY)/169,2)))-0.0))).
In excel the equation would be:
=roundup(sqrt(((CurrentX-OldX)/207)^2+((CurrentY-OldY)/169)^2),0)
As an aside, can you please rename that trait you call a spreadsheet. It’s a data store and barely that at best. Alternatively do something with it so that module developers can have at least a chance of some sort of ‘look up’ table. ie give it some properties like row/column that when used will give data on what is the row/column cell. Perhaps in the interests on backward compatibility, clone that “spreadsheet” trait and call it tabulated data or whatever.
The subject of tabular data lookups has come up and been answered before on this forum. There is a workaround that has been proposed (Implementing a lookup table) using Global Properties to implement a high performance table lookup.
Sort of done. I am working with a 2D table, not 1D. So I have 1 case where the hexes moved is equal to the xdifference (ydiff<=1) and then 18 textx GPs. ‘x’ being a ydiff number from 2 to 20. I then used the instring(a,b) to get the number of hexes moved.
(int)(Math.round(stdrange-(ydiff<=1?xdiff:GetProperty(textgptouse).substring(xdiffx2,xdiffx2+2))/2))
textgptouse is “text”+ydiff
Everything was working, but as CPs. As all these CPs will really start to slow response down as they would be applied to over1300 game pieces, I am currently attempting to make them DPs.
The 1st difficulty I’ve struck is triggering 2 DPs to save a pieces current X/Y coords when placed onto a map (using the key command for units ending movement on this map). I’ve even added an watch for this keystroke hot key for manual trigger. Nothing triggers.
Fixed. Should have clicked on expression builder as I forgot to add the {}. Doh.