Help in designing module

I am trying to design a module as a variant of Championship Formula Racing (CFR) and the old Waddington’s race game Formula-1.

My problem is:
Each car has a map window with a specific configuration including 7 characteristics ( speed, 2.acceleration, 3.deceleration, 4.tire wear, 5.brake wear, 6.pilot’s skill, 7.motor temperature). Each characteristic has a value of -1, 0 or +1 and is represented by a piece on a map window for each car with 3 different images / layers that can be increased or decreased when selecting the piece (for example top speed is represented by a gauge with 3 different images for the 3 different top speeds available) . You can change at the start of the game all the characteristics but you cannot exceed +1 when you sum up all the characteristics chosen.

I would like to have a number at the same map window that would express the sum of all the characteristics added and that could change instantaneously when you modify the value of one of the characteristics (so in theory that would range from -7 to +7). For that purpose I’ve built another piece with 15 layers with those numbers images, but I really cannot make the correspondence between the characteristics pieces and adding up or subtracting in that 15 layer piece.

I’ve already consulted the designer’s guide and tried many options but I’ve failed.

That’s why I’m addressing the community to see if someone could help me out. What can I do to solve this problem that possibly is not that complicated for people who are not as ignorant as me.

Thank you very much in advance,

José Miguel

Hi Jose,
Have you considered using a “dynamic property” trait to track the values of each car? If you do this, there is a really cool feature that you can use to tie them to a “layer” trait so that they synchronize. With this approach, you can use the value of the dynamic property whenever you need a quantity for use in an expression. That expression could be something like a “calculated property” trait that is graphically presented to the user with the “text label” trait…which accepts an expression…which could be your sum.

Also, if you aren’t doing it already, I recommend working on a copy of your module whenever you are going to try implementing something risky that may not work. If it doesn’t pan out, you go back to your original “good copy” so you don’t have a bunch of broken stuff left over from the attempt.

Finally, the Designer’s Guide is a good orientation to Vassal. But, the “Reference Manual” is really what is maintained and up to date (mostly). Each release of Vassal comes with both in the file structure. The Reference Manual is the one that is all HTML pages. Double-click on one and it will open in your browser. You should be able to navigate effectively with the bread-crumbs that are at the top of each page.

Good luck,

1 Like

Thank you very much for your fast reply.

I’ve tried the dynamic property but I will try it again using your advices.

Thanks also for the tip about the reference Manula; I will check it.

I am really much obliged,

Thank you again, I will let you know if it worked.

José Miguel

I am going to give you a little more detail on how I would do it.

First, in each player’s map window, create a global property called “sum.” It will contain the sum of your car values. It’s numeric, starts at 0 (assuming your at-start sum is really 0), and it ranges from -100 to +100. Those values don’t matter provided they cover your range.

Edit the layer trait that shows -1,0,+1 in each car piece. Set it so ^A increases the level (or adds +1 to the value). Set ^S to subtract 1. Disable the rollover. This means ^A will be grayed out when it reaches +1 and ^S will be grayed out at -1.

Add to each piece the “set global property” trait. The property is “sum.” Set it up the same as “sum” is defined up top. Now add two commands. The first one is ^A. It increments sum by 1. The second is ^S. It also increments “sum” but by -1. Do NOT give these guys menu commands! You don’t want players screwing with “sum.”

Add a new piece to each window. It should have do-not-stack trait that says never to everything. Add a text label trait. For the label, put in something like “My car setup value is: $sum$”.

Try that.

1 Like

Thank you very much Shilinski for your practical advices, but I have some problems following you instructions from the start.

You have written: “First, in each player’s map window, create a global property called “sum.” It will contain the sum of your car values. It’s numeric, starts at 0 (assuming your at-start sum is really 0), and it ranges from -100 to +100. Those values don’t matter provided they cover your range.

But when I right-click at a player map window the only thing similat to your “global property” is “Add Global Key Command” or, if I chose “Insert”, a pop up list appears with “Global Key Command” and “Start up Global Key command”. None of the menus that appear under these options shows me a numeric option and I get bogged at the start. I have an up to date the Vassal Version (It’s 3.6.14).

What am I doing wrong?

Could you please explain me further? Sorry for my dumbness…

Yours indebted,

José Miguel

Every map window by default contains a node called [Global Properties]. Right-click it and you can add one.

1 Like

You are not dumb, just inexperienced.
Joel does a great job on how to create a global property.

A global property in a map is something that everything in that map— pieces, buttons, etc can view and change. You need to do this definition in each player’s map. Each player’s map will have its own copy of this global property.

When you talk about “set global property,” that a piece trait inside a piece. A piece needs that trait so that it can CHANGE the global property. It doesn’t need it to see or use the property, just to be able to change it.

