I'll settle for non-live data to and from processing to start with... For example, a definition creates a group of points that I want to pass into processing to manipulate. Then I want to bring the modified points back into grasshopper for further work. If I change the original ghx points I'm happy to repeat the process, for the time being. Any ideas? Cheers, Nathaniel.
On Apr 28, 7:25 pm, damien_alomar <dominos...@gmail.com> wrote: > > I did once this very clumsy thing - script with Rhinoscript a macro > > that moves a point over and over and over again, while that point is > > referenced in grasshopper. this is a very electro-shock kind of way to > > convince grasshopper to update (i couldn't make the script stop > > afterwards without killing the whole rhino process). It was cool > > though to see some boids running around :) > > You have to be very careful when you do this as there's the potential > to get in to a cyclical reference and things will spiral until they > crash. If you have some code that connects somewhere else and changes > something, and some code within that other environment that on a > change moves that point in grasshopper (thus firing the original code > again), than one update will cause the scripts to update themselves > continuously. You can set this up so it doesn't cause this reference, > but you need to take extra steps to prevent this. Mainly, one code > cannot be fired by event and trigger the event. If you have code that > is set up to respond to events and fire code that could potentially > cause events, then its best to find a way to suspend an event while > making any changes. If after those changes, a condition is met and > you still want to fire off the original code again, then that's > another thing and you should do so in as controlled a manner as > possible. > > I agree that moving a point to fire off an event is rough, but when > set up correctly, it will get the job done. Until David offers up > something else.... > > Best, > Damien
