Two questions: no reporting trait, and stacking in order

I still consider myself a very limited module creator; most of my design is cut and paste from an existing module. As such I’m having trouble finding out how to limit auto-reporting for some marker pieces in an Afrika Korps module I’m making.


The markers designate the route the Rommel unit has moved and I don’t need to have their placement recorded in the chat log. I’ve created a prototype for the markers but the only trait I can find that limits auto-reporting is the Invisible trait. Set up like this:


That works…but only if the trait is turned on. I don’t want auto reporting ever.
I’m sure there’s a way, but I don’t know it. Anyone?

My second question also relates to these markers. As you can see from the first picture there are Route markers and Road markers. I’ve given them all the Basic Name of Rommel marker and created a Menu Button to return them all to their respective holding areas.


That works fine except that they return in no particular order. Notice that the stack of Route markers is disordered as opposed to the Road markers which are still in numerical order. (That’s how they start when the game begins.) I would like to have them return to the holding area AND be stacked in numerical order.

I don’t know whether that would be a trait of the holding areas (one for Route markers and one for Road markers) or maybe a trait for each of the individual markers saying they can only stack on top of the next larger piece. I have no idea of how to do any of that. There may be another or better way too.

Please understand that I’m a carpenter by trade so I’m not at all literate in complex computer terminology. I appreciate any help I can get, but please keep it simple if at all possible.

Thanks,
Frank

Auto-reporting gets configured in a Map Window (i.e., find your Map Window in the Editor and double-click it to access its settings):

You can blank out any/all portions you don’t want (movement within, movement to, creation in).

One way to re-stack pieces in a desired sequence is to use a Multi-Action Button, which is basically a single button that carries out the actions of other toolbar buttons in a specified order. In this case, you might define X number of toolbar Global Key Commands, one for each Route Marker (GKC for route marker 1, GKC for route marker 2, and so on). The GKC would send a command defined in the Route Marker as a Send to Location trait that sends the marker to the desired location. Every GKC you define and give a button text will by default go into the toolbar as its own separate button. But if you go on to list a GKC’s precise button text in the Multi-Action Button’s list of menu entries, the GKC button will actually disappear out of the toolbar and be subsumed into the Multi-Action Button. At the end you have a single button that carries out X number of actions in one press.

MAB shown on top, GKC for Route Marker 10 shown below (you’d make however many more of these you need, each one will explicitly target a different Route Marker by name or some other way of uniquely identifying one):

(this is quick and limited for demonstration purposes only, an actual GKC would need the Global Key Command to send specified–the part right above the “Apply to counters on this map” setting–and the command would need to match the Route Marker’s Send to Location key command that puts it in the desired stacking location)

1 Like

Joel,

Thanks for the quick reply.

Wouldn’t that affect all the pieces on the map? I only was referring to the Rommel markers when I said I didn’t want reporting “ever.” I still want the other game pieces to be reported.
Is there a way I can differentiate/exclude/include whatever, so only the Rommel markers aren’t reported?

Frank

Hi Joel,

I gotta put this down as “I don’t know WTF I’m doing.” It’s coming up on 2am and I wasted the whole day on this. I double checked spelling in entries and expressions so I don’t think it’s that simple. I refreshed counters after each save and I closed and reopened the module many times. I’m at a loss.

Here are some screen shots. (I only worked with Route Marker 11 to make it easier,) The MAB button would always appear but the Return Route Marker 11 would appear and disappear at the beginning of each module restart. Once it disappeared it was gone until the next restart. It would appear when I opened the Return Route Marker 11 entry box in the Editor and disappear when I closed it. I have no idea why.

This is what it looks like when it opens. Notice no secondary button in the green area.

Here’s what it looks like after one click in the Editor on “Return Route Marker 11 (Global Key Command.)” The secondary button appears!

And then it disappears if you open the MAB in the editor.

As I said, I have no idea why this happens. But all of that is just smokescreen because I could care less if the buttons worked, but they don’t. Neither the MAB or the Return Route Marker 11 button works. The markers will return if I use the right button or Alt+R.


So that seems to show that the GKC is working.

So I don’t know why it doesn’t work in the MAB or in its own Return Route Marker 11 button.

