Jesse Cogswell

Sam, The SetLineWeightChoice procedure is looking for the actual line weight value in mils, not the indexed choice of the pop-up. As for the line type, you would use SetLineTypeChoice with a LONGINT of the line type as the third argument. To find the internal index of your line type, you would use Name2Index('ISO-08 Long Dashed Short Dashed'). But also keep in mind that this would only work if that particular line type is already in the drawing (otherwise Name2Index will return 0). So you could do a little check with: IF(GetObject('ISO-08 Long Dashed Short Dashed')=NIL) THEN BEGIN resList:=BuildResourceList(96,14,'Attributes - Line Types',numLineTypes); FOR i:=1 TO numLineTypes DO IF(GetNameFromResourceList(resList,i)='ISO-08 Long Dashed Short Dashed') THEN h:=ImportResourceToCurrentFile(resList,i); END; This will import the line type as defined by the Vectorworks defaults file. Also keep in mind that SetLineTypeChoice may be looking for a negative value, so if you aren't getting the results that you want, try making the result of Name2Index negative, at least that's the case with SetLSN.

@mattryan The Unified View and Screen Plane were deprecated in VW2022 for better or worse. By default, Unified View will be set to on for new drawings, but it means that opening an old drawing that had it switched off will have it seemingly locked off. But, for a spot of good news, Unified View and the Screen Plane are still present within Vectorworks, they just need to be switched back on. Go to Document Settings - Document Preferences and navigate to the Legacy 2D tab. There is a checkbox there to re-enable the features.

@line-weight I only tested the script on a handful of files, none of them terribly large. I'll try to get some time tonight to test it on a much larger file and nail down the issue. In the meantime, could you PM me a list of the Layer names and Saved View names? There might be a naming conflict somewhere preventing the viewports from being created. Also, which VW version are you currently using?

@MarcelP102 I tried to make it a tooltip thing but was not able to get it to work through the list browser, so I took some space from the Viewport Name column and added it to the On Layer column. Copy Viewport Settings.vsm

@line-weight All right, give this a shot. When you select a saved view, press the button at the bottom to set things like where the viewport should live, what its name should be, etc. If you select the saved view without setting the options, it will default to the top sheet layer. It will also do an error check on the viewport name, but if you leave it blank it will do the standard "Viewport-X" scheme that VW does automatically. Also, pressing the button with the saved view selected will automatically put a check in the Selected column. This only looks at class and layer visibilities, and will rope in stuff set to "Ignore" if you're not careful (it loads the Saved View, pulls the current layer and class visibilities, then builds the viewport and applies them, if the class or layer is set to ignore in the saved view but is visible at the time you run this command, it will end up in the viewport). It also pulls the scale of the active layer to apply to the viewport, so it works best if you have the saved view Active Layer set to something other than "Don't Save", since then if you run the command while a sheet layer is active, your viewport will be at 1:1 scale, which probably isn't ideal. The plug-in was written in VW2019 but tested in both VW2021 and VW2022, so let me know if something doesn't work right for you. Saved Views to Viewports.vsm

@line-weight I've run some tests this morning and think I have a handle of this and am working on a script for you. It will launch a dialog showing all Saved Views, allowing you to select them, choose a Sheet Layer, and set things like Viewport Name, Drawing Number, and Drawing Title before cycling through the selected views and creating Viewports. As @Pat Stanford mentioned, Saved Views are a little tricky, so at the moment it will be creating viewports strictly based on the class and layer visibilities of the Saved Views, not the screen view itself. It IS theoretically possible to pull the screen view and use that to create a crop, but it is a fair bit trickier.

Updated plug-in attached. Let me know if this creates any bugs or issues that I might have missed in my (admittedly rather quick) testing. Copy Viewport Settings.vsm

@line-weight That would be no problem at all. I'll try to get around to that tomorrow or Sunday.

