Marissa Farrell

If you convert back to a wrapper and then convert back to an object node, does that resolve the issue? I'm just trying to see where the logic is being lost.

In this case, the reason it isn't carrying over to a new file is that you're using a symbol as your input for the profile. Because that symbol doesn't exist in the new file you're trying to use it in, it cannot generate geometry from the symbol. I'll try to get something that works the way you're hoping, but right now I'm not sure of the best solution.

@Markvl, can you attach the file(s) that you're experiencing this in? I'd also like to bring attention to the nodes "Set Closed 2D" and "Set Closed 3D" which exist in the Poly2D and Poly3D categories, respectively. Those nodes will allow you to choose whether or not your poly is closed.

Alan, The animate node that you're trying to use in this file won't really help you out. I've attached a revision of your Clock_02 file. The change I made is to the "Transform2" node (again). If you open it up and take a look at the bottom, I added the line "vs.ReDrawAll()", this line will update your drawing area with the new rotation each time the node gets run. I also edited the logic behind your sequence. In this case, we want to rotate it -30 degrees each step because we're adding to the previous location. A negative angle will move us clockwise. If we were to leave it with the sequence you were using before, the line would move in different increments, which isn't what you're looking for. Let me know if this makes sense and if you have any questions! Marissa (I'll try to get a node that will just update the view without having to append code to the node. I tried briefly for this example, but failed. )

Alan, You are right that in this case (and in most others following this example) a loop is running. There are some other obscure times where the lists could be used in a different way that would not result in a loop, but those (so far, to my knowledge) would be more rare. It's perfectly acceptable to think in terms of looping in this example. Great demonstration! Maybe at some point I can get a detailed description of what exactly is going on in this example, and provide a case where the behavior would be different. Thank you for sharing!

AH my mistake. It only works if it's accepting inputs, not with wired outputs. Sorry!

Patrick, To avoid the issue of connections getting destroyed, when you save your symbol, convert it to a plug-in object. I've found that as the best route.

Alan, Let me know if this version of the "Transform2" node behaves more like you would expect it to.

Alan, I'm aware of that issue and I almost had it fixed yesterday to post. When I get in to the office this morning I will make it my top priority to post the revised node here, and will push to get it updated for a future service pack. The problem with a chunk of our library is that it wasn't thoroughly tested, but fortunately users like yourself (and a few newly dedicated workers at the office) have been going through to try and identify which nodes aren't behaving the way they are described to. That's one huge reason why I love this community so much, we can bring to each other's attention where Marionette is still kind of incorrect in behavior, while understanding that sometimes new features (especially those as extensive and unique as marionette) have had some things slip through the cracks. The priority on testing marionette, to my understanding, was not to test each individual node, but was instead to assure that the tool itself functions as required. Our content library is so large, there's bound to be a few "oops" nodes. The other benefit to this forum is that you don't have to necessarily wait for a service pack for updated nodes, providing the issue isn't related to the actual base program. If you know there's something wrong, and it can easily be fixed, we can share that solution right here as soon as we have it. (Or even if another user has a solution!)

Hi Patrick! I'll have to probably modify the rotate node, I really don't think it behaves the way we all expect it to. For the time being, I replaced 'rotate' with a 'transform' node, and it appears to give you the results you want. Let me know if this helps/if you need further explanation! Marissa

@J. Wallace, could you post the full "error1.png" message that you get? I'm not seeing an error when I run this node. That's usually the best place to troubleshoot, but I need to see everything in that window.

I don't believe that we have anything currently implemented for that at this time. If that's the case, I'll wishlist it and make sure we figure something out for it.

In the case of the "Print List" node I was mentioning, it would only output the values from the node it's attached to, much like how the "Text" node would function. The difference between the "Text" node and the "Print list" node would only be that for the "Text" node, a new text object is created for each item of an input list, whereas the "Print List" node would concatenate the values onto their own separate lines. This isn't really a feature specific to debugging, it's just another way to view the values being transferred through a wire.

In Marionette, we have a "debug" mode, which you can activate by clicking the ladybug-looking icon in the mode bar while the Marionette Tool is active. While Debug Mode is active, if you click on a wire (it will highlight in red, if you're selecting it properly), a dialog box with all of the data flowing through that wire will be displayed. A node to print this list to a text object in the document is in progress (I just want to check it over a little more before I share it), and I'll post it here when it's ready.

Yes! That does sound like a logical method for doing this. As long as you always know what order your objects would be drawn in, I don't see an issue arising.

This is very cool, Alan! I love seeing all of your creations, you're a very inspiring learner!

@Nik, The node you're describing would be an awesome addition, however that's not something in the realm of how Marionette works (currently, at least). In a network, every input/output port is executed. There's not currently a way to just get one output port to execute the way that you're imagining it. All nodes attached to the network will run in every case. There would have to be a different application of logic to have it perform how you would like. Could you give me a more descriptive situation of what you want to accomplish? There may be another way to achieve this, but at the moment I don't think your proposed node will be the solution.

Hi! So there are a few threads that have already been started on this topic, and it's a tricky one to answer at the moment. Towards the end of this first thread explains my current knowledge of stacking order within Marionette, and links to this thread, which contains a file with Stacking Order nodes. In short, to summarize without visiting the other threads: Stacking Order does not behave as expected when in an unwrapped network, it can vary in a number of ways. This is being looked into by myself and one of the Engineers for a solution. In a Marionette Object or a Wrapper, stacking order appears to behave as intended. The second link will bring you to a thread where Stephen has posted some stacking order nodes - "Send Nodes" (near the bottom, posted on Jan 07, 2016)

Here's a network that may accomplish what you're trying to do. I moved the order of operations around. Let me know if this helps!

If you don't care about that first piece of geometry at all, you could just attach the "Path Extrude" node to a "Delete" node, but if you want to keep it and lump it into the same group as the rest, you'd have to use a "Group" node. I've been playing with grouping them, but for some reason the EAP appears to disappear, and all I'm keeping is your path. I'll keep poking around, but let me know if this helped!

Here's a place to make requests for new nodes/enhancements for existing nodes. The libraries of nodes are continuously growing and changing - either to fix inadequate behaviors that have been found in general usage, or in other cases to change the way certain nodes behave (i.e. OIP Controls vs. Input Ports for variable inputs). The best thing about Marionette Content is that, for the most part, it won't be necessary to wait for a new version to be released! In some cases, you can get new content within hours of the request - depending on how difficult implementation would be - so please report here if there's something you're looking to accomplish that can't be done with the Default Content.

This thread will serve as a 'Table of Contents'-like location for the sharing of nodes/networks that have been posted to the forum. At the moment, we have many collections of nodes, and occasionally some repeated content is being shared. My hope is to use this thread to help eliminate some of the duplicates. Below, a list of available nodes/packages is listed and linked to the original thread, hopefully a categorization system can be applied to better manage the information shared here - they will initially be alphabetized. Nodes Dialogs - Predefined - Shared by JaredM Equal - Shared by Patrick Winkler Golden Angle Node - Shared by MarissaF Hexagon Grid/Honeycombs - Shared by Patrick Winkler Light Nodes (Complete Library) - Shared by MarissaF Move to Point - Shared by DomC OIP Controls Example Node - Shared by Patrick Winkler Platonic Solids - Shared by sbarrett RGB - Shared by Patrick Winkler Worksheet Nodes (Partial Library) - Shared by MarissaF Networks/Objects 3D Grid of Objects - original shared by Alan Woodwell Animation - Shared by DomC Arch Networks - Shared by ahedley Boom Object - Shared by Stephen Sorenson Brochure Holder - Shared by DomC Cabinets - Shared by Jonathan Pickup Clock - original shared by Alan Woodwell Extrude Along Path Demo - Shared by MarissaF Fill Area with Symbols - Shared by DomC Grab Rail - Shared by Alan Woodwell Helix/Surface Along Profile - Shared by Patrick Winkler Metal Framework Cabinet - Shared by DomC Piano Key Layout - Shared by MarissaF Pyramid Shape - Shared by MarissaF Rubix Cube - Shared by Alan Woodwell Set of Casters - Shared by Alan Woodwell Skylights - Shared by Robert Anderson Stadia Seating Block - Shared by Alan Woodwell Stair Object - Shared by MarissaF String of Lights - Shared by Alan Woodwell Suction Effects - Shared by DomC Trusses - Shared by Mark Flamer Various Furniture Objects - Shared by Tim C. Usability Demonstrations GIS Shapefile Demo - Shared by rowbear97 GIS Shapefile Demo 2 - Shared by rowbear97 This list is in progress. If there are posts that I've missed that need to be added, please either send me a direct message or post to this thread and I will update as soon as possible.

Yet another revision of the Golden Angle node I created a while back. This one behaves best of all so far. I think v3 had an issue with not being the proper radius of you changed the center point. This also has a better orientation method. I hope to clean it up a bit more in the near future, but am interested in feedback at its current state. GoldenAngle_v4.vwx

My most recent understanding is as follows: In an unwrapped Marionette script, the outcome of the stacking order continues to vary. This, I believe, is because when the script is compiled, there are some variables as to which nodes get run first, which I guess somehow messes up the stacking order. I cannot get a consistent and correct result using an unwrapped network. On the other hand, if you were to create a network, wrap it, and convert it to a Marionette Object, it appears as though the results are (at least for my testing purposes) always correct, as long as you define the stacking order at the end of the network. There is another thread that discusses these cases here, and Stephen has posted a file that has stacking order nodes towards the bottom. Once we figure out a way to handle the unwrapped network case, I'll try to get a good node file together and start a new topic of best use cases. I'm just not sure how long it will be until things are all in order.

It doesn't look like you're doing anything wrong. I do still think it has to do with the Extrude Along Path somehow, I'll throw this in as a bug and see what other information I can find out, and if I'm able to get something to work, I'll post it here. I'm baffled by this and absolutely want to get it to work.