Marissa Farrell

Well if you run into any sort of reproducible case, let me know, and I'll be sure to pass it along.

I haven't seen it produce a closed poly in my testing, are you always in the same view? For 2016 we recommend always running networks from Top/Plan. You can always override that using the Set Closed nodes in the Poly categories. (Technically those nodes are interchangeable, they're basically identical in their scripts. I'll try to remember to simplify them into one later on.)

Hey Alan! The problem is that the wire going into your Divide Curve node has 3 values going into 'divs', which essentially runs the network 3 times, so it's dividing that curve into 11, then 13, then 11 again. This can be remedied by adding in an 'add list' node (from Basic Math) between the 'int' and 'Divide Curves' node, as shown in the attached image. (I would upload a file, but I'm working in 2017 primarily and exporting back could show some upcoming changes you aren't allowed to see yet ) Let me know if this helps!

You guys put a lot more work into this than I have for getting a distance, haha I usually just use the two points as input for a line (or NURBs curve) and use the length node from the object info category (I apologize if my node name/location are incorrect, I'm doing this by memory...). After I've returned the length, I just delete the line/NURBs. I guess it's the lazy in me!

Hey @dvdv! The Marionette forum can be found here And the Marionette Resource Share can be found here They're lumped into the 'customization' category on the forums list. Hope this helps!

A magician never reveals her secrets In all seriousness, I'll be more than happy to give you a run down of my tricks once I stomp out some of the work I've got going on here. I've been a little swamped with testing 2017 features/installers/etc., but I would imagine once we release I should have the reigns loosened up on me at least a little. (Not that they're incredibly tight to begin with - how do you think I learned Marionette AND Python in less than a year?!) I'll keep in touch on this

Your animation reminds me of a Python script I worked on last fall - but my script animates along a path. I've been working on optimizing it for Marionette, but haven't had the time to complete it. Here's a video of the output if you're interested. (Please ignore at the very beginning - I used the freehand tool to draw my path and didn't clean up the sharp turns...) Also, please ignore how terrible the model is, it's a mockup of my apartment that I never finished. I promise, my television is not on the floor and I have more furniture/appliances than this...

I still stand by what Will quoted. It's being looked into, but I don't think enough progress has been made to say it's coming any time soon. Basically, the issue is that the OIP fields are only generated when you edit a script, not when you run it, since they're defined in the Params class. We can't push information there to update when the script runs at this time. I don't know what kind of backend work would have to go into it.

The original intention was for Marionette to have a 'mirror' node. Unfortunately it didn't make it into 2016, and since it was backend work, I had a hard time resolving it. (We can't fix/introduce API stuff between versions, to my understanding, due to the possibility of introducing bad code.) This should be resolved in the near future, which should then allow you to mirror the components within your Marionette object (and hopefully get rid of the current limitation you've encountered) As for mirroring a Marionette Object itself on the screen with the Mirror Tool, honestly, it could work. I haven't tested it, therefor I wouldn't recommend it. I'm not sure how VW stores a mirrored state of an object, and my thinking is that if you were to mirror an object, then change a parameter in the OIP, it may regenerate only parts of the object, or it would completely redraw the whole thing - if it redraws anything in a non-mirrored state, it would no longer look like what you intended. I could be wrong though, it could work regardless, I just can't imagine that we store a mirrored object the way that Marionette Objects would need to be stored. My suggestion is to wait it out until the Mirror node is working properly and then use that within your Marionette script to mirror your objects. (it will take in the handle to an object and two points of a line of which to mirror over, similarly to how the current Mirror Tool works.) Or again, once you have your Marionette object looking how you'd like, you can then ungroup it (which will detach it from the parametric script) and mirror that object instead.

The dots refer to how active you've been on the forums. (i.e. how many posts you've contributed) I agree that it looks misleading, but if you check out your profile it may help clear things up.

Currently I'm not sure that I would advise mirroring a Marionette Object - since it's generated by a script, I think that any adjustment could 'reset' it and revert it back to a state you didn't desire. What you COULD do, if you're 100% on mirroring it, is 'ungroup it' (which would detach it from the Marionette script) and mirror that (which would currently eliminate the parametric parameters for it, unfortunately), but it should certainly allow less mishaps when mirroring/duplicating/etc. As for duplicating Marionette objects - I think there may still be some logic missing on the back-end there. I looked into it for a while a few months ago because the object wasn't being generated properly (specifically using 'move by points') so, again, I would suggest 'ungrouping' the object before duplicating it (I know, it's not necessarily ideal... but it would also make your filesize smaller... )

I haven't had much time exploring the best practices when using a script exported by Marionette as the script for a plug-in object. I'll do my best to revisit this after release. Things are pretty hectic internally right now.

That alert often means that you're trying to ungroup a plug-in object. For example, if you were to insert a door into your drawing and attempted to ungroup it, you would encounter that error. I would guess that your network may be using a command that creates a plug-in object when you encounter that error using your modified ungroup node.

