Jump to content

Travis

Member
  • Posts

    808
  • Joined

  • Last visited

Posts posted by Travis

  1. Is this a file you started in 11.0.1? I've had the same problem, but only with elevation markers. The only only "cure" I've found is to delete the viewport and create it again from 11.5. (On one file, I just grouped all the markers so I could easily select them all and make some small change which caused them to refresh correctly.)

    Good luck,

  2. Charles,

    I'm going to take advantage of your experience, if you don't mind.

    Let's presume the VS-export process isn't perfect, a little like looking at the world through colored glasses. However, even with the colored glasses on, I can make out differences of another type: the sidewalk sections all look purple (because of the glasses) but some have cracks in them and some don't. The cracks wouldn't seem to be related to the color purple, even tho they appear purple through the lenses.

    When I export a layer of a file and some objects have the truncated string and some don't, what does that mean? Is the export function really that random? And is that randomness really only focused on strings of a certain nature? Or is it consistently showing us everything it sees, only through a wierd filter?

    Would welcome your thoughts.

    [ 04-01-2005, 02:50 PM: Message edited by: Travis ]

  3. I believe, Charles, that the three more or less current "crashing" threads all started before this one. Most of us, of course, remember the number of crashing threads back in versions 9.+ . . . which we all managed to survive. (All this talk of crashing makes me want to head out to the race track and watch a figure-8 derby!)

    I agree that panic here would be as foolish as reacting to some prankster crying fire in the theater (that's "theatre" for those of you who speak Queen's English). . .but one might at least sniff curiously to see if he can smell smoke.

    I had posted a new thread wishing to explore possible tactics to minimize corruption, but took it down because I made some declarative statements that seem accurate but I don't quite have enough experience to feel completely comfortable making.

    I do know this: When file sizes start ballooning unexpectedly, when things are not in the same state they were when the file was last open, when elements drawn and modified using the latest tool iterations begin to behave erratically, a dead file is looming. If a run through export/import is also a useful predictor of upcoming problems, I for one would be grateful to have the warning.

    I posted over on the VectorScript board asking if the VS text file was an accurate reflection of the underlying file. No response. I simply don't know. But based partly on the information learned in this thread, we'll exercise a little more prudence in our office going forward.

    It's likely "corruption" means different things to folks. Perhaps most of us don't think about it until a file dies. Others may see corruption because the 23rd decimal-place is out of whack, even though the file will still run. It would be nice to have a reasonably accurate assessment of reality. . .a little like the hard-drive "map" that gets created when you run your disc optimizer utility. Anyone who's used a computer much knows the hard drive is gradually being "corrupted" by repeated use; and also knows how to repair it before it dies of confusion.

    Mr. Armstrong has spoken loudly but I've inferred no acrimony. He's offered cogent explanation of his observations and even tried to suggest a route to a solution (the reason for his reference to the well-crafted flight simulator, X-Plane). Does he see reality clearly through the lens of VectorScript's text file? I don't know. No one has yet posted an alternative explanation. Some have had an annoying quantity of crashes and others haven't. Anecdotal evidence at best.

    If this thread has done nothing more than to spur a few more to adopt a reliable back-up routine, it's likely been worthwhile.

    I'm sure we'll all continue to contribute our best efforts to this valuable board. I know I'm going to spend a little less time writing and more time drawing to catch back up!

    Thanks and good luck,

  4. Found the solution:

    In the VectorWorks application folder go to

    Plug-Ins > VW_Arch > Lumber Sizes.txt

    Carefully read the warning. Add a 1 (or even 01) to each of the width sizes listed. 1.5" becomes 1.51"; 3.5" becomes 3.51".

    I even added a new line showing 2.51" for my oft-requested 3x material.

    Now joists, rafters and beams calculate nominal (and therefore volume in board-feet) correctly.

    Happy day!!

  5. Wow, I really like your last two suggestions. A little more info re classes in that dialog would be very useful.

    You can, by the way, generate a worksheet report that will list things by class/layer/etc. If you set it to sum based on class, you'd get what you're looking for. But it's not quite as convenient as you're wishing.

  6. Thanks for your candor. This is a serious blow to my confidence in what seemed a valid business plan.

    Having spent much of my "off" hours these last three days exploring this issue in our various files, I can say that the corruption is worse in 11.5 files than 10.5.1 or even 11.0.1. I haven't been as careful to start everything "new" as we moved to 11.5, so maybe some things were brought forward from 11.0.1

    Some years ago I taught myself enough about one of the database manager software packages that I've successfully written several "programs" to accomplish various business-specific needs. I had thought to use a similar paradigm here: the core data changes some as needed, but the "reporting" functions can be wide and expansive and varied. But, it seems, with VW the core data gets randomly corrupted every time I generate a report.

    It's clear why we went along so successfully for so many years with relatively small files and many, many projects. As our libraries of objects and symbols has grown, so have our problems.

    I'm going to think very hard about this. There's nearly always more than one way to solve a problem. And I'll be very interested to learn anything more you come up with. We'd be willing to consider some type of collusion and/or compensation as appropriate.

    Regards,

  7. eja,

    I've now taken time to search through one of our larger, more critical files.

    I find 54 occurances of the problem you describe above. 36 are truncated, of which 30 are related to WGR'd layers.

    As you predicted the VectorScript text file triggers so many errors on import it doesn't even list them all in the error report.

    Additionally, I get this from the error report:

    Line #10995: NameClass('Detail-Rebar');

    |

    { Error: Expected a new factor here. }

    |

    { Error: Expected a string. }

    |

    { Error: Expected ) }

    |

    { Error: Did not expect this after end of statement - missing ;? }

    Would you be so kind as to explain this latter error message? Is anyone at NNA listening in here?

    In practical terms, is there any "salvation" for this file other than to make as few changes as possible and keep one's fingers crossed?!

    [ 03-29-2005, 10:49 PM: Message edited by: Travis ]

  8. I'm anxious to explore this issue:

    In my variable-results file I mention above (it's a two-level deck addition made up of two floor objects, a stair object, several railing objects and a small column object that has been saved as a symbol and repeated about a dozen times), I learn the following from VS:

    1) The hatch name is never truncated "off" or missing.

    2) The following commonly occurs:

    objectHandle := LNewObj;

    objectHandle := LNewObj;

    boolResult := SetVectorFill(objectHandle, hatchName6);

    As does:

    EndPoly;

    objectHandle := LNewObj;

    Since I'm utterly unfamiliar with this syntax, and since Islandmon suggests searching on "objectHandle := LNewObj;", are these occurances considered anomalies or normal.

    I'm now going to undertake a similar investigation of one of our large files to see what I can learn. Any further information to guide me would be greatly appreciated.

  9. Unless you're rendering, especially in OpenGL. That uses the video card just like a game would.

    I happen to be a big fan of horsepower: I've never owned a computer that I haven't eventually replaced because it wasn't "fast" enough. As a result, I always purchase the fastest computer I can possibly afford at the time and then run it into the ground (often upgrading the CPU along the way). My brother lives in a PC world and replaces his computer every two years, I generally get 3-5 years from my Macs. (Now tell me which is more cost-effective?!)

    At least you're considering the right platform, IMHO.

  10. Isn't humor a great lubricant? (I'm even a big fan of IKEA's designs, and their ingenuity.)

    At the risk of adding one more (less than useful?) metaphor to this thread, I'd describe the use of Sheet layers and Viewports this way:

    Before: Imagine a model sitting on a table. Building, furniture, the newest flip-phone, whatever. To prepare a visual image for someone else to look at, I would orient the model just so; add a frame (title block to some); place little sticky notes (or whatever) to clarify the size and materials and my suggestions on how to build the real thing. Once I got everything where I liked it, I could take a photo - one photo that included everything - and call it a Saved View.

    Now: I take snapshots of the model and prepare a "scrapbook" (some might even suggest many of my models belong somewhere that begins with "scrap") page. On this scrapbook page I can place as many or few photos as I like, I can move them around easily, I can include a frame (or not). Yes, each snapshot is still of the model (requiring that I turn off/on the features [classes and layers] I'm trying to bring out), but it's not the whole view. I find this a simpler way to work.

    Leaving the metaphysical, the practical implications for me are:

    1) I build a model the same old way. Bottom (Design) layer has your concrete and CMUs (footings and foundation), next layer has the floor, next one has walls, and so on. I just make sure the various components line up vertically and have appropriate classes so I can highlight or minimize them later. We set up templates that include a standard "stack" of layers and a standard group of classes. More can be added at the users discretion.

    2) I take snapshots from different vantage points and organize them onto Sheets (Sheet Layers). I use the same title-block symbol I used before in the same way (I let Issue Manager oversee the details). I don't wrestle with deciding whether to place dimensions/notes/etc directly on the same layer with the model or on their own layer. I "print" them on my Dymo-labeler and stick them on the scrapbook page. (Dimensions and callouts go "inside" the Viewport, notes can go inside or "float" on their own.)

    I suspect I'm restating what others have said better: I was just trying to extend the metaphor into practical use.

    All the best,

  11. John,

    I've struggled with this "nominal" anomaly to the point I'm missing large chunks of hair on some days.

    See http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=16;t=001442

    However, I've not had problems with the 1.5" dimension. Perhaps Delmer has a point. . .but try 1.375, or even 1.495 to see if that will trick it into the proper nominal.

    This could be such a more powerful tool, especially for matieral take-offs, if this feature worked properly. Perhaps it could be set up with a few standard "nominals" and then let the user input more data for his specific needs.

    Good luck,

  12. Generally the jamb is very nearly the same thickness as the wall behind it.

    If you can't see the jamb/casing joint, just make parallel lines on the floor (use straightedges if needed) that extend from inside the opening to beyond the back of the casing. Measure the distance between the lines in the opening and subtract the combined distance from each line to the face of wall out beyond the casing.

    Good luck,

  13. Charles,

    We're peer to peer. All computers are running same OS and version of VW. One of the lesser-used macs (G4, 1ghz, 1gb) has a second hard-drive installed that functions as the "server". . .perhaps more accurately as a shared hard drive.

    To be more precise, the only time we've had problems is when the notes database is first created by the user on the "server". When it's created by one of the remote computers (we have a whole 5 computers on our network!), there doesn't seem to be a problem. I've tried to track it down to permissions, etc., but can't seem to get predictable failure other than all of them (so far) have been with files created at the "server" station.

    Hope that helps,

  14. The reality, my foul-mouthed friend, is that you're not obligated to use the "new speak" method whatsoever. You can continue doing things the way you were. . .not one single capability has been eliminated.

    You can continue to use a hammer to drive a nail, but if you'd like to borrow my nailgun please don't complain that it comes with an airhose.

    As always, good luck,

  15. To further the above issue:

    I exported a current, very simple, drawing as Vectorscript. I then open a new "clean" file (not one of our templates) and import the Vectorscript.

    Tried it three times and got three different results. But never got an error message.

    My consternation level just went up about 30 notches.

  16. I've found the transition to Viewports to be quite intuitive.

    Before we had to figure out which layers, in which order, needed to be "turned on" so the printed sheet looked like what we wanted. If one wished to show an element in 2D (with dim's) yet have it also appear at a small scale in 3D Isometric, the mental gymnastics began. Then, when everything was properly "turned on" and correctly layer-linked and modeled, I could save it all as a Saved View.

    With Sheet layers (yes, there had to be a new use of terms introduced to accomodate the new capability), I can treat each Sheet exactly like a sheet of paper. I place views of the model layers (called Viewports) on the Sheet Layer. From this one Sheet Layer, I can move the views around; go "inside" and adjust cropping and add annotations. I can change scale to my heart's content.

    Perhaps it's just a matter of getting used to a new paradigm. One that, for me at least, is much simpler and more intuitive.

    Perhaps you'd benefit from Jonathan Pickup's Architect manual. Once or twice through the exercises he presents and I think it would be come much clearer.

    Good luck,

  17. Islandmon,

    We've just made a large commitment of resources to developing several "semi-custom" plansets of some of our designs. The plan is to set up a file with the basic structure complete with the linked viewports for sections, elevations, enlarged portions, etc. Based on very favorable market response, we envision taking the "basic" file and adding the interior layout and other elements as required.

    This means the "original" file will be used over and over again, a little like an extremely elaborate VW Template. As improvements are made that seem more or less universal, the original file would likely be modified. We have three of these so-called base files complete. Each one has about 250 classes, 50 to 60 design layers, 17 or 18 sheet layers, about 75 hatches and well over 100 objects and symbols. We have refined a couple of methods that yield very workable "live" sections and elevations. This all seems plenty complex, even to me, but the flexibility to respond quickly (read "cost effectively") has turned out to be impressive.

    I've lobbied (successfully) to base our variable-CAD plans entirely on Vectorworks. Our investment to this point is something over US$100k and will likely grow. (We're poised to purchase several more seats of VW, tho by ourselves I'm sure we're but a drop in NNA's bucket.) Based on your much deeper understanding of code-level problems like you describe above, are we contemplating business hari-kari?

    What can we do to keep our core files (especially) as clean as possible from corruption? Where could we turn for reassurance that a file is/is not stable?

    Please, anyone posting in response, can we leave the rants for another thread. Rather, clear explanations and realistic expectations will be much more useful.

    Thanks in advance,

    [ 03-28-2005, 02:52 PM: Message edited by: Travis ]

  18. I generally do the floor components (joisting/slab, subfloor, finish floor) on one layer and the walls on the layer "above". This way windows are always set to sill height above finish floor. Any changes to the floor's component thickness(es) are taken care of in the floor layer with the layer's (or often layers') Z-height adjusted if necessary.

    Using this approach, I find the current floor protocol to be "natural" and intuitive. The slab/joisting/framing is represented by one Floor object that is x-thick (Start=0, thickness=x), the subfloor is represented by another Floor object that starts at "x" with thickness "y", and so forth.

    Just another way to look at it.

    [ 03-25-2005, 10:19 AM: Message edited by: Travis ]

  19. Surely you don't need to use all the imported classes. Perhaps you could just rename the ones you do need to move objects to. By renaming, everything already in that class stays there and with a more typical VW name, you'll be able to add objects.

    (I rarely import Acad dwgs, so I haven't struggled with this specific issue.)

    Good luck,

  20. I think I understand what you're asking, so here goes. . .

    After the first two dashes "-", I generally resort to another typed symbol, say the backslash "\".

    For example:

    Wall-Int-Upper\Insul

    Wall-Int-Upper\Firew

    I hope that proves useful,

    [ 03-23-2005, 08:29 PM: Message edited by: Travis ]

  21. Roof Framer on individual faces won't create Hip/Valley rafters. But, like Mike, I prefer the control of smaller segments, so I usually frame groups of faces and then insert missing rafters as needed.

    And, I always work with a copy of the file until I know I've got the framing right. Then I copy/paste the framing layer(s) back into the original.

    Good luck,

×
×
  • Create New...