apbills
Elder Member
That's why you are the keeper of the code. I apparently can't keep track of a discussion, let alone code.
VASL6.6.7-beta2.vmod released
- Thread starter DougRim
- Start date
@ScottRomanowski
I believe I may have fixed the first bug as well.
Here is a snip of the chat window when replaying your log file of DB88.
When I tried the log file previously I am pretty sure the "Other 3" and "[1 / 1 avg 3.00 (3.00)] (01.77)" were not showing in the chat window.
This is with 667beta4 which I hope release in the next day or so.
ScottRomanowski
Forum Guru
- Joined
- Jul 31, 2010
- Messages
- 1,854
- Reaction score
- 2,446
- Location
- Massachusetts
- First name
- Scott
- Country
-
I also see the problem when I type something when not using dice images. Here I typed "test", hit F2, then typed "test" again. What I typed didn't appear.
In your previous post, "2. When using no dice images, ..." I see this problem when using dice images. See my screen shots above.
I am not sure why you would use "F2"? Why not just hit enter? F2 does nothing on my machine.
Regardless, the issue of text messages not displaying is still an issue. In my testing today, it does not happen all the time. I am trying to isolate the circumstances which cause it. It appears to be related to previous dice rolls. I can trigger it when using dice images as well as when not.
This issue is definitely fixed in 667beta4 whether using dice images or not.
Thanks for your time on this.
ScottRomanowski
Forum Guru
- Joined
- Jul 31, 2010
- Messages
- 1,854
- Reaction score
- 2,446
- Location
- Massachusetts
- First name
- Scott
- Country
-
F2 is the keyboard shortcut for "Other DR". To be verbose, I typed "test", hit enter, hit F2 to show that some things do appear, typed "test" and hit enter again.
Another bug I noticed today. I went to type "<virtual handshake>" at the start of a PBEM game, and found that nothing in angle brackets appears. If you type "This is <not> a test" ENTER, you see "This is a test". Methinks your HTML parsing may be a little too aggressive. Perhaps you need to sanitize your user input. :-D https://xkcd.com/327/
Another bug I noticed today. I went to type "<virtual handshake>" at the start of a PBEM game, and found that nothing in angle brackets appears. If you type "This is <not> a test" ENTER, you see "This is a test". Methinks your HTML parsing may be a little too aggressive. Perhaps you need to sanitize your user input. :-D https://xkcd.com/327/
I have just released the vasl667beta4. Get it at http://vasl.info/vasl_coop.htm.
I think I have fixed all of the Chat Window message bugs but for one.
The one that still remains involves the delay in displaying user messages entered into the chat text box. Enter a message, it doesn't show. Enter a second message (or just hit enter a second time and the first message is pushed to Chat along with the second one. I can only trigger that error if (1) the Show Dice Stats after Dice Rolls preference is checked and (2) one of the three dr buttons has been clicked. I have not yet determined what is blocking the first message from being displayed. Any further testing and confirmation of results would be appreciated.
I think I have fixed all of the Chat Window message bugs but for one.
The one that still remains involves the delay in displaying user messages entered into the chat text box. Enter a message, it doesn't show. Enter a second message (or just hit enter a second time and the first message is pushed to Chat along with the second one. I can only trigger that error if (1) the Show Dice Stats after Dice Rolls preference is checked and (2) one of the three dr buttons has been clicked. I have not yet determined what is blocking the first message from being displayed. Any further testing and confirmation of results would be appreciated.
EDIT: in my original message, I got the versions mixed up. Idiot! Sorry about that. Corrected version now appears below
Question for those who have moved from 6.6.5 or 6.6.5.1 to 6.6.6 or any of the 6.6.7beta versions:
After you updated, did you have to frig around with resetting your coloured die color?
You should not have to. VASL should remember your preference setting. Is that what happened?
The reason the colour is not maintained between 6.6.4 or less and 6.6.5+ is that 6.6.5 and newer versions use a different colour scheme and cannot use the preference value from 6.6.4 or lower.
Once past 6.6.5, normal programming should resume and the colour preference should be remembered.
Question for those who have moved from 6.6.5 or 6.6.5.1 to 6.6.6 or any of the 6.6.7beta versions:
After you updated, did you have to frig around with resetting your coloured die color?
You should not have to. VASL should remember your preference setting. Is that what happened?
The reason the colour is not maintained between 6.6.4 or less and 6.6.5+ is that 6.6.5 and newer versions use a different colour scheme and cannot use the preference value from 6.6.4 or lower.
Once past 6.6.5, normal programming should resume and the colour preference should be remembered.
Last edited:
ScottRomanowski
Forum Guru
- Joined
- Jul 31, 2010
- Messages
- 1,854
- Reaction score
- 2,446
- Location
- Massachusetts
- First name
- Scott
- Country
-
I didn't notice but yes, going from beta2 to beta4 my dice images were both white when I'd set them the colored die to red. I think 6.6.6 to beta2 stayed red.
apbills
Elder Member
I have been playing on 6.6.6 and looking at the 6.6.7 beta versions. My dice remain the same red for colored and white for white (and yellow for a dr) as I normally have set. Looking at the beta4 version right now.
Jeff Leslie
Member
Sorry for my tardiness coming into this conversation this late.
I had to reset my dice colors when I updated to 6.6.6. When I switched to 6.6.7 beta4 from 6.6.6, I did not have to reset my dice colors.
For a long time now (I want to say several years?) with every VASL update I've had to change the keyboard shortcut for Step Forward (PgDn is default) because when I hit the PgDn key it scrolls the map down rather than scroll forward through logfiles. I get this with the NumPad PgDn key (NumLock OFF) or the other PgDn key above my arrow keys; it doesn't matter which one I use. I typically change it to the End key (forward) and Home key (undo). I think I reported this on GitHub a few years ago, not 100% sure about that though.
As far as the message delay, I am also getting that. When I first open a logfile and start stepping through, it works as intended - one click/keystroke = one step forward. As soon as I hit any command key other than the step forward key, now I am seeing the one line delay and it persists from that point onward. I never had this prior to 6.6.6.
Edit: Oh, as far as dice size... My preference is as long as they are both the same size I don't care what size they are.
I had to reset my dice colors when I updated to 6.6.6. When I switched to 6.6.7 beta4 from 6.6.6, I did not have to reset my dice colors.
For a long time now (I want to say several years?) with every VASL update I've had to change the keyboard shortcut for Step Forward (PgDn is default) because when I hit the PgDn key it scrolls the map down rather than scroll forward through logfiles. I get this with the NumPad PgDn key (NumLock OFF) or the other PgDn key above my arrow keys; it doesn't matter which one I use. I typically change it to the End key (forward) and Home key (undo). I think I reported this on GitHub a few years ago, not 100% sure about that though.
As far as the message delay, I am also getting that. When I first open a logfile and start stepping through, it works as intended - one click/keystroke = one step forward. As soon as I hit any command key other than the step forward key, now I am seeing the one line delay and it persists from that point onward. I never had this prior to 6.6.6.
Edit: Oh, as far as dice size... My preference is as long as they are both the same size I don't care what size they are.
Last edited:
Jeff Leslie
Member
Somewhat related maybe, but now I'm getting this new error with 6.6.7beta4 ...
VASL LOS disabled: java.lang.NullPointerException: Cannot invoke "java.awt.Color.equals(Object)" because "color" is null. VASSAL los active
The LOS thread still works but now it just shows the thread and doesn't indicate hindrances/obstacles anymore.
VASL LOS disabled: java.lang.NullPointerException: Cannot invoke "java.awt.Color.equals(Object)" because "color" is null. VASSAL los active
The LOS thread still works but now it just shows the thread and doesn't indicate hindrances/obstacles anymore.
This is not an error message. It is a notification that VASL los is disabled. I suspect it relates to the work I am doing on having overlays work with los. Were there any overlays on your map? The value of beta releases is in finding these issues before the official release.
What you are seeing is the default VASSAL LOS thread, which simply draws a line between the two points and indicates the range. It is not in anyway checking LOS.
I could only replicate this problem when I had the Show Dice Stats after Dice Rolls preference checked. Do you have that preference checked or unchecked when you get the problem?
Jeff Leslie
Member
Yes there are overlays on the map.
I do not have Show Dice Stats checked.
I also need to amend my earlier statement about any command key causing the problem. When trying to duplicate the issue I discovered it only happens after I use the undo command or a keyboard shortcut for it and also after I use the 3 dice button.
Jeff Leslie
Member
Yes the 3 dice button is an extension 3d6.mdx . I rarely use it but I recently played J53 Setting the Stage and it had a special Dust LV SSR and the 3d6 button came in handy for that.
The scenario is J54 Showtime and the overlays are OW1, RR13, RR4, RR6. I noticed some of those overlays had updated versions available and were automatically downloaded when I made the map.
Not sure if it has any bearing on the issue but since the Undo command seems to be what is causing this - when I downloaded beta4 there was no keyboard shortcut for the Undo command (it used to be PgUp), so I added one (Home). I never use the actual buttons, I always use the keyboard commands, and like I mentioned earlier I have to add my own shortcuts for step forward & undo because the PgDn/PgUp key scrolls the map instead of stepping the log forward/back. It's been that way for years.
Edit: Removing the 3d6.mdx extension had no effect on the issue. It seems to be totally dependent on hitting that Undo command - as long as I don't do that the step forward command works as intended.
The scenario is J54 Showtime and the overlays are OW1, RR13, RR4, RR6. I noticed some of those overlays had updated versions available and were automatically downloaded when I made the map.
Not sure if it has any bearing on the issue but since the Undo command seems to be what is causing this - when I downloaded beta4 there was no keyboard shortcut for the Undo command (it used to be PgUp), so I added one (Home). I never use the actual buttons, I always use the keyboard commands, and like I mentioned earlier I have to add my own shortcuts for step forward & undo because the PgDn/PgUp key scrolls the map instead of stepping the log forward/back. It's been that way for years.
Edit: Removing the 3d6.mdx extension had no effect on the issue. It seems to be totally dependent on hitting that Undo command - as long as I don't do that the step forward command works as intended.
Last edited:
PresterJohn
Elder Member
Is that extra dice different from the extra dice added by selecting Preferences - Environment - Special Dust Setting?
Yes, it is a separate extension which adds a button that rolls/displays 3 dice whenever it is clicked. Whereas the Special Dust Sitting die is built into VASL, and affects the standard dice buttons by displaying a 3rd die where appropriate for Dust (TH but not CC for example). Different source, different output.
Jeff Leslie
Member
Update: I may have isolated the problem with the chat line skip.
So I started trying other versions of VASL going backwards to 6.6.4, which was the last version I was using before I upgraded to 6.6.6 and was also the last version I used where I knew the line skip was not happening. When I upgraded from 6.6.4 to 6.6.6 (I never did use any of the 6.6.5 versions) was when the chat box started skipping a line. I tried all versions going backwards from 6.6.7beta4 and every one of them did the line skipping until I reached 6.6.4, at which point the line skipping went away and was working normally again. So it looks like the issue starts with 6.6.5, at least for me. With all versions after 6.6.4, the thing that kicked off the line skipping was first use of the undo command (or button).
So I started trying other versions of VASL going backwards to 6.6.4, which was the last version I was using before I upgraded to 6.6.6 and was also the last version I used where I knew the line skip was not happening. When I upgraded from 6.6.4 to 6.6.6 (I never did use any of the 6.6.5 versions) was when the chat box started skipping a line. I tried all versions going backwards from 6.6.7beta4 and every one of them did the line skipping until I reached 6.6.4, at which point the line skipping went away and was working normally again. So it looks like the issue starts with 6.6.5, at least for me. With all versions after 6.6.4, the thing that kicked off the line skipping was first use of the undo command (or button).
You are correct. 6.6.5 was the first VASL version where the chat window was html enabled.
Our friends at VASSAL advise me that the problem is most likely caused by sending an incorrect html string to the code that parses it for display. Which is what we have been suspecting all along.
The challenge is to find where and when in the VASL code that incorrect html is being generated and fix it. The fact that it does not happen every time but only when certain circumstances exist (even if those circumstances seem to be expanding) actually make it much harder to find. I have not succeed yet but will continue to throw time and effort against the wall until something sticks.
Our friends at VASSAL advise me that the problem is most likely caused by sending an incorrect html string to the code that parses it for display. Which is what we have been suspecting all along.
The challenge is to find where and when in the VASL code that incorrect html is being generated and fix it. The fact that it does not happen every time but only when certain circumstances exist (even if those circumstances seem to be expanding) actually make it much harder to find. I have not succeed yet but will continue to throw time and effort against the wall until something sticks.