[Plugin] SketchUcation Tools 2.6
-
Whilst autoinstalling v2.6 in SU2013, my Comodo Security popped up twice wanting to partially sandbox a VBS script with a numerical name.
The two files are no longer in the "Temp/SCF" folder.
Is this normal ?
-
Perfectly
-
v 2.6.0
On SketchUp v8 upon starting I get in the console:
%(#004000)[(eval):3119: warning: parenthesize argument(s) for future version (eval):3142: warning: parenthesize argument(s) for future version]On ALL versions 8 .. 14 upon starting I have do deal with multiple VBS sandbox popups, and new entries into my Comodo sandbox file list (which don't exist.)
(1) It is a major PITA.
(2) The VBS file names could have been something to indicate they belong to the SCF Plugin Store extension (instead of some meaningless number.)
-
I'm not familiar with the VBS additions in this release except that they are necessary for older SU versions.
I think TIG will be able to shed more light on your alerts.
We're they occurring on 2.5.2 beta?
-
No I did not see them occurring before.
I will have to turn the extension off, and only use it "on demand".
-
Cool
Sent from my iPad
-
We had some reports about vbs warnings in earlier beta tests but code adjustments were made and there were no further reports.
I am surprised about the 'parenthesize' warning in v8 - I can't think of any arguments passed in this code-set without () ?
Can't you set up an 'exception' for your over zealous 'Commodo' security - to skip vbs files, 'by folder' [.../Temp/SCF] ?
http://help.comodo.com/topic-72-1-451-4758-.html
shows examples using will-cards etc.
So a pattern something like*\Temp\SCF\*.vbsshould work ?These vbs will always run in v8/2013...
The SCFapi in v2014 can use Ruby2 [open-uri etc] for most of it 'communications', but earlier versions rely on vbs scripts using 'XMLHTTP' etc on PC [and .command using 'curl' for MAC].
These tiny vbs scripts are written to the .../Temp/SCF folder to ping data-packets to the SCF server and sometimes receive a response.
These scripts are named "f_nnnnnnn.vbs" where the "nnnnnnn|" is a random integer.
This is to ensure separation between several such pings that might run all but contemporaneously.
Any txt file they might make to hold any received data has a matching name.
On the creation of the txt file the data is read and the two files are deleted a few ms later.
That is why they no longer exist when you look for them.
In case of a rare 'left over' file remaining, on load the SCFapi also purges the ...Temp/SCF folder.Other vbs files are used by other modules to extract the plugin files etc from RBZ archives [renamed ZIP] where the destination folder is not the default Plugins folder [i.e. a custom-plugins folder has been added to the $:]
So even if you disable the SCFapi from loading you will get continuing vbs nags when installing into custom=plugins folders...
-
No tried 6 ways to Sunday to setup exclusions. Does not work as advertised.
Like I say... I only heed SCF Tools when manipulating plugins or extensions.
I'll turn it off.
-
@Dan
You are the only user to report these issues...
I cannot believe it is insoluble
-
I'm getting load errors after installing sketchucation tools 2.6. Could be a coincidence. This occurs when I open an .skp by double clicking it. It does not occur when I load SU by double-clicking the .exe or shortcut, then opening the model. (Win8, SU Pro 2014)
Thx
Error: #<LoadError: cannot load such file -- open-uri>
c:/users/drew/appdata/roaming/sketchup/sketchup 2014/sketchup/plugins/sketchucation/!scfapitools.rbs:76:inrequire' c:/users/drew/appdata/roaming/sketchup/sketchup 2014/sketchup/plugins/sketchucation/!scfapitools.rbs:76:inmodule:SCFapi'
c:/users/drew/appdata/roaming/sketchup/sketchup 2014/sketchup/plugins/sketchucation/!scfapitools.rbs:22:in<main>' C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:25:ineval'
C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:25:inload' C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:25:inblock in <top (required)>'
C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:14:ineach' C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:14:in<top (required)>'
D:/Program Files (x86)/SketchUp/SketchUp 2014/Tools/extensions.rb:197:inrequire' D:/Program Files (x86)/SketchUp/SketchUp 2014/Tools/extensions.rb:197:inload'
C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/!SketchUcation_loader.rb:189:inregister_extension' C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/!SketchUcation_loader.rb:189:inmodule:SCF'
C:/Users/Drew/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/!SketchUcation_loader.rb:16:in `<top (required)>' -
This thread looks similar.
http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=57121 -
As Box says...
Running SketchUp v2014 MR0 by double-clicking on a SKP that is not on the same drive as the SketchUp installation has a bug.
It fails to load the Ruby libraries into the $: aka $LOAD_PATH...
Therefore any tool that uses any of the new methods provided by v2014 will fail when it tries to load them as the folder is not found.
SketchUcation v2.6.0 uses open-uri with v2014 to make much faster downloads and installation of RBZs etc...
This is is not a SketchUcation issue - it will occur with any Plugins using the new methods.
The fault is known to Trimble and we are assured that a fix will be included in MR1...Meanwhile don't try to start SketchUp that way.
Instead, start it from the shortcut to the SketchUp.exe, then open the SKP via SketchUp.There is a temporary file to try to fix it - by Dan Rathbun - goes in the Tools folder and resets $:.
I've found it messes up if SketchUp itself is not installed on the system drive [
], otherwise it resets the S: Ruby Lib paths correctly... -
Thanks Box and Tig
-
This file is a temporary fix http://sketchucation.com/forums/viewtopic.php?p=519331#p519331
-
Getting this in the Ruby console with 2.6.0:
(eval);1; warning; already initialized constant SCF;;RESTART (eval);1; warning; previous definition of RESTART was here -
@jim said:
Getting this in the Ruby console with 2.6.0:
(eval);1; warning; already initialized constant SCF;;RESTART > (eval);1; warning; previous definition of RESTART was hereAll of the time ?
Or just after the initial update of the Plugin ?
I don't see it at all either way ??This Warning is just about a Constant [RESTART] already existing that is being overwritten.
It's not a load Error per seI see the reason, the .strings file defines RESTART twice !
I'll fix it...
-
Hello,
Since 2.6 I've noticed a slow down on Sketchup actions involving the plugin - opening/closing SU, making a modification in SUT2.6 and so on. Nothing shows up on the ruby console - but everything runs smoothly with SUT2.6 disabled.I keep plugins on dropbox (including SUT2.6) and access them using TIG's !loader.rb on 2 PCs using 8free and one with 2013pro.
Slightly separately - I seem to remember being able to control plugin/extension loading in SUT locally (by the registry perhaps?) - but now disabling a plugin/extension does so by appending ! and so disabling the file system wide.
Is the renaming of ruby files the future for SUtools? If so, I'll modify my use of it to compensate.
Thanks
-
Please update your User Profile so we know your OS and SUp version - are you still on v8 ?
Because v2.6.0 uses new Ruby methods to speed up downloads and decrease AutoInstall speeds by up to 400% there is a slight parallel 'downside' when opening/closing some of the dialogs used by the toolset, which now ping tiny amounts of related data back to the server [used in various analytics - like the new MySetup > Bundles feature]. With v2014 it's all done pretty instantaneously, but earlier SUp versions don't have the new methods which Ruby2 offers with v2014, so their alternative more cludgey methods may run noticeably slower [especially if you have a slow Internet connection], however it should still be barely perceptible... how long are you talking here...
If you disabled a plugin in a 'shared' Plugins folder, then it is disabled for all SketchUps using that Plugins folder.
If you disable a plugin in a local [default] Plugins folder, then it is disabled for that one SketchUp.
It has always been like that.Using SketchUcation PluginsManager Sets exported/imported on all of your computers you should be able to quickly reSet your Plugins to suit specific work-tasks...
Because v2014 PC now AutoInstalls / loads your plugins using your User default Plugins folder [like MACs have done for several versions before] it means that several users on the same computer can have different sets of plugins loading when their SketchUp starts...
-
I am as my user profile says
8free at home and mobile (but 2013 at work)The additional time is pretty hefty - Is there a way to check individual load times like libfredo tools? Or record what the active tool or process is?
I started to check between load times with and without SU2.6 but with SU2.6 loaded SU hangs at start, while orbiting, and changing tools. I'd lean towards a description of unworkable (sorry)
My mistake on the plugin disabling. Could've sworn I tested local loading, as I remember being impressed and thinking how useful that was. I don't tend to dream about plugin management, but its possible.
I think I'm used to waiting for downloads and installs. I wouldn't notice faster speeds as I'm usually doing something else in the mean time. Perhaps enough users are of the same mindset that a return to slower Ruby is possible? (my 2pence)
How long are you intending to support 8 and 2013 though?
Bear in mind I'm only whinging because 2.5.1 suited my cross-platform/multi-version/dropbox-plugin-folder setup perfectly. Must get round to upgrading to premium so I can whinge with a bit more weight, and a lot more abandon.
Thanks for responding - happy to help if I can.
-
Upgrading to Premium offers no extra weight to complaints.
The tool is free and all members avail of the same whinging rights.
Advertisement