is there a way for a unit, when determining its appearance, to do something like figure out where it is in the stacking order in its hex and total the number of DP value N of all the units above it in the stack?
similarly when responding to a trigger is there a way for a unit to check DP value K of all the friendly units in adjacent hexes?
much simpler… is there a way when a unit is moved to have it drop to the bottom of a stack in a hex it enters instead of the top, but not globally so that some kinds of units can do this and some can still drop on the top?
I am going for the gusto here on a module that is barely playable in its current form, requiring beta 4 it seems (tried with beta 4, sluggish but doable, just about undoable in the release version iirc), but all these are items I would like to implement if there is a way that does not involve re-programming Vassal.
I am happy to look at examples if anyone knows what modules I should check out for this kind of behavior.
Not easily. I wrote some custom stuff for Tim McCarron for Combat Commander, but it has efficiency problems. Part of the problem is that internally, Vassal cannot easily determine units that are adjacent to other units. The only way is to iterate over all pieces on the board, checking there location and measuring the distance from the target piece. When this starts to happen for a lot of pieces in the main unit redisplay loop, the game grinds to a halt.
This can be done fairly easily using the apply after move key feature of the Map. Basically, each piece that ends its movement on the map is sent a command. Have this command fire a Trigger which checks if the unit should go to the bottom or not. If it does, then it can issue the command to move to the bottom of the Stack (down arrow).
If your units have Text Labels with no key commands to display DP values, then beta-5 should give you a huge improvement in play performance.
Is there somewhere to download your module from? I would be interested in running the profiler over it.
that description re text labels is on the money, they track DPs and there are no key commands as the key commands are used to change DPs.
download site is the same place as before, I have not updated it for a while, working on the granicus scenario details - they need a little work since I bugged out when the scenario started crawling - while ideas knock around for the charts and module design.
essentially units can stack in any order unless moving into a hex in an enemy zoc, then they have to enter the hex by stacking at the bottom or anywhere beneath at least 9 stacking points above them (only the top 9 stacking points fight). unless they are retreating from combat or they are leaders in which case, enemy zoc or not, instead they have to go on top of all combat units.
given the number of counters that can be in a hex doing this for the poor player would be a big help.
no way to get a report when a counter is rotated or the stacking order is changed?
and download and intall the svn4304 version which has my performance improvements. You should find this fixes the performance problems you have with the beta-4 and earlier versions.
This sort of stuff starts to get pretty complicated. By default, counters will stack to the top of a hex, so that is already covered. I would just add a ‘Move to Stack Bottom’ command that issues a Down Arrow. The players manually select it if required.
Sure, just add Report Actions for the Command Key that does Rotation, and for Up Arrow, Down Arrow, Left Arrow, Right Arrow.
I updated the vmod on the site to include your suggestions re stacking and rotation messages and a map end-of-move stack command. It seems to do what I want for now.
Thanks.
Now I really need to get the scenario file re-done. FOr one thing the pieces on the board are created with an older module version and are missing somethings but also there a few a errors and additional details, plus a few leaders, I did not bother with yet.
Beta4 seems workable. I had thought Tim indicated the svn file did not show much improvement over beta4 (for combat commander at least)?
I will give it a try though, I downloaded it from Joel’s site a while back.
Someday I’ll get back to the drawing improvements branch I was working
on about six months ago, and finish the binary space partitioning tree
code. That will help massively with checking for locations.
is cc a much larger game in terms of counter count (?) than the granicus scenario in strategos? is this (cross-checking all the distances) something that might be workable in a smaller module like this?
I did something like what you describe when I wrote my C# code for a miniatures game, had to check for intersecting rectangles which was even worse given they could be arbitrarily rotated, but it turns out I just had to check the four corners (or less if you know which direction you are moving) against the nearest face of each other piece. That part of it actually worked decently, had a lot of trouble with what exactly to do when they hit though, problems when squeezing a stand between another stand and the map edge bouncing back and forth infinately. Enough pain to drop it for a while.
none of which is relevant, except to say that I understand cross-checking N^2 combinations (or even N+N^2/2) is going to get hairy real quickly.
what is the mechanism if I wanted to try it? is there a way for one piece to access properties of another piece (which I would presume $location$ is a property)? and how would it iterate through all of them? would I need custom Java code?
You dont need to write any code (but can if you want) but one way to cross read other component properties is to ‘pass’ the variable/property value to a module level Global property and then read/use that GP. The GP acts as a placeholder your components can use to interact with one another indirectly
Some of the demo’s Ive posted here to illustrate something do this in varying forms (do not remember which ones)
okay I can grok that.
but I am not sure I will be able to hold all the properties of all the units in GP’s, since the number of units is not even really set in stone.
maybe this idea has to sink in a little until it hits that epiphany moment… or I may have to start tearing into those Java tutorials.