Hey Alan! The reason the Marionette script always results in a group is so that when you re-run the network you don't end up with duplicate objects. The group created by Marionette is directly associated with the network. The change you made may cause problems in the end. Say you wanted to change your base shape, by altering the ungroup node, you will now end up with 2 pillar objects instead of replacing the original one. The best practice is to manually ungroup once you're satisfied with your results to detach your object(s) from the network.

It's not really feasible for a Marionette object to run on selected objects because you'd have to select the Marionette network to run it... The criteria you can use for the Objs by Crit node is here: http://developer.vectorworks.net/index.php/VS:Search_Criteria http://developer.vectorworks.net/index.php/VS:Search_Criteria And as for creating/deleting classes/layers, I know for sure you can create them, and I'm also pretty sure they can be deleted as well with our default content EDIT: Confirmed. You can delete the layers and classes using the Delete node if you pass their handle into it (which you can do using the "Name" node in the input category.)

Kevin covered most of what I was going to answer initially when you started this thread. I just wanted clarification before I gave information that may have been irrelevant to what you wanted I believe all of these things are already possible with Marionette. I'd be more than happy to try to go over all of these cases in the near-ish future.

Could you please elaborate on this? How would you like to determine which objects are selected? How would you like to manipulate them? I'd like to help you with a workflow for this in Marionette.

I tested with both the polyline and freehand tools, both sticking to my initial results of drawing to the left when negative, right when positive. I've also tested by 'reversing' the polys and get the same results. So there must be more to it. I don't know what determines the sides.

That's funny because I'm seeing different results here. (Which is why I'm holding off on it )

Currently the orientation for Rectangle is in vector form, I know, it's not ideal. It just hasn't been updated yet. You'll want to use the Vec2 node for orientation. We're working on a better naming convention for the ports to show right on the node what type of variable needs to be wired there/is being wired from the port. Unfortunately, because of the way descriptions are stored/queried from the object, I don't think we can do a contextual menu item with the description. I know many changes are coming with resources in general, and I'm working with some of the people on the platforms team to come up with a better way to display descriptions. The reason the error points to the rectangle is because that's where the script is failing. The rectangle node houses the script to create the rectangle, and because it's receiving an incorrect variable type, it's the one kicking back saying "Hey, you wired something wrong to me." If you want to see the code for the node, just double click on the node. It will bring you to the "guts" of the script. Unfortunately, currently the line numbers returned in an error are misleading. How Marionette works in the end is that it compiles the entire network into a singular script and runs that instead, so those line errors could be pointing to something there OR they could be pointing to functions in Marionette.py which exists in your Application folder, if I remember correctly. If you're interested in seeing what the Marionette script compiles into, if you right click on your network you can select "Save Marionette Script as Python Script" and that has the script the network uses at the end.

Hey Kevin, I'll have to think of the best way to word things, but yes, I can work on making that change. There are other cases with the offset node - in your case, it seems you're talking about closed polys. It's always important to also consider open shapes - like an "S" shape, I want to believe that it follows the negative = left, positive = right, but I don't want to be incorrect on any information before I share it, and I need to think about cases like 'What if the "S" is rotated 90 degrees?' I can certainly, for the time being, work on including a note for closed shapes.

You can use the "Any" node which will evaluate the input you give it and assign it to a variable type chosen by Python. It's USUALLY pretty good at determining the best type to give something, however there may be some mistakes occasionally when using numbers that you want to be strings.

The set layer node is kind of a pain right now. If you want to update the list to show the layers you have in your document, I believe you have to open the script of the node, close it (you don't have to make changes), run the network again, and at that point the OIP control for the set layer node SHOULD have your actual layers in it. If it doesn't work the first time, follow those steps again. Let me know if you still can't get it to work after that.

Hey Alan, 2016 doesn't have the capability of radio buttons for Marionette, but I put in a strong request for them to be added to the possible OIP controls. I suppose you'll have to wait it out and hope they make it into 2017

Hey guys, Sarah and I were talking this morning, and I figured it would be a good idea to share some alternative nodes for Classes with you. In the attached file are 2 nodes. Class Name - this node will allow you to choose a class in the OIP and will output the string name of that class. It can be used in conjunction with the currently existing "Set Class" node. Set Class V2 - This is a modified version of the existing "Set Class" node. Instead of passing a string name into the styleClass port, the OIP control will define which class the object goes into. NOTES: 1) The current Set Class node that exists in the default library is located in the Attributes section, in case you're looking for it. 2) When setting the class of an object, that class will NOT be applied to the group which the object is created in. (Reminder - this group is created so that when you re-run the script, the old objects get replaced by the new objects.) If you enter the resulting group, the object inside will have the class applied to it. AlternativeClassNodes_MFarrell.vwx