Yes yak supports multiple versions. It also includes support for “pre-release” builds if you want.
This a test beta release to get users to help find bugs, they are probably working on this alongside their active production projects, icons will probably some of the last items updated.
Yes please use the pre release option on PackageManager!
This is a big wish. In the past, many times I had a dilemma if I should use Human plugin or Elefront. Elefront, unfortunately, has fewer attributes supported, but I prefer the Elefront way of baking. Also, Human plugin is no longer developed.
Is there a chance that Elefront will support more attributes?
good update.
time to acclerate my long-lasting baking/block mgmt project.
Hi @Czaja we will look into this for the future. As we make this for ourselves we never really use those features in our work, however I can see the value it has to others. Our primary objective is to iron out the major bugs, then bring feature parity to the previous release. After that, we will look into adding additional features. Point well noted!
Will do! One of us will probably add it to Yak over the weekend or early next week.
cool, thanks! we will check that out.
Sorry I made a mistake, the no6
file also prevents Rhino 7 from loading it. It’s for Rhino5-only plugins.
Using yak
version descriptor is probably the only correct way to do that.
That’s what I thought. I just had to ask for it.
Another thing I can’t resist mentioning is more support for the VisualARQ elements. For example, the way Bake Name works is not compatible with VA Objects. This would unlock VA potential in a big way.
Other than that, Elefront looks even more powerful than the previous version. I will let you know if I stumble upon some bug. Thanks!
Hi @Czaja regarding VisualARQ and BakeNames and the issue is on the VA side of things at the moment. There has been recent discussion on this topic here:
Glad you like it! And please find the bugs. We have a few other interesting bits up our sleeve that have been borne out of trying to make really big things that we think others will enjoy as well.
Hi @elevelle,
As I mentioned in the linked post, this issue is now fixed in VisualARQ, and the fix will be available in the next release.
I found a problem in Elefront’s BakeName feature: when the previous baked objects are deleted, there is no active undo recording, so undoing the bake will not bring back those objects. Anyway, this bug only happens in EleFront 4. It seems you already fixed this issue in EleFront 5.
Enric
@enric Brilliant! We completely re-wrote the BakName logic in eleFront 5 and have not touched it in previous versions, so the behavior you describe between the versions makes sense.
Is there a way to automatically replace EF Data Descriptions with Relays? EF became an integral part of my workflow but exporting my definitions to other people or some services like Shapediver can be problematic.
Hello again,
I’m testing out Elefront 5 again and I can’t seem to bake an object into an existing layer. But if I use Elefront 4 it works. Also I noticed features that I think need to be improved:
- Boolean toggle input for “Bake Objects” component - It’s gone. Please bring it back.
- Material attributes from “Get Rhino Attributes” - It would be better if it’s added in the outputs. Also it’s missing in the deconstruct attributes, unlike in Elefront 4.
- Materials Table w/ selector feature request - It’s actually in Elefront 4 already in the “Define Attributes” there’s an option to plug in a value list for the material. But I’m requesting a separate component for it so there will be more control for materials attribution. It’s not possible right now to plug in multiple value lists.
Elefront Bake to existing layer problem.gh (9.6 KB)
Elefront Bake to existing layer problem.3dm (777.7 KB)
Hello - yeah, Materials haven’t really been implemented anywhere in this release just yet. It’s at the top of the list.
I’ll look into the layer issue.
Regarding the Boolean toggle input - in what circumstances were you using it before? If you want to trigger multiple components at once, the Bake All and Bake Group components should provide the functionality you need. If you are trying to trigger the bake component programmatically (that is, trigger it using the boolean result of another GH component), that could cause some issues. Removing the input was the safer approach, but we’re interested to hear if there’s a scenario that requires it.
Hello, Keyan
The scenario I’m talking about is if I want to only update 1 long Definition. I usually place all my Boolean toggles at the left-most side of the canvas. So if I have a very long Definition and there’s no option for Boolean input, then I would have to scroll very far to the right just to click and bake the single Definition. Also when I cluster my definitions, I usually include the Elefront Bake component in it so I can set a Boolean toggle as an input for my cluster. Now, imagine if I have multiple definitions that depend on a sequential baking, I wouldn’t want to group all of it in a single bake. Having individual control is good, I think.
Triggering Bake while running a grasshopper player script would be another scenario requiring a Boolean Toggle.
Grasshopper player is a very good example, also for the other component.
Interact Rhino Object component could solve the problem from the first post:
The same as in Bake Objects component there is no wire input to trigger the component, and also we can’t feed the type of action (Select, Hide, Show, Isolate) other than from the popup list.
Buttons and popup lists with options are elegant, and handy to use most of the time, but sometimes wire input is needed.
Do you think that adding Deselect option would be possible?