Feature requests.. simple ones, I think

Feature Requests
21

Thus spake anonemous123:

“barbanera” wrote:

IMHO, it is a matter of playing style or module designing style. If a
module follows the typical Vassal tradition of giving a virtual game
table and virtual components to players to mess around at will, then
combo keys are a must, I guess, and kudos to that and if the
developers want to give more fine by me. However, if the module wants
to try enforcing rules and give a video/pc game look and feel to the
game play, then it should be possible to avoid right click commands
and, especially, combo keys.

Enforcing rules? No, the players enforce the rules. In fact the rules
come from the book that came with the game in the first place. Vassal is
there just to allow me to communicate my moves with the other guy.
Really the game was a board and counters in the box. So, we enforce the
rules. In fact I would make a deliberate point as a module designer of
NOT enforcing ANY rules of any kind. Give the players the freedom to
work this out themselves. You have to remember, out in the real world
people play the same game in different ways with different variations.
Sometimes we pick up a pen and paper, perhaps some symbols on the blank
counters that came with the game. Perhaps some house or local rules. As
I said, I make a deliberate point of not enforcing any rules. Just give
the players the board, pieces, markers, some space and latitude, and let
them decide how they will play the game.

One of my long-term plans for V4 is to develop a rules description
language, which could be used to validate the legality of moves. It’s
not something I intend to be mandatory for modules, and there will be
a checkbox for turning it off if you don’t want it. So, yes, I think
rules-enforcement is important; but, I think rules-enforcement as people
attempt to do it now is entirely misguided.

–
J.

22

Thus spake barbanera:

I was just asking for the option to hide combo keys… :wink:

Of the ways we could go—always showing hotkeys in menus, never showing
hotkeys in menus, showing hotkeys in menus if the platform does, making
the display of hotkeys in menus a settable preference, or making the
the display of hotkeys in menus settable by the module designer—there
is no way we’re doing the last one. It’s a recipe for user confusion.
The “do as the platform does” option I see as better than the “always”
and “never” options, as it makes VASSAL fit in where it’s running. I
still maintain that there is no good default if you let the user toggle
the display of hotkeys: If the default is “on”, you’re expecting new
users to turn it off, but I don’t see that they’ll know the setting even
exists; if the default is “off”, then new users won’t be aware that
there are hotkeys, for the same reason.

–
J.

23

I want to start by saying that this whole argument is really moot. I don’t really care if combo-keys will never disappear from Vassal’s right click menus. I can live with them and I am happy enough to work with the engine as is and thank you for the good (and free) work to all developers, of course. I just personally believe my own module (I wouldn’t presume about everybody else’s) would benefit from reduced clutter in right-click menus, but it is not a make or break feature.

I didn’t think requesting an option to hide key commands from the right click menu (but not remove: they are still there and I could give a list of key commands in a help page for whoever wishes to use them!) would cause such a crusade on what’s wrong and what’s right.

Especially, not such strong positions like “no way we are doing it”. In other words, you are saying that even if took you (or some other willing developer) just 10 minutes of your time to allow for this feature you wouldn’t allow it because you want to impose your own view of what’s not acceptable even in my OWN module?

Wow… :slight_smile:

24

Misguided most likely.

But if results are what matters, and if there is no other option at the moment, than I would just commend whoever managed to do it, not sneer at him.

25

Thus spake barbanera:

“uckelman” wrote:

So, yes, I think
rules-enforcement is important; but, I think rules-enforcement as
people
attempt to do it now is entirely misguided.

Misguided most likely.

But if results are what matters, and if there is no other option at the
moment, than I would just commend whoever managed to do it, not sneer at
him.

I’m not sneering at anyone. I’d say the same thing about the Twilight
Struggle or Combat Commander modules as I’d say about somehting like
Google Docs: They are amazing achievements given the available tools;
nonetheless, that doesn’t make the available tools the right tools for
the job. (If Michael, the TS module designer is lurking, I think he’d
agree.)

–
J.

26

