Updates
- [DEV] Interface.onWindowClosed being incorrectly called for child windows after recent change. Fixed.
Printable View
Updates
- [DEV] Interface.onWindowClosed being incorrectly called for child windows after recent change. Fixed.
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
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.
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
I'm up to it, just let me know if you need any help.
I am getting this error on D&D and SW rulesets (didn't test others)
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.Code:Script Error: [string "scripts/manager_image.lua"]:91: bad argument #3 to 'setViewpointCenter' (number expected, got nil)
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.
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.
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
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.
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
Updates
- [DEV] More FG client guards to help prevent crashes when closing windows during initialization.
Just updated again.
All bugs that I had found to the date have been tackled. Nicely done, thanks!
It's more like a guard rail on the edge of a deep canyon.
JPG
Updates
- [DEV][CoreRPG+] Added indent number field to reference manual article record. If not defined or non-positive, then looks the same as now. Otherwise, indents name by 10 pixels per indent specified.
Usage for the above feature is as follows:
<indent type="number">N</indent>
Default refpage indentation value is '0' and each indentation "shift" is 10 pixels × the indentation value.
End result appears as follows:Code:<refpage_0003>
<indent type="number">1</indent>
<name type="string">refpage_name_here</name>
<blocks>
[block_content_here]
</blocks>
<keywords type="string"></keywords>
<listlink type="windowreference">
<class>reference_manualtextwide</class>
<recordname>..</recordname>
<description field="name"/>
</listlink>
</refpage_0003>
https://www.fantasygrounds.com/forum...1&d=1545070050
Most of the refpages have the default '0' indentation and appear normally, then a value of '1' for the indented refpages. If the book had been laid out with further sub-levels, I could have used '2' and so on to accomplish that.
The default indent value is 0.
JPG
That's what I meant! Read my mind not my words! :) Fixed!
Something I noticed today. I am not sure if this is because of v3.3.7 or if this has existed long before.
I have following code in regular stringfield.
The stringfield is in windowinstance wihtin windowlist. The window.windowlist.applySort() does exist and work properly, however if I have my focus on that field and close the window the contain the windowlist I get script error (showing that A was printed before error). Script error in states: attempt to call field 'applySort' (a nil value)Code:function onLoseFocus()
print("A")
window.windowlist.applySort()
print("B")
end
There are many places in SavageWorlds ruleset where the list is sorted when onLoseFocus from name field. If this error has been long before what would be the better way to do sorting?
Updates
- [DEV] More guard rails for scripts closing windows.
- [DEV] Adjusted new window deletion code to clear focus on all children upon deletion request, even though window is not immediately deleted.
I am having a new issue. Whenever I need to use a Search Field, when I type the first letter it automatically moves my typing to Chat. I find this hard to explain, just check my video. I try to search for Goblin on that and it keeps moving me to Chat.
If the list isn't being sorted out again (When it has no entries left), it stops changing to Chat window.
https://youtu.be/ngtQXSGQ85Y
I was noticing the same behavior as @Dr0w last night. I wasn't using any filter lists, though, I was creating new tables and story templates and I'd get one letter of the window name entered and the focus would shift to the chatbox. Same entering in the description field.
It settled down a little later (no changes to extensions or anything on my end) and would let me finish typing the titles or descriptions but would immediately shift focus to the chatbox so it was something I had to keep track of.
Hello and well met. There are several users in FGC reporting issues with the search functions whithin FG. They sound so similar to the posts already in this thread.
Lauren.
Just pushed a hot fix. Please update, and try again.
Regards,
JPG
Not exactly a bug, but certainly didn't work this way.
When you unlock lockable things on the desktop like: Chat, dice, modifier, etc. and you lock them somewhere else. If you close the campaign and open it again, they will have returned to their default position.
I like this extension to keep things in place between sessions...
https://svn.fantasygrounds.com/forum...aver-Extension
For the following update (which is awesome btw):
[CoreRPG+] Images can be sent to background panel or full screen panel.
Would it be possible to have one expansion level between expanded and full screen. Where the image covers the whole potential play area (including/and or excluding the menu section). So it's placed in the background underneath the combat tracker, chat, dice, dice modifier, character portraits? That way you can have an image or combat map covering all the available play area, while having access to all the tools needed to play on top.
I decided to stay away from that option for now, because the fact that the other windows over the top of the image would obscure sections of the image, and make those areas unreachable to view or access tokens. With the current image implementation in FG, images must extend to the edge of the window control area. It might be something we try in future versions.
Regards,
JPG
It would be great if that would be a feature in future versions, but this alone is a huge step forward. As has 3.3.7 been in general I dare say.
Thank you for the reply. :)
If you unshare an Image that a player is currently viewing, it will cause their client to crash.
Dr0W,
Can you try this scenario again please? I just pushed a possible hot fix to the Test channel; but want to verify that it works for you as well.
Regards,
JPG
Can this get added to the Reference Manual wiki page: https://www.fantasygrounds.com/wiki/...erence_Manuals? Cause I don't have that ability.
Any chance that:
..caused a new bug where Cat's Grace and Flat Footed combined now double count the lost dexterity???Quote:
[PFRPG/3.5E] Dodge bonus effects not ignored when other effect caused loss of Dexterity bonuses. Fixed.
I believe this has to do with a bug in CA/GRANTCA effects interacting with DEX effects. I'm hoping to push a bug fix update tomorrow with a fix for that specific issue, and a couple other minor items.
Regards,
JPG