1 Like

Aha, now I got it!

You really give very clear instructions.

I’ll tell how it went.

Much obliged, thank you!

José Miguel

I made a mistake when I showed you what to do, but it’s not a big one, and we can fix it.

So what’s the problem?
If you right click one of your controls (for example, “brakes”) and choose a menu command (for example, +1 or -1), it will work fine. When brakes is at its maximum or minimum, vassal will gray out the commands so you can’t keep hitting +1 or -1.

There’s a problem though if you instead use the keystrokes ^A and ^S. You can still hit ^A when the layer trait is at its max, and this will add 1 to your global property “sum” even though you don’t want it to. For example, if I hit ^A ten times in a row, it will add 10 to sum, and it doesn’t matter if the trait was maxed. Oops on me.

To fix this, we can change ^A and ^S to key strings instead of key strokes. Edit your layer trait, and change ^A to plus1 and ^S to minus1. You type in these strings in the field which is just left of where you typed in the key strokes.

Next, edit the “set global property” trait, and change ^A to plus1 and ^S to minus1 just as you did above.

Now when someone right clicks “brakes,” they won’t see keystroke shortcuts. They only thing they can do is use their mouse to select an action. This is fine because everyone has a mouse these days. By doing this, it is impossible for a user to hit ^A or anything else a hundred time to add +100 to your sum.

Sorry about my mistake, but I’m glad you got it working.

1 Like

Thanks again Shilinski, you anticipate my problems!

I’ve changed the commands and it works.

There is still one small detail, though. Each map window represents a cockpit F1 car from the fifties with seven gauges to subtract / add (-1, 0 or +1). Those gauges are at start stacks with single pieces with 3 layers for the appropriate values (ie, -1/0/+1). The sum /subtract system works fine if we select and modify one single gauge per action. But if I select two gauges at the same time (for example one gauge is at its maximum value +1 and the second one not), right-click the mouse and stroke plus1, the counter adds 2 points when it should only add 1.

This problem could be easily solved if I could define that only one gauge could be selected at a time (forbidding multiple piece selections at the map window), but I don’t know how to do it, I’ve already tried in vain many traits.

I will try to insert an image of one map window in here to clarify better (although I think you caught perfectly well my prolem).

As you can see the “sum” appears at the smal square named Setup below the pilot’s photo, In this case it added correctly: -1 (skill), -1 (speedometer), 0 (acceleration & deceleration) and +1 (for temperature, brakes and tyres each) giving a total setup sum of +1. But if the player starts selecting and modifying two gauges at the same time the problem appears and the sum goes wrong…

As you had already been so patient and helpful, would you have a suggestion to solve this?

Thank you very much in advance.

Yours indebted,

José Miguel

Your problem stumped me, so I created my own small test module to understand what was going on. I normally don’t control-left click multiple pieces at a time, so I easily would miss this.(And it’s likely I have a similar problem in modules I’ve made, and I don’t even know it.)

And you are right. I got mine to behave the same as yours. At first I thought it was a Vassal bug, but the more I thought about it, the more I think Vassal has no choice but to behave as it does. It took me some work, but I think I have figured out how to get around it. First I’ll tell how what to do, and later I will explain why it didn’t work as we hoped.

  1. Edit one of your car pieces (e.g. “brakes”). Then edit the layer trait. At the top is the space for a name. Type in a brief name, and please don’t embed spaces in the name. For example, “brakes.” Later when I refer to “layerName”, I mean your specific layer name. You should substitute what you typed there (brakes) in place of layerName, You will need to do this for all your pieces, but for now let’s do one at a time.

I am assuming, by the way, that each of your layers has 3 levels corresponding to -1, 0, +1.

  1. Add a new trait to this piece called “restrict commands.” For the restriction field you can choose hide or disable. Hide will make a command completely disappear; disable will gray it out. Choose one. I don’t care.

For “restrict when properties match,” we will tell Vassal the condition when the command will NOT be available. This is a bean shell expression. Here you will type this: { layerName_Level == 1 }
Yes, the expression must be enclosed in curly braces. If you instead click on the icon to the right, which looks like a calculator, you enter the expression without the braces. It will add them for you, and you should see a green checkmark to indicate your syntax is correct or a red X if it isn’t.

For “restrict these key command,” click on the “+” to create a blank line, and type minus1 in the left space What this restrict command will do is to not allow anyone to subtract one from the layer level when the level is 1. We need this primarily to shut down the “minus1” in the global property.

  1. Add another restrict commands trait. Yes, you need two of them. In this one, you will have {layerName_Level==3} and the command is plus1.