Not sure what I’m agreeing to here, but I think the Twilight Struggle more or less proves that VASSAL is not really up to the task of rules enforcement and by that I mean I had to do an awful lot of custom programming. That’s not the same as saying that VASSAL shouldn’t make this easier and I’m hoping that it will. I’m looking forward to version 4.

  • M.

On 2012-04-17, at 5:15 PM, Joel Uckelman uckelman@nomic.net wrote:

Thus spake barbanera:

“uckelman” wrote:

So, yes, I think
rules-enforcement is important; but, I think rules-enforcement as
people
attempt to do it now is entirely misguided.

Misguided most likely.

But if results are what matters, and if there is no other option at the
moment, than I would just commend whoever managed to do it, not sneer at
him.

I’m not sneering at anyone. I’d say the same thing about the Twilight
Struggle or Combat Commander modules as I’d say about somehting like
Google Docs: They are amazing achievements given the available tools;
nonetheless, that doesn’t make the available tools the right tools for
the job. (If Michael, the TS module designer is lurking, I think he’d
agree.)

–
J.

messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

27

Thus spake barbanera:

I didn’t think requesting an option to hide key commands from the right
click menu (but not remove: they are still there and I could give a list
of key commands in a help page for whoever wishes to use them!) would
cause such a crusade on what’s wrong and what’s right.

Especially, not such strong positions like “no way we are doing it”. In
other words, you are saying that even if took you (or some other willing
developer) just 10 minutes of your time to allow for this feature you
wouldn’t allow it because you want to impose your own view of what’s not
acceptable even in my OWN module?

The amount of effort it takes isn’t relevant. What I’m objecting to is
that implementing this on a per-module basis would be confusing for
users of VASSAL generally, many of whom will use more than one module.
As a developer, I have to look out for how modifications like the one
you suggest will affect all of our users, not just the users of your
module.

Every line of code in any program imposes someone’s view of what’s
acceptable on the people using the program. Without that, you have
no program at all.

–
J.

28

I must be missing something… and people might have hinted about this to me… or maybe not… but what was all this argument about hiding right click commands about? Since 3.2.0 now allows the designer a decision if to show or hide them…?!

I was finally trying out 3.2.0 (beta1) for real and I noticed the right click command keys will not show if use named keys (like “foo”) instead of actual command keys (like CTRL-F) in just about any trait I tested! Why not tell me that clearly from the start? Or I am really missing something here…

I love 3.2.0 already ;)

29

I think they did.

Anyway, the whole problem here is not that shortcut keys are displayed, it’s that they are not presented well. They are jammed right up to the end of the command name without any separation other than a space. Ideally they should all be right-justified against the right edge of the popup menu, or at least spaced over farther or preceded by some kind of punctuation. To me the context menus in Vassal look very “unfinished,” and I end up putting an ellipsis (…) at the end of all my command names to make the more readable. (Which of course is quite tedious, especially when using sub-menus.)

And I will agree with everyone else: if you change all of your key commands to named commands just to make it impossible for players to use short-cut keys, you are doing your players a huge disservice. That is flat-out poor design, going out of your way to make your game less playable. Just because you don’t use shortcut keys doesn’t millions of others aren’t using them.

30

Maybe… but wish you would point me out where.

Anyway… again, I must repeat myself: the designer is the best placed, imho, to decide how his module should be played. After all we do this for free, and we are not paid to develop modules for somebody else, are we?

I am pretty sure in some modules right click commands are very useful. I can think of situations were you have to do various repetitive “mindless” repetitive actions on a set of units or cards and then right click short cuts are surely a big plus.

However, in my modules there is no need for them. More to the point: they are confusing and nobody would ever need them, as you don’t really do repetitive actions like moving units or something, but just specific one shot type operations which need you to right click on cards/miniatures to look at the available options and think about which one you choose. Nothing repetitive you can really bypass by using short cuts.

Therefore, I am happy there is now a way to avoid showing them, even though it came too late for my major project.

31

