old behaviour (< 35.1) was: receive node will get red when selected sender is missing (renamed or deleted)
since 35.1 : node just shows NIL as receive string but wont turn red.
→ harder to debug. also sender renaming is hell when you dont remember where you placed the according receives in your project…
sr_not_red.v4p (2.0 KB)
under investigation. Thanks for reporting! Also good to hear that red enums are actually perceived as a feature in some rare cases… ;)
To me red Enums have not only been
- early warning signs with S+R problems,
- a visual hardware list that auto-checks all the devices availability
- a project’s life line when upgrading to newer versions, especially with diffff.xml absent or incomplete
- restless guides while refactoring patches with vvvv-Message
There I say it: They are not only “a feature in rare cases”. When red, they visually highlight that some user-based patch assumption has not been met, or said differently, they spell out the name of an expected item that is currently not available on your system.
thanks velcrome for your assuring words!
we’ll work hard to get your nodes red again.
when touching that code… maybe it would be possible to sort the enum lists alphabetically!
upcoming alpha comes with these changes:
- bug fix: invalid enum entries get red again
- s/r channels sorted in pop up
- r nodes don’t forget last sender even when sender got deleted
- ex9 effect: shader technique not red even when null
edit: alpha is up
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.