On Land

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.

An unheralded new feature of Archicad 20 was a repair to the Mac version where Archicad will continually hunt on the network for missing servers. This happens when 1) the project uses resources (libraries, external drawings, hotlinked modules) on server volumes, and 2) you open the project away from the network where the servers reside. The effect is 1) a delay when opening the project as the external resources are sought, and 2) periodic warning dialogs saying that a server with a certain IP address cannot be found.

This has been a problem since at least Archicad 9, or maybe forever and that's when I started carrying projects around. I was always told it was hard to reproduce or impossible to fix, and it doesn't happen on Windows. (I mean, they never told me the Windows thing, that's just a fact.)

In Archicad 20 it was definitely fixed for a while, and there was great celebration all around, uh, my kitchen table which is supposedly one of the few places the problem occurs. Then it returned, likely an unintended consequence of an update. I am led to believe that now the issue is impossible to reproduce, so I'm not holding by breath on a fix. I think that was the shot.

So we still need DisableCrossPlatformMountingFeatures. If you are a Mac user and this situation affects you, close Archicad, open Terminal, and paste this in:

defaults write com.graphisoft.AC-64\ 20.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

This will work for any version of Archicad back to 15, just replace the '20' with the relevant version number. (Before that, drop the '-64', and for heaven's sake please upgrade.)

Let's just say I have a feeling the next version might be in the same boat, so for your clipboard convenience:

defaults write com.graphisoft.AC-64\ 21.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

First, to review: The New Construction renovation filter has these settings:

Existing: Override
Demolished: Hide
New: Show

In plan, new walls are gray and existing walls are white. Demolished elements are hidden.

When you demolish an opening in an existing wall, the opening disappears and is replaced by a piece of wall whose status is new.

I think this behavior is correct and intuitive. My only quibble is with the lines on either side of the new segment. I'm not convinced the lines should be there at all, and using the cut pen definitely makes them too heavy. But I can overlook it. (Archicad does not consider the difference between element-is-cut and cut-element-meets-air, and I think I have given up waiting for that to change.)

I can't overlook what happens in the elevation. The filled-in portion of wall is explicitly drawn with the shape of the demolished window. There's no way this is OK.

Note: Cut new siding at old window location

• The new wall fragment is based on the existing wall, so it has the same surfaces. Where elements of the same surface meet, the line should disappear. (This is true in AC17. In 16, the material of both sides of the filler piece matches the edge material of the wall. No words.)

• With the surface cleanup rule in place, they would have to create an exception to it, in the belief that it is conventional to show filled-in windows on elevations. We have never done this.

• If I did want to show this condition, it would be dashed and in a lighter pen. These options are not offered. It has nothing to do with the override styles, even though the override setting is what is causing the rectangle to show. The GDL of the demolished window is not involved. The rectangle is drawn with the outline pen of the wall, making it a heavier line weight than the proper windows on the same elevation. Bad graphic, no user control. It couldn't be wronger.

So we need to get rid of it. I stumbled on a way. (N.B.: In the reference guide, there is precisely zero discussion of elevation and hidden line viewpoints in the Renovation section. Once you leave the floor plan you are on your own. Unless you're issuing OpenGL demolition docs, which, um.) In the As Built renovation filter, both existing and new elements are set to show. In the plan, we can't have this because the existing and new look alike. But in the elevation, it means the filled-in wall blends in and there's no rectangle.

Alright! We just need to use that filter for elevations. Maybe change the name so its purpose is clearer. I don't mind workarounds as long as they work, ya know!

What? Sections? Right, they have cut elements (existing needs to be overridden) and uncut elements (existing needs to match new).

Right like the plan, wrong like the elevation

Good elevation, but we can't tell new from existing

It looks like that filter trick doesn't solve it, and I think we've reached the end of the line. Direct demolition of openings just doesn't work. I don't know how they released this feature in this state, and I don't know how they haven't fixed it three versions later. It's really poor.

We will continue to use renovation. But we have to go back to the old method of splitting the wall on both sides of the opening, demolishing the piece, and filling in manually with a piece of new wall. This works reliably as ever and cleans up in all views.

The logic of renovation is that removing an opening involves creating some wall. When I create a wall to meet another wall and their surfaces match, there is no line. That stupid filled-in chunk should do the same thing.

In situations like this, where a plainly wrong graphic is presented as normal, I get the feeling that Graphisoft's strategy is to hope that conventional documents are swept away very soon by BIMx Docs, live cutting planes, and iPad Pros. My concern for "pens" will seem as quaint as a wax seal! I think they underestimate the status quo bias on the average job site. Today, I need drawings that function in the field. The present is sadly non-futuristic sometimes.

That new world, when it comes, is going to have graphical conventions too, and users will always be charged with turning an ever more complex model into visual information that people can use. At the moment there is a disconnect between the information I can attach to the model ("This window is to be removed"), and the tools to convey that information. ("If this is removed why is it showing?") It should be a core competency of Archicad to bridge that gap.

How to Demolish Openings

First the simple case.

Split the wall at both sides of the opening. The split can be right at the opening's ends, or you can allow some slack.

Drag a copy of the wall with the opening. It's less confusing if you drag it away.

Demolish the opening's wall by switching its renovation status to Demolished. When you demolish a wall, openings in the wall are automatically demolished.

Change the copy's status to New, and delete the opening.

Drag the new wall back in place.

The more complicated case is where a new opening will be placed overlapping the demolished opening. In this situation the pair of walls (demolished and new) must be extended to span both openings, so that the new opening is placed entirely within the new wall.

Placing New Openings in Existing Walls

You do not need to split the wall to place new openings in existing walls. Just place them. The new opening will appear as a demolished portion of wall in the demolition plan. As far as I can tell, there are no graphical problems with using this, the intended technique.

If you encounter a failed Archicad autosave (Crash followed by no recovery dialog at relaunch), and you are running Time Machine in OS X, restore the Autosave folder from Time Machine instead of messing with cron job workarounds.

Make sure Archicad is not running.

Activate Time Machine on the Dock.

Navigate to [Home]/Library/Application Support/Graphisoft/. You should see a folder called Archicad Autosave Folder. If you don't, go 'back in time' by clicking the next window. If you see more than one Autosave folder, sort the window by Date Modified to determine the right one.

Highlight that folder and click the Restore button. (You shouldn't get a 'replace this folder' warning, because if the Archicad Autosave Folder was present, Archicad would have seen it and given you the recovery dialog. If you do get it, make sure Archicad is not running.)

Once the folder copies over, relaunch Archicad. It should find the Autosave data and present you with the recovery dialog. Depending on when Time Machine ran last, you may have lost more work than you would with a normal autosave.

The other day I had a puzzling problem with VR objects saved out of Archicad. Some files would open in QuickTime as conventional movie files rather than VR objects. (Press play and the building spins around once for each parallel. It runs about five seconds. It's not making any sales.)

As is often the case with puzzling intermittent problems, I was working too fast and not paying attention. After running a VR and viewing it in QuickTime, I would return to AC and run it again. Trouble is, sometimes I left the VR open. It took me an embarrassing while to figure out that those VRs were winding up corrupted on the second pass. In further testing, sometimes the VRs would be too corrupt even to open.

So the concrete tip is: Don't redo VR objects while they're open. Maybe this is 'duh', but there are filetypes that can be rewritten while open in other apps: Preview has no problem with me overwriting open image files, e.g. And it's common to let AC have most of the screen area, so who knows what else is open in the background.

The meta tip is: If a weird problem crops up when you're rushing, it's very likely a normal problem that either wouldn't happen or wouldn't seem weird if you weren't under deadline pressure. When you see something weird, slow down, pay attention, and fall back on the good workflows you practiced back when the wolves weren't at the door.

This has got to stop.

You know the one I mean. Three walls meet at a point, and the inline ones are different thicknesses. The corner formed with the inner wall simply must be expressed. We've had this one for-[stupid]-ever.

HCTPBWIW

Roundup of info on daily shutdown, backup, and power failures.

More»

Somewhere, a roof is unhappy. Most likely, the angles of nearby roof edges are causing the geometry to turn inside out. The report will say something like:

This is actually helpful! Use find and select to find a roof with that ID, and you can fix it. The trouble is that you probably have a lot of roofs with identical IDs, and you can't tell which of the n roofs is the problem.

If the IDs were unique, the report would lead directly to the bad guy. So you need to change the IDs of all the Roof 004 elements. You certainly can do this one at a time, and it will work.

Instead, use an Element Schedule to isolate the roofs, and correct the IDs.

Make a new schedule (Document -> Schedules and Lists -> Schedules -> Scheme Settings; Create New). The criteria:

For the fields, you just need 'ID', from the General heading:

This will give a schedule with all the roofs whose ID is not blank:

Make sure the 'Uniform Items' checkbox is off. If it's on, you'll get one line item for Roof 004, regardless of how many there are, defeating the purpose.

Now all you have to do is change all (but one) of the Roof 004 items to something unique. You can use numbers in the same pattern, as long as they aren't used elsewhere in the schedule, or you can add a, b, c, or something to the IDs.

Next time you run the 3D, section, or elevation window, you'll get the report again, but this time you can use the ID to find the specific element.

Heads up concerning the issue date in the title block. I'm getting very erratic results when publishing; sometimes the title block drawing (on the master layout) updates automatically, sometimes it doesn't. If that drawing doesn't update, your title block data will be wrong, including the date.

I have confirmed that the drawings on the master layouts are set to auto update. That should be all it takes, but it's not.

For example, I changed the date and then published a PDF. The dates on the resulting PDF sheets are not changed. I immediately published again, without making any changes anywhere in the project. Now the title block is right.

Erratic.

The title block drawing will always update if you open its master layout. It seems it will also update if you open a regular layout. But I have seen cases where the layouts of some masters are updated but not others; it probably depends on what regular layouts have been opened.

But, each layout automatically opens as the publication happens! Yes, and it skips updating the master drawings. Sometimes.

Once again, we have an output-related, liability-hazardous, supposedly-automatic behavior where Archicad can't quite get the door all the way shut. And once again we have to follow it around making sure it's using its litter box.

My recommendation: If you are publishing anything where the date is critical (that's anything you're giving to anyone else), before publishing, open each master layout that is in use. Essentially, that's all the masters of a given size, just to be safe. Opening the master should trigger the auto update of the title block drawing, and then you should be set.

We have had a handful of cases where Archicad autosave recovery has failed when it should have succeeded. We have also had cases of human error where the autosave never had a chance.

Since Archicad deletes the autosave data once it decides (right or wrong) that it's not needed, you don't get a second chance.

Unless you routinely back up the autosave folders.

More»

After I posted about the jellyfish a couple third-party observers commented, paraphrasing, 'Duh, of course you need to turn the hidden stuff off'. (Quick review: The issue there was clustered arrangements of elements, where AC was taking a long time to sort out the hidden lines.) Maybe so, but the last time we visited this issue, which was probably way, way back when, it didn't make much difference. But our projects today are more complex, with many more polygons, so we should look into it.

I tested the front elevation, with fills, of the hairiest project I could find. On the Quad G5, generating the SE from scratch took 2:45. This is with all the interior elements on.

I made a new layer combination and hid the interior elements. This includes:
• Structural columns, beams, footings. (Remember, we don't do joists or rafters.) (Also remember, architectural columns are layered as walls.)
• Interior walls (which shuts off the doors, natch)
• Interior trimwork
• Appliances, mechanical equipment, plumbing fixtures
• Stair parts
• Fireplace flues

Generation time: 2:15 (18% better) Noticeable, if not life-changing, improvement.

The question: Should the templates be equipped with such an LC?

• The improvement would only be noticeable on very complex models.

• A separate LC would mean a separate clone, making the view map more complex.

• SE generation will improve as we move to Intel hardware.

The dramatic slowdown in the jellyfish was caused by 'clumping' of elements in an unusual case. Such cases could be handled piecemeal, not burdening the template. Templates should be geared toward standards and typical usage.

I'm going to say the improvement isn't worth making the templates more complex. On a complex model, it might be worth forking the A2 LCs.

On a truly large, multistory building, I think it would be advisable. As you add lots of stories, it would seem you're adding interior polygons faster than exterior.

And I reserve the right to change my mind after another 8 years.

Smarter cleanup please.

Other dialogs here.

The source files of some Hotlinked Modules are missing

Sources of the following Drawings are unavailable!

If this item is part of a clone, its clone will also be deleted

Polygon boundary intersects itself!

More»

Kinda looks like a jellyfish

By themselves, it's not a lot of elements, or even a lot of polygons.

Yet these guys were found to be the cause of a severe and mysterious performance problem. An elevation containing the tower, which should generate in about 30 seconds, took four minutes to generate with these elements in the model.

The problem: AC has to figure out what's in front of what behind what in front of what, for all those overlapping elements. The calculations quickly become very complex and it takes time.

Here's the tricky part: The columns and objects weren't even visible in the elevation; they weren't going to be drawn at all. But apparently there's no way for AC to know that in advance, so you have to wait an extra 2-4 minutes for every section/elevation to generate.

It was hard to figure out, which took some time, but I'm afraid to wonder how much time was wasted over the weeks since those elements were put in.

BTW, it's not my project.

How I figured it out. I tried tearing out all the old objects, resolving the intermittent report errors, doing a forward merge, and opening the project as a dummy user, none of which worked.

There was a clue in the progress dialog as the elevations generated, but it took me a while to recognize it as such. The progress bar would hang up on 'Processing Objects' and 'Processing Columns'. The objects clue isn't much of a clue; of course there's a lot of objects. Hanging on columns is weirder, so weird that I figured it was a glitch; that was a mistake.

I still suspected mystical corruption, and it's my superstitious belief that corruption develops over time, so I tried deleting the whole first phase of the model, which is not in the current scope of work. (I used a heavy marquee for this.) That worked. I undid the delete.

Then I noticed the tower. I thought such a contraption probably has some funky geometry. I deleted the tower only, and that worked. Then I switched to the thin marquee and tried deleting one story at a time. This was disappointingly ineffective. Now I know that the reason is that the complexity was spread over several stories.

But when I trashed the top story, with all the beam objects, the 'Processing Objects' delay went away, leaving only the 'Columns' delay. I finally realize that the progress dialog wasn't totally off base. If losing objects helps, then we should look for some columns to lose. I did a select-all-columns within the marquee on each story, which finally coughed up the balusters.

Delete. End of slowness.

Tips:

• If you've ruled out file corruption, you need to look for 'heavy' conditions in the model itself.

• If you just did some weird complex modeling and suddenly it slows down, that's a big hint.

• You can tear the model in half and throw it away. Undo is your friend. Saving as is your friend. Start trashing stuff and see if the problem goes away. You can do a similar test by turning off half the layers, then the other half, etc.

• Watch the progress dialog. If it spends a long time on 'Objects' or 'Columns' or whatever, or the time estimate shoots up at a certain stage, that's a clue.

I thought we were supposed to model everything.

This is a good time to review this. We don't 'model everything'. We model what it is efficient to model, which, for a skilled ACer, is a lot of stuff. You model the major pieces of the project. You model stuff that shows up in a lot of views. You model enough to really understand the building. You model enough that annotations can be added easily.

You have to work within your own abilities and within the power of AC on your machine.

I hope it's obvious that you don't model things that cause AC to bog down and start wasting your time. We don't model joists, individual rafters, or other generic framing. Too much work for us, and, it turns out, for AC.

In the tower, some of the framing was intended to be exposed, but most of it was 'architecturally' insignificant and should have been skipped. The balusters are definitely nice to model, but there are situations where you need to compromise to keep the model running smoothly.

Maybe the tower section should be a drawing, or maybe a drawing elevation of the balusters should be pasted into the model SE window. Maybe the balusters should be on a layer that only shows in 3D views and not in section/elevation. That kind of lateral thinking.

Which is short for DisableCrossPlatformMountingFeatures.

Where to start. Let's just say, do this fix. It's a preferences modification which turns off a feature which, though of questionable value, causes a lot of problems. In other words, I don't know what it's supposed to fix, but it sure breaks a lot of stuff. The feature breaks stuff, that is. Not the fix, the fix is good. The fix that turns the feature off. Where to start.

These are the big issues that the fix fixes:

• In AC9, the infamous 'Connection Failed bla bla bla' warning, which pops up frequently while updating drawings in PM.

• In AC10, a long hang (rainbow ball) at startup, and various mysterious hangs here and there. (In an early beta of 10, this issue manifested itself as a two-minute hang every time I switched away from AC and then back. Awful.)

The issue has been implicated in many other intermittent problems. And the 'feature' which the fix turns off is of dubious value. In an office with no PCs, it's completely worthless. It should be off by default, but it's not, so we're going to turn it off.

How to:

• Close Archicad. Open Terminal. It's in Applications / Utilities.

• In Terminal, copy and paste the following:

defaults write com.graphisoft.AC\ 10.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

...and hit Return. It will appear that nothing has happened. This is a good thing. (If you get any message that something didn't work or doesn't exist, try it again, or try typing it manually. The thing to note about the typing is that there is a space after each backslash (\).)

• Close Terminal and relaunch AC.

That's the Terminal command for AC10. You can fix AC9 the same way, changing 10.0.0 to 9.0.0:

defaults write com.graphisoft.AC\ 9.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

And PM9 too:

defaults write com.graphisoft.PM\ 9.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

And you'll probably need it in 1112:

defaults write com.graphisoft.AC\ 12.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

Rest assured that this fix has no effect on project files; they are still cross-platform. The feature has to do with AC automatically mounting Windows servers in a cross-platform network.

I am the lucky recipient of a large renovation project which is moving into CDs.

I was surprised to see the file size, a finished-large-house-like 91MB. There's only one way for a project in DD to be so large: It must be carrying 2D axonometric and perspective drawings, pasted into details, from the 3D window. Sure enough, there are two axons and two perspectives, totaling 517,000 lines.

Is that a lot? Oh my yes. When I got rid of the four drawings, the file size dropped to a completely uninteresting 20MB. So, over 75% of the file consisted of four detail windows that you would never open in the course of daily work.

Who cares? You do, because it means that 75% of the time spent waiting for the file to open and save is wasted. Including opening it in the background from PM. Anybody think that process is fast enough? Me neither.

So don't drag half a million lines around with you. What to do instead?

Axons and perspectives should be published as PMKs. Once the PMK is saved, you can delete the linework in the window. If you want to save it for some reason, save it as a module. You can always merge it back. But listen: You never will. If the project image changes, you do the PMK over and the module is obsolete. If it doesn't change, the PMK sits there in the layout and no one ever thinks about it.

Note: This process will change substantially in AC10. How much? Well, AC10 doesn't do PMKs for one thing. And PM10 doesn't do anything at all because it's gone to a better place. More on this later.

In the meantime, no 90MB DD files.

Archicad is designed to automatically save project data periodically. In the event of an AC or system crash, project data can usually be recovered. AutoSave is described on page 150 of the AC9 Reference Guide.

More»

UPDATE: Better info here.

Suddenly, Richard's AC could not open a file on the network, and would hang (rainbow ball of death) when attempting to browse a network resource, such as the Hotel. We noticed it when attempting to open another project in Attribute Manager; since the previous state of that Open dialog was viewing the Onion, hang.

All conventional treatments exhausted, I had to call tech support. They directed me to this knowledge base article, which has to with switching off a cross-platform browsing preference that we don't need anyway.

If you ever see this behavior in AC, here's the fix.

Make sure AC is not running. Open Terminal (Applications : Utilities : Terminal). Paste this text into the window and strike enter:

defaults write com.graphisoft.AC\ 9.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

That's it. Quit Terminal and relaunch AC.

One day, I lost the ability to move door tags by their editing hotspot. Once I went to WE and switched "Pet palette movement" to "Jump to preferred position" under User Preference schemes -> Dialog boxes and palettes, the tags worked again.

This is the same setting that caused Kay's roof handle problem. It's interesting that they're both "moving a related thingy" problems.

Repair Permissions.

This is recommended for lots of issues, and it's at least partially voodoo. But it worked for me.

This is one of the stock OS X troubleshooting tips. It does actually solve some problems, and it doesn't do any harm.

Open the Disk Utility application in Applications : Utilities.

Select your hard disk name in the left panel. Select the First Aid tab in the right panel. Click the Repair Permissions button at the bottom.

It will take about 5 minutes, depending on the size of the disk. When the repair finishes, quit Disk Utility and restart the machine.

Some elements were deleted because of bad parameters (n)

This project is in use by [Somebody]

Unable to read temporary section file [ID]

Cannot find some Library Parts or Macros.

Other dialogs here.

More»

Problem: When dragging roof handles, they would sometimes end up at an arbitrary point, rather than where they were dragged.

Other problem, which only emerged after reinstalling AC: Attempting to pan with the scroll wheel would zoom instead.

We tried everything*, including wiping the disk. The fresh system fixed the panning problem. We were bringing in the work environment when we discovered that the trouble was caused by the User Preference Schemes segment of the RND Profile. We re-exported the scheme to the Onion.

Fortunately, that scheme is easily rebuilt. If the shortcuts or the Info Box had been the problem, I would have been very sad.

Moral: If you see weird behavior in Archicad, try switching to a standard Work Environment profile. If that fixes it, recreate the needed profile and trash the old one, and don't reinstall your system!

* Unrotating the grid. Looking for pattern related to shift constraining. Trying different files, and new roofs. Trying to reproduce the problem on another machine. Checking permissions. Saving locally. Saving and reopening an archive. Trashing the prefs. Trashing the caches. Creating a new user and seeing if "he" has the problem. Reinstalling Archicad.

It's odd that neither trashing the prefs or creating a new user solved the issue, since the Work Environment is in the prefs. But we tested the cause carefully as we brought the WE back, and it's definitely the culprit, probably in combination with an underlying system problem.

UPDATE: The precise setting that caused the problem is the "Pet palette movement" under User Preference schemes -> Dialog boxes and palettes. "Follow Cursor" was the culprit. Switching to "Jump to preferred position" fixed it.