Bug 4600 was closed as Won’t Fix. There is a standard way to achieve what you are trying to do.
I’m not sure why this is significant. As long as at the end of the command stream, the appropriate labels are displayed, what is the problem?
The actual time that any image is redisplayed under java is out of our control, we can only request Swing to refresh a screen area or component, the actually timing of refreshes is handled by Java. If you are trying to implement some type of animation effect through Vassal Key Commands, you are doomed to failure.
I have found and fixed the centering problem. This was quite straight
forward, when the text changed, the position of the label was not being
recalculated. This is bug 4322.
Brent, I wholeheartedly agree. Indeed, I made an attempt (back in January) to properly define offsets. However, and here is the catch, then there is a bug with offsets. Or maybe I don’t understand how to use offsets…
Piece with multiple text labels:
first text label at default vertical offset 0
second text label at 10
third text label at -10
All the rest being equal (default selection for alignment etc) they should appear one on top of the other 10 pixels a part, correct? They don’t. And they didn’t work properly even in early builds of 3.2.0, that is before your fix to revert to 3.1.x automatic line feeding style.
That’s why I was happy with the 3.1.x behavior that automatically added line feeds between them. It was contrary to the whole point of having offsets, sure, but then please fix the offsets situation or tell me what I am doing wrong
Anyway, there is an obvious drawback to having to calculate and define offsets (when they actually work): you can’t just add another text label and/or change the respective font size of the existing ones without having to go through a whole bunch of calculations and one-by-one fiddling.
Maybe giving the piece component a “do not stack text labels” (or “add automatic line feeds between text labels”) check-able attribute would be nice. Or perhaps make it a map or module level property…
Yes, I know, the invisible gif. But then one has to predetermine needed length of the invisible gif and keep changing it whenever he changes his mind about the string to display. I think this is cumbersome and ugly and needlessly adds (potentially) tons of small invisible gifs to the module. But of course it is hard to implement otherwise then I am pretty happy with the ugly workaround, it’s not a crucial issue at all.
I have a “Click here to start the game” piece with an action button which a player in a network game pushes to initiate a complex setup process. What I am trying to achieve is for the button itself to revert to “… game starting, please wait…” and then to proceed to the actual setup (which takes a minute or so) before deleting itself.
I tried using a Layer or a Text label which follow the value of a Dynamic Property called “Status” defined on the piece (tried also with a global property) and having the action button first thing change it from 0 to 1, before proceeding to invoke the rest of the setup procedure via a bunch of triggers.
The problem is that people (including the player pushing the button) won’t ever see the “… game starting, please wait…” image/string because it won’t change till the very end, when it actually deletes itself. Thus, players will keep pushing the button not knowing if the game started or not till the very end. No way to achieve this then, I gather? I also tried Replace with Other, but no cigar.
Moreover, remote players will not even get the update of the “Status” DP/GP from 0 to 1 till the very end, so that they will disrupt the setup procedure by initiating it themselves while setup is already in progress (resulting in out of synch setups). But I guess this is another story… (wish somebody had a clue how to solve it… how to force a resynch on the fly…).
Change your method and force it to pause instead at the “game starting please wait” by requiring the user to click the action button again and changing what the text says so you might have
step 1 - “Click here to Setup Game”
step 2 - “Setup complete - Click here again to begin play”
The problem is the actual lengthy setup, which you suggest to do in step 1. How would everybody (including the clicking player) know the button was actually pressed till the very end if there are no visual clues about it right away? This is just the original issue. It is not crucial in solo mode (just a bit ugly): after all restrict commands are in place to block the player from clicking multiple times. However, in network play it completely breaks the game if some remote player bona fide clicks “start game” again (no visual clue, no update yet of the DP/GP tracking the click).
Similarly, if step 1 is just a label replacement (from “Start game” to “click to continue”) the problem will again arise exactly as before in step 2.
Anyway, there is an obvious drawback to having to calculate and define
offsets (when they actually work): you can’t just add another text label
and/or change the respective font size of the existing ones without
having to go through a whole bunch of calculations and one-by-one
fiddling.
Yes, that is a problem with absolute layouts in general.
But short of having some sort of automatic layout definition, it isn’t easy
to solve.
One solution to the font size issue, though, is to allow font-relative
units to be used. Something like “ex” and “em” for spacing. IIRC the
JGoodies layout manager has a provision for that based on Microsoft’s (?)
“dlu” (dialog units) measurement.
Look at what I did in the Urban Sprawl module - click on the 2 setup deck
buttons and watch the chat window and what the buttons do. Exactly what you are
trying to do here. Use the chat window to communicate the internal process -
everyone will see it
Change your method and force it to pause instead at the “game starting
please wait” by requiring the user to click the action button again
and changing what the text says so you might have
step 1 - “Click here to Setup Game”
step 2 - “Setup complete - Click here again to begin play”
Hmm, how would this solve the problem?
The problem is the actual lengthy setup, which you suggest to do in step
How would everybody (including the clicking player) know the button
was actually pressed till the very end if there are no visual clues
about it right away? This is just the original issue. It is not crucial
in solo mode (just a bit ugly): after all restrict commands are in place
to block the player from clicking multiple times. However, in network
play it completely breaks the game if some remote player bona fide
clicks “start game” again (no visual clue, no update yet of the DP/GP
tracking the click).
Similarly, if step 1 is just a label replacement (from “Start game” to
“click to continue”) the problem will again arise exactly as before in
step 2.
Your setup takes less than a second while mine takes much longer (kudos to you!)
Your setup doesn’t mess with text labels and layers, using report actions instead
Your setup doesn’t even bother storing the info that it was started (it being so fast, I guess)
I wonder what would happen if your green, white, red etc players would all happen to click on setup at the same time though…
I guess your setup happens fast enough not to bother about issue 4. However, I do have that problem, as my setup takes 20 seconds… Yes, I could use report traits to let everybody know the setup is in progress, but that means trusting everybody to pay close attention and not be tempted to hit “start game”…
Moreover, it’s difficult for me to understand why a layer or text label will be updated whenever Swing feels up to it, while report traits would be sent across the network right away…
for item 4 set a DP to 1 as the first step the button performs and configure the
action button to only work through a trigger that says if the DP = 0 then
execute
This works. Have done it many times
Another way to do it is to immediately destroy the button and replace it with an
identical non clickable button that when placed performs your setup routine and
once complete replaces itself (again) into a functional button (if needed). This
should also prevent 4 from happening
Your setup takes less than a second while mine takes much longer
(kudos to you!)
Your setup doesn’t mess with text labels and layers, using report
actions instead
Your setup doesn’t even bother storing the info that it was started
(it being so fast, I guess)
I wonder what would happen if your green, white, red etc players
would all happen to click on setup at the same time though…
I guess your setup happens fast enough not to bother about issue 4.
However, I do have that problem, as my setup takes 20 seconds… Yes, I
could use report traits to let everybody know the setup is in progress,
but that means trusting everybody to pay close attention and not be
tempted to hit “start game”…
Moreover, it’s difficult for me to understand why a layer or text label
will be updated whenever Swing feels up to it, while report traits would
be sent across the network right away…
Unfortunately, this is just what I have been talking about and doesn’t work. The DP (or GP) will get updated for the local user only (the one clicking the start button) and as I mentioned I do have restrict commands to forbid a second click when the DP=1. However, the change won’t propagate to the remote users till the very end (20 seconds), same as any visual clues using layers or text labels (but reports might be faster).
Same when using the Replace with Other method: it happens for the local player (but the display refreshes 20 seconds later anyway, if I recall correctly from my tests time ago), but it definitively only happens 20 seconds later for the remote ones so that they have those crucial 20 seconds available to launch another setup…
Yes, the reason for this is that we now guarantee that all Commands issued as part of a single action are bundled up as a single Undoable action at the other end. The only way this can happen is that the single batched command is sent at the very end of a an action sequence.
Essentially, you are trying to implement an animation (on-screen message changing at certain times) and have it visible to other players in the same way. As I said earlier, this will never be possible.
The only way I can see you getting this to work is to break the initialisation sequence into two parts. The first button says ‘Take control of setup’. All this does is set a global property, change the button text and this gets sent to all other users and stops any one else from starting the initialisation. Then, initiate the actual initialisation with another button click.
Ah, but that’s because of the ‘bug’ that causes multiple text Labels with no Key Command to appear with a line feed between them. Take away this ‘bug’, or add Command Keys to the text labels and your example works.
The way it is now is confusing and inconsistent, the labels behave completely differently depending on whether or not there is a Key Command attached, making it difficult to use offsets. There is no logical reason why separate text Labels should be related in any way.
Having offsets specified in pixels is not really so much of a problem surely, it’s something you set up once and it’s done.
A much better way to do a multi-line text label is to use html in the label.
Ok, so maybe I was remembering incorrectly, because I thought that even in early builds of 3.2.0 (=no line feeds) defining offsets like -10, 0 and 10 was not working as expected.
Assuming that’s the case (i.e. removing the line feeds offset work as expected), what’s the take now? Are you going to remove the line feeds again or are we sticking with line feeds (and then potential issues like #4 and maybe #5 in my original list) in the 3.2.0 final release? Thanks.
P.S. As you might remember I am happy to add text labels ad libitum to a single piece with no image, to monitor values of GPs and DPs for debugging purposes (my “Debug” screen). Using HTML to do that sounds really cumbersome, when you have a single line prompt and markup 20 lines long… Ideally this would not be a problem if there was a “debug” or “inspect” or “trace” mechanism in the engine to allow inspection of variables during a run (in edit mode)… Vassal 4?
Yes, I am now scratching my head trying to come out with an elegant way of achieving that without brutally telling everybody only player C can start the game (which would sound a bit bizarre)… But that should be the way to go, thanks for the hint!
Is the playerName/playerSide of the player originally starting the game exposed in a GP, by any chance?
