Jump to content

Jesse Cogswell

Member
  • Content Count

    167
  • Joined

  • Last visited

Everything posted by Jesse Cogswell

  1. This is best done using an Extrude Along Path. If you have a section view of the venue, use that to make a closed polygon/polyline of the profile. Then, draw an arc representing the path. If you have a plan view of the space, you can easily draw the path using either the arc tool or the polyline tool. Once that's done, select the profile polygon and the path arc, then click on Model-Extrude Along Path. A dialog box should pop up allowing you to select which of the two objects is the path object (highlighted in red), click OK and the the Extrude Along Path will be built. IMPORTANT NOTE: Vectorworks will treat the path as the exact center of the extrude, so if you use the bottom step in your example to draw your path, you will need to move the profile after creation. Do this by double clicking the Extrude and select Edit Profile, then move the profile shape so that the "origin point" is where the path should be. Profile shape created from section view Selecting the path object (an arc in this case) Repositioning the profile Final Object All of this depends on what kind of drawings/resources you have to start with, but even if you have a rough idea of the dimensions of each "step" of the amphitheater and a rough idea of the curve, it should be pretty quick to build.
  2. Make sure that the symbol has the "Parts" record attached. This determines which pieces of geometry are the Base (in this case, the clamp), the Yolk, and the Body. If the record is not attached, follow the instructions below. Edit the 3D component of the symbol Select the C-clamp Click on the Data tab in the Object Info Palette Click the Attach Record button Find the Parts record and double-click it. If this is not in your drawing, import any lighting device symbol form the VW library into your drawing. Below the Records box, there should be at least three check boxes, one for Base, one for Yolk, and one for Body. For the clamp, select Base. Follow steps 2-6 with the yolk, but select Yolk instead of Base. Follow steps 2-6 with the body of the fixture, selecting Body. Note that this needs to be a single object, so if the body is made up of multiple objects, you will need to group them before attaching the record. Also ensure that the body is pointing straight down. Ensure that there is a 3D locus point at the pivot point of the body. This is where VW will have the body pivot in the yolk, and will serve as the point of origin for the beam when Draw Beam is selected. Looking at your image, I'm pretty sure that this 3D locus is properly placed. This locus should not be placed in the body group. If the Parts are properly attached, then shoot us a copy of your file and we'll see what we can find. You can also try importing in new versions of the symbols from the VW library. Also, what version of VW are you using? VW2021 made some pretty substantial changes to Lighting Device objects, so there's a chance that the symbol you are using is out of date, but as long as the parts are still set, you should be seeing the fixture orient properly.
  3. @michaelk Oops, forgot to remove that criteria in the second script, since it's really not necessary. The ReDrawAll should cover doing the reset, at least it did in my (admittedly very quick) testing.
  4. Here's the fix that should cover the redraw: PROCEDURE Test; PROCEDURE StompIt(h:HANDLE); VAR LW : INTEGER; BEGIN LW := GetLW(h); IF LW >10 THEN SetLW(h,10); ResetObject(h); END; BEGIN ForEachObject(StompIt,(INSYMBOL & ((LW<>2)))); ReDrawAll; END; RUN(Test); It's not all that clunky, really. I moved the LW variable in to the StompIt procedure since you don't need it to be global, and I added some indentation to make it a hair more legible. But the core script is about as elegant as it can be for what it does. The only change that I would consider making would be to add in a criteria for the ForEachObject procedure to only operate on the active layer (since DWG exports tend to be on a single layer immediately following import) to remove the possibility of accidentally overwriting intentionally set high line weights (I usually have a higher line weight on my title blocks, for example), or to just set all of the flagged objects to setting the line weight to be By Class, as I think that would be more useful in the long run. This comes with the added benefit of not needing an additional callback procedure for the ForEachObject procedure. These changes are made below: PROCEDURE Test; VAR activeLayer:STRING; BEGIN activeLayer:=GetLName(ActLayer); ForEachObject(SetLWByClass,(INSYMBOL & (L=activeLayer))); ReDrawAll; END; RUN(Test);
  5. @Mia Casa I keep the three most recent versions of VW and Vision on my computer. 2019-2021 of both softwares use black for their logos. So, on my taskbar there are three identical logos followed by three more identical logos. Might be worth a feature request for 2022 to use a different color.
  6. Some of it may be determined by the mapping type. By default, Vectorworks will apply the mapping using Perimeter, which I've found to flip textures on a pretty consistent basis. Try changing the map type to Auto-Align Plane and see if that properly orients the textures. Depending on the 3D solid type, you might have to map the top/bottom and sides separately to get all of the textures properly mapped.
  7. @virk I've never been able to get the CreateShell function to work. It's looking for a NURBS surface, but I have no idea on how to properly extract the specific surfaces from a sweep object to use for CreateShell. Theoretically, for an elbow could use an CreateExtrudeAlongPath function using a circle representing outer dimension and another using inner dimension with the same path object, then a SubtractSolid command to create your shell.
  8. Took a look at the Concentric Reducer plug-in in VW2021, I forgot about a "feature" added to OffsetPolyN starting in VW2020 in which the offset now takes the poly's direction into account. I reversed the points in the Poly procedure and now everything works as intended. Concentric Reducer.vso
  9. I'll take a look at the code in VW2021. I use 2019 primarily as I find it to be the most stable on my machine, and there are some rather annoying and persistent bugs in 2021. For as much as Vectorscript generally doesn't change, every once in a while they will change a command and cause scripts from earlier versions to break, and I seem to recall OffsetPolyN to be one of those commands. I also didn't try using it in a metric drawing, there is a chance that OffsetPolyN doesn't respect document units (as you get deeper into the weeds of Vectorscript, you'll come to realize that there's not always a rhyme or reason to which units functions and procedures use, and it's not usually detailed in the Function Reference. I'm glad that you were able to get this working. Scripting in VW is incredibly powerful and one of the major reasons that I have stuck with VW in spite of the quirks and bugs. To answer your questions: All of the information from the Edit Definition dialog box is stored in the vso file including parameter defaults, plug-in strings, and tool-tip information. The only thing not stored in the vso file would be an external resource file (like if you wanted to have a drop-down menu to select common wall thicknesses, all of that data could be stored in a tab or space delimited text file), but any changes you make on a script through the Plug-in Manager stays with the file. Vectorworks will be far happier with you if you store the plug-in object into a symbol if you're going to have that many. The Concentric Reducer that you have outlined is very lightweight in terms of processing and memory usage, but each instance would be individually computed even though they're identical. Symbols are about as lightweight as you can get in VW, with each instance only needing to compute X, Y, Z, and rotation data while the symbol definition is computed just once. I'm a huge proponent of symbols for this reason, even if you might only have one instance in the drawing. I work with a lot of designers who seem to favor using Groups instead, and it drives me up the wall.
  10. Based on your example file, I think a sweep would be a better option than a multiple extrude. Based on past experience, sweeps generate better wireframe meshes than multiple extrudes, important for Hidden Line drawings. The only time I would use a multiple extrude for something like this would be for an eccentric reducer, where a sweep would not be possible. With that in mind, on to the code. For a simple solid 3D cone, the coding is very simple. Steps are outlined below. You will need to create a new plug-in by going to the Plug-in Manager (Tools - Plug-ins - Plug-in Manager) and clicking on the "New" button. This will open a dialog asking for the plug-in type. In this instance, I think a Linear Object is the best type, which will be used to set the length of the reducer. Name it and click OK. With any Plug-in Object types, you will need to define some parameters before starting in on the code. To do this, select your script and click on the "Edit Definition" button. In the General tab, assign a category for your plug-in. This is where you will find the plug-in to add it to your workspace. In the Parameters tab, you will assign additional parameters above the given ones of your plug-in type. Important things to note is the Name vs. Alternate Name. The parameter name in the Name column is going to be what the code itself references, while the Alternate Name is the one that Vectorworks is going to show in the Object Info Palette. Having these separate allows plug-ins to be localized for different languages without needing access to the source code of the plug-in. In this instance, I would create two Dimension parameters, named diameter1 and diameter2 with alternate names being Diameter 1 and Diameter 2. There's no defined rules for parameter naming, but I tend to set their Names based on how they will appear in the code, so I tend to do uncapitalized, camel case with no spaces and use the Alternate Name to make something a little more friendly. Any Dimension type parameters MUST have a default value, so set this based on what the most common reducer you tend to use (such as 3/4" x 1/2"). The other tabs don't really matter for this particular instance, but I'll detail them anyway. The Strings tab is used to define strings for localization purposes. If your object has text that appears outside of parameter names, such as dialog boxes or warnings and such, the strings should be defined here and called into the script using GetPluginString. I tend to build categories like "Dialog Strings", "Dialog Help Strings", "Messages", and "Miscellaneous Strings". Having these outside the actual code allows your plug-ins to be localized even when they are encrypted. The Properties tab allows you to select an icon, set projection requirements, and write out the tooltip help for your plug-in. The Options tab lets you set a couple of options in terms of how your plug-in will operate. Event-Based plug-ins allow you to customize the OIP with buttons or more aware parameters (such as a drop-down list populated with items from a particular drawing rather than being hard-coded into the plug-in). Events-based plug-ins are a whole different beast with a relatively much more complicated coding to get them to work correctly. The current documentation surrounding events isn't great, but there has been some discussion of filling it out with some helpful articles from a now-defunct website called VectorLab, so stay tuned if you are interested in events-based plug-ins. Other options include Reset on Move or Reset on Rotate, these are used if your plug-in does things regarding its location. If it creates a text box displaying its X and Y value as an example, you will want Reset on Move to be checked. Other than that, the Options tab has the standard Insert in Walls functions that symbols can have. Click OK to close out the dialog box. One more step before you can really get coding is to insert your new tool into the workspace. To do this, exit out of the Plug-in Manager and open up the Workspace Editor by going to Tools - Workspaces - Edit Current Workspace. You will find your new tool in the "Tools" tab in the left box under the category that you specified (or "Miscellaneous" if you did not specify a category). Click and drag your tool from the left box into the desired toolset in the right box. Click OK to close the editor and reset the workspace with your added tool. The code I used is listed below and also attached it to this post as "Concentric Reducer Simple.vso". I've added comments explaining how it is set up. Vectorscript is based on Pascal, so there's a couple of things that can be odd if you're used to more modern languages like Python or Java. PROCEDURE ConcentricReducer; {All methods in VS are either Functions or Procedures. Functions return a value, procedures perform a set of operations, though they can also return a value if you need to. To do so, specify a variable in the constructor with a VAR flag in front of it} {* Creates a 3D Solid object representing a Concentric Reducer pipe fitting Developed by: Jesse Cogswell VW Version: 2019 Date: 5/1/2021 Revisions: *} CONST {This is the constant declaration block. All constants in VS must be declared and initialized in one of these blocks. You do not need to specify types here, VS will determine the type based on the entered value. This block is not necessary if you have no constants, it's provided here by way of example} DUMMY = 0; VAR {This is the variable declaration block. All variables in VS must be declared in one of these blocks before it can be used. This particular one is the global variable block. Here, we'll declare the parameter variables} lineLength,diameter1,diameter2:REAL; {Between this point and the main driver block, you can specify any number of procedures and functions as necessary. VS compiles from top to bottom, so if you call a procedure, make sure the definition appears above the call} PROCEDURE CreateReducer(length,dia1,dia2:REAL); {Here is the procedure that actually creates the 3D solid. It takes in the length and two diameters and creates the object} {Creates 3D Solid based on given variables} VAR {Just as above, this procedure has its own variable declaration block. The variables declared can only be used within this procedure definition} Origin,A,B:POINT; sweepHd:HANDLE; BEGIN {I usually specify an Origin point but don't initialize it, this ensures that it will read as (0,0)} {Point types are a special Structure within VS which contains an X and a Y value. This information can be accessed by calling <point name>.x or <point name>.y} {Other special Structures include POINT3D, VECTOR, and RGBCOLOR types} {You can define your own Structures in the TYPE declaration block, though it's a bit more of an advanced usage. Information can be found in the Language Guide in the "Structures" chapter} A.x:=Origin.x+(dia1*0.5); A.y:=Origin.y; B.x:=Origin.x+(dia2*0.5); B.y:=Origin.y-length; BeginSweep(0,360,10,0); Poly(Origin.x,Origin.y,A.x,A.y,B.x,B.y,Origin.x,B.y,Origin.x,Origin.y); EndSweep; sweepHd:=LNewObj; HRotate(sweepHd,Origin.x,Origin.y,90); {Because of the nature of Sweep command, the outlining shape is created 90 degrees off from the created line and then rotated in place} END; FUNCTION CreateReducerH(length,dia1,dia2:REAL) : HANDLE; {Here is the same code as above but as a function to return a handle to the resulting object. This is useful if you wanted to use another procedure to change the object later, such as setting color} {Creates 3D Solid based on given variables and returns a handle to the resulting 3D Solid} VAR Origin,A,B:POINT; sweepHd:HANDLE; BEGIN A.x:=Origin.x+(dia1*0.5); A.y:=Origin.y; B.x:=Origin.x+(dia2*0.5); B.y:=Origin.y-length; BeginSweep(0,360,10,0); Poly(Origin.x,Origin.y,A.x,A.y,B.x,B.y,Origin.x,B.y,Origin.x,Origin.y); EndSweep; sweepHd:=LNewObj; HRotate(sweepHd,Origin.x,Origin.y,90); CreateReducerH:=sweepHd; {This is how you specify the returned value, it's <Function Name>:= <variable>} END; {MAIN DRIVER BLOCK} BEGIN {At the beginning of the Main Driver Block, I will always transfer the OIP parameters, accessed using the syntax "P<parameter name>" into global variables. This is a personal preference, and you're welcome to just use the P<parameter name> call everytime you need the variable} lineLength:=PLineLength; diameter1:=Pdiameter1; diameter2:=Pdiameter2; CreateReducer(lineLength,diameter1,diameter2); {Best practice is to think in a modular fashion, with most operations being outside of the main driver} {Below is an example of the using the function instead of the procedure to create the object. Note that the handle would need to be declared in the global variable declaration block before this code could be used} {reducerHd:=CreateReducerH(lineLength,diameter1,diameter2);} END; Run(ConcentricReducer); {Final run statement to execute the script} Also attached is a similar script, "Concentric Reducer.vso" that will incorporate wall thickness to draw a more realistic tube shape. I won't go into the code here, but you are welcome to open it and noodle with it. There is probably a much more simple mathematic method of determining points for wall thickness, but as someone who hasn't studied trigonometry since high school, I opted to use an OffsetPolyN and IntersectSurface solution instead. Let me know if you need any help installing or opening these plug-ins, as the process is a bit complicated. Concentric Reducer Simple.vso Concentric Reducer.vso
  11. There used to be a pretty good primer for Vectorscript in the native help file for Vectorworks, but they removed it at some point. I've attached it below. It's old, but Vectorscript hasn't changed much in the last 10 years since it's based on Pascal, which first appeared in 1970. Vectorworks has incorporated Python, which is a much less esoteric and more powerful language, but you're still hamstrung by the Vectorscript function library when you want to interact with VW, so it only really helps for data management. Another terrific resource is the Vectorscript Function Reference, of which an offline version is installed alongside Vectorworks. No idea about where it ends up on a Mac, but on windows it can be found in C:\Program Files\Vectorworks 20XX\VWHelp\Script Reference\ScriptFunctionReference.hml. I usually have this open on a second monitor any time I'm working in Vectorscript. I will warn that it's not exactly complete, some functions have no information at all other than outlining the constructor, and some are fully fleshed out with examples (though sometimes the examples can be less than helpful). The Developer Wiki site that others have posted about is also a good resource, as it can sometimes fill in the holes in the local version, but I find the local version much easier to navigate. VectorScript_LanguageGuide.pdf
  12. That can be tricky on Mac. ETC Eos (https://www.etcconnect.com/Products/Consoles/Eos-Family/) is what I use and there is a Mac version, but you will need a Nomad dongle or physical console to get the software to output to Vision, so unless you have one of those things, it probably won't help much. Chamsys MagicQ also has a Mac software (https://chamsyslighting.com/pages/magicq-downloads). I've never used it so I don't know if you can get ArtNet or sACN output to Vision without having physical hardware, but it's worth a shot. Otherwise, there's Obsidian Onyx (https://support.obsidiancontrol.com/Content/Support/Downloads.htm) which I know can output sACN with the free software, but only appears to have a PC version. I'm afraid that you might not find too many users of Vision on the forums. Of the major previsualization softwares, Vision tends to be the least used, with Capture, L8, Depence2, and WYSIWYG being much more popular. I personally went with Vision because of the ease of getting a file out of Vectorworks quickly, but with the recent MVR export standard, this is now much less of an issue for other software. I mean, the built in visualizer in GrandMA2 and 3 do a damn fine job of visualizing moving lights, and the Chamsys visualizer is no slouch either. The ETC Eos software also has a similar tool called Augment3d, but it's a programming tool first with the previsualization being pretty substandard.
  13. I have some ideas of how to make this work. Would it be possible for you to post a file with different configurations or examples of what you want to see? I might be able to work on this over the weekend.
  14. I've never had a viewport generate a locus point, it's most likely that the locus point is somewhere on one of your design layers or embedded in the annotations space of the viewport (but unless you're generating the viewport through a third-party script, that locus point would need to have been placed by someone...). The way I would go about tracking it down would be to edit the viewport crop and see if I can crop out the locus point. If I can, it would tell me that the point is on a design layer. If I can't, the locus point would most likely be on the annotation layer of the viewport. If it is on a design layer, select the viewport, click on the Layers button in the Object Info Palette, and make sure all layers are set to "Not Visible." The result should be an outlined red box with red lines connecting the corners to form an X. Then, one by one turn the layers back on. When the locus point becomes visible again, that will be the design layer containing it. Then, double-click the viewport and select Design Layer, and the offending design layer from the drop-down menu. You should then be able to delete the locus point. If this does not work, could you post the file, and one of us could try to track it down? As far as I know, there's nothing in the process of creating a viewport that should generate a locus point on its own.
  15. There is for sure something wonky happening in VW2020. I opened this first in 2021 SP3.1 and it looked exactly as you would expect, so I opened it in 2020 SP5 and I'm seeing exactly what you are seeing. There appears to be a but where the focus orientation cannot be -90. Moving the focus point or the fixture 0.01" in either direction on the Y axis seems to alleviate the issue. At this point, I don't think VW will fix this in 2020, as it appears to have been fixed already in 2021. As a workaround, I would make the focus point objects on the SL side of the center 0.01" higher on the Y axis. That way your beams draw correctly and your fixtures are still in the correct position. Annoying bug, though.
  16. @Ross McLee Hmmm. The script should center the viewport for you. When viewports are created, they are created in relation to the existing page center on the design layer. I'll look back at this script when I get some time, maybe I don't have it read in the existing page location. It certainly centered the viewports in my testing. Ah, just tried playing around with it. It gets screwed up if your User Origin is different than the Internal Origin. If you run Tools-Origin-User Origin and select Set User Origin to Internal Origin, this should correct this. This is a big pain point I have with Vectorworks, as the Internal Origin is poorly explained but is what the GetOrigin VS command references. A lot of draftspeople start a drawing without regard to the Internal Origin, then set a User Origin later. There is no direct coding in VS to get the User Origin, you instead have to use a GetPrefReal(6702) and GetPrefReal(6703) and convert the units. So, if I'm feeling lazy and writing scripts for free, I tend not to put that scripting in. After I started scripting, every single one of my drawings is very cognizant of where the Internal Origin lands, usually on CL-PL intersection. When I get a moment, I'll add in the scripting to compensate for the User Origin, but that will probably be in a couple of days.
  17. I've seen this quite a bit in 2021. I find that changing to a different layer and back fixes the issue and can be done without losing the current view.
  18. Okay, done bashing in a script for you. This script performs the following actions: Prompt the user to enter a starting value for the device index. This allows you to add devices later and maintain the current index count. If you always want to start the count at 1, then comment out line 96 (the line with the IntDialog function). Also, if you want to change the prompt question to German, just edit the sIndexInput variable in the LoadPluginStrings procedure. Polls current layer using GetLName(ActLayer) Strips existing suffix from selected objects using the SubString function and "-" as a delimiter. If you want a different delimiter, change the sDelimit variable in the LoadPluginStrings procedure. So if you have something like "projector-media room-01", this will reset to just "projector". This allows the script to be run on objects if they move to a different layer or change Device Names, or if they are copied and pasted from a device which already has a suffix. Builds an array of strings selected Device Names. This allows multiple Device Names in the selection to be counted separately. Uses a FOR loop with the Device Name array to go through one Device Name at a time using ForEachObject to add the suffix to the device name and tag. The current format is Device Name-Layer Name-Index (as in "projector-media room-01"). The script will add in a leading 0 to indexes below 10 (so an index of 9 will be changed to 09). A COUPLE IMPORTANT CAVEATS: The Device Name and Tag cannot contain a "-" (or whatever delimiter you choose) as the data will be stripped off. So you can't have a device name be something like "mixing-console" as this will be shortened to "mixing" with the script. The index will be determined by creation order. VW always goes through order of creation when using ForEachObject, so the first Device with a Name of "projector" will be given an index of 1, with the next created Device getting an index of 2, etc. So if you're wondering why the counting seems off in terms of where Devices are in relation to each other, that's why. I do not have ConnectCAD, so I was only able to test it on a couple of dummy objects that I attached the Device record to. It all worked properly in the testing, but let me know if there are any oddities that appear. Code is pasted below. Let me know if you need any help with it or if you want any help adding it to your permanent workspace. PROCEDURE DeviceLayerSuffix; {* Polls selected Device objects on the active layer and appends the layer name and an index to the Name and Tag fields Developed by: Jesse Cogswell Date: 4/26/2021 VW Version: 2021 Revisions: *} VAR {Plug-in Strings} sIndexInput,sDelimit,sDevice,sName,sTag:STRING; {Other variables} currLayer,currDevice:STRING; devNames:DYNARRAY[] OF STRING; devCount,devIndex,devIndexOffset,i:INTEGER; blah:STRING; PROCEDURE LoadPluginStrings; {Loads plug-in strings into variables} BEGIN sIndexInput:='Enter Starting Index Number:'; sDelimit:='-'; sDevice:='Device'; sName:='Name'; sTag:='Tag'; END; PROCEDURE PollSelectedDeviceNames(h:HANDLE); {Polls selected Devices and builds array of Device Names and strips current suffix} LABEL 99; VAR fullName,name:STRING; j:INTEGER; BEGIN fullName:=GetRField(h,sDevice,sName); name:=SubString(fullName,sDelimit,1); SetRField(h,sDevice,sName,name); ResetObject(h); IF(devCount=0) THEN BEGIN devCount:=1; ALLOCATE devNames[1..devCount]; devNames[devCount]:=name; END ELSE BEGIN FOR j:=1 TO devCount DO BEGIN IF(devNames[j]=name) THEN GOTO 99; END; devCount:=devCount+1; ALLOCATE devNames[1..devCount]; devNames[devCount]:=name; END; 99: {End} END; PROCEDURE UpdateDeviceName(h:HANDLE); {Appends layer and index to given Device object's Name and Tag fields} VAR name,fullTag,tag,strIndex:STRING; BEGIN name:=GetRField(h,sDevice,sName); fullTag:=GetRField(h,sDevice,sTag); tag:=SubString(fullTag,sDelimit,1); IF(devIndex<10) THEN strIndex:=Concat('0',Num2Str(0,devIndex)) ELSE strIndex:=Num2Str(0,devIndex); SetRField(h,sDevice,sName,Concat(name,sDelimit,currLayer,sDelimit,strIndex)); SetRField(h,sDevice,sTag,Concat(tag,sDelimit,currLayer,sDelimit,strIndex)); ResetObject(h); devIndex:=devIndex+1; END; BEGIN LoadPluginStrings; devIndexOffset:=1; devIndexOffset:=IntDialog(sIndexInput,'1'); currLayer:=GetLName(ActLayer); devCount:=0; ForEachObject(PollSelectedDeviceNames,(SEL=TRUE) & (R IN [sDevice]) & (L=currLayer)); FOR i:=1 TO devCount DO BEGIN devIndex:=devIndexOffset; currDevice:=devNames[i]; ForEachObject(UpdateDeviceName,(SEL=TRUE) & (R IN [sDevice]) & (L=currLayer) & (sDevice.sName=currDevice)); END; END; Run(DeviceLayerSuffix);
  19. Sorry for the delay, it's been a very busy week, but I have today and tomorrow off so I can take a look at this. Based on your first post, it appeared that you wanted to have the script both append the container layer as well as an object index number, but in your last post, it looks like the device name already has an index number and you would be instead just add the design layer. Either of these options are easily done, I just need to know which you are going for. Next, I need to know how you plan to use the script as there are a couple of different options: Does this command want to apply to ALL of the devices of a certain type in the drawing? It would be relatively simple to write a script that generates a dialog box with a pop-up menu populated with all Device Names found in the drawing, allowing you to select one and click "OK" and have every one of those objects with the selected Device Name to have their Device Name updated with their layer and an index (unique to the layer or to the drawing as a whole). I can also make it so that you can select a Device Name and a Layer, so that the command only runs on one device and one layer at a time. Or I can make it only work on selected objects, regardless of Device Name or layer. The perk of this is that it will work without a dialog box, simplifying the code quite a bit. Final question, what is the Device Tag? Is it different information than the Device Name (assuming so, since it's a different field).
  20. There's a couple of things here. Right now, based on what you are showing in VW, the devices aren't properly mapped. Both the Send to Vision and Export- ESC or Export - MVR commands ignore the "Instrument Type" field in the Object Info Palette. What the export is instead looking for is the "Fixture Mode" field in the OIP. Since I don't see it in yours, you'll want to make sure that it is visible by going to Document Settings - Spotlight Settings, clicking on Lighting Devices-Parameters in the left list box, and making sure that Fixture Mode has "Show in Shape Pane" clicked on. The Fixture Mode tells Vision what Vision profile to use for the device, and clicking on the drop-down should show the possible profiles. If you are using a custom symbol (which it sounds like you are), this drop-down will likely show two options, "None" and "Other." Clicking "Other" will launch a dialog box containing the full library of Vision fixtures sorted by manufacturer. Select your desired profile here (in this case, Martin MAC Encore Performance CLD). If you would prefer to use the GDTF format, you will instead need to go to the GDTF-Share page and download the GDTF file, import it in to your VW using Import - GDTF, then set it using the "GDTF Mode" field of the Object Info Palette. Generally, I prefer to use the Vision symbol, resorting to the GDTF only if the Vision symbol doesn't exist and if I don't have enough time to wait for Vision to build one (there's a fixture request form on the Vision Service Select page. They're generally pretty quick, taking about a week or so). Now then, on to exporting. I would advise against using the Send to Vision command, as I find it a little more useful to parse things out in the export to keep things organized in Vision (old habits, older versions had a bug where moving things around in the Scene Graph would crash Vision, so I would organize it using strategic exports). The Send to Vision command will take everything visible and export it using the ESC format, which is mostly an outdated format at this point. The preferred format is the MVR format, found under Export - MVR. This corrects some of the geometric oddities on 3D objects caused by VW and corrects the normal mapping, making Vision rendering much more realistic. It also allows for updating of the file later, as merging in an updated MVR file into your Vision file will only affect objects that have been changed since the last MVR file import. It's a little clunky and not all together flawless, but it is a bit better than the old merging ESC file process. There are a couple of bugs with the MVR export to keep an eye on. Conventionals usually don't track their color across the export, so you'll likely have to re-drop color in Vision, which can be a drag. I've also seen a couple of bugs where Lighting Position objects don't properly come over in the export, but I think they might have fixed that in the latest Service Pack. I have also seen a bug where the entire file comes across in the MVR export regardless of whether it's visible or not in VW, so I've gotten into the habit of doing exports with "Selected Objects" instead. I hope this was helpful. Let me know if you have any questions. I don't work for VW but have been using Vision regularly since Nemetschek acquired ESP Vision in 2017 and have found workarounds to a lot (but not all) of the bigger quirks.
  21. This is certainly possible with a script but might be out of reach with Marionette (I find it far faster to script something like this as it's faster for me to type everything out compared to the thousands of clicks a similar Marionette script would require). I don't have ConnectCAD, so I don't know what the needed Records and Record Fields are, but what you're describing is easily achievable using a ForEachObject call to find objects with a matching record field (device name), on a target layer, then using GetRField to pull that information, Concat to put it into a single string, the using SetRField and ResetObject to reapply that string to the Device Name field. I'm a little busy this week, but if you get me the record and field information for ConnectCAD devices, I can draft up a script for you. It would even be feasible to make a GUI with a drop-down for device type and layer to help with selection.
  22. It appears that you can't auto-fit column width, but you can auto-fit row height (if it's any consolation). Select a row, right click on the row header on the left, and select "Row Height" (or go to Format - Row Height). There is a radio button for Auto Fit Row Height. This would also require the cell to be set to wrap text. Too bad that we can't do that with column width as well.
  23. Dumb question, you don't have any hidden columns/rows or merged cells in your Google Sheet, do you? I copy and paste things from Excel a lot, but don't think I've ever tried from Google Sheets.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...