Do this for all the pieces in this player’s window. Then check it out, and if you are happy, do the same thing for the other players. You could do all of this in protypes, by the way, and save yourself a lot of work.

So why didn’t it work? Suppose you have three pieces, and you left click on A, B, and finally C, which selects all of them. Then right click C, and choose some valid command. Let’s say it translates to “minus1.” What it does is it unconditionally sends minus1 to all the other selected pieces as if C had issued a global key command to A and B. In your case it caused the set global property to subtract from “sum,” even though we thought we had stopped that via the layer. I did discover though that by using restrict commands, I could stop it.

This is something I never check for or anticipate, so this ticking bomb is probably there in most of my modules. I wish I could disable the control click feature, but alas, I can’t, and I just have to hope no one sets it off. Thanks for bringing up your problem because I learned something out of it.

1 Like

Thank you again and excuse me me for all the trouble.

You’re great!

With that solution I will definitely make a prototype (there are 20 cars available!).

I’ve noticed the problem cause I had all the gauge pieces on the map window with a “does not Stack” trait to specify that they never move and coud be selected only if pressing shift+left-clicking on them (the setup of each car is made at the start of the race by each player and it is fixed from then on). This way I inadvertently selected more than one gauge at a time and noticed the problem.

We don’t really need to change simultaneously more than one gauge. Besides your ellegant solution isn’t there a propriety, for the map window or for the pieces, that can simply forbid to select more than one piece at a time? If that would be possible, for my particular module that would be enough… (and yes, all the changeable pieces in my game have 3 layers)

you’re very good at this and have been extremely helpful.

I am some sort of a newbie and self learning; this programming thing is not really my area; I’ve started with some simple modules (origins of WW1 and Championship Formula Racing), then a bigger one (Leipzig 1813) then I got more ambitious; this hobby is making me obsessive-compulsive!


The other approach you’re being advised on–where every time you are incrementing/decrementing an individual statistic, you are incrementing/decrementing the global property representing the sum of all statistics–can work. As discovered, it needs other supporting parts to make sure the sum never gets out of sync.

An alternative that doesn’t need all the Restrict Commands traits to prevent adding when you’re at the max and subtracting when you’re at the minimum is the Calculated Property trait, which lets you just track the sum you want automatically as the individual statistics themselves change.

I am not sure what you are getting at because you are short on detail. I will take a guess though. Another way to do this is to add up the car values whenever we need to know it. For example, sum=(brakes_Level-1)+(acceleration_Level-1)+etc. The trouble with this is those traits are piece-local and not directly accessible to add. We’d either have to have the car components store their values in global properties, or we would have to use the beanshell sum function.

Also I would not use a calculated property here because it’s unnecessary. First, the sum is only of interest during the setup phase, and second, we KNOW when it will change–when a user clicks on a car component. It’s straight forward just to add up the values when they click the component.

Maybe I’m wrong and you have another and better way to do this. Please elaborate if you have a much better idea.

I neither said you were wrong, nor that my proposal was better. It just differs by not needing guardrails on the math.

Thanks for all the tips and troubles.

I will let you know how it went in a few days,


José Miguel

I’ve noticed the problem cause I had all the gauge pieces on the map window with a “does not Stack” trait to specify that they never move and coud be selected only if pressing shift+left-clicking on them (the setup of each car is made at the start of the race by each player and it is fixed from then on). This way I inadvertently selected more than one gauge at a time and noticed the problem.

You are not jmc3, the person who’s been writing to this thread, or are you?

Why would you expect shift left click instead of the simpler left click?

What happens if someone changes their car setup after the race has begun, and can you think of a way to stop them?


Funny because the message that came today from carlzdooms was something that I wrote Tuesday from another computer. Maybe I sent it wrongly to Carlzdooms (?) and he redirected it to this forum…

The idea of selecting only the gauges with shift left click is because during the game we keep selecting the pointers (separated pivoting pieces that are in a different upper level); it is a way of not selecting inadvertently the gauges instead of the pointers. Of course any player can change their gauges but we are counting in honesty…

I hadn’t yet time to fix the problems with your suggestion, Shilinski; I will let you know by (hopefully) Sunday.

Thank you

Jose Miguel

I know I said to give each layer trait a name (like “brakes”), but you can make them have the same name in all car setups (e.g. “car_setup”). If you do that, then all the restricted commands will refer to the same “car_setup_Level”, which means you can put the commands in a prototype, and all that is left is the basic piece, the setup layer, plus the prototype.

FYI, you could also disable the setup controls for each player once the setup phase is done, so then you don’t have to worry about players accidentally or intentionally changing setup once the game has started. Let me know if you want to do that, and I will explain.