Status: 

Vuo version: 

Fixed in Vuo version: 

OS version: 

  • Mac OS 10.10

How severely does this bug affect you?: 

●●○○ — It's annoying but I can work around it.

Steps causing the bug to occur: 

[Original title: Combination of Build List and Make 3D Triangle nodes fail in simple construct]

  1. create a simple build list iteration with 3D Cube node that makes list of 100 cubes.
  2. replace the cube node with a Make 3D Triangle — list fails to generate
  3. 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: 

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.

Watch screen capture here:

https://dl.dropboxusercontent.com/u/1585739/Make3DTriangle-bug.mp4

Comments

Mmm.

Bodysoulspirit's picture
Submitted by

Mmm.

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 :

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.

This is no silliness @useful

Bodysoulspirit's picture
Submitted by

This is no silliness Alastair (@usefuldesign) 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.

See video here : Revert to generic.mov

Ahhhhh… ok got it. Thank you

useful design's picture
Submitted by

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.

Thx Jaymie, for coders like

useful design's picture
Submitted by

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 :-)