Environment Details
Foundry VTT Version: 0.8.9
Operating System: Windows 10 64bit
How Are You Using Foundry: (Hosted on Forge)
Which Game System: GURPS
Modules Enabled?: yes (including drag-ruler v1.8.2, FoundryVTT Arms Reach 2.0.11Libwrapper v1.10.6.0)
Issue Description
Drag Ruler doesn’t work properly when Arms Reach is also enabled.
So at first I thought it is a conflict between Arms Reach and Drag Ruler and opened and issue for
It also only happens when using Foundry via the Forge. Foundry on the desktop with both modules enabled works fine!
So by now I am convinced that it as a Forge issue. Which the following error message underpins:
Uncaught (in promise) SocketlibUnregisteredHandlerError: Function '_socketRecalculate' has not been registered as a socket handler. [Detected 2 packages: socketlib, foundryvtt-arms-reach] SocketlibError https://assets.forge-vtt.com/bazaar/modules/socketlib/1.0.9/src/errors.js:3
Also when I access a self-hosted game via Chrome it also woks fine. So it just happens when The Forge is involved.
Just going to confirm I have somewhat the same error messages trying the module. It seems to happen once in a while if you try to drag quickly in my experience, and then loses track and just doesn’t move at all. Then you have to re-drag.
Though I am not sure if this is a Forge issue or a module issue, I will confirm it for now and have a look a little bit later when I know more. I don’t see why it would be on the Forges side as of yet.
It might be a version different from your local world? Foundry? System? I’ll have to look further tomorrow.
I double checked to make absolutely sure everything is the same.
Same modules.
Same module versions.
Same system version.
Same Foundry version.
Same world (Exported the world from Forge to local Foundry).
Tried different browsers with The Forge and self-hosted.
Huh, could it still happen if you connect through a browser to your local game?
I am not sure if that is already mentioned in the above statement, but might be interesting to ask.
Yes, I also tested that scenario.
Hosted the game on my locally installed Foundry version and accessed the game via browser (http://localhost:30000/game). Worked on both tested browsers (Firefox, Chrome).
So. What I’ll do from this point is:
We can provide a testing environment for the module creators on the Forge, to see if they can have a look at it. The errors we have provided in this thread should point them in some direction ^^
Second, we’ll continue looking at the issue, to make sure it isn’t on our side. Sadly this will take a little bit of time, I imagine, but we want to get it fixed either way.
I’ll continue looking though, thank you for bringing this up and helping us, your report was most excellent ^^
Pinpointed the issue. There is something wrong with the Bazaar version of Foundry Arms Reach. I realised that their manifest isn’t set correctly, as when I tried to install in Foundry, it didn’t find the package.Didn’t think much of it and just installed it through manifest instead, locally. They have the same version number in Forge, might be a hiccup by the module creator or the versioning not working correctly.
To fix this till we get some more information on what to do about it, you can install the correct version through manifest
For my part (Arms reach author) I can only say that the error is “strange”, I could not replicate it on my local windows machine or on my linux machine in the cloud with 70 modules active. This weekend I will try to test it on forge and do some debugging.
Thank you ^^ We’ll continue to look for answers to this too. It is very peculiar, as I’ve also tried it locally (not on an external server) and it worked fine.
At this point I have no idea how forge behaves, but it seems to duplicate the structure of the “drag-ruler” module under the “foundryvtt-arms-reach” folder:
which however is not the original and seems to have some problems with the management of sockets etc.
At this point I see these three solutions:
[Best solution] Ask the author of “foundryvtt-drag-ruler” to add a hook for the functions I reuse from him, so as to avoid using the relative paths of ecmascript here the request .
[Patch solution] Create a specific version of “foundryvtt-arms-reach” to take into account the “directory” added by forge with the version of the module in the relative paths of the ecmascript.
[Forge solution] Now that the problem has been highlighted I don’t know if you can do something on the Forge side to handle the use case.
Thank you for investigating the issue.
Using a relative import from one module to another would indeed cause these kinds of issues. It is part of the best practices for module development because it can cause these kinds of issues, see : Package Development Best Practices Checklist | Foundry VTT Community Wiki
Never do a relative import (esmodule) from one module to another (or to a system). If you need access to something, contact the developer and ask them to expose it instead.
The Forge doesn’t really duplicate the drag-ruler under the arms reach folder, but rather the server is able to determine that the file being imported is a relative import from one module to another, so it tries to prevent a 404 error by returning the right data, although it has the issue that :
1 - it returns always the latest version, which might not match the currently installed one
2 - the URLs are different, so the data inside that esmodule may not be initialized properly, or cause duplicate ‘inits’ to be called, etc… which can cause problems.
I assume that’s what’s happening here.
The best solution is for drag-ruler to expose their module or a hook/API to Foundry for other modules to use. I don’t think there is a way for arms reach to function with the incorrect file, because it is simply not correct to break out of the module’s own sandbox, and that will cause various problems.
This is an issue that we’ve spent a long time brainstorming with the dev community over a year ago, and there doesn’t seem to be any way to solve it from The Forge’s side.
Thanks!
