Very excited about GP4 and just installed it. Amazing new implementations, can’t wait to learn and familiarize myself with it all!
Unfortunately, upon opening an existing gig file (from GP3 obviously) the scrip logger throws out this error:
“Plugin ‘PLUGIN1’ not found in rackspace ‘Clean Fat Funk’
Scripting has been disabled for this rackspace
Clean Fat Funk (Rackspace) - Plugin ‘PLUGIN1’ not found in rackspace ‘Clean Fat Funk’
Scripting has been disabled for this rackspace
Uh oh - GP Script runtime error”
Then it proceeds to throw out the same exact script error for ALL my rackspaces. In the wiring view, plugin1 is there and in the script editor, the script compiles successfully. The plugin itself is loaded successfully. What is up with this script error?
UPDATE: Seems to be a upper/lower case text error. In the script, it is listed as “PLUGIN1” but of course, the handle name for the plugin, even if entered in upper case, it will default to all lower case. So it was the issue of PLUGIN1 vs. plugin1. The bad news is, once I fixed that, it moved on and complained about the next syntax case difference and I realized that almost ALL of my scripts in all my rackspaces contain these case differences. It was not a problem in GP3 but it is in GP4. The odd thing is, the script editor itself compiles SUCCESSFULLY, but the script logger still throws out the error and disables all scripting for the rackspace(s).
I was writing my update as you were writing your response. LOL Yes, that’s exactly what it is, but why was it OK in GP3 and why does it compile successfully in GP4?
Hmm, it probably was — but we have improved the error handling to report more issues and GP Script now refuses to run if it finds a problem.
Is it possible that you were not actually referencing that plugin in gpscript ? In that case, although a warning might have appeared, GP Script would have continued working.
All the scripts worked smoothly and was doing what it was supposed to in GP3 and it is refusing to run in GP4. Again, the odd thing is that it compiles successfully in GP4.
No, its not possible. I don’t have another plugin with that name, plus now that I see that it is complaining about all my scripts (about 6-7 instances in each rackspace script), it is definitely not a matter of referencing a different plugin and all scripts worked perfectly in GP3. Since it is not possible to enter upper case names in the plugin handle name, I guess I’ll have to edit all my scripts in all my rackspaces. It’s just a complete mystery why it worked in GP3 if case sensitivity was an issue even then?
Thanks for looking into it! Here is a gig file with the same scripts in the racks. Please note the script syntax with “PLUGIN1”…2,3…through “PLUGIN6” and “SceneBlock” names. All these are written in caps (or partially) in the script, but not in the handle name and it is NOT throwing up errors in GP3 for me. HLsample.gig (570.1 KB)
I can confirm–script compiles fine in GP3 despite the difference in upper/lower case between GP Script handle and variable name in the script itself— eg. plugin1 in GP Script handle, PLUGIN1 in the script itself. The difference in case throws an error in the GP4 compiler, however.
I can confirm, as soon you use plugin1 and plugin2 instead of PLUGIN1 and PLUGIN2 etc, the scripts run
Or you set the OSC/GPScript Handle exactly like you used it in scripting.
OK - let’s be clear here — this is not a compiler error — which is why compilation is successful. It is a run-time error, when the compiled script starts executing and is looking for the plugins declared in the script.
Well it seems that the GP3 compiler should produce an error and doesn’t , while the GP4 compiler does the job correctly. The plugin handle name has to match the plugin name defined in the script.
Yes – in that sense, GP4’s implementation is correct and could be considered a bug fix. In fact the documentation for GP Script notes that the names must be identical.
I guess we always assumed that people were using the same names, given that identifiers are all case sensitive in GP Script.
I have however updated the documentation to point out that this corrected behavior will break GP3 scripts if such scripts were not written with case-sensitivity in mind.
This community is amazing! So many respond so quickly! I’m glad we figured this out, BUT I’m left with
this question, should GP3 have in fact thrown out an error when in fact it worked flawlessly?
That’s what I tried to formulate differently. But OK, if you want… it is a bug fix in GP4 which seems to generate a bug as it worked before which indeed is not a but because it shouldn’t work before even if it did.
… which is now fixed !
