I’ve created a ton of content based on the false assumption that Global Hotkeys were global, but they actually aren’t quite global in many cases. Unless it’s something like a dice roller that displays a public result, they only work for the active player i.e. person who selected the Piece that triggered the Hotkey. For instance, I have map shading that is supposed to remind players that the weather is mud, but the shading only turns on for the player that ended the turn. I also have Game Piece Inventory Windows that are owned by one side (say the Axis) that I thought were popping up by Hotkey when a chit was pulled. I figured since there was an “Available to these sides” option, those were the sides that would see the pop-up. It worked when I was testing offline as Solo, but now I’m finding out the hard way that with online play, if the Allied player draws a chit that is supposed to invoke an Axis GPIW, nothing happens at all unless the game is being played Solo. Is there any workaround for this?
Presently the actual messages passed from client-to-client in both online-via-server and PBEM-via-vlog-file are, with the exception of chat messages, focused on the passing of changes-of-gamestate – Vassal’s model does all the rules/triggers/traits processing on the machine of the client who made the move, and then sends the results to the other clients.
If you’re mainly concerned with conveying information and popping up windows (rather than directly triggering further gamestate changes), it wouldn’t be “that hard” to create a custom class that would cause other clients to check for and display something. How I’d do it for maximum-easiness is override the Chatter (the class that handles the chat window), send my “commands” as Report messages w/ a little code like “/command AxisGPIW” which I would then have my Chatter intercept and instead of displaying in the chat log I’d pop up e.g. the AxisGPIW if appropriate.
I know you’re resistant to going down the “light custom classes” road, but I am here to continually tempt you!
Brian
Grr. I know that’s coming eventually but I guess I’m soured by my experience with the TripleA open-source platform. I wrote a Java custom class for that engine that tracked supply in real-time for all units. It took me about 50 hours and worked brilliantly until they permanently and irreparably broke it with a new release. I realize that is idiosyncratic, but it makes me gun shy of custom classes. Also your whole drinking water from a hose / rabbit-hole analogy. Been there done that with TripleA. If you’re not in the development inner circle it’s like being a mouse in a room with elephants…
I’m having a good experience so far – I’ve made a handful of custom classes that have made my modules a LOT better. And I’m going to go back and “do surgery” on them soon once the batch of 3.3 improvements comes, but most of my custom classes are fairly simple overrides of existing classes, so what I’ll do is just pull down the “new and approved” versions and re-apply my relatively simple alternate logics, and good to go.
Meanwhile my “best” custom class, the HTML Chatter, is up for possible inclusion in Vassal 
We have always tried to maintain 100% backward compatibility with all existing custom code. I have custom code running in modules that I wrote 15 years ago and it is still going. Although I have to admit to being one of the elephants.
Over the years, many changes have been reverted and reworked because we got reports of broken custom code. From time to time, necessary changes (often forced on us by Java upgrades) have broken some custom code and we have worked with the authors to work around the issues.
I am kind of a baby elephant in this “inner circle” and I can assure you, the big old elephants are very adamant about keeping backward compatibility, supporting existing modules, or at the very least offering the module developers an alternative and giving them enough time to adapt the alternative before things break. And if you are active and reachable it’s even better, the worst cases are older modules whose designers are not reachable and their custom code uses features that we would like to change.
Also the old elephants are pretty cool and welcoming so why not just join the inner circle!
Just get in the damn pool, m3tan! 
Also getting your workspace up and running just got 20x easier literally tonight, complete with a how-to wiki entry…
I’m guessing that it is not the Global Hotkeys that are the problem, but what you are doing with them. Windows don’t pop up for other players, and Game piece layer controls (your weather indicators?) only affect the view of the player activating them. These are actually desirable behaviours for my modules - if one player is deactivating all the layers with pieces on them to have a look at the map, I really don’t want all the pieces disappearing for the other players!
That said, I’m finding global hotkeys seem not to be affecting closed map windows, or something, and it is confusing and frustrating me, so there’s definitely something I’m not understanding.
Until 2 months ago, I’d never used Vassal, let alone tried to build a module. I don’t think it was unreasonable to think that the Global Hotkeys were affecting all players as that was how it worked when I was testing it in Solo mode. In any event, I have a much better understanding now of Vassal architecturally than just 30 days ago. It’s pretty obvious that no alert, hotkey, or keystroke in Vassal will affect all players as its basically a bunch of standalone games that are constantly syncing results, not activities. Once I realized this, the multi-player behavior became very predictable.