idealsceneprod wrote: ↑Thu Oct 31, 2019 8:17 am
Reactor - Installer.lua:962: bad argument #1 to 'floor' (number expected, got nil)
Thanks for your bug report.
I haven't downloaded Resolve 16.1.1 yet. I will test it out today and take a look at the issue with the Reactor install process.
On the surface, line 962 of the source code is trying to detect the active Fusion version. It tries to check a Fusion v7-16 version range by accessing a variable that is based upon a "
" value in Lua. Possibly that value is now undefined in the latest version of Resolve? I'll have to take a look and find out.
Added in 12 minutes 42 seconds:
Yeah. The issue is BMD broke the pattern used for Fusion Script API version numbering in the latest v16.1.1 release so the version number is no longer able to be converted to a floating-point or integer-based number with the stock Lua scripting
function in Resolve v16.1.1.
Gotta love unit-test driven development vs actually trying a new software release out on real-world workflows before shipping it.
In summary, a different approach will need to be used in Reactor's installer script to detect if it's running inside of Fusion v9.0.2 - v16.1.1 vs if the script is being launched in an unsupported Fusion v7.7 - 9.0.1 range of the software that can't act as a Reactor host.
A fix for this issue should be ready in a few hours.
For anyone who loves technical nitty-gritty details here is a breakdown of the issue:
Examples of the Fusion/Resolve Versioning Issue
And now we have double periods in the number value in the newest release which causes compatibility issues:
Keen-eyed readers who are good at detecting patterns in how things are supposed
anticipated to work would likely notice that last version output from Resolve v16.1.1 should have reported "16.11" as the version number returned by "
". We didn't get that as a result so it breaks the expected conventions that go back earlier then Fusion v7 and as a result we get the error you now see today.