JBenghiat

Take a look at: https://www.benghiatlighting.com/index.php?option=com_content&id=117

It’s a JSON string. You can parse it manually in VS, but python has built-in JSON libraries. If I recall, you also need to update the apropriate control points.

Plug-ins essentially store parameters identically to record data, so a plug-in script can use Set/GetRField to access the data, for example to create text from that data. You can also run reports on plug-in parameters. If you're going the plug-in route, you would have parameters for all the elements you would need for the plug-in to draw the panel. You could save the plug-in as a "Red" symbol (if you're unfamiliar with the term, that's what to search for in the help) for different models. You can indeed have plug-ins inside other plug-ins, calling CreateCustomObject() from in the PIO code. Another way to think about the problem is to still base the PIO on symbols, but have a PIO that uses the symbol for geometry and handles the labels and data management. If your combined screen also needs to have the labels, it could actually also do the work of placing a label for each panel.

You may need to attach the record before linking the text. I would suggest doing a manual link in an otherwise blank file, then exporting to script. Examine the script to check order of operations. That may also reveal something silly, like a spelling error. I do have to ask, if you’re coding this, why not just create a plug-in object? That would save you from having to figure out link text to record.

You need to attach the record to the symbol. Add as the last line: vsRecord(vs.LNewObject(), ‘L ED Install Panel’ )

The Truss object has a symbol field — so not too hard — just get the name of the symbol and a handle to the definition with GetObject(). When you reset the Truss object, is should replace the contents of the profile group with the modified truss symbol. In theory.

The general practice would be to do something like: // Create class newClassName if (VWClass::IsValidClassName(newClassName)) { gSDK->SetUndoMethod( kUndoSwapObjects ); gSDK->NameUndoEvent("Create default classes"); VWClass classObjNew(newClassName); MCObjectHandle classH = gSDK->InternalIndexToHandle(classObjNew); gSDK->AddAfterSwapObject(classH); gSDK->EndUndoEvent(); }

This menu is a filter. If you have lots of kinds of resources in a document, this lets you only see the resources that interest you, for instance if you are looking to just browse textures and ignore a long list of symbols. I believe that All Resources is the setting for new installations — if that is not what you experienced you may have discovered a bug or inherited a setting via the Migration Manager. It's worth noting that when you have the Lighting Instrument Insertion tool selected, the resource manager dropdown in the mode bar is not subject to the filters, as this is automatically filtered by the tool's code to always and only show you lighting device symbols.

2D and 3D objects are all together, so start with FInSymDef() and traverse the list. If you want to set attributes differently for 2D and 3D objects, you have to check the object type to see if it is 2D or 3D, and if 2D check to see if the planar ref is set to zero (screen plane).

The Setup/SetDown events run when the tool is selected and de-selected. You might want to try as part of the GetStatus or UpdatePreview events. You may also need to manually invoke a screen redraw.

Normal drawing activities, like moving or dimensioning, shouldn’t have a delay. Have you tried testing in a new document? That would determine if something is amiss or inefficient about your file. If you have a lot of verticies or end points, particularly with imported geometry, that can slow things down when you are snapping. Adjusting snap and or layer options can help, as otherwise you are asking Vectorworks to provide hundreds of SmartCursor cues in a short time. 2019 added caching of sheet layer viewports. You may notice a slight delay when first navigating to a sheet layer, but then navigating within that layer should be significantly faster. If you are noticing long delays, submitting your file as a bug will help Vectorworks improve this feature.

In your texture options, you have the part selected as overall. You can have separate selections for top, bottom, and sides.

You may have misunderstood one of my suggestions, as wireframe and light visibility isn't a factor for any of them. If you're reacting to the Top view suggestion, you can still be in wireframe in a Top view. Also FYI, if you're using viewports for your final renders, you will never see the light geometry, regardless of the preference.

As you've discovered, you are seeing the light snap to geometry below. In addition to suspending snapping, you have a few additional options to prevent this: - Place light objects in their own layer. You can then set your layer options to one of the Show Others modes and avoid snapping to lower objects while still allowing light objects to snap and align to each other. I recommend having a layer for render lights even if you use one of the other methods. - Use the Move by Points tool with Object Retention mode off. This should keep the move action co-planar while still allowing you to snap to objects below. - Move in Top view as opposed to Top/Plan. That seems to avoid snapping to objects in 3D planes.

Yes, you can use scripting to work with resources. Unless you are always performing the same action or looking to do batch modifications, making the scripts isn’t necessarily faster than using the resource manager, though.

The Location selector only works for objects in the design layers, not for the crop. You'll have to add additional named polygons to your design layers. An extra step over restricting by VP, but easier than manually counting.

The other way to do this automatically is with a worksheet script. Add the following as a new Python Script resource: vs.WSScript_SetResStr( vs.GetName( vs.GetParent( vs.GetParent( vs.WSScript_GetObject() ) ) ) ) Then use this formula where you want the HP name: =RUNSCRIPT('SCRIPT_NAME') where SCRIPT_NAME is whatever you called the resource.

