'Brep Closest Point' GUID mismatch

bug

(qythium) #1

The ‘Brep Closest Point’ component in Grasshopper for Mac has GUID 4beead95-8aa2-4613-8bb9-24758a0f5c4c, whereas the same component in Windows is cdd5d441-3bad-4f19-a370-6cf180b6f0fa.

This causes files created by the Mac to be unrecognized when opened on Windows:
unrecognized


(David Rutten) #3

I’m confused. Both those IDs are known to Grasshopper on Windows, one represents the old component, other other one (the one you posted first) the new component:

Can you upload a file you saved that fails to open on Windows?


(Laurent Delrieu) #4

On Windows have you rhino 5 or 6?
Brep closest point is not the same between gh0.9 and gh1.0


(qythium) #5

Ah yes, it appears to be a Grasshopper 0.9 - 1.0 compatibility issue… somehow it escaped my notice that the mac version of the component had an extra ‘N’ output parameter. :sweat_smile:

I had mistakenly assumed that the .gh files produced by Mac Rhino 5 and Windows Rhino 5 would be cross-platform (our organization won’t be upgrading to Rhino 6 licenses any time soon)

Is there a complete list of such components that have been deprecated between versions 0.9 and 1.0? As it stands, a file with a GH1.0 ‘Brep CP’ component completely breaks the definition for someone opening it in GH0.9, leaving no trace of where the component or its wires were connected.


Keep Rhino 5, or upgrade to Rhino 6?
(David Rutten) #6

There is no central list I’m afraid, and this same problem of course also happens on files written on Rhino6 on Windows, or whenever a file was saved using a plugin which is not available. This is very annoying and there’s no solution for the time being.

You can always try and replace a new component with an obsolete one whenever someone tells you your file doesn’t open. You can access obsolete components by typing a # into the double-click-pop-up first:

ps. if you were to consider upgrading soon, you can probably get a much better deal now than later.


(qythium) #7

Thanks, that ‘#’ trick is just what I was looking for! (was about to point out how dragging GUID strings into the canvas doesn’t work on the Mac version)


#8

This sounds terrible! But I’m confused. @qythium, if you are using Rhino 5 on both Windows and Mac, how does GH1.0 get into this picture?


(qythium) #9

Somewhat confusingly to me, Mac Rhino 5 ships with GH 1.0.0004, which is lacking ( catching up) in a few features compared to the GH 0.9.0076 version that comes with windows Rhino 5. This is the first time I’ve encountered a compatibility issue going the other way !


#10

What a mess! Not just two but three different incompatible versions of GH? :disappointed:


(Steve Baer) #11

GH for Mac V5 is not 1.0. It looks like we may have messed up the version numbering scheme in the latest Mac build, but I can assure you that version of GH is based on the version which is available for Windows V5 (0.9)

I’m still a little confused about how this GH definition was created. Was this made entirely in V5 for Windows?


(qythium) #12

It was created in RhinoWIP 5.4 (5E397w) for Mac, and subsequently opened in Windows Rhino 5, where the error occurred. The stable release 5.4 version for Mac also appears to have the new BrepCP component.

Here is an example:
brepCPs.gh (8.3 KB)


(David Rutten) #13

Yeah me too, I thought that there was no code-flow set up from the Rhino6 GH component repository into the Mac one, so the Mac shouldn’t have had access to that new component. But I wasn’t sure.


(Laurent Delrieu) #14

Here is a sort of list of new components


(Steve Baer) #15

Maybe we branched for Mac after you added the ‘new’ version of a component. I’ll have to check


(qythium) #16

Thanks! I checked, and out of that list only the Brep CP and various Jackalope (morph) components are present in the GH for Mac version.

And here’s what it looks like when opened on Windows V5
image


(Steve Baer) #17

Ok, that proves it. I must have started the GH for Mac project based on Windows code after David added a few new components. Not too sure what to actually do about this. It is the first I’ve even heard of it being a problem over the last couple years.


(qythium) #18

Just another comment: the reason I was initially confused and thought this was a bug was the ? ? ? in the error dialog, where there would usually be useful information about the plug-in details.

Perhaps a default placeholder text saying something like Could be a component from newer Grasshopper version would help in that respect?
(especially for very common components like Multiplication, which I see has been upgraded too)


(David Rutten) #19

Since this dialog was designed to show missing plug-ins, it doesn’t know how to handle missing native components.


(qythium) #20

Yeah I understand that, it was just a small suggestion from a UX point of view to include a word or two about possibly native components being missing due to upgrading / deprecation

I can easily imagine someone new to GH creating a simple definition like


in GH1.0, and sending it to someone else with GH0.9, who would see that confusing dialog and come away thinking the file was corrupted ( not knowing the same-looking multiplication component had been changed )


(Steve Baer) #21

That would require an update to GH 0.9