Printable View
I hope this helps if you haven't already figured it out, I've applied this to my own file and it seems to be working without issue thus far.
This message
is solved by swapping all instances of "ActorManager.getActor" with "ActorManager.resolveActor"Quote:
ActorManager.getActor - DEPRECATED - 2021-01-01 - Contact forge/extension author
The extention will retain functionality until "getActor" is completely removed from FGU in the near future.
https://www.fantasygrounds.com/forum...uleset-Updates
@Berwind
Thank you. Got that part figured out. I should have addressed it when I saw the “Debug.console” warning in the previous FG version.
I’m trying to coincidently address a couple other “housekeeping” items, but finding enough time in my personal schedule is my real problem.
And as you say, when Smiteworks completely deprecates getActor(), I’m going to be in trouble.
Release Notes
Local Dice Tower Extension (LDTE) version 0.0.10:
1) Fixes the "deprecation" warning reported by EllivasKram (see posts 94-96 of this thread).
2) Addresses extension naming and Forge issues as brought to light by MrDDT (see posts 98-100).
3) There is now one extension for all supported rulesets (CoreRPG, PFRPG, 3.5E and 5E).
Details:
First: absolute kudos to Moon Wizard and the rest of the Fantasy Grounds development team for their multi-tiered approach in handling the deprecation of the getActor() function and its replacement by the resolveActor() function.
When they deprecated getActor() in a new version of Fantasy Grounnds, a couple releases ago, they announced it in the release notes, which I never read, and redirected program flow to resolveActor() via its call within the deprecated and stranded getActor() function. Additionally there was a Debug.console warning embedded in getActor(). In a subsequent release they trumped up the warnings by embedding a Chat warning of the getActor() deprecation, employing extension consumers to light fires under the extension developers.
What all this has done is allow those of us community developers who dawdled, and didn't address the deprecation in a timely manner, additional time to get our act together without causing our extension to just become broken. Thank you Smithworks. I'll endeavor to be more participatory in the future.
Second: I use three methods of identifying what version of my extensions are being employed by users of my work. (1) The extension <name> field in the extension.xml file which is presented to the user when they select which extensions they're going to use on the Fantasy Grounds Launcher page. (2) The extension <announcement> field in the extension.xml file which is presented to the user in the Chat box on the Fantasy Grounds tabletop. And, (3) the name of my extension's file itself as seen in the extensions folder.
MrDTT asked that I present updates via The Forge in a manner that doesn't require users to have to reselect the new version of the extension on the FG Launcher screen whenever I post an update. After some experimentation, it appears as though, the only item that I use for extension version identification that I have to be mindful of is the file name itself. So in the future I will attempt to use the same name for every version of LDTE. I believe I can still relate extension version info, in both the <name> and <announcement> fields, and Fantasy Grounds will not require extension reselection prior to launch.
Please note, I am setting the default file name with this release, so this time you will have to reselect the latest (v0.0.10) version in the Launcher but hopefully not in the future.
Third: Some time ago I started a thread and I asked for help managing extensions that require desperate coding over multiple rulesets. Recent posts to that thread have allowed me to recombine all the code into a single extension file, yet still maintain the desperate code required by each supported ruleset.
Thanks for updating this and it's working great!
The Druid Wild Shapes Implementor extension of mine has been updated so the problem of it and this extension, Local Dice Tower Extension (LDTE) not playing nicely with one another has been remedied.
(For those users that use both LDTE and DWSI.)
Hi Minty - could you please see if this code breaks your extension?
filename: LDT_record_char.xml
code:
note the super stuff....Code:function onInit()
--[[ Debug.console("LDT_record_char.xml | charsheet | onInit() | ruleset=", User.getRulesetName()); ]]
LDT_DiceTowerManager.registerControl(self);
if super and super.onInit then super.onInit(); end
end
So what's the story of the LDTE being delisted and re-listed ?
If anyone has noticed their EXTN has gone AWOL - You have to re-subscribe to the LDTE extn as the older extn was delisted..
@damned
As mentioned in PM and in another, somewhat off-topic thread, we've run into this before:Quote:
Originally Posted by damned
LDTE and your Hero Points extension bumped into one another. Last time I put a band-aid on the problem and solved it by putting code that specifically looked for a Hero Points <label> in LDTE and then dealt with it.
It appears as though you want me to do the same, although using a different method, and I am assuming, some code on your end.
What I would like to do is propose a different methodology: maybe something that iterates over the <anchor> fields and places our icons properly based on what's there (from ruleset and any other extensions loaded). Hopefully this would prevent any future issues as well. We'd have issues with <loadorder> unless we both adopt the proposed methodology.
damned, I suspect you have more clout than I do with Moon Wizard, if you don't mind would you run this idea by him? I'm not asking him to solve the problem and provide the code, I can do that and know you're capable of doing it to. I'm just wondering if the methodology I propose is sound.
--deleted--
Hi Minty Im all out of time this week. Ill take it back up with you next week if thats ok.