Here’s what the entry boxes look like in the two buttons. Maybe you can see what I’m doing wrong:
MAB (bottom half not shown 'cause it just counts down to 1)

Return Route Marker 11 GKC entry box.

Route Marker 11 piece entry box w Send To information box included:

I hope you can make sense of that and tell me how to do it right.

Thanks,
Frank

.

I only skimmed, but it looks like you are missing " " for your BasicName GKC targeting.

{BasicName==“RR11”} targets pieces with a BasicName of RR11.

{BasicName==RR11} targets pieces with a BasicName of whatever value is assigned to a property RR11.

2 Likes

I had a thought about your second question. Suppose when you looked at your stack of markers, they had no numbers on them. You drag one off and drop it on the board. The number “1” appears on it. You drag and drop another one, and the number “2” appears. And so on. Now you do the command to send them all back. (“Everyone out.of the pool!”) They all fly back helter-skelter, and all the numbers are gone. No ordering needed. You think you could do this? I think it’s easier and more fun.

A question for you. Am I well enough off with a circular saw and a straight-cutting jig, or should I pony up for a track saw?

This is from the point of view of a woodworker, not a builder: Track saws are amazing for breaking down sheet goods. Because I can bring most anything else I’m working on to my table saw, I can use that for tackling anything too large for my track saw, so my track saw also doubles as my circular saw. As a result, I sold my circular saw and have only the track saw now.

Good morning Benkyo,

Thanks for skimming. It seems you spotted the error. I put the quotations in and the Route 11 marker returned to the holding area. Now I’m going to do all the other Route and Road markers and see how that turns out. I’ll post again with the results.

I thought that at some point in my many attempts that I had those quotations in. The original name for the piece was Rommel’s Route 11 and there were quotes around all of that. (It didn’t work then, but probably for another reason.) I thought the quotes were there because there were spaces between the words. Eventually I changed the name to RR 11 and then simply RR11 because I just got tired of typing the long name. I dropped the quotes when I took the space out. The expression builder gave it a green checkmark so I thought it was okay. I didn’t realize there was a functional difference between the two that a GKC would need.

Thanks,
Frank

Yep, that was just unlucky. You’d done everything else exactly right. The finer points of expression writing will seem like a lot at first. Referencing something directly by name (as opposed to slotting in a property value) will always need the name put in quotes. The Expressions reference page is pretty good.

The short answer here is that no, there’s no way for a piece to “opt out” of movement reporting. It’s the main reason I dislike it so much–it’s too chatty and just drowns the log in spurious info.

An alternative to explore is using a map’s “Apply a key command to all units ending movement on this map” setting. Then you can decide on a piece or piece type basis whether or not to handle that with a Report Action trait that spits out the piece name, old location, and new location. Or handle it with a Trigger that in turn does a Report Action, and you can add precision in the Trigger’s expression–e.g., maybe it should only report movement when ending in a given zone, or moving from one map window to another, but otherwise be silent.

Good morning Shilinski,

It does sound like fun but I’m sure I couldn’t do it. I wouldn’t know where to start.

Ha, ha, I love it!

Well, I’m an old carpenter. An old yankee carpenter at that. We have this saying: “If it ain’t broke; don’t fix it.” I’ve been using my old Milwaukee circular saw with a guide for over forty years. It never let me down and I never saw a need to replace it. (There also weren’t any track saws back then.)

The guide (actually two: one 54" and one 8’) is a piece of 1/4" thick hardboard with a straight piece of 1 x 3" maple screwed to it. The maple is positioned so that there is about two inches of hardboard on one side for clamping and a little more than your circular saw’s width on the other. The first time you run your circular saw down the guide, the hardboard will be cut exactly to the blade’s kerf. From then on, all you do is align your hardboard edge with the marks you want to cut, and clamp the guide down.

Over the years I’ve beat up the edge and had to renew it. And that’s simple. You simply unscrew the maple, move it over about a half inch, and remake the cut. Presto! Brand new edge again.

(I see Joel has chimed in on this so I’ll continue over there.)

Good morning Joel,

You probably saw what I replied to Shilinski so you know what I use. I’m happy with it and too old to buy new toys. That said, I’ve only heard good things about track saws. If I was young and had the money, I’d consider it.

LIke you, I only use my guide for cutting down sheet goods to manageable sizes. Then the table saw does the rest.

Happy woodworking!

1 Like

Hi Joel,

That’s what I hate about the log too. That’s why I don’t want the markers to be reported.

I guess I’ll keep using my Invisible trait. (Is there a way to have that turned on when the game starts?)

If the Invisible trait has the checkbox disabling auto reporting…


…is there a way to “tap into” whatever command does that? Then that “trait” could be applied to the marker prototype. Possible?

Frank

The short answer here is that no, there’s no way for a piece to “opt out” of movement reporting. It’s the main reason I dislike it so much–it’s too chatty and just drowns the log in spurious info.

An alternative to explore is using a map’s “Apply a key command to all units ending movement on this map” setting. Then you can decide on a piece or piece type basis whether or not to handle that with a Report Action trait that spits out the piece name, old location, and new location. Or handle it with a Trigger that in turn does a Report Action, and you can add precision in the Trigger’s expression–e.g., maybe it should only report movement when ending in a given zone, or moving from one map window to another, but otherwise be silent.

I agree with Joel’s recomendation to disable the auto-reporting entirely and instead take explicit control of reporting unit movement. Besides solving your immediate problem, it is much more flexible and allows fine-grained control of reporting.

The steps are:

  1. Edit the Map Window component to disable auto-reporting of movement and to generate a Named Command (MovedOnMap in this example) to all units which end their movement anywhere on that map:

  1. Define a Prototype trait (called ReportMoves in this example) which will listen for the MovedOnMap command, ignore moves which are entirely within the same map zone (to eliminate spurious reporting), and report all other moves to the Chat Log. That Prototype should contain the following two traits:

A Trigger Action trait which listens for the MovedOnMap command and sends a different command (PieceMoved in this example) only if the movement is between different map zones:

A Report Action trait which listens for the PieceMoved command and reports the move into the Chat Log:

  1. Edit your module so that every unit for which you want moves reported (i.e. - almost all of them) - and only those units - somehow include your new ReportMoves prototype. Ideally, you have already defined one or more prototypes which those units are already referencing in their Single Piece trait. In that case, you merely need to add the ReportMoves prototype into those existing prototypes.

If your units do not already include references to some existing prototypes, then you would have to laboriously add prototype references to all units which need movement reporting.

Cheers,
Jim Hunter.

1 Like

To all the helpful and knowledgeable gents who pitched in and solved my problem:

Thank you. It works!

My Route markers and Road markers go back–in order!–to their respective holding areas with just one button click. Just what I wanted.

One interesting note is that it takes 4 full seconds for this to happen. It doesn’t bother me, but it did surprise me. I thought some of you might find that unusual. Very probably it’s due to my old computer: Dell laptop with an I5 chip running Windows 10.

I’m going to pursue the reporting ideas that Jim Hunter brought up and let you know how that turns out for me.

Again, thanks to you all.

Frank

If you use the “Pre-select (Fast Match)” options to narrow the target of your GKC, that should speed it up considerably. Try using Pre-select by property instead of using the Additional matching expression.

Hi Jonathan,

I confess I don’t know how to go about assigning a property that the fast match can compare to. What I tried didn’t work. This is what I did:

To the Road and Route prototypes (this is for the Road prototype), I did this:

And to the corresponding Return buttons (this is for Road 10), I did this:

Clearly I don’t know what I’m doing in assigning or seeking out the property. I used the term Rommel marker because I figured that would be a common value for all the pieces I want to return. (If value is the right word to use.) But to have the same dialog box appear in the prototype entry and also in the Menu button (the GKC) confused me. I don’t know what to enter and clearly, using the same term Rommel marker isn’t it.

Frank

If you are looking to speed up the same thing as the previous GKC {BasicName==“RR11”}, you could probably just use BasicName.

No additional traits, change nothing except the following:


Delete {BasicName==“RR11”} from Additional Matching Expression.

Check Pre-select by Property.

In Property Name, write BasicName, just that, no “”{}. In Property Value, write RR11, again just that.

Same selection criteria, but by a faster preselect matching.

Whenever a GKC is very slow, it’s because you are not using preselect to narrow down the number of targets for the GKC, so a slower Beanshell {} expression is being used to check every single piece in the game.

You might still need the quotes around “RR11”; I don’t recall for certain, so if it doesn’t work without the quotes, try adding them back in (e.g., for “Property Value”, try "RR11" if RR11 doesn’t work).