Closed mcubas76 closed 4 months ago
I would like to know as well. This is one of the last modules keeping me from migrating to v12.
Unfortunately job & life have been busy, and I haven't had any free time to fix breakage introduced by v12. I do plan to eventually update Dungeon Draw, but I don't have a concrete estimate when. Right now I'm working my way through all my various systems and modules, to fix them for v12.
No problem. Good to know the module is still alive and kicking. This is an amazing tool.
I fixed the obvious v12 breakage and pushed a new Dungeon Draw 3.0.0 build, now compatible with Foundry v12. It may still have lurking bugs, so please let me know if you run into any :)
https://github.com/mcglincy/dungeondraw-foundry-vtt/releases/tag/3.0.0
Appreciate the effort. I'm definitely running into some bugs. I keep getting and error about 'addChild'. Once I get a stacktrace, I'll post a bug report.
also getting it I can't even create a new scene and go to it without hitting it :(
Error: Failed drawing primary canvas group: Cannot read properties of undefined (reading 'addChild'). Cannot read properties of undefined (reading 'addChild')
at Hooks.onError (foundry.js:630:24)
at 🎁call_wrapped [as call_wrapped] (libWrapper-wrapper.js:507:22)
at 🎁Hooks.onError#lib-wrapper (listeners.js:138:11)
at 🎁Hooks.onError#0 (libWrapper-wrapper.js:187:52)
at #draw (foundry.js:24914:15)
at async Canvas.draw (foundry.js:24798:5)
at async Scene.view (foundry.js:21268:7)Caused by: TypeError: Cannot read properties of undefined (reading 'addChild')
at InterfaceCanvasGroup.addDrawing (foundry.js:50469:70)
at #addDrawing (foundry.js:53848:24)
at Drawing._draw (foundry.js:53825:34)
at foundry.js:26571:18
at <anonymous>
ok - stupid error on my part... I forgot to actually merge the new v12 code before building :P
I just pushed a new build 3.0.1, with the v12 fixes this time.
I still see this error on 3.0.1. I can disable BaileyWiki modules (a number of them) and then it works. So there might be some more compatibility issues going on here outside just with DD itself.
Chatting and debugging on the Baileywiki discord #foundryvtt channel, to see if we can narrow down exactly which module(s) are conflicting, and how.
ok - stupid error on my part... I forgot to actually merge the new v12 code before building :P
I just pushed a new build 3.0.1, with the v12 fixes this time.
hah! done that too many times before
I see the error with only dungeon draw enabled
@BladeFireLight what OS, Foundry version, and browser are you using?
So far I haven't been able to repro the error on my local setup (Foundry 12.328 node.js build, running on macOS, either chrome or Firefox browsers).
I found something interesting that may be helpful. The scenes that are active when you open the game world seems to matter.
I have a custom scene that I created using DD and a premade (Galleon Airship) from Baileywiki. If my scene is the only one open initially and then I go and open the other scene everything is fine. However, if the Baileywiki scene is in the navigation bar when I load the world then I get the 'addChild' error.
What is even more strange is that the Baileywiki modules don't seem to matter. I deactivated all of them and I still see this behavior when I have one of their maps and a DD map open when the world loads.
FYI, I'm using the latest version of Chrome on Windows 11.
On Fri, Jul 5, 2024, 12:41 PM Matt McGlincy @.***> wrote:
@BladeFireLight https://github.com/BladeFireLight what OS, Foundry version, and browser are you using?
So far I haven't been able to repro the error on my local setup (Foundry 12.328 node.js build, running on macOS, either chrome or Firefox browsers).
— Reply to this email directly, view it on GitHub https://github.com/mcglincy/dungeondraw-foundry-vtt/issues/131#issuecomment-2211154969, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ3WBBTLZA6PFA3LMQM2ATZK3EDJAVCNFSM6AAAAABIW6PXU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJRGE2TIOJWHE . You are receiving this because you commented.Message ID: @.***>
Thanks @pbtura - following your steps I'm now able to repro. If I have a Baileywiki scene activated, when I refresh the browser tab I see the error. If I have a DD scene activated, when I refresh the browser tab I don't see the error.
Now to debug what is actually making that error and how to fix it :)
I've just been testing with FVTT 12.328, OSE 1.10.3 and Dungeondraw 3.0.1 and I was also getting the 'reading addChild' problem, no scenes (using Dungeondraw or not) were visible although they seemed to load. I found disabling the Dungeondraw module, loading a scene (with a Dungeondraw map), seeing all the walls and other items but not the map of course, then re-enabling the module then loading the scene again, now has all scenes loading correctly.
I just restarted Foundry for good measure and scenes are now displaying normally, no sign of the error.
Tested with Brave browser on macos 14.5, Brave [Version 1.67.123 Chromium: 126.0.6478.126 (Official Build) (arm64)]
Changing that to, it was working normally... I changed the Foundry Performance Mode from high (new default I think) to Medium and the problem returned and now I can't get rid of it again even toggling the module state. It's weird. :) Anyway, this is all on a test server and my main game is staying on v11 for a while yet.
It looks like DungeonDraw's "DungeonLayer" layer being on the canvas is somehow confusing other parts of Foundry, causing an InterfaceCanvasGroup object to exist with an undefined #drawings collection, which then throws an error when #drawings.addChild() is called as part of drawing various other Drawings. (In my testing, it was a drawing on the Baileywiki scene that was attempting to draw.)
I need to dig more through Foundry code to understand how/why the DungeonLayer is causing this badness in v12. It could be it's missing some new v12 layer option/field, etc.
I noticed there is a new field called 'sort' for tokens that seems to have replaced the z index. Not sure if it is related but it might be a good place to start
On Fri, Jul 5, 2024, 2:10 PM Matt McGlincy @.***> wrote:
It looks like DungeonDraw's "DungeonLayer" layer being on the canvas is somehow confusing other parts of Foundry, causing an InterfaceCanvasGroup object to exist with an undefined #drawings collection, which then throws an error when #drawings.addChild() is called as part of drawing various other Drawings. (In my testing, it was a drawing on the Baileywiki scene that was attempting to draw.)
I need to dig more through Foundry code to understand how/why the DungeonLayer is causing this badness in v12. It could be it's missing some new v12 layer option/field, etc.
— Reply to this email directly, view it on GitHub https://github.com/mcglincy/dungeondraw-foundry-vtt/issues/131#issuecomment-2211242663, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ3WBAWBXMDGEXHANAJRWDZK3OQFAVCNFSM6AAAAABIW6PXU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJRGI2DENRWGM . You are receiving this because you were mentioned.Message ID: @.***>
Changing DungeonLayer to be in group "interface" -- rather than "primary" -- makes the addChild error go away.
Now I'm working through why after changing that, drawings are incorrectly showing up below the DungeonLayer, even though I've got the DungeonLayer's zIndex set lower than DrawingsLayer's zIndex.
Edit: I likely need to get "primary" group working for DungeonLayer... as otherwise "Object" drawings (including DD's tool previews) which are in primary group will get drawn below the "interface" group, which isn't what we want for DungeonLayer.
I believe I've found how to both keep Dungeon Draw in the primary group and avoid drawing all other drawings in the scene (which causes the addChild error when Dungeon Draw is in the primary group).
New build 3.0.2 released, if folks want to grab it and test.
Ultimately, Dungeon Draw should probably stop extending the Foundry PlaceablesLayer and/or stop using the Foundry Drawing class for its tool previews... because when new versions of Foundry change how these things work or are drawn, it breaks things with Dungeon Draw.
It's working ok now for me. Tested with FVTT 12.328, Brave Version 1.67.123 Chromium: 126.0.6478.126 (Official Build) (arm64) on macOS 14.5.
Thank you for the support of this excellent module.
Going to close this issue. If anyone hits more v12 bugs, please file new github issues or ping me on discord (mcglintlock on the Foundry discord).
Hi. Would like to know if you are working to get this module running in V12. It is an awesome module that is super helpful. Thanks!