Jump to content

mgries

Member
  • Posts

    135
  • Joined

  • Last visited

Everything posted by mgries

  1. I'm encountering a different problem related to calculating space areas, and have officially run out of brain cells on this. This seems totally screwed up to me, but I'm new to 2019, so maybe I'm missing something here... When using 'Space'.'Area' in my worksheet, the values are getting multiplied by precisely 92903.384. See screenshot. When using 'Space'.'11_Area', the area is reporting correct however, so there's no issue with my units or anything like that. I'm trying to tabulate total areas of multiple spaces, so I need to be able to apply the SUM function to these values. The worksheet will not SUM the space areas when delivered via text field, so I need 'Space'.'Area' to work for this. Also, can someone please tell me how the new database header option called "sum values" factors into any of this? Clicking this on or off doesn't seem to do much, other than add a little 'plus' symbol at the header. please help me! ...and thank you! Matt
  2. @Alan Woodwell, ok here's the file with a a couple of screenshots added. You can see that the wall style is set up for story/levels. Thanks! Marionette House V002-MOD_mgries.vwx
  3. Hi @Alan Woodwell, Great job on these marionettes! I'm trying to use a chunk of the V002 script (just slab and walls) in VW2019. I'm pretty much a novice with marionette, so I'm running into few obstacles I'm hoping you can help me with... The 1st issue I'm having is that when the walls get created, the insertion options associated with the wall style I'm using are getting overridden. Instead of the height being bound by story levels, it reverts to layer elevation. And instead of the wall object coming in on a specific class, it reverts to the current class. As mentioned, both of these parameters are hard wired into the wall style I'm using, as insertion options, so I wasn't expecting the marionette to override any of this, and can't understand where this is happening. In addition, regardless of the class the objects come in on, the whole thing comes in as a group within a group, and with the opacity overridden to 95%. This is a complete riddle to me. Any idea what going on here? Finally, is there any quick way to spread out 2016 nodes when the file is transferred to 2019? Because of autoscaling introduced in future releases, the 2016 marionette nodes are all bunched up, sitting on top of each other. Thanks, Matt
  4. Thanks Tui, This is the way I have things set up too!
  5. Hi, I struggling to understand the best way to place my site model with respect real world elevation (feet above sea level). If my base elevation for the project is 150.0', I am currently setting Story 1, Level: "Finish Floor" to 150'. Is this even right? It feels a little weird to have the whole project floating so high up above the XY plane. Should Story 1 start at 0", and the design layer start at 150'? I then wonder if I should also relate my site model's design layer with respect to Story 1. Currently, I'm placing my site model on a design layer that is not attached to any story, and set to a 0" elevation. The Site model topography is drawn at its real world values, so the whole model floats up above along with all the story related building assemblies. Anyway, I would really love some feedback on what the best practice is for all this. Thanks! Matt
  6. @Pat Stanford, Any idea why this modification to your formula doesn't work? The goal is to simply write the word "Custom" into a designated user field, and then use this bit of data to overwrite any of the record fields. It's not working however. Do you know what I'm doing wrong here? Thanks, Matt
  7. works like a charm! I tried to do the other option, which represents a more universal approach to overwriting values for custom doors: =IF('Door'.'UserFld10’<>'Custom', 'Door'.'Config', 'See Door Elevation') The goal is to simply write the word "Custom" into a designated user field, and then use this bit of data to overwrite any of the record fields. It's not working however. Do you know what I'm doing wrong here? thanks, Matt
  8. thanks for this Pat! I'll give this a try and let you know how it works out! And yes, I've used symbol geometry in the past for certain custom doors. Cheers Matt
  9. I finally got it to work! I think the fact that it was the beginning of a new week, and the coffee was flowing fresh in the veins. But it ONLY works for me written the following way: =('Door'.'Width') None of these work (the first one is what everyone agrees should work): =(Door.Width) =('Door'.'DoorWidth') =(Door.DoorWidth)
  10. Yes! This 3rd script would kind of complete the right click dream work flow. Good call @markdd
  11. @michaelk thanks for hooking it up! I haven't had a chance to use it, but I really appreciate that both of these tools exist now!
  12. Great work everyone!!! This is a gem! Now all we need is a second contextual click / menu command to put below this one that updates the designated class of the selected object with the overwritten graphic attributes of said object! Think of it as the all too often needed "option B" workflow scenario.
  13. @Pat Stanford, I have another idea maybe you can shed some light on regarding the use of IF/THEN/ELSE formulas in database headers... Issue: sometimes we use a cased opening to schedule complex door types that aren't available in the pre-made options. The particulars of the door are placed within the frame, maybe using multiple (non scheduled) door plugins to create some kind of custom configuration. This works fine, except for the one hiccup being that the door operation is not accurate in the schedule. At this point, I'll usually give in, and just past an opaque piece of text over that cell to say something like, "See Door Elev." Question: Is it possible to get this cell to read "See Door Elev." using the IF/THEN/ELSE strategy? Perhaps it could be triggered by the operation simply being a "cased opening", or even better, by certain text appearing in one of the User Fields? For example if User Field 10 has "custom door" entered into it, this could trigger the "Else" option in the Door.Operation header formula. I'd thinking about giving this a shot, but was hoping you could tell me ahead of time if you would expect this to work. Thanks! Matt
  14. Michael, that's not it. The headers are written correctly. I'm getting this dialogue box when I try to change the value in a cell. What's this "new record field" business about?
  15. Pat, This is an amazing thread! I have another door/window worksheet issue maybe you can shed light on... Is there anyway to edit the width and height of doors directly from a worksheet? I don't understand why these 2 fields must be "read only". Why can't they behave like all the other Record.Field columns? Thanks, Matt
  16. Not sure why you need this dedicated layer. It looks like the "keynotes editor" worksheet will work the same from anywhere.
  17. Good stuff Chad! I think I'd make one advancement to this: a second field for multiline spec info. to be entered. This would allow the global worksheet, if desired, to turn into a more full fledged keynote spec. sheet. Great work! thanks for sharing! Matt
  18. Yes!!! Fantastic job! These improvements are equally important to very organized workers, as well as to those dealing with very disorganized coworkers. This is getting me excited for 2019's "Quality first" agenda. Could it be possible the notes tool has received similar improvements? 🙏🤞
  19. I like this approach! It's a good work around considering the enormous failures of the current note system. I wrote about it here: @Chad Hamilton HAarchs, the Keynote Editor worksheet is not working bi-directionally for me though. I can't edit from the worksheet. I'm getting grey text instead (see screenshot). Any ideas what's going wrong for me? Thanks, matt
  20. I'd like to bring this other post related to customizing wall openings into this thread. It discusses how to make openings with curved corners. Looking at both threads, it makes for a very strong argument for creating a stand-alone wall opening tool. As I mention in the other thread (link provided), there actually was such a tool posted to Vector Depot. Only problem is, it doesn't work in versions of VW beyond 2013. Can anyone please update the script for this thing to make it work in 16, 17 or 18?
  21. that's an interesting idea! Let me give it a shot
  22. thanks for looking into this Pat. Was hoping for something a bit more efficient. Unit Type driven design seems to be a bit of a blind spot in VW.
  23. OK...here's a gutted file with just a single floor plan design layer and a single sheet layer with the schedule. Don't be confused by the fact that the 2nd Floor Plan design layer contains all the 1st Floor Residential Unit Plans. It might look like this is a mistake but it's meant to be this way. These are town houses that start on top a podium. Thanks for the help! Matt Hey thanks! will do. I ran out of time today unforturnately...I'll send tomorrow. Issue_scheduling_doors_inside_a_Symbol_mgries.vwx
×
×
  • Create New...