[Original title: Combination of Build List and Make 3D Triangle nodes fail in simple construct]
create a simple build list iteration with 3D Cube node that makes list of 100 cubes.
replace the cube node with a Make 3D Triangle — list fails to generate
replace 3D Triangle node with the same Cube node used previously, that fails too now.
Have you found a workaround?
I surely wish :-/
Other notes
Vuo version: 1.2.1
macOS version: OS X 10.10
How severely does this bug affect you? It’s annoying but I can work around it.
This is driving me crazy. Buggy code environments are a huge turn off for me and my frustration goes through the roof because I can’t work out what I don’t know and what i might be doing wrong.
I guess if Jamie has not answered your email it is because she had no time to figure it out or test it. But a bug report here is better I guess.
I don’t think the problem here is related to the “Make triangle node”. You can switch from Triangle node to Cube and back as long as you switch them instead of reconnecting / reconnecting.
The problem appears when you disconnect the “Make triangle” or “Make cube” nodes. It seems the Build List its cache somehow appears not to be able to reactivate itself again.
Look at these videos :
Switch works :
.
Disconnect / Reconnect breaks :
So a workaround for now is to directly connect a “Make triangle” node to the Build list if you want a triangle list or switch instead of disconnecting as shown in the screenshot below.
Let’s await some feedback from the team on this Build List behavior.
good point. I can’t even get a simple example to work at all now to test if it works again after a stop & start operation. if you can get a simple loop to work, and then you make it fail, what happens when you stop & start the composition.
More silliness, when i try and replace the Make a Text Layer node with the Make a Cube node List Item port won’t even take the cable. Even if I stop the comp!
This is no silliness @useful_design as it is the same thing as Pianomatic pointed out concerning your What node am … question.
Once multiple possibility nodes have been connected to some node, it is set to that data type (Layer, image, 3D object …).
So once connected to layer, the “build list” becomes a build layer list node and you can’t connect a Cube (3D object to it).
To do so, just right click the port and hit “reset to generic type”. Then you can connect it back again.
I remember this has been discussed before somewhere. About the fact that there should be a sign to show a port is assigned to some specific data type as this can be really disturbing when new to Vuo. I have been striked too, thinking some nodes could’t connect but actually they can.
Either a way to show a port is set to specific (a color on the port) or even better, connecting a new data type port should be possible. The editor could be able to change reset it to default and automatically accept new data type.
Perhaps there is already a feature request for that but I can’t find it with a simple search.
Ahhhhh… ok got it. Thank you very much for explaining. Yes, Editor canvas definitely needs a visual representation of the various states of input and output ports if they are not able to reset on incidence of a new cable. For novices and for the convince of intermediate to advanced users. This assignment to a datatype seems to be persistent even if the comp is not running, which feels a bit new coming from QC. I’ll think about this and then feature request it when I have a visualisation in mind. Auto-reset would be nice though, so many little things in making an app polished I guess, and we all want more node sets and compile options that must take priority at this stage i think.
@useful_design ;) glad it helps. Still I don’t understand why the Build List node doesn’t fire events when a 3D object is disconnected then reconnected (the first object of this topic).
Let’s await some answer, there may be a reason we both don’t know ;)
I retitled this bug report to reflect the underlying issue. It is indeed Build List that’s causing the problem. Same happens for Process List. This will be fixed in the next Vuo release.
Thx Jaymie, for coders like myself instant feedback is a big part of the appeal of Visual Programming as it opens up more gentle learning curves in self directed learning.
‘If i do this, what happens? what about that? …ok now i seem to get it’.
If there’s niggling questions about the validity of the viewer appearance, if one is questioning the value of the visual feedback itself, it undermines one’s confidence in the process, which can escalate to frustration if one is blocked with a fundamental misunderstanding or block about the way a node works, or events and datatypes work in general. Hence my frustration the other night with this issue: a perfect storm of my ignorance about datatype persistence for some nodes with cables taken away and the Viewer not reflecting what should have been current composition state :-)
