Marissa Farrell

Another note, the file must exist in this directory from your user folder: ...\2016\Libraries\Defaults\Marionette That is where the Marionette content will be pulled from.

Do you have the "Convert to Plug-in object" checkbox checked in the "Symbol Options" dialog in the file where you have the wrapper saved? That would be my first guess. If you don't check this option, the wrapper will be imported as a 2D Symbol, which won't allow you to run wires to/from the ports. If this isn't the solution, please describe to me what exactly you're seeing so I can help you troubleshoot further.

Sorry I didn't get back to this sooner, it fell off of my radar. This isn't the most efficient way to do this, but I've attached a file that demonstrates one way you can accomplish this. I don't think we have anything else set up at the time. The record attachment/modification takes place on the script level. Notice that the script inside of the Marionette objects is stored as a symbol so that you can modify the OIP controls to produce different objects while still retaining one master script. In this script, I've attached a record format to the handle of the PIO (using Parent PIO - note: I don't think the one that is currently shipped with VW works as well as this variation, which I stole from Robert Anderson's skylight demo) and then created/updated fields as desired. Please let me know if this doesn't make sense, it's the only method I could think of.

Jim's example is very complex, and not currently how things are set up, but it's being looked into. I'll venture to say that locating and replacing a texture is doable, but I haven't actually tried it out. Searching folders and being prompted for shader properties is a maybe at the moment. I think I began looking into it, but didn't get as far as I wanted to... and then more projects came up. I can definitely re-explore, textures are pretty complicated within Vectorworks, though, so I'm not sure as to how detail specific we can get. It's on my list (again)

Art V, The named objects are the slabs, which in this case allows the script to query which layer each slab exists. This was just for demonstration purposes, there's absolutely a way to avoid having to use named objects, as long as we take the correct logic into account. As for moving the object, I'm not sure why it breaks because how the node is supposed to work is it makes a duplicate of the object you're moving, essentially "pastes" a copy to the layer you want it to be on, and deletes the original. Again, there are ways around this method that should work (and the breaking that takes place only means that if you were to rerun the network, you may end up with more objects than intended - in most cases when you rerun a network the objects get redrawn each time which leaves no duplicate). You can absolutely create as many variants of objects as you want. It's really all about the logic with creation. For my example, I just created a rectangle at one of the corners to extrude it, but you could do anything, really. I'm more than happy to guide you in the right direction when/if you get stuck, if you want to continue exploring this.

We've encountered this error a few times because of a custom plugin having a UUID collision. Do you have any custom plugins installed? I can't remember which one has been the problem exactly, but this post also mentions the exact issue. https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Main=44155&Number=221688#Post221688 If I find the information I'm missing currently I'll post it here, otherwise maybe someone else can lead you in the right direction. I'm 99% sure this is the same issue.

In short, yes. I'm attaching a simple file to hopefully demonstrate. How this works, it takes Slab1 and Slab2 (by name) and returns which layer they reside on, it then takes the Elevation of each respective layer and uses those as the inputs for the extrude. It then moves the extrude to the layer of the slab above (in this case, Design Layer-2, where Slab2 lives) There are many other ways to do this, I'm sure, and now that it's been brought to my attention, I want to create a better set of nodes for this operation (such as taking into account a negative thickness of slab, etc.). I'll post back here if/when I make progress on them. This also has enlightened me to the issue where if you move an object between layers it loses its connection to the network... meaning you can find yourself with many duplicates and not even know. I'll try to look into that further since the steps I usually take to fix that didn't work. Let me know if this helps or if you need any more guidance.

My main question is why would you want to name more than one field in a record the same thing? I do notice that you CAN have multiple fields with the same name if you edit your record from the resource browser, but I'm just stuck wondering what good that would do? Secondly, if you were to use Marionette to extract the information from a record field, you would choose the name of the field, and if you have more than one with the same name, how can you be sure you're getting the right information? I'm not sure if this points out an issue with the node, really, because I can't personally see a use case for this to be available. Can you enlighten me as to why you want this to work? I can take a look into it, I just need a better grasp on the workflow.

For your case sensitivity, you should be able to use .lower() to kind of bypass it. example: in the "Is In" node for x in list: if substr.lower() in x.lower(): res.append( True ) else: res.append( False )

Actually, nevermind. This might work. I updated the Control Geometry node in the script symbol to include some extra lines of code. Let me know if this works for you, because I don't see the issue appearing anymore, but I may just be missing something.

