https://www.fantasygrounds.com/forum...icent-Darkness
worked last time i checked
Printable View
https://www.fantasygrounds.com/forum...icent-Darkness
worked last time i checked
Busy state added for players! players can now add a busy action, name it to whatever action it is, set a duration, and get a notification of completion in the chat! This can be minimized by unlocking the window. One entry per active character.
Summary
When attempting to change the hours by either double-clicking the hours field or by clicking one of the 6am/12pm/6pm/12am buttons, an error is generated until the minutes value has been changed at least once.
Steps to Reproduce
- Create a new 5E or PF1 campaign and activate the Clock Adjuster extension only.
- Optional: Open a calendar module and select a calendar (tested with no calendar, the Gregorian calendar that ships with FG and with a custom calendar).
- Change the time by either:
- Setting hours adjustment field to a non-zero value and then double-clicking the field.
- Clicking one of the Dawn / Midday / Dusk / Midnight buttons.
Result
The hour is changed as expected, but the following error is also posted to the console:
This error will continue to occur every time the hour value is amended like this.Quote:
[ERROR] Script execution error: [string "scripts/manager_time.lua"]:110: attempt to perform arithmetic on field 'nMinute' (a string value)
Workaround
Changing the minutes value - either on the FG Calendar screen or by setting the Minutes Adjustment field to a non-zero value and then double-clicking on it - prevents the error from occuring again.
Notes
Confirmed that it happens in both 5E and Pathfinder (1E) campaigns, haven't tested any of the other rulesets.
It does look like humby did that.
Unfortunately, setting a calendar doesn't set minutes and hours. At least not if I remember correctly. This is why at one point I had "or 0" listed for all fields like nMinutes that might be missing values.
This is a result of getValue() not having a default value when fields have not been used yet (unlike DB.getValue()) which has the optional 3rd arg which is used as a fallback when it would usually return nil.
EDIT: didn't read error fully. value is string but should be number. i assumed it was nil.
Yes, first picked it up during the session I was running last night, which uses a custom calendar. Re-tested it this morning on a fresh campaign and forgot to set the calendar first, so had to create another fresh campaign where I did it properly. And then did it a few more times to test the other permutations.
When you set your calendar up, FG automatically populates the hours and minutes fields in the front end with 12:00AM so to an end user it does appear to have been done completely and correctly...
After looking at code and re-reading the error, it's not a nil error just something being handled as a string when it should be a number.
The issue is either in getCurrentRawDate, getLastDate, or buildRawDate.
Unfortunately since CurrentDate.nMinute and LastDate.nMinute both use nMinute in their names, you can't tell which is exhibiting the issue.
I'd start by just doing this to getCurrentRawDate:
although there could be a deeper issue here.Code:function getCurrentRawDate(sFactor)
local Date = {};
Date.nMinute = tonumber(DB.getValue("calendar.current.minute", "", 0));
Date.nHour = tonumber(DB.getValue("calendar.current.hour", "", 0));
Date.nDay = tonumber(DB.getValue("calendar.current.day", "", 0));
Date.nMonth = tonumber(DB.getValue("calendar.current.month", "", 0));
Date.nYear = tonumber(DB.getValue("calendar.current.year", "", 0));
return Date;
end
It does, and it’s unfortunate the node is not set as well. I’ll be looking into what happened to BMOS’s fix, why it’s not taking anymore.
A lot of people seem to like to start their campaign at midnight so guess I better hop on it as soon as I get done work :p
As a tangent, I’m currently working on adding automation for the AlienRPG within the clock adjuster, as the ruleset was what inspired me to create the extension in the first place. Lots of cool effects to be added, just got to iron out the details a bit more. So the fix will come when that feature is complete.
Ok I’ll check that out. Although something I noticed before was in the desktop widget, the various values were being called incorrectly, and I can’t remember if I fixed that for all of them or not. They were doing something like DB.getValue(“calendar.current.minute”, 0); which I don’t think returns what we expect. It should be DB.getValue(“calendar.current.minute”, “”, 0); or DB.getValue(“calendar.current”, “minute”, 0);
So if that wasn’t fixed everywhere, that may be part of the problem too. I’ll take a look after work here. Thanks for the tip.