Okay wait … are you saying what you want is to hide the command from the player entirely? It’s just an internal module function that nobody’s going to type a keyboard shortcut for and nobody’s going to click on a piece to activate? Heck, if that’s all you want, that’s super easy and has been there for a very long time: just don’t define a command name and the command won’t appear at all.

Sorry, I thought you were saying you wanted to force players to right-click on pieces and choose commands from a menu without any possibility of a keyboard shortcut.

32

No, mate, of course I know about that trick but you had it right the first time. I am saying I want players to right click (since in Vassal that’s you are supposed to do most things) and pick the option from a menu. No short cuts.

I am saying, in my module, that’s more elegant than showing short cuts as well, because you are never really routinely making the same choices. Short cuts, imho, are great if you always repeat the same thing so many times you get bored using the mouse, not less routine operations.

Heck, I use myself CTRL-C / CTRL-V when I want to cut and paste in Windows and that’s great, sure.

However, when I want to save a document with a different name, choose a font from a list, display mail merge operations or whatever similar less customary operation; I use the mouse. Are you telling me you had rather have a list of combo keys for all possible fonts and fonts sizes in Word, say? Ridicolous, unaesthetic and unnecessary, imho.

In truth that’s not a fair example, because I am not saying that in my case there are so many options (like so many fonts) to choose from. However, as said at the beginning, the problem is in my module right click commands on pieces are not completely predictable: players are going to right click on a piece to check the list of available commands for the given time/phase/turn/action/etc. And once you open up the right click command menu what are combo keys there for if not to clutter the display?

33

well, for me the main interface is the keyboard, so once I have memorized what to press I can do things blinkingly fast (aside that I disagree on Linux attempting to mimic winsozz; ^C ought to remain the means of stopping a rampaging program… (sorry for the peeve)

Best regards from Italy,
dott. Piergiorgio.

34

hmmmm.

interesting series of miscommunications.

i would like to inject a mild correction, as a mac user.

right clicking has existing in the apple os since near the beginning. it was never obvious how to do so, agreed, but it was there.

i think that associating the choice to use apple with an inability to comment meaningfully on design and efficiency (and whatever else was stated, i’m not going back to find the exact quote) a rather judgmental and prejudiced point of view. different people find different methods to be efficient and intuitive, this means that for some, windows is logical and intuitive, for others *nix, for others apple, and for some none of the above.

the design criteria and goals for each piece of software and hardware are different, thus the end results will likewise be different.

besides, mac anymore is just an emulated OS running on top of darwin version of *nix using pc hardware(+1 or +2) anyway. as such, a mac can literally run almost any os natively. for someone who works on multiple platforms or with clients who use varying platforms, a mac is now a viable choice for a development and testing platform due to this flexibility. and still strong on the graphics side, like they have almost always been.

personally, i was raised on cp/m, then dos, then windows, then mac. i find myself comfortable using *nix shells, but get frustrated because of the lack of built-in verifiability, and the documentation is frequently lacking from my perspective. but i’ll keep at it till i figure it out.

anyhow, just some observations.

35

I read this post after voting for the feature request to be able to interact with the Turn Counter List values as suggested. This answers a post in the module design forum where I asked if/how this could be done - seems sadly that it is not available in 3.2.x :frowning: Hope it makes it to 4.x!

BTW in the module I am undertaking in 3.2.x right now, I am using the textual Key Commands. While this means that mouse clicks from the menu are the way to interact instead of short cut keys, I think my playing friends will be OK about this. It certainly helps with keeping track of the design as it is somewhat self documenting if you can settle on naming conventions for the [Global] Key Commands.

Also, I am implementing a fair set of the mechanics to assist players keep track of game status (avoid them having to!), and also implementing some of the rules which are of a more mechanical nature. This requires some thought at times, but the building blocks are there to make the playing more efficient and enjoyable. I want to achieve a result that makes the game more enjoyable through the improvements to the usability of the module. A click or two in situ is much easier than relying on a virtual counter tray in game with a variety of sides, cards and counters. It will be no TS btw (Mike - you have achieved a great result), but any features to assist module builders with implementation of rules without java coding should be encouraged.