I've been actually working to solve this problem for a while now. I first encountered it when I was playing with my Stair object, although in that case it was due to a convert to NURBS. It does have to do with being in Top/Plan vs. a 3D view. I think we tried what fixed some other situations to try to handle this, but it hasn't worked out as expected. I'll take another look into a way to solve this. I'm thinking in the direction of saving whatever 3D view you're in at runtime to a variable, and then changing to top/plan for calculations, and then resetting back to your custom view. I've just been trying to avoid that since there should be a better way.

This is a known issue that also bothered (still bothers...) me. I believe it's a high priority on our list of things to solve, hopefully we can implement it sooner rather than later. Be assured we are working on it either way!

We've actually started talking about encryption of Marionette recently, but there are a lot of things to consider. Right now, Marionette is very much open source, and I think it's important to keep that element for a handful of reasons - it makes it such a valuable learning tool for one. I have my own opinions on how encryption should be handled - I think we should definitely offer the option to encrypt or lock objects, and possibly wrappers as well, but I really don't agree with locking nodes. I think it's important for safety concerns (since it's all written in python) and I'm a big advocate on learning by example - being able to see the script inside will allow more people to become proficient in python as a language and it will help to teach elements and concepts of use cases for Marionette. I'm sure other people who work on Marionette with me don't share all of my opinions, so I really couldn't tell you which direction things will go. If we do take the route to encryption, it won't be until after at least another version. We're working on a lot of exciting improvements for 2017, and I don't know if we would be able to throw another large task into 2017 (but again, I don't know). I'm also uncertain on how difficult it would be to implement. So in short, I wouldn't hold my breath on it, but there's a chance that in the future we'll get something added in.

Yes! Please let me know if other nodes are affected/show the same issue. I'm trying my best to make our default library as consistent and accurate as possible.

Sorry Markus! This accidentally fell off of my radar! I looked at your file and failed to see where you're using a "Objs by Crit" node. Are you possibly referring to the Name node? Either way, we can definitely add an if statement to prevent it from freezing Vectorworks. As for your question about saving the Python script to the script palette, since you're receiving the character limit, I would say no. And you're correct that it will execute immediately if you use Run Script. There may be a way to save it as a menu command, but I'm not familiar with the process as of yet. Maybe another user could point you in the right direction.

Martyn, Can you check if the node in this file works how you expect it would? I did some preliminary testing, but you know the problem better than I. Thanks! Marissa

I don't know if this situation was explored when the node was created, but I'm adding it to our list of things to look into. Thanks for reporting!

The closest I can think of would be to use the filter node to filter items from a list that meet a certain requirement... But even then, the user wouldn't be able to choose one the way that I think you're asking for. There's not currently a way that I'm aware of to interrupt the script to have user selection. There might be some hope if using dialog boxes, but I haven't explored that.

Are you aware of Debug Mode? Many users aren't completely satisfied with it in its current state, but to use it, have the Marionette tool selected and in the mode bar activate the Bug icon. To use it, you can click on a wired output and it will activate a dialog box with the data that flows through that wire. We're trying to find a more user friendly way to run it - right now, each time you select a wire, the entire network is rerun (annoying) but it provides at least another method of seeing what's flowing through your network.

This isn't currently possible because the OIP controls are defined before runtime. We can't dynamically refresh the OIP controls within the script, unfortunately. I can't remember if this limitation is a hard limit or if we can find a workaround at a later time, but I'm going to guess it will be this way for at least another version.

MMMmmmmmmm. So. Your door tool is different than ours. I'll have to see what I can find out about this one. I'll let you know if I make progress. Who's your distributor, by the way?

Hi mattao! Can you show me what you mean by attaching a file with a simple example of what you're seeing?

So what I did here was divide the shell thickness by two, and then shelled each contour twice - once in each direction (positive half-thickness, and negative half-thickness) This in a sense will center where the shell is created on the contour. I converted them to a solid because when they were shells, I wasn't able to add the two halves together to create just one object, that's probably just something funny with how the Add Solid command works with shell objects. Does all of this make sense, or should I try to explain it differently?

I also hate this Jim, hurry it up!

Can you show me where these parameters are? Like in a screenshot of the advanced parameter window? I'm guessing that variable names aren't localized, and that you can still extract the data, it's just probably not under what you think it is.