> 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
