The module is being updated with cards that are larger and more readable. In the process this means making a lot of changes to the positions of everything.
Request: a zoom factor that controls the display size of the deck. This would allow the deck to be enlarged or shrank. I would expect it to be primarily be used for shrinking a deck thus giving the board more real estate. Cards would display at their real size according to the zoom of the map, while the deck would be displayed at a smaller scale.
Given the current Draw() in Deck.java, this seems like an extremely simple addition, the question is would this effect (or be useful for) other games. I would expect that screen real estate is always at a premium and being able to control deck zoom factors would be useful to others.
THX for helping me get set up!!!
And I OFFICALLY don’t like java… or maybe it is eclipse. break points don’t work so I can’t debug very well and java’s types… ok enough bitching.
I found that this simple task had some other ramifications that I initially didn’t foresee. Basically what happens if you have decks of different sizes? All decks would have to have this feature and then backward legacy decks wouldn’t work as well. Could send the zoom scale along with the deck that works until you send just a single card to a deck. Then there was always the highlighter which displayed the actual size of the cards.
Anyway long story short I tested out a simple method, when drawing simply adjust the zoom by the difference between the top card’s dimensions and the dimensions of the deck. Only draw back that I can foresee is that the deck actually has to have an accurate width and height. But with my initial tests, a new deck and an old deck worked the same. Other than when the card was displayed on the board, which is exactly what I wanted!
Now the question for the real vassal developers, should this be standard behavior? Or should it be a boolean check box to scale cards to deck size?
Let me know what you think. I can add the bool easily enough now (and make it backward compatible). It was all a good exercise in getting to know vassal code.
Next week I will take a stab at the sending decks to different locations
BTW if this code is accepted, would it be published in say a 3.1.8? (is there going to be one?)
How are you starting the module? Via the module manager, or directly via program arguments?
It’s actually not a question for developers. It depends on how many modules will break if you make the change. As a general rule, you should add an option to turn new behaviour on/off and make it default to off so that existing modules will work unchanged.
Having said that, the change you are suggesting does make a lot of sense, and in my opinion it probably should be the standard behavior with an option to allow card size to override Deck size. It will cause problems for any modules where the Deck size has been defined much smaller than the cards.
Further 3.1.x releases will be bug fix only. Anything new will go onto 3.2.
I use the F11 and the --edit {mod name} on VASSAL.launch.ModuleManager
I will add the option and like you said, it has made a lot of sense for the module im working on. Initially i will leave the option on by default. Rodney or you or one of the others should probably make the final call.
Now for the big question when is 3.2 scheduled? I thought I saw a comment on the boards that it would be out until august or later. That would sucks… But I understand. Real life has … some … priorities
