Beta Release v3.3.7

[Moon Wizard]

Updates

• [DEV] Interface.onWindowClosed being incorrectly called for child windows after recent change. Fixed.

[Moon Wizard]

Dr0w / Bruno / yako,

Does it happen in Savage Worlds ruleset when attack roll is dropped on combat tracker instead of map token? Does it matter if image is in floating window, panel window, or closed?

Thanks,
JPG

[Dr0W]

It happens when the attack roll is dropped on combat tracker, instead of map token. It also happens when you just click the attack button (not dragging and dropping).

Yes, it does matter if the image is in floating window. If it's in floating window I don't get a crash, only if it's panel window. It doesn't crash either if the map is closed.

Just checked and if it's in Panel window and you roll the attack but do not have a target, it won't crash.

[Moon Wizard]

Thanks. Talking with Aki as well.

My thought is to send you a special version of ruleset loaded with extra Debug.console calls throughout the attack workflow in order to narrow down on what is causing issue. Then, all those messages will show up in console.log file after it crashes. We'll see what Aki says first.

Regards,
JPG

[Dr0W]

I'm up to it, just let me know if you need any help.

[Dr0W]

I am getting this error on D&D and SW rulesets (didn't test others)

Script Error: [string "scripts/manager_image.lua"]:91: bad argument #3 to 'setViewpointCenter' (number expected, got nil)

This happens when I pass turn on Host, while having the map in Panel mode and having Turn: Auto-center map On. The error is displayed only to the Host, not clients.

Disabling Turn: Auto-center map fixes this, and the error stops showing up.

Even tough the Client doesn't get an error, the Auto-center option doesn't work if they are using their map on Panel mode.

[Ken L]

Something happened in 3.3.7 in respect to early window initialization.

I figured this out here: https://www.fantasygrounds.com/forum...094#post418094

This sort of happened at some time this week as the problem 'suddenly appeared' so I thought it was something I did, but there was some kind of early init change that affected the behavior of my downstream scripts.

[Moon Wizard]

See my reply in the other thread.

I just checked all the revisions to the window creation/deletion and the global window tracking code; but didn't see any changes to the initialization ordering. There was quite a bit of changes around the deletion, but not the initialization. So, I'm not sure why it popped up this week for you.

My first thought is that it is the difference between panel initialization and free-floating window initialization, but that has been the case for years. (i.e. Floating windows layout immediately on creation before onInit called; while panels layout is delayed until global desktop layout can be performed after all panels created.) As I mentioned in the other thread, you might look at onFirstLayout event I added for v3.3.7. It will be called the first time that a full layout is performed on a window, whether it is floating or panel.

Regards,
JPG

[Ken L]

I had introduced a feature where based on an option, a panel window would be W2/H2 size as opposed to W/H size. Since my panels are right aligned, this would cut off part of the windows off screen. My workaround was to both increase the size of these windows, and offset their position by the delta. This would use setPosition which would get rid of the anchoring on the right edge which I anticipated.

A day or two after that, I changed the chat panel from a <bounds> metric to an <anchor> metric and suddenly everything scrunched up in the upper left (as the chat window is the primary anchor for all my other panels). I reverted this panel change and it still scrunched up, and so started this annoyance.

If there was a way to access panel parameters, I could conceivably change their <bound> or <anchor> offsets to account for W/H, W2/H2 differences, then couped with the additional added ability to "reset position" of those panels with a call, I could keep right alignment to the edge, and preserve those resized panels.

For now, I'll have to be content with my panels not being scrunched up in a corner.

[Moon Wizard]

Could you use something like the existing "shortcutsanchor" panel in the CoreRPG ruleset, which moves position based on how many buttons are displayed in sidebar? The actual sidebar panel/window (shortcuts) is anchored to the shortcutsanchor. The shortcutsanchor defaults to a bounds location initially, but is moved based on sidebar initialization.

JPG