Jump to content

Robert Anderson

Vectorworks, Inc Employee
  • Posts

    3,233
  • Joined

  • Last visited

Everything posted by Robert Anderson

  1. Suukmel, thanks for your reply. I understand your issues much better and will give some thought as to how we can "free up" the stair object. To address your issues: 1. Techniques for "Y-joining" of walls are addressed in the VectorWorks Architect documentation. I don't know if your office is using VectorWorks or VW Architect. 2. To obtain a specific offset of a wall-inserted object (e.g. door or window), you can use the 'Offset Insertion' mode of the symbol tool. (see p. 10-13 of the VW852 manual or p. 11-11 of the VW901 manual.) Once you've placed a door or window in the wall, and want to change its offset, it's easy to do using the "Position" button in the Object Info palette. Just select the object, click the Position button, and you'll see a picture of the object and its wall. You can set the exact offset in this little picture dialog. 3. Cabinets (at least in VW900 and later) are set to insert along the surface of a wall without breaking it. You can change this behavior by using the Create Plug-in Object command. This command is documented in the VectorScript Language Guide (I strongly recommend the on-line version availble in VW900 and later). Look at "Setting options for the Object", page 12-3.
  2. Suukmel, I'm a little confused by your statements. You say that because you don't find enough flexibility in where the _2D_ break goes, you won't draw in _3D_? Seems contradictory. Please explain further, and also if possible explain your office standards for drawing stair breaks (so we can improve the stair object accordingly). In any case, there's an easy workaround for your problem. Simply draw the stair with _no_ 2D breaks and draw a "blocking" polygon with opaque fill to hide the portion of the stair you want hidden. Then draw a line or use a "break line" object to close the break. If this is unclear, I can send you a simple MCD file demonstrating this technique. If you want this, email me directly at mailto: randerson@nemetschek.net
  3. Ah! In that case use the "cased opening" option on the simple door 2.
  4. Wall openings were discontinued in 9 and replaced with a variant of the Simple Window. The command "Update to V2 Objects" (it's discussed in the readme file) will update your old style wall openings to new style with the same settings.
  5. 1. Classing;1.1. If you're placing the stair using the Stair Tool you can set its default class by opening the Create Plug-in command on the Organize menu, then scrolling down to the stair, selecting it, then clicking the Properties button. Then you will see a dialog that allows you to set the default class of an object placed with a tool.1.2. If you're placing the stair from a red symbol, you should open the library that the red symbol is in, and using the resource palette, change the symbol insertion properties to be the class you want (see VW9 manual p 11-19). 2. The 2D break is not moveable. The bug with the handrails disappearing was fixed in VW 9.01. HTH, Robert
  6. In VW 852, stair objects were auto-classing in the class 'Vert Trans-Main' (for VERTical TRANSportation). You should have this class visible and your class options should be 'show other classes' or less restrictive. My guess is that in fact you HAVE been placing the stairs; you just need to turn on their class...
  7. I believe this is a known bug, however I would still recommend that this issue be sent to mailto:bugsubmit@nemetschek.net as it is a bug report about our current public beta.
  8. As I say above, this is a bug (<default> setting not recognized) and the workaround for this is to enter an explicit class in your wall type. Then autoclassing works fine.
  9. Now you're describing a different problem. In the posts above I asked if a wall was drawn in a class different to the one explicitly assigned to it. That is what I tested, and this did not occur. Now you're saying that the problem occurs when the wall type has type has the class <<default>> set. I'm able to reproduce this, and will enter it in the bug list. The workaround for this is to enter an explicit class in your wall type, as the <<default>> entry seems not to work.
  10. jnr, I have tried to reproduce your problem but don't observe it happening. Here's what I do: In a document set up with Setup Assistant, I do the following: 1. Menu command: Select Wall type;2. SWT Dialog: push 'Add' button;3. New Wall Type dialog: choose 'Wall-Ext-Veneer' from the 'Assign to Existing Class' dialog; fill out other settings appropriate to a brick-on-CMU wall;4. Click OK;5. SWT Dialog: select newly-created wall type, click OK;6. Back in document: Use Wall Type tool and draw serveral of these walls;7. With wall selected, look in Object Info palette. Walls are 'Wall-Ext-Veneer' as expected.
  11. jnr, are you saying that the wall class defined in the wall style is 'Wall-Ext-Veneer' and the class assigned to the wall by the Wall Type Tool is 'Wall-Int-Full'? This obviously should not happen. I unfortunately can't reproduce your exact situation without all your external preferences files. Please re-check that the wall style you are using has the desired class.
  12. This situation is what the 'Modify Layers and Classes' command is made for, page 3-14 of your VectorWorks ARCHITECT manual.
  13. You yourself can make them autoclass using the script I posted above. I've put in our wish/bug-list for VWA the library list so this can make it into a future version.
  14. Please read my post above. The ***ONLY*** way autoclassing is implemented in VWA9.x is using the libraries in the object browser. Using the tools to place the objects will no longer auto-class. This is done because many objects are shared between VW and VWA and many casual VW users didn't want the system automatically making classes.
  15. I will summarize: Objects inserted from the default VWA libraries will auto class. Objects inserted from the "standard" VW libraries (which I listed last post) do not currently autoclass; These ought to autoclass in VWA if the autoclassing option is chosen by the user. None of the objects do or will autoclass when placed with an object tool palette (I assume this is what you mean by "tools on the menu bar"?). Autoclassing is available through the Object Browser libraries only. I was confused about your script reference. Here it is, cut and paste into a script palette to use: ================= Procedure Myproc;varhSD: handle;symname,classname,classdummy: string;insertdummy,breakdummy:INTEGER;beginclassname := strdialog('Enter the desired default class for all symbol defs this document','None');hSD := fsymdef;while (hSD <> NIL) do begin symname := getSDname(hSD); getsymboloptionsN(symname,insertdummy,breakdummy,classdummy); setsymboloptionsN(symname,insertdummy,breakdummy,classname); hSD := nextsymdef(hSD); message(concat(symname, ' - ',classname)); end;clrmessage;end;run(Myproc);
  16. These items autoclassed from the object tool in 852. We had users complaining about us "creating all these unwanted classes". So our approach was to remove the autoclassing from the object itself and restore the autoclassing to the symbol in the Object Browser (and give the VWA user the option to install the classing or non-classing OB libraries depending on if he was using our standards or his own). So to make a long story short, objects in VWA libraries still autoclass if you work from the Object Browser (and if you've installed the default libraries.) However, you are correct that default VW libraries do not autoclass any more, and for those users using VWA it might be nice to have classing versions of those libraries. I see the libraries affected as:Drafting Tools.mcdOffice Cubicle Furniture.mcdOffice Equipment.mcdOffice Furniture.mcdResidential Furniture.mcdSite Planning.mcd As regards the script in the other forum, why not just copy it out of the other forum posting and paste it into a script palette?
  17. You said:"Yes I was referring to the detail cut wood object. As an architect, you are well aware how picky we are about graphics. The "x or /" indicating continuous or blocking lines do not change thickness when one changes the line weight of the object. This is espically annoying when one is detailing headers or attempting wall sections at 1/2" scale. Things turn to mud quickly. This was not the case in 8.5.2" I hate to contradict you here, but this is _exactly_ how this object behaved in 852. The inner slash(es) are (and were) fixed at 3 mil, which is a (quite light) 2-pixel line on a 600dpi printer. The lineweight of inner lines is kept light precisely to keep the drawings from getting "muddied up". You also said: "One other comment about graphics. The doors and windows inserted into walls drawn with the wall tool have lost the graphical refinement achieved in 8.5 (yes I know about the line scale tool added in 9.beta.beta). Doors and window jambs got fat and you can' make it look like it is actually built the way you could in 8.5." The doors and windows in VWA9 added a "Wall Line Scale" parameter so you can scale the line weight of the door to be lighter than the line weight of the wall it's inserted into. The graphical refinement of the door and window objects is actually greater than that of either VW 852 (where all line weights in the object had to be the same) or VA 1.x (where the doors and window cut plane picked up the 'cut plane' weight of the wall but couldn't be diminished.) So I'm not sure what your problem is here? Lastly, talking about the structural shapes, you said: "In version 8, the list cascaded across the screen making it relatively easy to pick what you needed. Reducing the list to a single column is insane. What was wrong with the way it worked before?" What was wrong with the way it worked before was that it didn't always work. If you didn't have your screen resolution and text size system settings just so, you couldn't see all the options. They literally would fill the screen, and the Windows operating system doesn't give you any standard way of handling a super-long list that does this. Hence our current solution. If you have certain sizes you use frequently, you can make them into symbols. Or, you can use the following script to enter the size of a selected beam into a field: ================ procedure setbeam; beginsetrfield(fsactlayer,'Wide Flange (Inch)','size',StrDialog('Enter the size of beam:','W8 x 10'));setclass(fsactlayer,getclass(fsactlayer));end; run(setbeam);
  18. jnr, you mention "wood framing". What feature are you referring to? The Detail Cut Wood object? If so, how has it "devolved" in v9 vs. v8?
  19. When using the setup assistant in VWA9, enter a negative number (-1) in the Vertical Setup dialog to set up a basement. See page 3-6 in the VWA9 manual.
  20. I'm not sure what you're talking about here. Normally, you can use a symbol made from a window object to use as a skylight. What specific roof.mcd file are you talking about? Is this in the manual?
  21. vulcangrip, to help you, I need some info: -What platform? -What version of VW or VWA?
  22. I have good news for you on this item. This behavior has been fixed as of the VWA 9.5 beta 5. The Assign Room Finish tool now will properly "pick up" finishes assigned to a Room Name object when editing. You can either download the beta and begin working with it, or (if you don't have the stomach for working with a beta, which I fully understand) wait for the release of VWA 9.5 and update at that time.
  23. It's sort of in the manual, and a thorough reading of the VW9 manual chapter 16 will help. (Terms enclosed in asterisks are defined in that chapter.) What you will do, briefly, is enter in the column of the *database header row* that you want to hold your special data, a *formula* that is specified by "=RecordName.FieldName" (not including the quotes). This process is documented beginning on page 16-29 of the VW9 manual. HTH, Robert.
  24. You must use the Data Pane of the Object Info palette to enter custom field information such as this.
×
×
  • Create New...