Sketucation plugin load error
-
In v2014 SCF tools use
open-uri.rb
to get the RBZ etc...This is an extra Ruby tool provided by Ruby2.0...
It seems like you do not have afull installation or at least SketchUp is not loading properly
Run with the Ruby Console open, does the SketchUcation PluginStore AutoInstall files ?
Do you have anything odd about your Windows user-name?
Like a single-quote ('
) in it, or accented characters likeรฉ
?
I believe it is plain "alex
" but I need to ask these this FTAODCan you provide the following results, in the Ruby Console type / copy+paste:
$:
result?
Should be something like:
["C:/Program Files/SketchUp/SketchUp 2014/Tools/RubyStdLib", "C:/Program Files/SketchUp/SketchUp 2014/Tools/RubyStdLib/platform_specific", "C:/Program Files/SketchUp/SketchUp 2014/Tools", "C:/Users/TIG/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins"]
Are ALL of those folders listed ?In the Ruby Console type / copy+paste:
File.exist?("C:/Program Files/SketchUp/SketchUp 2014/Tools/RubyStdLib")
result?
Should betrue
Then:
File.exist?("C:/Program Files/SketchUp/SketchUp 2014/Tools/RubyStdLib/open-uri.rb")
result?
Should betrue
Type:
require("open-uri")
result?
load("open-uri")
result?
Run with the Ruby Console open, does the SketchUcation PluginStore NOW AutoInstall files ?
It looks more like a SketchUp issue rather than a SketchUcation tools issue ?
The required additional .rb file seems to be missing, or not in a folder in the$:
[aka$LOAD_PATH
]... -
Hi TIG, Thanks for you prompt and greatly valued input. I think you may have nailed it (being a Sketchup issue).
I do not run SU2014 from the "standard" library "C:\Program Files...." as I try to keep my
drive minimal for backup/restore of a workable Windows environment easier/quicker. Most of my applications are on my E:drive.
When I call Sketchup direct, the paths seem to be evaluated properly, however, if I click on a SKP extension, there may be library name truncation/conversion by the OS that is not addressed by Sketchup/application. It seems like something may be processing the library name as "SKETCH~2" (the 8 character DOS equivalent) instead of "SketchUp 2014". I did create a "M:/Graphics/SketchUp 2014/Tools/RubyStdLib" library to see if it would fix the problem, yet it was "not found" unless I entered yje name in full.
I was hoping to avoid re-installing into "C:\Program...",customising and installing all the ruby scripts again but it looks like that is may be the way to go unless I startup SU direct and open the SKP file manually from the program.
Can this issue be directed to the SU team and if so how?
Following are the logs for 3 different scenarios tested (as per the underlined heading). The first (and preferred method) gave me grief while the other two seemed to work;
1. Clicking on SKP extension file:
---------------------------------------$:["M:/Graphics/SKETCH~2/Tools/RubyStdLib", "M:/Graphics/SKETCH~2/Tools/RubyStdLib/platform_specific", "E:/Graphics/SKETCH~2/Tools", "C:/Users/Alex/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins"]
File.exist?("M:/Graphics/SKETCH~2/Tools/RubyStdLib")
falseFile.exist?("M:/Graphics/SketchUp 2014/Tools/RubyStdLib")
trueFile.exist?("M:/Graphics/SketchUp 2014/Tools/RubyStdLib/open-uri.rb")
truerequire("open-uri")
Error: #<LoadError: cannot load such file -- open-uri>
<main>:inrequire' <main>:in
<main>'
SketchUp:1:in `eval'
nil2. Starting with path in "Start in" properties tab (Win 7 desktop icon):
------------------------------------------------------------------------------$:["E:/Graphics/SketchUp 2014/Tools/RubyStdLib", "E:/Graphics/SketchUp 2014/Tools/RubyStdLib/platform_specific", "E:/Graphics/SketchUp 2014/Tools", "C:/Users/Alex/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins"]
File.exist?("E:/Graphics/SketchUp 2014/Tools/RubyStdLib/open-uri.rb")
truerequire("open-uri")false
3. Starting direct from installation folder:
------------------------------------------------$:["E:/Graphics/SketchUp 2014/Tools/RubyStdLib", "E:/Graphics/SketchUp 2014/Tools/RubyStdLib/platform_specific", "E:/Graphics/SketchUp 2014/Tools", "C:/Users/Alex/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins"]require("open-uri")false
-
That is the issue.
You have created a chimera !It has been discussed in other threads.
There is a known bug in the first release of v2014.
If you do not have SketchUp installed on your system drive [usuallyC:
] then it can fail to include the two Tools Ruby folders in the$LOAD_PATH
[see my example output for$:
] - as these are not then on the search path any script that requires one of the additional Ruby functions fails as it can't find the file.Also opening SketchUp by clicking a SKP that is not located on the same drive as the SketchUp installation will causes similar missing-Ruby-paths issues.
If you open SketchUp, then the SKP it is avoided...There is a
!_fix_ruby_startup.rb
by Dan Rathbun which goes in the Tools folder as a partial fix, until the next v2014MR1 comes out to fix this mess in the app itself...
Having that run should ensure that all of the correct folders are added to the$LOAD_PATH
and are therefore accessible in 'requires' as they should be.
Assuming that the Ruby folders etc exist where they should be in Tools with the SketchUp installation...
I can't find a link immediately so I have PM's you the .rb... -
So to recap...
On PCs, opening a SKP on a drive that is not the same as the SketchUp.exe installation drive, causes the paths to the two Ruby-Libs to be incorrectly defined in $:, which then prevents use of any Ruby2 functions, and gives startup error-messages for several newer Plugins...
The temporary 'fix' .rb [by Dan] only works if SketchUp.exe were installed on the system-drive, because it fixes the Ruby-Lib paths to match the system-drive...
But this fix fails when SketchUp.exe is not installed on the system-drive !This attached alternative version [by me] will reset the two Ruby-Lib paths in $: to match the Tools folder's drive - thereby keeping everything in step as all three paths should share the same drive reference.
It also now allows for several custom-plugins folders to precede the Ruby-Lib entries in the $: ...Drop it into the Tools folder of v2014 and restart SketchUp [by any method].
It only makes changes as SketchUp starts if it has to - i.e. the first SKP opened was by double-clicking its icon and it is not on the same drive as SketchUp.exe installation.You can remove this .rb once v2014 MR1 [or later!] comes out with a built-in fix for this PITA - although leaving it in will do no real harm, it will lengthen the startup time by a ~millisecond !
NOTE: This fix is only needed in v2014 and on PCs.
AND it's also only needed if you want to open SKPs by double-clicking their icons, and they are on a drive other than the one where SketchUp.exe is installed.
Installing it in other SketchUp versions or on a MAC is a waste of time.
[mod=:1my9troi]Edited so it will NOT run unless the version is 2014 MR0.
It now auto-deletes itself if installed in wrong version or OS.
It was already trapped to run only on PCs.
.[/mod:1my9troi]
-
If this is temporary and for a specific version of SketchUp then please ensure the code is only executed for that specific version of SketchUp.
SU2014 = 14.0.4900 on Windows, 14.0.4899 on Mac.
-
It is simply a reworking a Dan's system-drive specific fixer - which was posted elsewhere.
My tweak just allows SketchUp.exe to be installed on a drive other than the system-drive and still fix the issue of SKPs on other drives initially opening and executing Sketchup.exe and messing up the $: Ruby-Lib paths...
It was already limited to run on PCs only [the issue isn't MAC related so it already only runs on PCs] and it is clearly explained that it's to be used in v2014 only.
It might obviously break earlier versions of SketchUp, but why worry about that?
There are many ways to break things by being plain daft...
Because there'll be no Ruby-Libs in $: to grep, the iteration will be for [] not the v2014 two elements array - so nothing will happen anyway because the 'fixed=false' always...However, I have now edited it to RUN only on v2014...
If it's left in the Tools folder after v2014 MR1 arrives [or heaven-forefend later!], which hopefully should fix this issue properly, then there is still no harm since the script stops when it finds there's no issues to fix.
-
You know someone will find a way to misuse it - you saved yourself a future headache.
-
Thank you. I'm on a PC, my apps are on E:/, data on F:/, and TIG, your fix worked perfectly. It was 10 min. from search to solved. Only deviation from alexkara is that I start SU from a shortcut on my desktop. This just started a couple of days ago.
-
@tig said:
You can remove this .rb once v2014 MR1 [or later!] comes out with a built-in fix for this PITA - although leaving it in will do no real harm, it will lengthen the startup time by a ~millisecond !
The bug has been fixed for the next release. Please adjust this sample script to only be active in the M0 release - just to be on the safe side. The $LOAD_PATH is an internal Ruby construct so I'd prefer if interfering with it was kept to the minimum.
-
Hm... and Chrome downloaded this file as %21_fix_ruby... Might it be some server settings being incorrectly set?
-
Edited so it will NOT run unless the version is PC 2014 MR0 ['14.0.4900'].
It now even auto-deletes itself if it is installed in the wrong version or OS... -
Thanks. I might have been harmless to run with our fix in place, but I prefer to be on the same side.
We've uncovered several other issues with Ruby file handling under Windows where things isn't working as advertised and initiated contact with the Ruby developers with bug reports and in some cases patches.
-
Thank you!
I use the patch,but there is still different.
when sketchup install in drive c,and start with shortcut in desktop
Encoding.find("locale") #<Encoding;GBK>
when sketchup install in drive c,puts the patch file in tools folder,then start sketchup with shortcut in desktop
Encoding.find("locale") #<Encoding;ASCII-8BIT>
This different causes some error if filename uesed some Chinese character.
Does the patch file still miss something๏ผ
-
Thanks TIG worked great for me. I was unable to get sketchucation store to auto-install any plugins. I also run 2014 from a partition. This fixed it right away.
-
My error was
"Error Loading File C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb
Error: #<Encoding::ConverterNotFoundError: code converter not found (UTF-16LE to Windows-1258)>
C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:17:ineach' C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:17:in
to_a'
C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:17:inentries' C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/SketchUcation/SCF_loader.rb:17:in
<top (required)>'
C:/Program Files (x86)/SketchUp/SketchUp 2014/Tools/extensions.rb:197:inrequire' C:/Program Files (x86)/SketchUp/SketchUp 2014/Tools/extensions.rb:197:in
load'
C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/!SketchUcation_loader.rb:191:inregister_extension' C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/!SketchUcation_loader.rb:191:in
module:SCF'
C:/Users/Diep/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins/!SketchUcation_loader.rb:16:in `<top (required)>'Cannot figure out what it was about
different with alex my installation was on drive
already. OMG i really really hate using SU' extension warehouse
-
Please open the Ruby Console and copy/paste these strings +<enter>:
SCF::FOLDER
SCF::FOLDER.encoding
this should return
UTF-8
?It appears that you might have a UTF-16 based system [oriental?] and the Ruby re-encoding is failing ?
This is strange... -
Thank you for replying, the result is exactly the same with your predict = UTF-8 .
I had been searching the solution since Sketch up 2013 to Sketch up 2015 and get desperated.
Some of not working plugin
- Our sketchucation ofc - so download new plugins is a pain and well, then idk if i can use it - or not.
- TT_lib so i cannot use Clean up , it's a huge mess since then
Something had been change from SU2013 ... idk there must have been sth happened with the way plugin work or plugin folder i'm afraid.
-
TT_Lib2 needed an update to be compatible with SU2014 and SU2015. Update to the latest version and you should be good to go.
In SU2014 we updated the Ruby core from 1.8 to 2.0 which required a lot of extensions to be updated. In SU2015 we added a 64bit version which require some extensions to be updated if you where using the 64bit version of SketchUp (No change needed for the 32bit version.)
-
Since we don't have enough details to see how to fix your SketchUcation load issue... ***
All is not lost - you can always download the RBZ files from the SketchUcation PluginStore http://sketchucation.com/pluginstore and then in most versions of SketchUp [v8(M2)/v2013/v2014/v2015/...], you use thePreferences > Extensions > Install...
button to install/load the RBZ archive's contents into your default Plugins folder...
Thereafter the plugins should auto-load as SketchUp starts.***If you want to disable SketchUcation toolset completely [ so that it no longer tries to load ], just open the Plugins folder and find the loader file named
!SketchUcation_loader.rb
and add a!
onto the end of its file-extension, so it is disabled when SketchUp is started... [!SketchUcation_loader.rb!
] -
Well it's not about the plugins themselves but just sth with the OS i thought.
I had been searching solution for a long long time but cannot figure out how.
Maybe i can get rid of it getting Window 8, my laptop at work run Completely perfect.
Advertisement