I've been playing around with the file for a little bit and this definitely, definitely feels like a bug. Worksheets seem to have a hard time consistently showing images in the cells at different zoom distances. If I'm zoomed too far out, the images disappear in both the viewports as well as a copy of the worksheet on the sheet layer. I was curious if this was just a visual quirk and exported out a PDF when the images weren't visible on screen and the PDF came out with them properly rendered. Picture Zoomed Out a Bit: Picture Zoom In: I did have to go in to the Viewport crop adjustment before the image would load the first time after opening your file and had to edit the crop of any viewport that was copied and pasted before the image would show up. There is for sure something weird going on. I would submit this as a formal bug.

There are several very valid criticisms to be lobbied toward Vectorworks, but so far in reading this post and your other one, most of your criticisms are based on fundamental misunderstandings of how the program works, not quirks or workarounds, full on misunderstandings. It sounds to me like you have made up your mind that you dislike the program, and are using these questions to complain about it. I will do my best to dispel some of your problems. Having to force select everything: As I mentioned before, this sounds to me like you have either your class or layer view settings off. If you make sure that View - Layer Settings and View - Class Settings are both set to Show/Snap/Modify literally everything visible will be selectable and snapable as long as it is the same layer scale. I have NEVER ONCE encountered an issue where I was not able to select something with both classes and layers set to Show/Snap/Modify. Give it a try before faulting the program. There are several very legitimate reasons for the different options found in the menus, it is not the fault of the program that you don't have them set properly for what you are trying to do. Snapping: Make sure you have the right snaps engaged. You might not be snapping to points because VW doesn't know you want to snap to them. This is what my Snapping palette looks like literally 100% of the time. It's very rare that I can't get a snapping point that I need. I also occasionally use the Tangent snap mode on the end, it will make you infuriated if you have it on when you don't need it. Layer scales and why they exist: I use layers of different scale fairly often. I might have a lighting drawing that contains a block schematic view showing how the control system is laid out. This will appear on a sheet layer (the name isn't super great, think of sheet layers as more akin to AutoCAD's Layouts and design layers as AutoCAD's Model space) in 1:1 and not scaled. However, my plan view will likely be printed at 1/4" = 1'0" scale. Things like text size, line weight, and dashed lines will have a different appearance going from 1:1 to 1/4". Therefore it behooves me to have my schematic layer set to 1:1 while my actual model is in 1/4". It gives me a good idea of how it's going to look on the page without having to worry about setting different dash styles and line weights by scale. Unified View: Unified view is something of a holdover from earlier versions of Vectorworks before the existence of Sheet Layers and Viewports. With Unified View off, you are able to manipulate the view of each Design Layer separately (you could have your Walls layer in a plan view while your Ceiling layer could be in a front elevation view). This was useful for laying out a sheet, but will disengage snaps of layers with different views. I have never found a use for this feature and literally only draft with it engaged. I suspect there are some users who have found some use for it, but it has been deprecated and functionally removed from VW2022. Getting back to the Select tool with a single keystroke: This totally exists. It's the "x" key. It will stop any tool or action outside of a currently active text edit (in which case "esc" will close the text edit, then you can press "x" to close the tool and go back to select). This isn't a new feature or workaround, it's been in Vectorworks since at least 2008 and probably much longer. Screen plane: Screen plane did certainly have its uses, mostly with drawing and measuring 2D points in a 3D plane. When you are drawing 2D shapes when in a 3D view, VW would sometimes latch on to points at different depths. Let's say that when in a Left view that you wanted to draw a line straight up in the Z axis. VW might snap to points at different depths on the X axis. So from the left, it looks like you have a line straight up, but from the front you would see a diagonal line. Drawing on the screen plan negates all of that, everything drawn and measured is considered to be on the same plane regardless of view. The have cleaned up a lot of the coding and improved things with Working Planes, so the screen plane is no longer needed (for the most part). One of my very favorite things about Vectorworks is that symbols have a separate 2D and 3D component. It's what lets me make a moving light in full 3D detail while also making it an easy symbol to read on a printed plot. One thing they didn't think about before removing the screen plane is that it was what VW used to sort objects between the 2D and 3D components. But to be fair to Vectorworks, when I mentioned that on these forums one of the developers reached out to me and after sending a video showing what I meant, they started on making a solution. Input bar: I don't know what problems you have with them, it makes perfect sense to me. You have L for length, move an object a specific length regardless of angle (gives you a circle allowing you to select an angle but with the fixed length). This is all I need 99% of the time. You have A for angle, allowing you to lock the angle similar to ORTHO in AutoCAD. You have ΔX and ΔY, which are the X and Y distances from the initial click, and X and Y, which are the absolute X and Y coordinates based on the drawings 0,0 origin point. None of those are redundant and all have their uses. I've never had a moment where I type in a specific L value and VW throws something way off place. Like I said, I primarily only ever use the L option, which should activate by default anytime you click to start a tool or click and drag an object. The only time I ever see the XY inputs is if I accidentally press tab too many times thinking that I'm still editing in the Object Info Palette. Development: One of my other favorite things about VW is that it is freely open for people to create their own tools. Sure, the default language of Vectorscript is based on a language that's older than me, but they incorporated Python back in 2014 and even have the SDK freely available. There are several very useful tools you can find on this very forum that can drastically improve your VW experience if you look for them. To say that VW " shut the doors and windows to the other developers" is very unfair when literally anyone can download the SDK and write tools for it. They've even been very open about licensing other people's tools and directly incorporating them into VW. A good chunk of the Spotlight toolset come directly from Joshua Benghiat and C. Andrew Dunning, who both post regularly on this forum, that VW has licensed from them. One of the big inclusions to VW2022 is a door and window plugin called WinDoor from the Australian firm OzCAD. I love that if Vectorworks doesn't have a tool that I need, I can (and very much have) write one to do exactly what I want and that thinks the way I do. VW 2019: Your criticism about VW not supporting older versions of software is entirely legitimate but more of a byproduct of the general shift toward "Software as a Service" and not specific to Vectorworks. They still do offer support to older versions, but once a new one comes out, most of their resources get put toward the new version. This makes sense to me and isn't anything that I would say is uncommon within the software industry. It's nothing I haven't seen from AutoDesk once they transitioned to yearly releases back in 2004. As a general rule, you can backsave up to five version years and they do offer their Service Select plan, which allows you to stay current for a "smallish" fee (still steep but better than it used to be to pay the upgrade fee every year) and comes with exclusive symbol libraries and other perks. Ironically, VW2019 is my favorite version and what I daily drive despite having every release from 2015 onward (when I started my Service Select plan). Unfortunately, the newest releases usually have some major bugs to work out, so amongst most the users that I know, you usually wait until the next version comes out before adopting the previous (wait to adopt 2020 until 2021 comes out, wait to adopt 2022 until 2021 comes out, etc). So far, I have only ever used VW2020 to backsave to 2019. 2021 added some very convenient scripting commands for setting lighting photometry data quickly, so I use it for realistic rendering, and 2022 added several new rendering modes that are at once exciting and very disappointing (they...need some work before I can really use them). Developing your own software, with blackjack and hookers: There has literally never been a better time to do exactly that. With open source and mostly free tools like Blender, Unity, and Unreal, you could probably legitimately do exactly that, if someone hasn't started it already. I read a case study where an architecture firm had designed a building in Blender and decided that it would be less time to write their own BIM module than convert everything to Revit, so they did. If you have any coding background, this might legitimately be an option for you to put your money where your mouth is. I guess my point with all of this is: If you ask a question on these forums, please do consider the answers before pooping all over Vectorworks. It can be archaic, some features are very much half baked, but coming here and yelling about Vectorworks being useless and broken when it's clear that you haven't taken the time to learn it or digested the information others have tried to share on this forum is going to garner very little sympathy. Take some time with Vectorworks University and doing tutorials. Especially if someone is going to pay you hourly to do it. Let me know if you have any questions. If there's something you wish Vectorworks would do, also feel free post in the Marionette / Vectorscript / Python Scripting sections of this forum. There are several folks here who may help you create a tool or command if one doesn't exist.

