Thus spake “Rindis”:
Note for Brent: I think it’s the original piece, not the expanded piece,
which gets mouse events, so we have to check the original piece for the
SELECTED property. (That was the solution.)
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I think we’ve found all of the regressions we’re going to find now without
some wider testing, so I’m putting the current trunk up as beta5.
Thanks to everyone who had a look or reported problems.
Hmm, this is also tied up with changing the state of pieces in the GamePiece palette. This may be broken now. Commands (mouse and key events) will need to go to both the original unexpanded piece as well as the expanded piece.
However, any changes made to traits in prototypes will not (cannot!) be saved when the module is saved, even though they may appear to have changed.
I am starting to think that in Edit mode, palette pieces should be showed unexpanded so that wysiwyg. But in play mode, they should be displayed expanded so they look correct to users.
Thoughts?
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Apologies if I should post this reply elsewhere, but I have a strange issue with Vassal since beta 3 which still don’t seem cured by 4397.
This is an issue which appears as soon as I start Vassal, click on edit module, open properties for a piece in an at start deck. This piece has a basic piece trait with no image, followed by a layer trait with 3 levels. The first level has no image. The levels follow the value of a global property, called DUMMY, say, defined at map level.
The history of this issue is as follows:
Beta 1 and 2: no problem
Beta 3: just opening the module gives a NULL POINTER EXCEPTION and Vassal just hangs (the reason could be some other piece, though, for what I know…)
Beta 4: the basic piece is not happy with the null image (IMAGE NOT FOUND), ditto for the layer trait (IMAGE NOT FOUND for the first level in the layer)
Beta 4397: same as above except on first opening the piece properties window it immediately gives a BAD DATA. NOT A NUMBER: NULL error
What’s more, when clicking at the top of the properties window for this piece in the editor (where the piece image should show) the chat/report window reports error finding the global property DUMMY. However, the DUMMY variable is regularly present in the global properties of the map where the piece in question is, though. I guess that maybe the editor mistakenly looks for global properties at module level, for the limited purposes of that piece preview window.
I think I read, time ago, that the various issues with null images had been solved… or had they not? Any clue?
On a side note, beta 4397 now messes up positioning of some of my text labels (no problems with beta 4). But I remember that I had to purposefully misplace them at the time, to make them show where I wanted them… so maybe it’s just a matter of putting them back where they should really go now…
*********** REPLY SEPARATOR ***********
On 9/11/2008 at 5:42 PM Brent Easton wrote:
Re-thinking this, I don’t think there is a problem with the current code. All commands are applied to the original unexpanded piece and the expanded piece cache is immediately invalidated, so the expanded piece, when next recreated, will always be up to date.
Since commands are applied to the original piece and the expanded piece is recreated, then even though the traits within prototypes will be displayed in the palette, it will not be possible to actually change them, except by editing the prototype itself.
This is no different to the current situation, except that there may be some confusion from the fact that the contents of the prototypes a displayed, but not changeable.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Sorry,
where did you say this module is so we can inspect it?
Thanks.
*********** REPLY SEPARATOR ***********
On 9/11/2008 at 2:18 AM stine020 wrote:
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Hmm, is that a polite turn of phrase to say “no way we comment on possible bugs from now on without seeing the actual module first”?
I have no problem sending this module to you via private mail, if you can pm me your email address.
Sorry if I was rude. It’s late and I’m tired trying to get my head around Vassal bugs.
You would not believe the amount of time I waste running after people trying to get more information and a copy of the module to test for bugs. I think I need to step back from the front-line support and beaver away quietly in the background instead.
b.easton at uws.edu.au
I will look at it in the morning.
Regards.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “stine020”:
Sometimes we can tell exactly what the problem is just from a description.
In all other cases, it saves us a huge amount of time when bug hunting if
we can reproduce the bug ourselves. That is, having the module which is
causing the problem lets us work more efficiently, which benefits everyone.
It’s also unlikely that module designers or users will be able to guess
which problems we’ll recognize immediately and which we’ll need a module
for—so providing a module when initially describing a problem will
expedite our finding a solution, as we then won’t have to ask for one.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Might be a good idea to sticky a BIG BOLD thread in each sub-forum to
attract attention with a list of things users should consider providing when
reporting errors and problems to help expedite troubleshooting instead of
all the back and forth posts just trying to get information.
Very similar to the bug dialog in what is gathered through the error log,
suggestions for list might be
User contact Info
User Machine specs, OS and Java platform
Module name or link to it if not available on vassal website
Screenshots showing problem (before/after if in play mode, trait stack /
trait info if in edit mode)
Description to best of ability as user perceives it
Post generated using Mail2Forum (mail2forum.com)
The primary problem is that in Edit mode, the pieces in the At-Start stack do not actually exist on the board as no game is running. There is no Map and no counter.
What you actually see in the properties window is a facsimile of your counters living in a sort of no-where land. There is no context to use to resolve Map (or Zone) level global properties. It is the same for pieces in GamePiece palettes.
I’m not sure that this will be easy to resolve.
Correct me if I’m wrong, but the module works correctly in play mode? The problem is the inconvenience and confusion resulting from the messages?
B.
Correct, no prob at all in play mode with that particular piece. Just a worry about these unexpected error messages from the editor.
P.S. I think beta 3 had problems even in play mode (not 100% sure, though… not sitting at my pc at the moment), but it’s obsolete now, anyway.