Sam Jones

Both Field Angles are 14° and both Beam Angles are 11°.

My beams are drawing as straight 3D lines instead of cones with an oval on the floor. How can I fix this?

Well. ... Reloading the workspace solved the problem. ?? ! Prior to that quitting and restarting VW did nothing. Another example of how much I don't understand about what is going on under the hood, but a mysterious solution is way better than none.

I tried moving it. No joy. I upgraded to build 513812. No joy. I haven't a clue as to how to track this one down. I can't imagine that he "If" test makes a difference, but good error handling for PIO templates If anybody hears of anything I can look for or test, please let me know.

Interesting. I have always put the code in kObjOnWidgetPrep, and it has always worked. I use it with vsoWidgetSetVisible which has to be in the kObjOnWidgetPrep event, because I turn visibilities off based on other OIP actions. I will move it and see what happens.

Additionally, the exact command works in 2019. I use the exact same code in my WidgetPrep routine in 2019 and 2020, but in 2020 it does not work.

I can't get "vsoWidgetSetIndLvl(OutWidgID, indentLevel);" to work. Nothing indents in the OIP. Anybody getting this command to work? Should I file a bug report?

Very cool. Who knew.

Lec's in depth reply will be very useful, and another private communication from Sebastian will also be a great source for describing functionality. Unfortunately, I'm swamped right now adapting an Australian dance show to our space and trying to deal with a VW 2020 changes. I'm looking forward to examining what Lec and Sebastian have described as needed functionality and incorporating in into AutoPlot, but I cannot at the moment say when the would happen. It may happen in steps. I will keep you informed along the way.

Architects make the same complaints, about Spotlight and the very special Lighting Device Object Not to mention Vision, Braceworks, and ConnectCAD. Landscape artists make the same complaints Don't even bring up the subject with plumbing and air conditioning designer/engineers The Producers Pack is very cool isn't it.. Sam

And yet Spotlight is the CAD application that comes closest. This is why it is the industry standard. The adoption of 3rd party solutions helps VW determine industry needs. Hoists, Video Screens, an cables tools all started as 3rd party solutions, and even today they are being enhanced by their 3rd party developers. VW is not just Spotlight, so they have a lot of fish to fry that don't come out of the entertainment ocean. Excuse the rant, but you are not the only one I have heard from that don't want to use 3rd party products and think VW should be all the industry tool that they want it to be. Well, asking VW to continually improve and add the tools that the industry needs is a good thing, but avoiding the use of 3rd party tools severely limits you in improving your work flow. I have heard from 3rd part tool users how the 3rd party tools literally, yes I mean "literally", cut the time it took to do a task from 3 days to 4 hours. Do what you will. There are many simple things that Spotlight does not yet do, that it will in the future, and many of those are done by 3rd party tools now. The single capability in VW that has had the most value for entertainment industry users is the existence of vectorscript.

The quick answer is no. The fields in the Light Info Record that is attached to the symbols for each light are matched to fields in the Lighting Device parameters. There are not user field record fields in the Light Into Record. If you were to add them, the Lighting Instrument insertion tool wouldn't know to copy them. It would be possible to write a vectorscript to insert a value into a user field based on the Instrument Type value of the Lighting Device. This command would need a file to look up the values and a user interface for you to edit the file. How much is it worth to you?

Andy calls, and here I am. First, yes, Lightwright does a fantastic job of power management. Second, ConnectCAD is a gorgeous suite of tools, but we have yet to see what it will cost, and how that will amortize over hours you save. As for VW, there are questions and issues. Do you want to put Power Distros (PDs) on the drawing? What should they look like? Should that change between different PDs? Based on what? Is directionality of the graphic important? Do you have the drawing real estate to handle placing PD graphics? You can always hide them on a layer and have special views. Gonna do that? The big one. I assume that you would want the PD object to carry information. What information should each PD hold? What do you want to do with that info? Do you want to collect more than the number of each kind of PD? What kind of reports, if any, would you want from VW. Understand that PDs in VW would not interact with LW the way lights do unless John McKernon and VW put there heads together, do some work and make it so. I think coordination of LW and VW with both PDs and cable will probably not be a part of any update for LW 6, but I'm not in that club. As for LW 7, I know John has a list, but he also has 2 dogs, a farm, and other things to do with his time. Are PDs different from dimmer racks? How? (besides not dimming) Should dimmer racks be considered PDs and just lump them all together? PDs have a direct effect on cable layouts and requirements, so having some kind of PD display and record keeping will be a part of cable planning and management. I am planning on adding PDs to my set of cable tools, but I need to answer the above questions. Also, ConnectCAD may or may not interface with VW cable tools or my cable tools. I will need to see something of ConnectCAD in more detail before putting in the effort to develop PDs. Also, there are several other projects to work on in my cable tools, like creating accurate box contents reports, so the time table for PDs will be in some flux. All of this does not help you get the job done right now, but the specificity with which you answer those questions will give you 2 paths to the future. One, the development of your own symbols with records to hold info. Two, providing me with info to create intelligent objects to get the job done. BTW, No, I do not spend all my time sitting in front of my computer making VW plug-ins, I have a 13 hour call tomorrow, and the wife is painting the condo. The other 3rd party heavy hitters, Andy and Josh, have similar or greater obligations. But then you were hoping the VW mothership would get it done. Maybe, but records, worksheets, and vectorscript are the greatest boons to entertainment CAD since the pencil. Sam