Would you mind posting the file?

@LocisI think I am having a hard time understanding what you are looking for in terms of text rotation and setting focus. What are you trying to do in regards to rotating the dimension text? Dimension objects have a field in the Object Info Palette called Text Rot which give options such as "Horizontal", "Aligned", and "Horiz/Vert". Moreover, the dimension text itself can be repositioned by clicking and dragging it around. In terms of focus, what are your class and layer view options currently set at? If you go to View - Class Options you will have several different options with Show/Snap/Modify set by default. This allows for objects of any class type to be selected and snapped to. Now look at View - Layer Options. By default, this will be set to Gray/Snap, which means that only the currently active layer is shown in full detail (other layers will be semi-transparent with fills turned off and will not be selectable, but can still be used for snapping). What it sounds like you are looking for is Show/Snap/Modify for your layer options, which will allow objects on any visible design layer to be selectable and modifiable without having to force select things all of the time. I personally almost always have my layer options set to Snap/Modify, so that I don't accidentally move the floor symbol around when I'm trying to draw a marquee selection box around a lighting fixture and also ensures that I am placing things on the proper layer. Based on this thread and the other that you started, it sounds like you are having a hard time adapting to Vectorworks from AutoCAD and Revit, which is very understandable. If you have screenshots or drawings from other CAD programs showing what you want Vectorworks to look like, I can try to relay the best ways to get Vectorworks to work for you. I certainly understand frustrations about VW and how some of things work, it's weirdly strict in some ways while being overly flexible in others, and its inconsistencies point toward a product developed by a team of people who don't always agree on how it should work. And it's GUI has not changed in any meaningful way in the 13 years I have been using it, so it can feel really dated, with weird holdovers from earlier versions of the program being left in for legacy purposes (the Screen Plane, for example, which was functionally removed in VW2022 without overriding some settings). But all that being said, I have come to love the way it handles some things, one of which is the split with Layers and Classes. I love that I can have my visual attributes (pen color, fill color, lineweight) completely separate from my organization (wall lineweights can be quickly changed across the drawing regardless of being on the first floor or the third floor). It certainly makes it much more difficult getting drawings from Vectorworks back into AutoCAD, though. To answer a question from your other thread, the way I typically do it is to export each design layer as a separate .DWG drawing, then merge them together in AutoCAD as XREFs, which is less than ideal. Unfortunately, on .DWG export you either have to choose to keep your class structure or your layer structure, so you either lose your visual settings or your organization if you try to get everything in one go. Less than ideal, admittedly, but worth it to me for the other benefits. For my industry (entertainment lighting), Vectorworks IS the industry standard, so a lot of my fondness may be Stockholm Syndrome from knowing that for all its quirks, it is certainly better than the alternatives. I used AutoCAD with the LD Assistant plug-in for a number of years before migrating to Cast Software's WYSIWYG and finally landing on Vectorworks. It took about a year of swearing at the program before things finally started to click. I can say that it got easier when I stopped expecting it to work like AutoCAD and spent some time learning their intended workflows. I really do miss AutoCAD's use of the spacebar to repeat the last action or tool as well as the command line entry, but have come to love VW's use of the number keys as shortcuts for the tools since my fingers are already there to type in dimensions anyway (even if it means having to memorize all of them, now it's pure muscle memory). Please do feel free to reach out if you have questions about Vectorworks and how it works. There are a lot of folks on this forum from a lot of different industries that can steer you in the right direction if we know what you're looking for.

This may be an unrelated issue, but there has been a bug with Vectorworks for a LONG time (and still in VW2022, though I admit I don't have SP1 installed yet) that I posted about here: Any time you open an Edit Texture window, it kicks the fill and pen sections of the Attributes palette out of "By Class." So, if you use textures a lot, this is the likely culprit.

That would be simple. Using my second example, change the ForEachObject criteria so that the line reads as ForEachObject(BuildArray,((SEL=TRUE) & (T=GROUP))); That's one of the reasons I prefer to use ForEachObject, it really gives you a lot of control in terms of which objects to run procedures on. Writing out the criteria sections can sometimes get tricky, and there used to be a nasty bug where if you were missing a parenthesis, compiling would cause a memory leak and crash Vectorworks (thereby throwing away all of your hard work), so if I need a complicated selection I will use the button in the upper left of the Script Editor window and select Criteria to have Vectorworks build the correct criteria string.

The reason you are getting an infinite loop is that you are creating a rectangle, which would be selected after creation, with every iteration of your loop. So there is always a selected object to use NextSObj on. Are you looking to create one rectangle around all selected objects or a rectangle around each single selected object? Right now, your script will do the latter. Depending on what your aim is here, there are different solutions. Draw one rectangle around all selected objects: This is actually very simple (with some caveats). Since the objects are all selected, you can use the Group procedure to group them all together Then do H1:=LActLayer; to get the handle to the group Use the GetBBox procedure to pull the points of the bounding box Create your rectangle Use HUngroup to ungroup your selection The major caveat is that, if objects are spread across different layers, the group command will force them all onto one layer together. If this is the case, I would use ForEachObject or something similar to the code you have to go through the selection and build DYNARRAYs of HANDLEs to both the objects themselves and their parents (in this case, the layer they live on) using GetParent. Then you can use a FOR loop to go through the array and reassign the objects to their layers using SetParent. A code sample to do this, including resetting things on multiple layers, is included below. PROCEDURE BoxAllTheThings; VAR objCount:INTEGER; objArr,parentArr:DYNARRAY OF HANDLE; PROCEDURE BuildArrays(h:HANDLE); BEGIN objCount:=objCount+1; ALLOCATE objArr[1..objCount]; ALLOCATE parentArr[1..objCount]; objArr[objCount]:=h; parentArr[objCount]:=GetParent(h); END; PROCEDURE CreateBox; VAR h:HANDLE; A,B:POINT; BEGIN Group; h:=LActLayer; GetBBox(h,A.x,A.y,B.x,B.y); HUngroup(h); Rect(A.x,A.y,B.x,B.y); END; PROCEDURE RestoreParents(objects,parents:DYNARRAY OF HANDLE; iCount:INTEGER); VAR i:INTEGER; BSB:BOOLEAN; BEGIN FOR i:=1 TO iCount DO BSB:=SetParent(objects[i],parents[i]); END; BEGIN objCount:=0; ForEachObject(BuildArrays,(SEL=TRUE)); IF(objCount>0) THEN BEGIN CreateBox; RestoreParents(objArr,parentArr,objCount); END; END; Run(BoxAllTheThings); Draw rectangles around each selected object: This one is a bit more complicated. Use either your existing WHILE loop code or ForEachObject to generate a DYNARRAY of HANDLE of all selected objects. Use a FOR loop to go through the array. For each handle, use GetBBox to poll the coordinates Create a rectangle using the coordinates Below is a code sample of how I would approach it. I prefer to use ForEachObject when doing stuff like this, it gives you a lot more control of which objects are affected (targeting selected objects only on the active layer for example). PROCEDURE BoxTheThings; VAR objCount:INTEGER; objArr:DYNARRAY OF HANDLE; PROCEDURE BuildArray(h:HANDLE); BEGIN objCount:=objCount+1; ALLOCATE objArr[1..objCount]; objArr[objCount]:=h; END; PROCEDURE CreateBoxes(objects:DYNARRAY OF HANDLE; iCount:INTEGER); VAR A,B:POINT; i:INTEGER; BEGIN FOR i:=1 TO iCount DO BEGIN GetBBox(objects[i],A.x,A.y,B.x,B.y); Rect(A.x,A.y,B.x,B.y); END; END; BEGIN objCount:=0; ForEachObject(BuildArray,(SEL=TRUE)); IF(objCount>0) THEN CreateBoxes(objArr,objCount); END; Run(BoxTheThings);

Unfortunately, I don't think there's any way to toggle the visibility of an OIP parameter with Marionette. You can certainly do it with Plug-in Objects scripted in Python or Vectorscript, but I can't think of a way to do it in Marionette. Any input node given a name will appear in the OIP, but there's no way to change a node's name from within a Marionette network.

@KingChaos You would block off input data to prevent geometry from being drawn. Let's say that you have a Marionette object that can either be a circle or a rectangle based off of a drop-down or radio button in the OIP. You would need a Circle node and a Rectangle node in the network to achieve this, but if you supply enough input data into either node (radius for Circle, width and height for Rectangle) both objects would be drawn. So you would use some way of preventing the input data from reaching the nodes to ensure that only the desired object is drawn using either Valve or If nodes. I personally prefer to use Valve nodes for this, as they are simpler. I've attached a small demo showing how this works (in VW2019 format, it's what I had open when I read this post. I did quickly test it in VW2022 and it seemed to work fine). The named input variables are a Radio Button node named "Shape" (custom edits to name the options) and a Real node named "Size". The "Shape" node will output either a 0, 1, or 2 based on what option is chosen in the OIP. I use three Equal nodes to check the "Shape" output and will pass a TRUE if it matches. The "Size" node is plugged into the input of Valve nodes, which will allow the input to be passed on if it receives the TRUE input from the Equal nodes. The div nodes just halve the "Size" data since the Circle and Regular Polygon nodes use radius instead of diameter. In summary, the Valve nodes are preventing the "Size" input data from reaching the Object nodes unless they're the chosen shape. Marionette Valve Demo.vwx

Sorry that this comes so late, but the easiest way to bring back toolset palettes is to reset back to the default Spotlight workspace. Go to Tools - Workspaces - Spotlight. This should reset all of your toolsets back to default.

I wrote a tool for this a while ago that can be found here: It will list all viewports in the drawing highlight out of date viewports. It lets you select which viewports you want to update (with a button for selecting all out of date viewports), then updates them after pressing "OK". I have tested it in VW2022 and haven't had any problems with it so far.

@michaelk The SetTextWrap procedure basically just checks the "Wrap Text" parameter for a text object. The wrap itself is set using the SetTextWidth procedure. I also agree with @JBenghiat, I always use CreateText to create text objects. Fewer lines of code.

@willofmaine I think the only way I've found to reliably do what you are asking is to use either Valve or If nodes to block off input data. A Symbol node won't place a symbol if it doesn't have the string symbol name input, a Circle node won't produce a circle if it doesn't have a a radius input. But if a geometry-creating node exists and has enough of its parameters filled, it will generate geometry regardless of its placement within the network.

Python is probably the easier language to learn, and it comes with the added benefit of being applicable to Marionette since the nodes use Python to determine their operation. There are also a TON of classes online that teach Python. Don't be worried too much about it being white space delimited, it just means that you have to be very strict about how you use tabs and spaces or the code won't work properly. Python does get a little tricky in this regard, as its not a compiled language like Vectorscript, so there's no error checking until it's running, and it can be tricky tracking down what is causing the code to break. Unfortunately, I'm not too familiar with Python's operation in Vectorworks. I learned Python on my own back in 2010, but haven't really touched it since aside from editing a couple of Marionette nodes. By the time it was added to Vectorworks (2015 maybe?), I was very comfortable with Vectorscript and didn't have much need to switch. I am working on a project to add copy protection into some of my plug-ins that will require Python in order to ping an online database (there doesn't seem to be any way to do this with Vectorscript natively), and another project to ease the update process so that it's no longer manual (file operations in Vectorscript are strictly limited to text files and are severely limited on what you can actually do to files). Python opens up a whole world of possibilities outside of the scope of Vectorscript because of its ability to import libraries. My current plan is to script in Vectorscript and then use PythonBeginContext to script in just what I need Python to do. The thing that makes Python a little harder to use in Vectorworks is that you are still limited to the Vectorscript function library to actually manipulate Vectorworks. Most of the time, it's taking the Vectorscript function and adding "vs." to the beginning of it. So, creating a rectangle in Vectorscript would look like Rect(p1.x,p1.y,p2.x,p2.y) and would look like vs.Rect(p1,p2) in Python. The other thing to keep in mind is about how Vectorscript and Python handle variables. Both are "typed" languages, meaning each variable has a defined variable type. What makes them different from each other is that VS is "statically typed" and Python is "dynamically typed." In VS, every variable MUST be defined as a variable type (string, integer, real, etc) and can only ever be that type. In Python, you can define a variable without assigning a type, Python will do that for you. Variables are also able to change their type within the code. So you can have a variable start as an integer (whole number only), then change to a floating point value (decimal number) when needed. This makes the language much more flexible, but also potentially dangerous if your code is sloppy. It also makes the code slower to operate, in that the "higher level" operations that the code does for you comes at the cost of computation time. While this definitely won't matter much in the scheme of Vectorworks plug-ins, it does matter when writing complex programs like mathematical solvers. Python is considered to be a "slow" running language that balances out by being very quick to write. If the programmer's time is more valuable than the computational time, then Python is the way to go. If you need the program to be snappy and can afford the cost of competent programmers, then it's best to use something like C++ which has virtually no hand-holding (manual memory management, garbage collection, etc), but is basically one step removed from assembly code and super fast to run. If you end up really getting into the weeds, the absolute best way to write plug-ins for VW would be to write in C++ using the SDK (software development kit) since you would have access to basically everything Vectorworks can do, but C++ is a much harder language to learn and definitely not what I would try to learn first.

@Wilfrick You can totally do this. What you will need is a Boolean input node named "Mirror" attached to a Valve node. At the very end of your network, add a Mirror node attached to the Valve. What's important is that all of your geometry nodes appear BEFORE the Valve so that it gets generated properly before getting flipped.

@willofmaine The reason I alternate between letters and numbers for points in this example is more or less down to how I name and handle variable names between formal declarations (declared in the VAR block of code) versus variables named in the PROCEDURE/FUNCTION definition. Almost always, I will name points with capital letters, both because of ease of typing (handling points requires a lot of lines of code since each X, Y, and Z setting requires its own line), and because of how I learned geometry in high school. That all being said, because of the way Vectorscript handles PROCEDURE/FUNCTION definition, you need to declare what variables and in what order the constructor will be looking for as "arguments." While you technically can pass in the same global variables into the constructor, it's best practice to keep them as local variables within the definition (allowing for better modularity of code, even if Vectorscript really has no way of sharing code from script to script). I'm often lazy when dealing with constructor arguments, so I'll often just name them as the variable type followed by a number (s1,s2,s3 for STRINGs; h1,h2,h3 for HANDLEs; i1,i2,i3 for INTEGERs; p1,p2,p3 for POINTs) rather than giving each a more unique name that I have to remember and not conflict with an existing variable name. At the end of the day, Vectorscript or Python don't really care what you name your variables as long as they don't start with a numeral, and that they aren't the same name as an existing function or special word (can't name a variable var because of the VAR special word, or count because of the existing Count() function). Special words should be obvious as most IDEs will color them separately to highlight them, and naming a variable a function will throw an error in the compiler (or during runtime with Python). I'm glad that you got some use out of the crash course. Learning a programming language is definitely something I'd recommend, and the hardest language to learn is the first. Once you learn one language, a lot of the ideas will translate to another, then it's a matter of learning syntax and flow. Python is at once a wonderful language to start with (it's used pretty much everywhere nowadays, there are a TON of resources to learn it from, and, as far as programming languages go, it's really simple to learn), but also does so many things for you that it can be hard to transition to another language. Learning Vectorscript as your first language will also be challenging just because your resources are restricted to this forum and the developer wiki, as Pascal hasn't been a super relevant language in the last 25 years, so there are far fewer online resources. But at the same time, the Python implementation in VW is built on the Vectorscript function library, so knowing Vectorscript makes scripting in Python for VW so much easier. I'm pretty bummed with how Marionette has gone. When they first debuted it in 2016, I was really excited about the possibilities. It was even the very first thing I played with in VW2016, but it's very clunky as far as visual scripting goes, and I've always found it sluggish to both program in and the performance of Marionette objects. And overall, its implementation hasn't changed much since its inclusion, even in VW2022 Marionette objects are sluggish (though they take up far less in terms of file size, so that's nice at least). My twin brother works in the digital animation industry and uses node-based visual scripting in Blender and XSI SoftImage and was horrified when I showed him how it works in Vectorworks. Best of luck continuing your Marionette and scripting journey. Please feel free to let me know if you have any further questions.

I've had some success with placing symbols into an ordered list from bottom to top, then exploding the list back into a group. It's kind of messy, but it's the only thing that I have found to consistently work.