@Marissa Farrell I was curious if I could get this to work with Marionette. The issue was that you were modifying the objects inside the Hanging Position PIO, but every time the PIO regenerates, these objects get deleted and recreated by the PIO script. Instead, the network needs to modify the objects in the PIO's profile group. I needed to create two custom nodes: Get Profile Group and Get Contained Objects, the latter iterating over the objets in a container and returning a list. Also, the criteria at the start of the list needed to start with the Hanging Position and work in, rather than the contained objects, working out. HPMarionette_MFarrell_JBenghiat.vwx @SCParker See if my explanation to Sam helps. In your example, the worksheet that is doing what you want selects the Truss record, which is the record used to define the Truss PIO. This selector would be identical to saying Type is Truss. The correct report searches for all the Truss PIOs and then displays the Truss Record attached to them. Searching for objects with Truss Record returns both the PIO and the symbols inside the PIO. Your third worksheet searches for objects with the Truss Record that are NOT a Truss PIO, returning only the symbols inside the Truss objects

When you convert objects to a hanging position, you can base the position on a single symbol or embed geometry in the hanging position. If you have a symbol that is, for example, a 40' batten, you can base your HP on the symbol. Otherwise, you usually want to base the HP on embedded geometry (prior to VW 2014, symbol was the only option). The Convert to Hanging Position buttons in the OIP don't even give the option of creating a symbol. Whether the embedded geometry uses symbols is of no consequence to the script. As long as the HP is embedded geometry (i.e. in the profile group) this should work. The Truss PIO uses symbols with the Truss Record attached, an then also attaches a copy of that record to itself so the user can access it. Thus each Truss object has two objects with the record attached: the symbol inside the PIO and the PIO itself. If you want to create a report of objects with Truss Records, Including Components of Plug-in Objects will correctly look inside the Hanging Position. If your positions are made of Truss Objects, you have to edit the criteria to list objects whose Record Truss Record is Present and Type is Parametric object. Alternatively, you can do a report of objects of the type Truss and display data from the Truss Record. If you are using a mixture of Truss Objects and regular truss symbols, the report can get complicated, but you're really better off using a consistent method to place truss anyway. In terms of a script, that's actually a little simpler, as you can just not descend into objects that have the record attached (assuming you're manually iterating over objects and not using FEO).

Assuming the hanging positions all use embedded geometry and not symbols (which would make assigning individual position names impossible), you need to get the Hanging Positions profile group, then iterate through items in the group. The Hanging Position would then need a reset for data to show up in worksheets.

“Lighting Device” is the name of the Vectorworks plug-in. “Lighting Instrument” is a more generic term for the light on the plot. It’s also the term used by Lightwright and factored in to some of the pre-Spotlight lighting tools. You might say the Lighting Device is the tool you use to represent lighting instruments in Spotlight. Complicating things slightly is that the tool for inserting Lighting Devices is called the Insert Lighting Instrument tool. You’re never going to find the term Lighting Device in a lighting textbook or used when you’re referring to your actual rig, so much of the help and some of the tools and commands use the generic term rather than the name of the Spotlight object. I suspect that the name choice had to do with avoiding name conflicts and made sense from an engineering standpoint rather than an attempt to redefine the jargon. In the time since Spotlight debuted, VW gained the ability to change the display name of a plug-in (e.g. the Light Position Obj is now a Hanging Position); this may be the time to discuss whether the “Lighting Device” should change.

I believe this is an issue with the last item of the summary list getting ignored. Try adding an additional dummy item at the end, and see if that helps.

Yes — the hidden line preview is just OpenGL with show edges on, colors, textures, and shadows off. If you prefer to work in a hidden line-like mode, set your OpenGL options in this way. You’re likely not going to see many improvements in Renderworks speed among Vectorworks versions, as this is really just a bunch of math that always needs to happen, so only things like processor speed or availabile memory are going to affect RW significantly (the math is still the math). Where you will find improvements are new rendering options that can provide good results with less overhead — things like using parallax instead of displacement mapping for bump shaders, or using ambient occlusion instead of HDRI lighting. These settings sacrifice some realism for speed so they are not automatic. On the other hand, new options that increase realism, like caustics, will increase rendering time. Whete you should find improvements are things like 2D navigation, sheet layer navigation, OpenGL rendering, etc. The way many of these improvements happen, however, is by caching or sending tasks directly to the graphics card, which means that they are more prone to bugs, as they are dependent on specific OS hardware configurations.

Even embedded lights shouldn't display in VPs, regardless of the light object display preference. This behavior looks unique to lighting devices and looks like it might be a 2019 bug.

You're actually seeing the render light that's embedded in the Lighting Device symbol. Render lights should never show up in viewports (only the effects of the light), so this might be a bug. As soon as you render, whether in hidden line, OpenGL, or RW, they should go away.