if (execute)
{
// Find the component
foreach (GH_DocumentObject gc in GrasshopperDocument.Objects)
{
if (gc.Name == "Insert Block")
{
var comp = (GH_Component) gc;
// override its button state
var prop = comp.Attributes.GetType().GetField("_butdown", System.Reflection.BindingFlags.NonPublic
| System.Reflection.BindingFlags.Instance);
prop.SetValue(comp.Attributes, true);
// run its "magic" located in the AfterSolveInstance method
var meth = comp.GetType().GetMethod("AfterSolveInstance", System.Reflection.BindingFlags.NonPublic
| System.Reflection.BindingFlags.Instance);
meth.Invoke(comp, new object[] { });
// recover its button state
prop.SetValue(comp.Attributes, false);
}
}
}
Just as a sidenote, this plugin is not really doing much except attaching blocks to the RhinoDocument, it might be a better solution to just directly doing this. However for the fun part⌠Be aware that the double click functionality is not included in that scriptâŚ
Thanks so much Tom, this solved it. I can now trigger both Insert Block components from one place!
One thing I noticed is that since Instance Manager also changed the name of the component from Place Instance to Insert Block, even after the update the component kept its old name till it was replaced.
So it seems that between updates of a plugin certain aspects of a component get updated, while certain others remain. Weird.
In think you need to make sure that this script gets executed after the block insert component has been computed, otherwise it might take the old state or does nothing. This is a bit tricky but can be solved in native grasshopper. Just make the flag pseudo depending on the output of the block insert component
I agree. Banning is not the right strategy. But giving clear guidelines to developers is. There is no benefit to adding a button to a component, but there are drawbacks. The developer probably didnât realise this, which is why guidelines/best practices should exist.
But if there were guidelines, there would be quite a few grasshopper-native components that would violate those (image sampler for example), which is probably why no guidelines exist in the first place.
I am right now not using Instance Manager any longer. The lack of support with a lot of things still unfinished didnât make it feasable to still keep using it. Itâs a shame, but of course I am grateful for all the hard work Amin had put into it.
Funny you should say that because I just solved my old head-banging problem with this plugin which I got to know thanks to you !
I have essentially 2 layer blocks :
Main block ->Sub-Blocks->(one)Solid
I need the sub-blocks instances to be of the same layer than the solid they contain.
At last, I managed to do this with just a few âInstance Managerâ component that feed a Human âModify Object Attributesâ component.
The later inputs Guids , which is what the âInstanceDecomposeâ component provides, contrary to Elefrontâs strange object type, and contrary to Human who doesnât recognize sub-blocks as objects that can be referenced.
Iâm happy to see Iâm not the only one struggling with blocks in GH ; I sure hope @DavidRutten has something in store with blocks in GH2. For all the eye-satisfaction the fancy UI will give, it doesnât pay the bills.
I think Apple has very strict guidelines for its free apps. I donât think I find it delirious. Itâs reasonable. Not only because of security but also in terms of user experience.
If my phone gets infected because of an app on the Apple Store, its Appleâs fault.
David should control this stuff, in pose of a better user experience but also in terms of security. A plug is free, but it is still Rhino and Gh.
A quick example that recently was discussed here was about the Bifocals plug in forcing itself onto oneself, as it appears even when you have not installed the plug in.
There should be some sort of control over these things. And yes, those include things that are allowed and other that are not.
If a plug in is giving people a headache, Mcneel should reach out to the developer and say something like:
âHey, this tool you are offering is great but many people are complaining about X. Here at Mcneel we defend our users and we want them to have the best experience possible. Your plug in is attempting against this as it is creating great frustration by opening new possibilities but only going half way (not possible to automate). If you want your plug in to continue being part of GH, we advise you to change this. We prefer to stop offering a tool that creates expectation and disappoints the user altogether despite its small benefits in its current state.â
Mcneel should do that. Asking the user to do that feels delirious to me. This is their job. Not mine.
Yes. The potential for a truly malicious virus embedded in Grasshopper scripting components has worried me from Day 1. Virtually everyone who shows up on this forum, including myself, are offered a C# âsolutionâ by a certain enthusiast and unwittingly install it before realizing A) how utterly useless it is and B) the potential danger of doing so. The fact that scripting is so highly encouraged and frankly necessary to fill in gaps in GH functionality means we are all at risk from any GH file we open.
Bifocals demonstrates the ability to completely hide a component on the GH canvas. If not for its merely annoying labels, you would never know itâs there. That potential virus vector scares me.
You have to install C# solutions? They are mostly in the forum of the script component. Unless you mean Food4Rhino plugins in which case they can be c#, vb, python or a mix.
I am not against guidelines or quality control, what I am against is imposing a way of operating. If I, as a developer, want to not allow to automate a function, because there are reasons, and I want to force it to be used by click, what is the problem for you? I think itâs deliruous because youâre telling me, you canât develop it like this, you have to let me loop your functionality, no matter if you work for free.
Do not try to take the problem where it is not, making components dependent on the interface does not go against the user, it simply does not give you all the functionality. You should be grateful for what they share, not complain because they donât give you everything. Itâs delirious.
If you donât like it, donât use it. You have no rights if they give you the stuff for free, the developer owes you nothing as a customer/user, McNeel does not, because you have chosen to patch their software, not them.
As far as I know, when you upload something to food4rhino, you have to wait for the plugin to be validated. I donât know what kind of control they do, but something they already do, I guess to protect the users. In 10 years I havenât seen anything related against the users by GH plugins.
This experimental ecosystem, of amateur plugins, is what allows so many plugins to emerge. If you put demands like âit canât be a bad plugin, ban itâ, you are putting doors to the field, and you will stop seeing so many free animals.
Dani, I am pretty sure Apple does this. You just canât develop anything the way you want and expect it to be approved because it is free and people decide to âpatchâ and enhance their phones.
I see we are running into a fine line though: âGuidelinesâ, in a strict sense, all they are doing in fact is saying âyou canât develop it like thisâ.
Maybe the specific example of the thread, menu options vs boolean is not ideal. Forcing the developers to always use boolean might seem too much. Maybe not. I honestly believe it goes against the very sense of what GH is and what it is useful for.
Anyways, rest assure that there are many other things that canât and shouldnât have such flexibility.
David himself said he dislikes them:
Do you think David does not have the right to force developers into never using menu options for GH components? Of course he has.
And maybe, if enough people complain, David ends up doing just that. But if no one ever complained, as you say, we donât have the right to do so, David would have never known about his users having a bad GH experience because of a plug in.
If I were a developer, I would be extremely concerned about how plug ins are affecting the user experience of MY users. Suppose I do everything as perfect as I can for everyone to LOVE GH, and someone comes, releases a free plug in, with horrible icons, with components that take too long to calculate, with inputs that do not work, with no messages to know what failed, etc etc. All my work is ruined because of that.
You might think, âyour work is not ruinedâ the user just has to uninstall said plug in.
Sure, but he had a VERY BAD experience using GH. That is the only final outcome that matters, and it was all I wanted to avoid. So, it is MY job to avoid that, not the userâs job. I should protect MY users from this kind of stuff.
But where is the limit? Someone shares a shitty plug in that frequently fails. Should we still say âthank youâ just because it is free?
Someone gives you free food, you taste it and it is horrible, do you still say thanks and eat it?
If I receive a free washing machine, go through the trouble of moving it, making space for it, setting it up, installing it and try to use just to find out it does not work I will surely complain as anyone would. Moreover, if it works but cleans my clothes very poorly, I will surely complain and say âThis is shit, I need to wash my clothes 3 times with this thing for them to be actually cleanâ. Even more, I will go to the manual to try to fix the damn thing just to find out it is in Chinese! At that point I will be looking for a hammer to the destroy that piece of junk and throw it out and curse the guy that gave it to me and made me waste all my time. Same with plug ins.
Going back to the Apple Store, it is called the Apple Store for a reason, it belongs to Apple. This means, it is Appleâs job to supervise it. You are telling me users should supervise Appleâs store instead of Apple? Why do you find it delirious that Apple supervises itâs store?
Mcneel should supervise its store too. Food4Rhino in this case. And they actually do! Because it a service by Mcneel.
So like I said, is it their job to keep that place tidy, not the userâs. Users should not go around administrating the Food4Rhino site and chasing developers around to fix their stuff, to actually offer what they claim to be offering, to create tutorials or a how-to explanation, etc. This is Mcneelâs job.
Free plug in out there, no explanation how to use it.
âHey you, user! First say thank you, and then mail the developer to see if they are so kind to explain how to use the plug in.â
No. Mcneel should enforce at least a short âhow-toâ explanation on every developer.
Sure, this has allowed this kind of stuff:
Free wild animals are not good. For an animal to be free it needs to be domesticated first, if not, it will do what wild animals always do.
This discussion is hilarous. Even installing Rhino is a potential security risk. But besides this. Anybody uploading a gh file could potentially place malware inside. Now people complain about its risk, but people here also complain if you not provide a ready-to-use solution. People basically ignore if you provide a text written answer to a forum thread.
If you ask for a motivation why people offering C# solutions then this is actually a question I frequently have asked myself the last years. My initial motivation was to learn for myself when finding solution for others. I was kind of bored from the inital problems and was looking for challenge. Did it pay of? On a technical standpoint yes⌠from career point of view, it depends! But at least better then investing time on playing computer games or collecting stamps.
This is not an argument for or against, just wanted to point out for what it is worth that there is virtually no difference between Grasshopper and other user made Grasshopper plug-ins (except some few which require other external .dllâs), aside for the skill of the coder (and potentially the intent). They are .ghaâs made in the same way and format.
See here you can find the .gha plugins that make Grasshopper:
Additionally about providing tutorial explanations, I would say that for the most part user made plug-ins have more tutorials than Grasshopper itself provides out of the box (most GH tutorials are from users also). In my plug-in I provide many tutorials, but I will say it is the worst part of developing (aside form making icons), it is very time consuming, but I do it so I get less email questions .
At the end of the day, you could always avoid plug-ins which have bad ratings and poor comments on their download page.
Again, this isnât to say everything is perfect, just pointing some things out as everyone here seems to make some good points in some way. (Also I know @Dani_Abalde has a strong stand point on âyou get what you get for freeâ but he is one of the ones who makes very well done plug-ins )
True. Documentation is key, I had to learn this (for other projects). But if you need to explain to people what a tween surface or blend surface is, then you targeting the wrong audience at all. At least this was when I really lost the motivation writing plugins.
What is a good plugin, on how does a rating expresses this? Solving a technical problem for maybe 10-50 professionals or writing a plugin helping 20000 students solving their lab projects? With a certain expertice you indeed can taylor made your own functionality with no need to use any plugins and anybody should do as much as possible by him/her self.
I think here lies the crux of this specific problem âbecause there are reasonsâ. The problem was/is that I donât know what those reasons were, as they were not explained anywhere, even after I asked many times. The fact that it was changed from having a trigger to having a button and no trigger happened between point updates with no reason given. The old version was buggy and the new version, which didnât have the bug, had the new paradigm of using a button.
Thatâs how all this started.
Of course I am grateful for the work that went in, but its still frustrating to be investing a lot of time in redoing everything for a specific plugin only to find it is buggy first and then upon updating that the whole patch breaks. Thatâs 2 full days of work down the drain and of course that is frustrating - no matter if it was free or not.
Even free stuff is not free from fault, which is why open-source things exist. Itâs a way for everyone to pitch in with ideas/help. Not because we donât appreciate what has been done, but because it serves everyone to make it better.
I would love to discuss or find out the motivations directly from Amin who wrote the plugin, but unfortunatley it seems like he is not active on any forum or replies to emails or comments on food4rhino.
Apple has nothing to do with this. It is the most hermetic and avaricious software company and the only thing that can set an example is how to do good marketing. They steal a lot of money from application developers, so it makes sense that they control it. But even so, I donât think it forces you to use design patterns. And the free applications, 99.99% of them, earn money with advertising or similar. Nothing to do with this.
Youâre confusing guidelines with rules.
Thatâs what Iâm talking about, and the reason for the thread. SoâŚ??
No and yes. GH is what it is because itâs visual and an editable interface, but I agree that it breaks GHâs potential. But I donât see a reason to ban it.
Even if McNeel banned a design pattern (which they wonât), they couldnât stop someone from developing graphics that are supported by their graphics engine. At most they could ban it from their download page, but itâs so easy to avoid this inconvenience that it wouldnât mean anything.
I didnât say you canât complain, I said you have no rights as a consumer. To say that McNeel is responsible for third party plugins is to say that they are responsible for the use people make of this, and by license agreement, they are not. They have enough on their software to worry about the rest.
No dude, wtf? Do you fault Android or Apple for having a bad experience with an application? I, as a consumer, look at the developer and put him on my blacklist, Iâm not going to hunt down witches. Iâve tried shitty GH plugins and I never thought it was GHâs fault. I see the developer and distrust him in the future.
If a friend helps you and you canât use his help, you thank him or tell him to fuck off? Iâm surprised at this attitude. The price of giving away your hand is that they ask for your arm.
Thatâs okay if you pay for the washing machine or the plug-in. If you find it on the street, normal people donât complain, normal people think it was on the street for a reason.
No, Iâm not saying that. I told you before that Iâm not against control, Iâm against prohibition, thatâs all. Apple has nothing to do with this, or do you want to see advertising in the plugins? His business has nothing to do with this.
Welcome to internet, learn by yourself!
Pay the developer to do tutorials or documentation, Iâm sure theyâll be happy to do so. And yes, you should be grateful for little or incomplete help, not talk as if they owe you something.
And so it must be, free. If you donât want to get bitten, donât play with wild animals. No need to kill them, donât go near them. In the same way that you donât download software from a random website, but go to the official website, donât download plugins from random authors and only from those you know.
Your two lost days are less painful than the weeks lost making a bad plugin.
Even if it was a bad decision for him, it doesnât change anything. What if a developer wants to limit the functionality by using buttons on the interface in a free version of the plugin and you pay to have it all? All this discussion goes against encouraging third party developers to create for the community.
Two days is nothing compared to years of work in R5 that was effectively lost in the transition to R6. Complex models are so severely broken that each one can take days to repair, meaning only a select very few are worth the effort to salvage. Thatâs a very big deal to me and I expect it will happen again when R6 has run its course.
It has already been pointed out that a number of standard GH components have UI features that cannot be controlled parametrically, like Image Sampler and Gradient for example. Still, a case can be made for creating clusters with have UI elements and/or donât work properly with data trees. I wonât make it now but draconian enforcement of a policy against such things isnât the answer.
Well, thatâs not entirely true. Terminology and good description (documentation) is key. For example I am a naval architect, and I may benefit from some architectural or civil engineering techniques that havenât yet entered the tools and approaches I usually use. We have a very stagnant industry that very hardly allows new technolgies. I need exactly the definition of the tool and the method it uses in order to understand if it fits in my cases. Although in many (most) cases an user tries without reading and reaches to âIf everything else fails RTFMâ still itâs good to have such âManualâ.
At this point you are just way too stubborn Dani, I will not continue this any further and I will let you have the last word if so you wish, but I will say this:
Rules exist everywhere, whether you like it or not. Developing is not exempt from rules nor are developers, and even less, developers who develop for another main program, in this case Rhino. You need to follow the rules.
Your claim for total freedom borders the ridiculous. Rules exist for a reason. A plug in developer canât upload his plug in to Foo4Rhino in any format he wishes to.
See? That is a rule right there. There is nothing wrong in asking for two or three more rules.
PD: I recall a wild Panda was killed in Food4Rhino.
.