I see this is an ongoing problem, but I’m going to reiterate here. Whenever I have irregular grids defined, and I alter the dimensions of my board, the grids do not move (and I wouldn’t expect them to). However, when I move the grids, the zones do not move with them. It seems the zones are completely independent of the grid in this regard, which is pretty useless. When an irregular grid moves, its zones should move relative to it - not just stay behind.
Hi,
I’m not sure I understand exactly what you mean
What exactly do you mean by
when I move the grids, the zones do not move with them
Zone has a specific meaning in Vassal that does not match your description, What is the exact symptom you are seeing? Might need to see the module where this is happening.
Regards,
Perhaps it was meant to be written the other way around–in which case it makes sense and is easily reproducible.
Create a Zone, inside of which an Irregular Grid is created with a couple regions. Edit the Zone, Shift-drag to move it without altering its shape, and the defined regions might now be outside the zone, because they didn’t move with the Zone containing them.
Ok, that makes sense. The Shift-drag feature to move the whole zone is relatively recent and not something I was aware of.
The problem is that the Zone Shape editor is just that, a shape editor, it doesn’t even ‘know’ what sort of grid it contains.
Also, with a lot of the transformations you can do in the Shape Editor, there is no way to imply a logical effect on any enclosed irregular grid points.
For example, if you move the bottom left corner or insert a new point in the top horizontal and drag it down, what effect should this have on any defined irregular grid points?
The best we could do would be to make shift-drag a special case that pops up a dialog if a grid exists and asks ‘Move child grid by same amount?’. We could then move the regions on an irregular grid, and even slide the starting positions of a hex or square grid over.
I’ve had a quick review of the code and it is actually a really tricky technical problem to make this happen.
However,
Are you aware that in the Irregular Grid editor, you can select multiple regions and move them all at once by the same amount?
Thanks, I did have the terminology backwards. In a zone within a multi-zoned grid, if the zone contains an irregular grid of “regions”, and the board has its dimensions altered, the zone, its grid, and the grid’s regions do not move, as one would expect, since vassal cannot be expected to “know” where the new location would be. That’s fine and well. But when one moves the grid (by shift+drag), the regions under the grid do not move with it. One is reduced to moving the regions as a separate action. If this is possible by “lasso” of all regions (or by some other method), that’s certainly an improvement over moving them one-by-one, but the real problem here is that the zone (and its grid) should be owners of the objects found beneath them (in this case the regions), and so region location should be classified as a given location within that grid, and not as an absolute location on the board. Move the zone, its grid (or grids) should move with it, and thus the regions within that grid move the same amount and direction. I don’t believe this should be an exception, but a rule. Why else use the parent-child object metaphor in Vassal, if it doesn’t apply when it comes time to modify locations of zones?
In this example from my design, Minneapolis is a zone defined to be where the Minneapolis airport is on the map, and the 13 regions inside it will always be in the same locations within its grid (as implied by the irregular grid shown “owning” those regions). But if the board moves, the zone stays where it was (as expected), but in moving the zone, its “children” objects do not move with it. Coming from an object-oriented programming background, from back in the eighties and nineties, that just violates inheritance from parent objects. Location references for child objects should always be relative to location of its owning, parent object.
Brent’s suggestion to move all regions at the same time didn’t occur to me - and I’ll certainly be taking advantage of it, as soon as I determine how one selects them all at one time. But the problem I’ve identified - as a result of lack of inheritance in objects - still remains and requires time-consuming intervention by the designer that shouldn’t be necessary.
As I mentioned on Discord, moving the whole zone box is one small part of the Zone region editor and is the only function where some sensible manipulation of the enclosed regions makes any sense.Even then, it’s possible you may have moved the zone point by point completely away from the enclosed regions making a subsequent ‘move whole zone’ meaningless. Plus there are issues with handling multiple moves and undo on cancel.
You’ve raised some valid points and happy to add an enhancement issue but it’s not something that will have a high priority.
Regards.