Try this. It will only go on level deep. If you want to explode symbols in symbols or you want to ungroup groups within groups more is needed. PROCEDURE ExplodeSymbol; {---------------------------------------------------------------------} PROCEDURE Explode( h :HANDLE); BEGIN IF Gettype(h) = 15 THEN BEGIN SymbolToGroup(h,0); HUngroup(h); END ELSE IF Gettype(h) = 11 THEN HUngroup(h); END; {PROCEDURE Explode} {---------------------------------------------------------------------} BEGIN ForEachObject( Explode, ((SEL=TRUE))); END; Run(ExplodeSymbol);

Alternatively, is there a way to build a resource list that only includes resources (Line Types) that are already in the document?

I want to assign a line type with a specific name that already exists in the drawing to a line in the drawing. The command "SetLSN()" requires an integer not a name, and that integer seems to reference a pattern to assign to the line not a line style. How do I assign a line style named "Named Line Style" that already exists in the drawing to a line for which I have a handle? Yet again TIA. Sam

The argument made for DLVPs applies th sheet layer VPs and allows for many different views and object visibility choices from the same 3D model. Top/Plan view allows for all the 2D info you could want (or at least all I can imagine). Lighting Devices are particularly well adapted for for 2D presentation of a 3D model and truss do pretty well also. I don't find DLVPs provide as much information flexibility and SLVPs.

So it would seem that the trick for you is to get a handle to the path of the path object. For a path object: your first vertex will be (0,0) so just add the offset to that (negative numbers to move left or down). your last vertex will be Get NumVertices:= GetVertNum(PathHd); GetPolyPt(PathHd,NumVertices,LastVertX, LastVertY); add the offset to that (negative numbers to move left or down).

Using the second option the labels will not move when the path object is moved or edited, but it will place the labels at the beginning and end and allow the user to adjust the location of the labels to any place they wish.

Unfortunately, gFlag := SetObjPropCharVS(kObjXPropShowPrefDialogWhen, Chr(kCustomObjectPrefNever)); Does not seem to work. I have tried placing it in the Init Properties event (5) and at the beginning of the PIO code.

Do you want the labels to be part of the object ? If yes, then: (I do the following with cable objects all the time.) Do you want the user to be able to change the location of the label based on the user moving the control point? If not, forget about the control point and write the place at the location of the first vertex and the last vertex. If so, on creation, set the control points to the location of the first vertex and the last vertex, and from then on always place the text at the location of the control points. GetRField(theObj, theObjPIOName, 'ControlPoint01X'). If no, then: (I do the following with Truss Labels all the time); just find the location of the path object vertices and write the labels to those locations.

I don't think you can assign control point values to a tool, because there is no object instance, but I have never tried. I move the control points of PIO objects all the time. OffsetX := 10; OffSetY := 5; GetSymLoc(theObject, ObjX, ObjY) SetRField(theObject, 'TheObjectPIOName', 'ControlPoint01X', ObjX + OffsetX) SetRField(theObject, 'TheObjectPIOName', 'ControlPoint01Y', ObjY + OffsetY)

It looks like the truss you need is in the Vectorworks libraries.

In other words add the insertion point X,Y to the control point X,Y.

Thanks so Julian. I know I have never seen that SetObjProp call before, nor have ever seen one called inside another call. Cool beans.