interestingly if I open it to edit with the release version it is no problem, just the beta has the bug.
but you probably already knew that.
Sorry,
I edited and saved it in the latest SVN build. It will not open in regular
or beta builds.
I’ll rebuild it give me a few
Post generated using Mail2Forum (mail2forum.com)
Nevermind
If you got it open in regular build that’s good enough to see whats going on
Post generated using Mail2Forum (mail2forum.com)
I think I get the sequence to what you are doing.
Essentially that is a lot of trigger actions to support the scenario designer. But that is exactly what I am looking for.
So you work from the bottom of the trait list upwards…
At the bottom is the trigger which essentially provides a menu item and a keystroke for the user.
When the trigger triggers it performs two keystrokes.
The first keystroke performed by the trigger accesses the DP which prompts the user, using a list box, for the new troop type.
The second keystroke performed by the trigger switches based on the above-set string DP and kicks off another keystroke to set a numeric DP that will control the image for the troop symbol layer.
(I rekon the order in which the keystrokes are kicked off by the trigger is vital here then as the string DP needs to have the new value before the numeric DP can be set)
The troop type layer is then tied to this numeric DP.
And baby it all works!
I guess I need to work this in the release build, I can do that.
Man that does it! Not so gosh awful complicated once you see it. But I can tell that for me to work through the new concepts of triggers etc would have taken a very long time to come up with a solution.
So thanks yet again.
Now on to a Scenario Designer player side definition and Restricted Access (as a first try) and then onto text labels… keyed off of either the unit type DP or some special unit factor DPs… for the various unit factors.
Restricted Access is not what I am looking for, because that would seem to prevent the normal players from even moving the pieces. Looks like I need the Restrict Commands after all.
Okay I added a color stripe for inf/cav, and would like to key this off when the unit type is set.
See attached zip rename to vmod.
I think I did everything correctly up to a point.
But… what is the syntax for a rather lengthy expression using && and ||?
For instance, in the file there is a new trigger action I added which looks for a property match that goes something like Type=AE||Type=AL. I want to add that it only matches when the Player is set to one or the other color.
I imagine I need to add a DP for the player color for the piece, that operates with the background color. That would permit me to access that background color as a property in the above trigger.
But what is the syntax? Do you use ()? Like Player=Purple&&(Type=AE||Type=AL)? If you leave off the parens does it follow a convention for nested logicals like C code - whatever bizarre effects that would produce?
Well I made a first attempt to add inf/cav class stripes (to complete the old school retro look to go with the prestags art). Some stuff worked and some stuff did not. To wit…
-
The “moved” indicator does not show up. Not sure exactly when that stopped working. {EDIT - found it, the image went away sometime so I re set the image and now it shows up.}
-
Setting the unit type or color seems to have an intermittent effect on the class stripe. Hard to describe all the cases but it clearly is not functioning correctly and a scenario designer can tell within a couple edit attempts.
-
The class stripe name shows up in the reports for the piece, instead of just the background color name and unit type. And is there a way to add a space before the suffix? Maybe change the name of the color property to add an underscore at the end? {edit - fixed this too, if you set a name to the level in the layer it will go in the piece name in the report, optionally as a prefix or suffix, so I deleted the stripecolor level names and now the layer level for the backcolor shows like it should with no stripecolor}
#2 above is the main trouble for now.
I have, again, attached the vmod as a zip if anyone can shoot holes in it for me. I think I will just find a place where I can post it on the web and then I can just link to it and not have to keep re-attaching it.
(another question… is there a text editor that works for module design? if I open the module build file in Notepad++ will it work or are you pretty much limited to the editor GUI? because there is some stuff that just cries out to be manipulated like a text file with find/replace and refactoring for design speed sake.)
{ed - I have the DP’s working now with the strength, morale, movement and stacking factors on the combat units, but the darn inf/cav stripe layer dp is still acting funny… now starting into “restrict commands”, but man there are a lot of keyboard commands to list out with this and I have not even tapped into all the unit types yet - a summary display in the module editor of the keyboard commands you are using would be a big help for module makers I would think, but I can manage without it}
Meanwhile the game design parts are coming along very well.
I have the essentials of the game system ironed out but it will need to put some things into tables and do some testing after I have a playtest module to fiddle with.
I have the first scenario OoB and counter mix nailed down with a very good idea of the various factors to put on the units.
I am guessing at this point about 70 counters and about a 12x16 hex map. Since the two armies are essentially stacked into parallel lines about 10 or so hexes long I could probably get by with a 6x12 or so but the extra room is for manuever space and pursuit and in case the battle starts to go sideways.
No idea how I will manage the terrain just yet (I dunno but I am thinking a kind of Panzerblitz look for it?) but that is jumping too far ahead for now.
Thus spake “IrishBouzouki”:
Any program which is a genuine text editor (i.e., doesn’t add any formatting
of its own) could be used for hand-editing a module buildFile. (I’d recommend
Vim.) However, there’s a lot of content in buildFiles right now which isn’t
human-readable and is quite easy to mess up. So, you can do it if you’re
careful, but you should keep a backup copy before making changes this way.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I really need to change my handle to “Zarathustra”
Okay I am putting the module vmod file up on my webpage.
http://www.user.shentel.net/pmurphy/MyGame/mygame3.vmod
I am still having trouble with the inf/cav stripes, sometimes they work and sometimes not and I have not worked through why. I do know that the cav stripe essentially never comes on when you select a unit type of BC which should trigger it. And when you select an infantry type (AE, AL, AX, BI) the cross stripes sometimes come on and sometimes not, and sometimes wait until you change colors, and sometimes not.
Another bizarre thing I notice is that if I stack two units and then I rotate them the stacking order changes, rotate again and it changes again. Since I am not really doing anything too outlandish with the stacking or rotation I am not sure why that is happening or how to fix it.
Here is the command list if it helps anyone make sense of it.
CTRL-T user/menu starts sequence for set unit type (CTRL-SHIFT-T, ALT-CTRL-T, ALT-CTRL-C)
CTRL-B user/menu starts sequence for set unit color (CTRL-SHIFT-B, ALT-CTRL-B, ALT-CTRL-C)
CTRL-SHIFT-T internal brings up drop down list for unit type string
CTRL-SHIFT-B internal brings up drop down list for unit color string
ALT-CTRL-T internal switch on (new) unit type string sends CTRL-1/2/3/4/5
ALT-CTRL-B internal switch on (new) unit color string sends CTRL-SHIFT-1/2
ALT-CTRL-C internal switch on (new or continuing) unit type string and (new or continuing) unit color string sends ALT-CTRL-1/2/3/4/5
CTRL-1 internal sets unit type number to 1 (AE)
CTRL-2 internal sets unit type number to 2 (AL)
CTRL-3 internal sets unit type number to 3 (AX)
CTRL-4 internal sets unit type number to 4 (BC)
CTRL-5 internal sets unit type number to 5 (BI)
CTRL-SHIFT-1 internal sets unit color number to 1 (purple)
CTRL-SHIFT-2 internal sets unit color number to 2 (yellow)
ALT-CTRL-1 internal sets unit class number to 1 (purple inf stripe)
ALT-CTRL-2 internal sets unit class number to 2 (purple cav stripe)
ALT-CTRL-3 internal sets unit class number to 3 (yellow inf stripe)
ALT-CTRL-4 internal sets unit class number to 4 (yellow cav stripe)
ALT-CTRL-5 internal sets unit class number to 5 (no stripe)
CTRL-SHIFT-S user/menu prompts user to change unit strength
CTRL-SHIFT-M user/menu prompts user to change unit movement factor
CTRL-SHIFT-Q user/menu prompts user to change unit quality rating
CTRL-S user/menu prompts user to change unit stacking points
RIGHT user/menu rotates unit CW
LEFT user/menu rotates unit CCW
CTRL-D user/menu deletes unit
CTRL-M user/menu (un-)marks unit moved
CTRL-N user/menu prompts user to change unit name
Restrict Commands applies only to commands within the same prototype? Even if the prototypes are nested?
In my module, which I will update to the above website, I have a “Unit Traits” prototype which has as its first item a restrict commands. This restrict commands lists all the commands for the unit that I want to block and hide. SOme of them are from other prototypes that use this prototype (but this is the lowest-level prototype that is at the top of all the lists so there are no traits using these commands above it in the list).
But when I execute the lock (with a DP) it locks all the commands within the same prototype but none of the ones outside that prototype for the same unit.
I suspect also I want to use a GP not a DP for the lock as that would restrict the commands for all the pieces at once?
It restricts access to commands above it in the full stack of traits after all prototypes have been expanded
You would generally wany the Restrict Commands trait to be the last trait in the last prototype so that it ends up at the bottom of the list, affecting all traits above it.
The prototype with the lock must be defined after the other prototypes.
Depends whether you want the facility to lock off all new counter production once and for all in one go, or just be able to lock off individual counters.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I tried it with the restrict commands at the end first but it did not restrict anything and the dp did not even show up as a command to do the lock.
but… it occurs to me now that perhaps this was the problem where the module player in the editor does not update until you exit sometimes.
I will try it again.
thanks Brent.
(anyone have a thought about the inf/cav stripe layers/dp not working? I am really looking forward to that one!)
Good point I had not thought of. I think all in one go however, after going back and forth a couple times. If you lock after making a mistake as scenario designer you are hosed anyhow. Better save the file before locking it.
I tried it with a DP and it works using your instruction. Now to change it to GP.
And now I can get rid of the (scenario designer) player side!
okay lock works with the GP… but how I do prevent more pieces from being dragged out of the palette after the lock is in place?
can you use () in a property = value definition for a trigger action?
ie
(prop1 = val7) && (prop2 = val4 || prop2 = val6)
that may be my problem with the inf/cav stripes.
if this is a syntax error, then how do you create a compound expression such as this with multiple properties for a trigger action?
No, you cannot use () in property expressions (yet).
You can use the Regular Expression operator to do this:
prop1=val7 && prop2=~val4|val6
Otherwise, there is a certain order the expressions are evaluated in (that I can never remember), so something like
prop1 = val7 && prop2 = val4 || prop1 = val7 && prop2 = val6
might work also.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I tried this and it made a difference.
Now, with the vmod file on the site linked earlier, I can change colors with the BC cav unit and it updates the cav stripe to the opposite color. But if try to change it to an infantry unit the stripe remains a cav stripe. And if I try to change an infantry unit to the other color the stripe color does not update. Until I change back to the BC cav unit then it works again.
The cav prop=val has a simple format…
prop1=val1 && prop2=val2
The inf prop=val uses the…
prop1=val3 && prop2=val4|val5|val6
(as more layer types get added both inf and cav will be using something like the latter format, which is the one that does not work currently)
Thoughts on syntax issues anyone?
Are u using exactly as you have typed above, or the correct version:
prop1=val3 && prop2=~val4|val5|val6
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)