This is the current state of element schedules. All projects will have schedules for windows, interior doors, and exterior doors. Many projects will have finish schedules, which are schedules of zones.
Let's quickly review the basics of interactive schedules. In the scheme settings, there are criteria, which determine what elements will be listed, and fields, which are the information to be shown about each element. Schemes can be imported and exported as XML files.
Then there is the schedule itself, where you control the column widths, header content, and text settings. It is pretty WYSIWYG with respect to output.
In addition to making schedule output, schedules can be used to inspect and edit model information. More on that later.
This started, as so many things do, with making a symbol fill for a tile pattern. A challenge of symbol fills is they need to tile (left and right meet, top and bottom meet, invisibly).
You can make new grid, running bond, and herringbone fill patterns by duplicating the extant ones and changing the dims. Anything more complex, you need to draw and work out the tiling.
That's just the fill pattern, which is vectorial, meaning you can use it in plan and surface fills in elevation. But you are on your own in 3D (OpenGL, BIMx). If you are delivering BIMx, you need to keep your textures in sync with your fills. Here is a simple way to do that.
All the common layouts (that we can think of) are blocked up in the project templates. These guidelines apply no matter when a layout is first needed.
These instructions are current as of Archicad 20.
You don't need to use clones to create views, but I recommend them. To review, a clone folder is a viewpoint set such as stories, sections, details, etc., with view settings pre-arranged so that when you make a new story, section, or detail, a new view is automatically created with the correct settings. View settings are easy to mess up and there are a lot of them, and they directly affect output. Better to set up clones in your template, and have all your views perfectly set, even for viewpoints that haven't been born yet.
Some users/managers/template makers eschew clones in favor of placing dummy sections (e.g.) and moving them around as needed. That's OK, especially if your projects are of a consistent scope that you can prepare the template for it. Our projects vary in size a lot, and I like the user-proofing aspect of clones either way.
The only thing I don't like about clones is that they always clone the entire set of viewpoints. We have two clones of the sections: one for building sections at 48 scale, and one for wall sections at 16 scale. Both clones contain all the sections, so we sort the list using the section ID. Building sections are A2 and wall sections are A3, and then in each folder the user has to mentally tune out the sections that shouldn't exist. (And the junk sections, which are never used for output, appear uselessly in both.)
Junk trimmed for brevity
I'd like to see clones that could be filtered by ID, so that only the A2 sections appear in the building sections clone, and only the A3 sections appear in the wall sections, and the junk can be avoided completely.
I made a quick but not completely disposable scripted object. Probably 30-45 minutes of work. I saved it in the embedded library of a scratch file, rather than in a live server folder where someone might notice it before it's done. (The odds of this are crazy low, plus it's no big deal, but that's what I did.) The scratch file is Archicad 20, because we haven't officially migrated, but my projects are in 21.
Then the standard procedure is to save the object out in Library Manager, and delete it from the embedded library so the scratch file doesn't have a duplicate.
Then, reload libraries in the real project so the new object can be seen.
Upon reloading, I had several duplicates. Inspection revealed I had exported the whole embedded library from the scratch file. (The two files have some deprecated labels in common.) I had clicked the save button without highlighting the single object.
That's the kind of thing I like to fix right away, so I went to the Finder and found the stupid 'Embedded Library' folder inside '22 Plumbing' and deleted it. Because this folder was on a server volume, the deletion was immediate - such things don't go to the trash. (I still miss this from OS9.)
Then I went back to the scratch file to export the object properly. But since my procedure is to delete the object right after saving it, it was already gone.
It's gone from the embedded library, and the server copy was deleted along with the stupid folder. Maybe it still exists in the actual project, since I hadn't reloaded there yet. Alas, no, because while the object still appears in the settings dialog, it doesn't work at all because the file on disk is missing. I also tried crashing the scratch file's Archicad instance in hopes the autosave data might remember the object. Alas, no, again.
So that is how I managed to completely delete a new object. The only hope would be if Time Machine or Backblaze had run during the few minutes between saving the embedded library folder and deleting it. The odds of that are also low, and it didn't happen.
It's frustrating to lose work, but it wasn't a lot. Between automatic backups and autosave, it's difficult (knock wood) to lose a lot of work in Archicad. Autosave for objects would be nice, but it wouldn't have helped in this case. While I've been at this a long time, I still find new mistakes to learn from.
I am a Field Notes fan. They make awesome versions of a completely ordinary product: disposable pocket size notebooks of the type that would be given out as marketing by midwest farm/feed and hardware shops in the mid to late-mid 20th century. They make books in a different style every 3 months. If you subscribe, you get the new designs each season along with surprises. This May, a surprise was, they made a final exam type 'blue book', which you may remember from some phase of school.
I went to a preppy middle/high school for some years and my earliest memory of these books is from 8th or 9th grade.
Along with the books, which are 3x better executed than any blue book I have ever seen in the wild, comes a challenge/assignment/contest:
"Using one of the enclosed Blue Books, please submit a written essay relating a notable dramatic or humorous event that happened while you were in elementary or high school." And they list grading criteria including penmanship (in all caps), which I blame for my loss.
As we used to say in architecture school, I went around the program. This is not a memorable story from whenever, but it is a good idea IMO, and when you have an idea you should follow through with it. It is below the fold, and yes I wrote this out longhand and put it in an envelope with a stamp.
In Archicad 21 you can use autotexts in labels. Rather than describing an element in disconnected words, you can display the actual properties, attributes, dimensions, etc. of the element. Use Archicad properties and name your building materials, surfaces, and composites carefully, and you can get good automatic notes. GDL-scripted labels have long been able to do this, but it's an order of magnitude more convenient to have this built into the basic text label.
Generally, such associated annotations are better, because if anything changes in the elements the annotations change too. Think ordinary dimensions. An element and its associated annotations are one thing.
But my goodness they botched this for US users.
If you use (feet and) fractional inches for your dimension units, you can't use any dimensional autotexts in labels without looking like a hack. This is because autotext dimensions are formatted according to the calculation units preference rather than the dimension units. There are no fractional length unit options in the calculation units preferences.
Here are two simple dimension values. The wall thickness is a dimension and the fixture elevation is a label autotext. Archicad says with a straight face that one of them is a dimension and the other is a calculation. A calculation with no operators and a single term, apparently.
Doesn't everybody vary units within drawings? No, no one does.
Wait, here's a label that works.
This is the Archicad library's Elevation Label 21, a scripted label (no autotext) that has been available for years. (Like a lot of Archicad library parts, this label over-serves and you have to fiddle a lot to get it looking right, but it's functional and reliable.)
That's not so hard, is it?
This label is scripted to use the dimension units, as common sense would dictate. There are global variables for the calculation units too, so they could have this label use them, but it's not even an option, because that would be (is) ridiculous. If I wanted decimal units, I could just set the dimension standard that way.
Maybe in Archicad 22 they'll fix the Elevation Label to use the calculation units for consistency. (KIDDING!)
I don't know how this decision made it out of committee, and I'm sorry I didn't notice it earlier, but that usually doesn't matter. This is worse than How Could This Possibly Be What I Want, it's just carelessness that never got reviewed because it doesn't affect metric users. (But it's wrong there too.)
Why don't I care about the reason?
Because I'm a user, not a developer. My job is to make my projects work, and the developers job is to make the program work. I'm sure there's a reason for this situation, and it might be very interesting from a development point of view, but that's not my point of view. To a user, it's just wrong and needs to be fixed. (In all honesty, as an Archicad observer I'm curious about the reason, but it's not the user's role to care.)
And, the whole dimension and calculation units thing probably needs a do-over. It would be welcome to have units control at the level of the element (dimension, label) or schedule. An electrician might prefer that fixture elevation in fractional inches, for instance. This will become more important as more annotations become automatic.
PS, metric people: Sure sure, I'm with you but you're not helping.