Grasshopper unrecognized objects problem

unhandled

#1

On Rhino5 the latest GH build is 0.9.0076, and on Beta there is 1.0.0004.

If I create a definition in 1.0.0004 and later I open it with 0.9.0076 I get unrecognized objects errors for some components.

It’s difficult to identify and replace those unrecognized components in my definition because they are missing when I open it in 0.9.0076.

Things would be more easy if they would still be there, even though they would not work. I would just replace them with 0.9.0076 ones.

Is there anything to do about this?


(David Rutten) #2

Nope, the missing objects aren’t known to Grasshopper and without them it can’t know what to use as a placeholder. At this point in time, opening files made with GH1.0 on GH0.9 is often very problematic.


#3

Yes! Placeholders would be very useful for this situations.


#4

So, at the moment there is no possibilty to downgrad files? It would be very useful to be able to export Grasshopper-Files for older versions if one works in an heterogen version environment, where not all pcs are immediatly updated…


#5

Yes, this is a problem. It would be good to have an upgrade on 0.9 just to add placeholders.


(David Rutten) #6

There will never be an upgrade to 0.9, or rather, the upgrades are called 1.0 and are available with every Rhino6 release.

This will also not be added to GH1, its far too big a new feature for a product that is supposed to be in feature lockdown.


#7

So Rhino 5 is no longer a viable platform… Either upgrade (pay up!) or be left in the dust. Sad.


(Wim Dekeyser) #8

Well, you can just keep on running RH5 if that gets work done. Just don’t expect new functionally. Is there anything in this world that doesn’t work like that?


#9

The problem is not about upgrading, I think the new version is much better.

It’s just inconvenient to go trough every 0.9 definition and userobject and “translate” them to 1.0.

So I’ll end up having R5 with GH0.9 on one screen and R6 GH1.0 on the other and check components one by one. Imagine how inconvenient is that.


#10

It also means dropping out of forum discussions as it’s impossible to follow, even when no new functionality is used in Rhino 6 - just a Multiply component breaks the code for Rhino 5, even if it’s using only two inputs.


(qythium) #11

@Bogdan_Chipara If you knew in advance which components would cause trouble ( there’s a full list over here ) it’s possible to create the obsolete versions in GH1.0 by typing the # key into the search box, although that presents you with all components (even those obsoleted many times over) in seemingly random order:
image

I don’t think you would have to do anything to ensure forward-compatibility from 0.9 to 1.0, it’s the other way round that causes disappearing components (as far as I’m aware)


(qythium) #12

@DavidRutten I wonder if it’s possible to use the GH_IO library to ‘surgically’ edit a grasshopper file and replace certain components with Rhino5 compatible ones by changing their GUIDs?

The Multiplication and Subtraction components are particularly a pain* as they’re so commonly used, I think it’s been brought up multiple times in this forum before.
If there are only 2 inputs in the newer component, would the parameter mapping be one-to-one, or is there some complication due to ZUI functionality?

*Especially so on a Mac, where there’s not even the option of upgrading to Rhino 6 yet…


#13

@qythium you’re right. They disappear the other way around.
Good advice, thanks!


(Michael Pryor) #14

(David Rutten) #15

It’s as viable as it ever was for work, if however you want to share files with the rest of humanity then the older your software the harder it gets. I’m struggling to think of a commodity where that wouldn’t be the case at all, but it is especially true of software and hardware, given the rapid turnover rates.


(David Rutten) #16

Yeah I know, it’s a major drag. The same is true for GH on Mac and Windows too, at least until we figure out how to release an updated GH1 for Mac without doing all the porting work yet again.


(David Rutten) #17

It would be possible yes, if you’re willing to build and maintain a list of required translations. Plus you’d have to figure out what to replace a multiplication component with if it has more than two inputs. It can get pretty complicated if the parameters have additional options such as expressions or post-process toggles, but it is certainly possible.


(David Rutten) #18

Yes, if GH1 has trouble opening a file saved by 0.9, then that would be a bug that requires fixing. It’s just the forward compatibility that was never guaranteed.


#19

I use GH for play. All these years, GH has effectively been in “beta”, pre 1.0, and now because of a functionally insignificant enhancement in 1.0 (multiple inputs for Multiply), Rhino 5 is nearly dead already for exchanging code on this forum. Not a smooth transition in product development.


(David Rutten) #20

There are literally hundreds of bug fixes and dozens of new components in GH1. Including some really significant stuff (like the screen scaling fixes) which all but made GH 0.9 unusable on hi-res screens.

Yes that is true. The same problem also exists for Rhino6 3dm files, but at least it’s easier to export to a Rhino5 flavour, because the data isn’t dynamic, it’s just geometry that sits there doing nothing.