v3.4.1 - delayed output to chatter bug? HTML related?

I’m seeing an new oddity with v3.4.1 and thinking it might be a bug…

I first noticed that sometimes a simple Right-Click Command to do a Report Action was not longer working. But - perform the action a second time and the output was generated twice. Or just press return and then output would arrive once, along with the line break.

Now I notice that simply pressing return in the chatter window can be delayed; first first doesn’t work, then the second one generates two line-breaks.

I could not replicate this with v3.4.0.

With v3.4.1 it seems to happen after the point where my module had generated some HTML that output images. Unusually, back-tracking with UnDo did not seem to restore normal behaviour.

Thanks - I know precisely what is causing this. When fixing some chat flickering I think we gave Swing a little too much credit for being smart about updating. I will put the update back with the flicker protection.

Came here to post about this. Glad to see it’s been addressed. You guys rock.

Mentioned in v3.4.0 bug and repeated here for v3.4.1: I can create a new extension, but the editor refuses right clicks to create any possible entry, on a macos.
That does not work if the new module was created in v3.4.1 either : can’t see any right click interaction in the eidtor for the extension.

I don’t think the delayed output bug is fully fixed.

Playing a game under v3.4.2 (online, but v3.4.2 both ends), and am getting the delayed output. Though this time, it seems to be just lines that are typed directly into the chatter window that are getting delayed. It started only in this game session too. I have played other v3.4.2 sessions with the same module that were fine.

I will have a log file when done.


UPDATE: Spoke to soon. The bug is delaying Report Trait output too.

yep, I have seen this too. I have a symbolic dice that shows results in the button, nothing fancy. Well for one player, the button refreshed, but the log report wouldn’t show up until a new chat message would “push” that message to the screen.

Three players online, all of us with 3.4.2 and same version of the module. Only one of us had the problem, all the time. He uses windows, I’m on linux, I have no idea what SO does the 3rd player use.

Please let me know the exact module & dice button if possible – often the problem is that some message in the module has a < symbol in it which is creating illegal HTML in a situation when the HTML has been turned on for the chatter. This can be corrected by changing the < in the message to an <

3.4.3 may improve this somewhat, but the problem is that if the module designer turns on HTML output but then unwittingly sends “illegal HTML” then this sort of delayed reporting will be a side effect.

The module is an unpublished one. Please tell me if you want to take a look into it, I can share it with you.

The die report is:

** $name$ = [$result1$] *** <$PlayerName$>

Yes I’d love to take a look, for sure. Also please let me know what OS you run on.

And I assume that $name$ and $result1$ wouldn’t contain a < symbol? There are a lot of modules that have a < > surrounding the player name in the format that is specified in Player Roster (might have even been some old default)

Not quite ready to let this one go…

I am still occasionally getting games where this delayed chat output condition recurrs. Once it does, it persists through the session. I had another one yesterday. It doesn’t seem like it is the module; I searched through the buildfile for all occurrences of “<” - there were none once I stripped out the ones used for the buildfile format itself. The module is not generating a great variety of output, though I did find some “<” use early on, I think I have eliminated it all now or replaced with “<”.

Is there some workaround I could implement - like say a hot-button that outputs a html close, whilst hoping to find or be given a fix?


The only time we’ve been able to reproduce this (and then it’s 100%) is when bad HTML of some kind has been sent. “<” characters are one example but not the only potential example of bad HTML.

In terms of workarounds:
(1) You could turn the main HTML support switch OFF for the module, and use the “Quick Colors” first characters to “opt-in” individual lines to HTML (any line with one of those first characters will always be processed for HTML). You can use “|” to opt-in a line of the “standard color”, if you need to put some tags in it.
(2) I suppose you could try sending an extra or something to see if that gets things on track after a problem (let me know if that helps, I’m curious – if it works I suppose we could try tacking on extra ones of those automatically, although I shudder a bit at intentionally sending spurious tags).

I’d be happy to have a look at any specific module that’s reproducing this. After I cleaned up my HTML I haven’t been seeing it in my modules even after vast amounts of chat use. Which doesn’t mean that there couldn’t be some other problem hiding out there – but we probably can’t fix it unless we can find specific repro steps with a specific module, etc, so that we can catch it and find out what’s happening.

It is certainly too bad that Swing’s HTML code doesn’t throw an exception or something when it gets “clogged”. That would make it much easier to catch it in the act!