Jump to content

Markus Barrera-Kolb

Member
  • Content Count

    343
  • Joined

  • Last visited

Everything posted by Markus Barrera-Kolb

  1. We use automatic drawing coordination in part to automatically match the sheet titles in our custom title block with the sheet layer names. These are set as multi-line fields using the # suffix. However, we really wish these two limitations would be eliminated: 1) The only way you can enter a multi-line title is through the Edit Title Block dialog. You presently cannot enter a multi-line title by editing the sheet layer name and you cannot enter a multi-line title using a worksheet – please make it possible to enter multi-line fields in worksheets and when editing sheet layer names (presumably using a soft return)! After all, worksheets are obviously able to display multi-line fields, so why not allow us to edit them there as well? 2) Only the first line of multi-line titles is used as the sheet layer name – please allow the full title to be shown in the sheet layer name!
  2. I've had all of my sheet border objects and title blocks disappear from one of my current VW2016 files – I can see them when I query for them in a custom selection of worksheet database row, but I can't select them and I can't see them in the drawing. Not a class or class visibility issue, I've quadruple-checked that.
  3. Yup, spoke with support and also suggested it as a feature for future releases. In the meantime, I discovered that the H&V offsets for the 3D ID tags are fields that can be set within a worksheet, so I made a quick worksheet that makes it possible to center the 3D tags for all windows in two quick copy-and-paste operations (made one for doors as well). Cheers, Markus
  4. Just discovered this old thread – is there no way to automatically center the 3D tag on each window regardless of its size and proportions? Silly to have to adjust that V & H number for each differently sized windows in order to get the 3D tag in the right place...
  5. With 2016 we've lost the Z coordinate field in the OIP for the DTM. Presumably NNA wanted to discourage users from modifying the DTM heights by just moving the whole thing vertically. However, you still CAN move it on the Z axis, only now there's no easy way to tell whether this has happened accidentally! We've always made a practice of keeping our DTMs at 0,0,0, so we know that they're where they're supposed to be – now that no longer works. What would be really great is if the DTM could be locked in place, the way design layer viewports can, then we wouldn't have to sweat this issue. And if the DTM can be moved vertically, then we should be able to see its Z coordinate. Cheers, Markus
  6. Hi Marissa, sorry, looks like I'd uploaded the wrong file. I switched to "Objs by Crit" to make the script slightly more user-friendly, but it does ook like it'll freeze VW with either node if it doesn't find an object that matches the criteria, so it'd be great to be able to solve this with an if statement (or some other solution?)! I imagine that in order to save the script as a menu command I'd still have to be able to compile it – perhaps there's another compiler out there that can handle the excess length? Is anyone else familiar with something that would do the trick? Thanks so much! Cheers, Markus
  7. Hello, I am still trying to figure out whether there's something that can be added that will prevent the script from freezing VW if the first "Objs by Crit" does not find an object that meets the specified criteria. This little glitch certainly makes the script less user friendly! Thanks! Cheers, Markus
  8. ...I take it back: I was able to remove the additional last label (I've circled the added nodes). Thanks!
  9. Thanks Marissa – that's fantastic! The only thing I noticed is that the last label is placed twice, and with my limited skills, I've not been able to remedy this. Also, I've noticed that if the footprint polygon is not correctly named, the script freezes the whole app. Is there a way to use an if/then statement to prevent this and perhaps display a message along the lines of Footprint polygon needs to be named "AEG footprint" if the name is not present? Finally, is there a way to save to and run this from the resource browser or a script palette? I've seen that it's possible to save the Marionette script as a Python script, but then when I try to paste the Python code into a new script I get the message that the Script Editor cannot save a script with more than 32001 characters, and it looks like File>Import Script only executes a script immediately Thanks again, I so appreciate all of your help on this! Cheers, Markus
  10. It would be great to be able to lock worksheet cells to protect them from accidental editing. And I remember also posting a request for this in the past: it would be very helpful if the row and column labels of the selected cell(s) were highlighted – it would make it much easier to tell what cell you're in, especially in larger worksheets.
  11. It's very frustrating not to be able to get the ZCENTER and length for 3D polys in worksheets, and it seems like this should be a pretty straightforward function – please add this capability! Cheers, Markus
  12. Hello Michael & Art – thanks for your suggestions! 3D polys can certainly be non-planar, and yes, there's the open question as to whether one would want to find the volumetric center or, say, the Z coordinate at the poly's linear midpoint. In my current application, this question is inconsequential, as I'm exploring the possibility of using single-segment lines, i.e. polys or NURBS, sending them to the surface of a DTM (if you do this with 3D polys while they're grouped they will not be draped over the DTM but rather have their midpoints set to grade), and then using their elevations & lengths to calculate Average Existing Grade for a given building footprint. I've also been corresponding with Marissa about using Marionette to automate this process, but somehow I still like the idea of using a database row within a worksheet to perform this task... I'll add the ability to obtain the ZCENTER for 3D polys and NURBS curves in worksheets to the wish list! Cheers, Markus
  13. Thanks so much Marissa! I was able to combine the two scripts and get the expected results. I've changed the expected name for the poly to "AEG footprint" and the output name for the worksheet to "AEG data". A couple of remaining pie-in-the-sky items would be: automatically add the data to the "Diagram - AEG per DR 4-2012 (Marionette)" worksheet starting at row 7 (though a simple copy & paste isn't that big a deal) place something like an elevation marker (or custom symbol) instead of a locus change the text to vertically centered justification & rotate it, say, 45° If I understand correctly, you wrote the "Site Z Height" node from scratch, right? How about the worksheet nodes? I don't see those in the list of available nodes using the Marionette Tool... I'll attach the updated file for your reference – thanks again! Best, Markus
  14. I think this has at least in part come up in the past: I'm looking for a way to extract both the Zcenter and length of 3D polys in a worksheet. Neither ZCENTER, ZCOORDINATE, LENGTH, nor PERIM yield anything at all. Seems like pretty basic information that should be easy to extract. Any help is greatly appreciated, as always! Thanks, Markus
  15. Thanks so much for the file, Marissa. Here are the DTM and AEG elements from a file I'm currently working on. The footprint in many jurisdictions is formed by the outermost walls, including overhead cantilevers, so we typically just draw a polygon (I suppose a space would do just fine as well). The file also includes the worksheet we've been using to date...
  16. Hello all, I haven't gotten to dig into Marionette as much as I'd like, but am hoping I can get some feedback as to whether the following is possible... We often have to calculate average existing grade for building departments in the following manner: 1) trace the footprint of the proposed building 2) measure the height of the existing grade at the midpoint of each line (wall) 3) measure the length of that footprint segment With the Z-coordinates of the midpoints and each segment's length, we then calculate the length-weighted average height for the footprint as a whole. Presently we're manually placing Stake Objects along line midpoints at the footprint segments (sent to the surface of the 'existing' DTM with Send To Surface); point ID numbers and segment lengths are entered manually, and the whole thing is then calculated in a worksheet. Ideally Marionette would allow us to just trace the footprint with a polygon or polyline, and then place the 3D points automatically (with labels displaying an index number and the elevation) and then provide the Z-value and segment length to the worksheet. Within the realm of do-ability? Thanks for any and all feedback! Cheers, Markus p.s. attaching a screenshot of a typical AEG calculation...
  17. These improvements would greatly enhance the usefulness of VW's parametric window (and door) objects in our workflow: allow the shim gap to be hidden in 3D view (but optionally displayed in 2D) allow for a drywall (or whatever your wall finish is) wrap with a variable offset from the outside of the jamb (frame) for sides (jambs) and tops (heads) at the interior allow for separate control of interior and exterior sills allow for exterior jamb liners (not all windows & doors are set at the exterior surface of the wall!) allow for offset from the interior face of the jamb (frame) for the exterior trim – the current alignment makes no sense and has no basis in reality (I've never seen trim covering the entirety of the window frame!) pie in the sky: allow for the exterior wall finish to be lapped over part of the frame at the jambs & head (we often over-insulate part of the frame in our super-insulated envelopes and then extend the cladding, as in the attached details) As it stands, we end up having to model our trim from scratch, sometimes our exterior wall finish from scratch, and doing a bunch of cleanup and manual 2D work to make our interior elevations reflect reality – that's not particularly effective BIM(ing). Cheers, Markus
  18. Thanks Raymond and Wouter – I'd tried SetPref and GetPref with 506, and of course it didn't work, but I couldn't figure out why. Shorter and simpler is pretty much always better... Cheers, Markus
  19. Thanks Raymond and Wouter – I'd tried SetPref and GetPref with 506, and of course it didn't work, but I couldn't figure out why. Shorter and simpler is pretty much always better... Cheers, Markus
  20. You're right Bill! Some poking around and trial and error yielded this – I think this one might work: PROCEDURE Toggle_DisplayScreenObj; VAR layopt:INTEGER; BEGIN SetPref(95,NOT GetPref(95)); layopt:=GetLayerOptions; SetLayerOptions(layopt); END; RUN(Toggle_DisplayScreenObj);
  21. Had just started a separate thread about what turns out to be the same issue – the following script now works for me. It re-sets the Layer Options to the current setting, and thus forces a redraw that for whatever reason does the trick when REDRAW and REDRAWALL do not: PROCEDURE Toggle_DisplayScreenObj; BEGIN SetPref(95,NOT GetPref(95)); SetPref(506, GetPref(506)); END; RUN (Toggle_DisplayScreenObj); Cheers, Markus p.s. As some of you may have noticed, in 2016 any scripts you add to your Document Context menu cannot be run via keyboard shortcut – weird! Adding them to another menu instead solves the problem...
  22. Had just started a separate thread about what turns out to be the same issue – the following script now works for me. It re-sets the Layer Options to the current setting, and thus forces a redraw that for whatever reason does the trick when REDRAW and REDRAWALL do not: PROCEDURE Toggle_DisplayScreenObj; BEGIN SetPref(95,NOT GetPref(95)); SetPref(506, GetPref(506)); END; RUN (Toggle_DisplayScreenObj); Cheers, Markus p.s. As some of you may have noticed, in 2016 any scripts you add to your Document Context menu cannot be run via keyboard shortcut – weird! Adding them to another menu instead solves the problem...
  23. Yay, trial and error yielded the following successful script – forces a redraw and makes the toggle for showing/hiding screen objects work: PROCEDURE Toggle_DisplayScreenObj; BEGIN SetPref(95,NOT GetPref(95)); SetPref(506, GetPref(506)); END; RUN (Toggle_DisplayScreenObj);
  24. Yup, sure enough, that's exactly the same thing. I've looked through the SDK documentation and haven't been able to find a pref code to set the render mode, only the default render mode. Setting the render mode again might do the trick, as might (re)setting the Layer Option... Anyone know how to poll what the current Layer Option is and then set it to the same value again? Thanks!
  25. I've got an old script that toggles the display of screen objects – however, in 2016 the display doesn't update with the script until I manually set the render mode again (whether I select the same render mode or a different one). I used the script a lot in previous version of VW and would love to keep using it in 2016. Does anyone know how I might amend the script to automatically select the current render mode again and thus force a redraw (I've already tried REDRAW and REDRAWALL, to no avail). Thanks! Here's the script I've been using: PROCEDURE Toggle_DisplayScreenObj; BEGIN SetPref(95,NOT GetPref(95)); END; RUN (Toggle_DisplayScreenObj);

 

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...