Plugins Not Compatible with SU2015-64bit
-
Live Ivy not working?
-
@krism said:
Re: Requirements for SketchUp 2015
That the moderators of this forum show unflagging patience in dealing with the multitude of questions which are about to appear as to why the plugins don't work in 2015.
Thanks in advance for your generous help (and repeating the help for the thousandth time).
KrisM
We try but it would sure be nice if the posters of those multitudes of questions could take at least a few moments to read the thread before they ask questions that have likely already been answered many times.
-
Seems to me that less things were broken this time around than with 2014... I'm quite pleased.
-
@krisidious said:
Seems to me that less things were broken this time around than with 2014... I'm quite pleased.
In SU2014 we changed the Ruby engine to a brand new one. In SU2015 we only added 64bit. So if you installed SU2015 32bit there should be no broken extensions. And even in 64bit only some with binaries would break.
-
NOTE:
Some plain Ruby scripts might break under v2015 - e.g. IF they ill-advisedly messed with Float by adding new methods.
The way Length is now related to Float HAS changed in v2015, so it won't inherit the new method and then the script fails because it's not defined for Length...
Of course good practice is to NOT mess with the base classes, but some older legacy tools still do !I have a separate issue with some of my Extrusion tools [EEbyRailsByFace, which uses EEbyFace looping] in v2015 64bit...
There's a BugSplat after the seemingly successful creation of geometry, as the tool exits.
I am investigating the cause, but the same SKP & process in v2014 works without any problems...
I've submitted a Bugsplat report - I can see no cause... -
Is progressbar.rb obsolete or is it still needed? or is it dependent on if a plugins needs it?
-
It would be dependent on the plugins that are installed. Some plugins such as the current version of Shape Bender don't require it anymore.
-
@tig said:
There's a BugSplat after the seemingly successful creation of geometry, as the tool exits.
Did you submit the splat?
-
Many authors have incorporated progressbar code within their own scripts - like ShapeBender, which no longer needs it.
A few older scripts might still 'require' it as a separate file - particularly Smustard.com ones ?If you don't have it installed then any affected plugins will just 'break', probably as they try to load
It can be copied across into v2015 plugins folder if needed - there is no 'updated version'. -
-
thank you...
-
@tig said:
@tt_su said:
@tig said:
There's a BugSplat after the seemingly successful creation of geometry, as the tool exits.
Did you submit the splat?
Yes: Under 'TIG' within the last hour or so...Hmm... something is happening in
SketchUp!CRubyTool::UpdateVCB
afterSketchUp!CRubyTool::OnLButtonDown
. The stack trace is a bit junk after that though. I need to dig deeper. But do you have the snippet of what the tool does in OnLButtonDown? Are you by any chance selecting a new tool? -
def onLButtonDown(flags,x,y,view) ph=view.pick_helper ph.do_pick(x,y) best=ph.best_picked if best and best.valid? case @state when 0 if best.class==Sketchup;;Edge and best.curve @sel.add(best.curve.edges) @profile=best Sketchup;;set_status_text(db("Extrude Edges by Rails by Face; Select the 1st 'Rail' Curve...")) @state=1 else UI.beep view.invalidate view.tooltip=(db("Pick Profile")) end#if when 1 if best.class==Sketchup;;Edge and best.curve and not @profile.curve.edges.include?(best.curve.edges[0]) @sel.add(best.curve.edges) @rail1=best Sketchup;;set_status_text(db("Extrude Edges by Rails by Face; Select the 2nd 'Rail' Curve...")) @state=2 else UI.beep if @profile.curve.edges.include?(best.curve.edges[0]) view.invalidate view.tooltip= db("Pick 1st Rail") end#if when 2 if best.class==Sketchup;;Edge and best.curve and not @profile.curve.edges.include?(best.curve.edges[0]) ###and not @rail1.curve.edges.include?(best.curve.edges[0]) @sel.add(best.curve.edges) @rail2=best Sketchup;;set_status_text(db("Extrude Edges by Rails by Face; Select the 'Melding-Profile' Curve...")) @state=3 else UI.beep if @profile.curve.edges.include?(best.curve.edges[0]) view.invalidate view.tooltip=(db("Pick 2nd Rail")) end#if ### when 3 ### melding profile if best.class==Sketchup;;Edge and best.curve and not @rail1.curve.edges.include?(best.curve.edges[0])and not @rail2.curve.edges.include?(best.curve.edges[0]) @sel.add(best.curve.edges) @mprofile=best view.invalidate if @rail1.curve==@rail2.curve Sketchup;;set_status_text(db("Extrude Edges by Rails by Face; Making Mesh from Profile and 1 Rail.")) else Sketchup;;set_status_text(db("Extrude Edges by Rails by Face; Making Mesh from Profile and 2 Rails.")) end#if self.make_mesh() else UI.beep if @rail1.curve.edges.include?(best.curve.edges[0])or @rail2.curve.edges.include?(best.curve.edges[0]) view.invalidate view.tooltip=(db("Pick Melding Profile")) end#if end#case end#if end#onLButtonDown
in EEbyRailsByFace.rb Tool you preselect the face and an optional cpoint, BUT then click the four curves in turn to define the profile/rail1/rail2/melding_profile [rail2 can be rail1 and profile can be picked twice too]
Much the same picking code is used in EEbyRails and that works fine on v2015 !
YES it does select another tool - EEbyFace is run after the picking, it is called in a loop for each of the 'ribs'. If one rib is processed it's OK, but if more it Splats in v2015...
-
I don't recall all the details right now, but I think I ran into an issue some time ago where selecting a new tool in the mouse event might cause a crash. I need to dig into my notes.
-
The mouse event doesn't immediately select the other tool.
It runs 'self.make_mesh()' which generates some temporary objects etc...
And in turn does some processing... and then calls EEbyFace to make the 'ribs'...And of course it has worked fine in versions < v2015 for years !
-
You suggested that jumping out of a tool's mouse click method by calling another tool can cause splats.
Although the other tool is accessed after considerable other code has run outside of the mouse click method, AND it worked fine in <v2015...I cobbled together the code from the second tool into the first problem one, and it processes everything just fine - no splats, so there MUST be some cause relating to the tool-swapping, BUT why in v2015 and not earlier versions ?
I'll use that fix for now...
-
Can you send me the original tool that splat? I'll see if I can dig into the guts of this to be sure.
-
@tt_su said:
Can you send me the original tool that splat? I'll see if I can dig into the guts of this to be sure.
I've PM'd you v2.6 which has the Bugsplat issue in v2015, and current v2.7 which works OK... -
-
@tig said:
@tt_su said:
Can you send me the original tool that splat? I'll see if I can dig into the guts of this to be sure.
I've PM'd you v2.6 which has the Bugsplat issue in v2015, and current v2.7 which works OK...So a few weeks ago I investigated a similar issue - a tool that was using select_tool a lot to switch functionality of the tool instead of using stages. Nothing wrong with that per se, but we have a bug in SketchUp where under certain circumstances SU is trying to call the old tool after it was removed from the tool stack. It's filed as an issue internally for us to look at - though a fix for SU2015 didn't make it.
When I investigated this the first time it was happening in SU2014 - so you have been "lucky" it hasn't happened to you until now. Why SU2015 provoked it in your case I'm not 100% sure, could be due to memory corruption what manifest itself differently in 64bit or simply that fact it's a new binary of SketchUp.
I personally use tool juggling in Vertex Tools, but then I use push_tool and pop_tool to nest the tools on the stack instead of replacing which select_tool. That might be one workaround to use.
Advertisement