On Land

An object like the Foundation Drain is trying to offer total geometry and annotation for a particular detail. We want to pack this object with all the data we can think of. The geometry is in good shape, but we're missing the notes calling out all the parts. These will need to be added manually with labels or texts. Since these notes are standardized, they will be written down somewhere; if nowhere else, in the last place you drew the detail. Or in a module, or in a text file. Either way, it's remembering and typing or copy and paste.

How could the notes live in the object? You could script a series of 'labels', with leaders pointing to the detail parts, and editing hotspots to position the texts. I'm skeptical of this. It's sophisticated coding to get an interaction that, to the user, would never be as smooth as moving text elements and drawing arcs and labels. To me, placing the notes isn't the problem, it's remembering/locating the data to write into them.

Here's another idea that would let us keep the notes in the object. Create a switch in the settings to put the whole thing in 'note mode'. Instead of drawing the lines and fills, the object creates a series of text blocks. (These can be multi-line and arbitrarily styled, like text elements, using the TEXTBLOCK and RICHTEXT2 commands.) Then you could copy/explode the object, which would give you text elements you could stretch and arrange as needed.

Unfortunately it doesn't work. When a multi-line text object is exploded, you get multiple single-line text elements. Not helpful.

We need RICHTEXT2 that explodes into a single text element regardless of shape.

Something to think about, or maybe not. Not all objects have to be right in every way.

Plan symbol
Plan symbol on remote stories
3D hidden line
3D shaded
3D render
Elevation
Elevation in distant area
Section
Polygon efficiency
Scale sensitivity; which compounds the plan symbol, section, and polygon issues
Listing
Labeling
User interface
Parameter list
Parameter transfer management (Unique parameters)
2D graphical editing
3D graphical editing
Selectability
Code maintainability
Intra-library consistency

A frequently used, complicated, widely viewable object, such as a window, needs to be right in virtually every way.

The development environment gives very poor support for many of these requirements. As ArchiCAD adds features, items are added to this list. Irritatingly, the environment has not kept up, and is way overdue for a tear-down. There is no section window, no remote stories, no graphical editing. The full features of the current GDL architecture are not supported, so we can't even imagine modern development features such as syntax coloring and auto-completion.

One of those things that bothers some people more than others.

This is somewhat redundant with the GDL Syntax section (pg. 23) of the reference guide. I'm trying to make it a little clearer.

More»

An object consists mainly of parameters and scripts.

More»

• The GDL Reference Guide. They don't give us a printed version anymore. That's OK, the PDF is better. This guide is a really bad tutorial, because it's not a tutorial. It's more like a dictionary. Once you have the basic ideas, it's very clear, and indispensable.

• The GDL Cookbook 3, by David Nicholson-Cole. PDF. Out of print, out of date, but still useful. How to do lots of things. What most of the commands do. A bunch of tips. Handy references for binary arithmetic and circle geometry. Inspirational objects by people smarter than us, such as fountains, waving flags, ferris wheels. David is the primary evangelist for GDL and ArchiCAD culture in general, one of the pillars of the community, and also the author of...

• Object Making with ArchiCAD: GDL for Beginners, published by Graphisoft. PDF, or buy it at the link. It covers object making without GDL, and then GDL for beginners.

• The Libraries / Library Parts / GDL forum of ArchiCAD Talk. Like any question you might consider asking on ACTalk, ask me first, it's faster.

• GDL Talk on Yahoo Groups. Same advice as above, with the added caveat that issues in this forum tend to be of a higher level.

• The File -> GDL Objects -> Open Object command. GDL scripts are de facto open, and it's a good way to see applied examples. A word of advice: It's also a good way to see bad scripting, especially in the ArchiCAD library itself. Anyway, no one can stop you from reading a script and trying to figure it out.

• Your humble narrator. On a scale of 1 to 10, I'm a seven. I don't know everything, but I know of everything. I've done tons of it, over the course of five years. I've done a couple of things first, maybe. I can't teach you all I know due to time constraints, but I can give guidance on basic to intermediate questions.

All the PDFs mentioned here are available at 3 Resources : Documentation. Remember, PDFs in your local ArchiCAD 9 : Documentation folder will show up in the help menu within ArchiCAD. So handy.

I strongly, strongly, strongly recommend opening all PDFs in Preview, the reader by Apple that comes with OS X, rather than Acrobat Reader by Adobe. It's faster, simpler, launches quicker, and has better searching. No comparison.

You're mostly on your own. I can help with questions, but the way you learn is struggle. Once you get the basic ideas, the GDL manual actually makes sense. The code itself is not very hard; GDL is a lightweight in programming language terms. The hard part is design, and being perfect.

Yes, perfect, at least with regard to spelling and syntax. When you are working with code, errors really aren't tolerated very well. The machine has no idea you meant "PRISM_" when you typed "PRSM_". This is very different from high level software, where the developers of a program have written in the ability to cut the user some slack. For example, you can have MS Word switch that spelling error for you before you even see it. Another: A big part of ArchiCAD is detectability, which is a way of saying, once you're close enough, you're there.

Code doesn't work like this, and it can be frustrating, especially since some of the error messages you get are a little cryptic. It takes patience, which, it turns out, is more of a habit than a trait.

OK, end of parental advisory. What is GDL? It is the language of Objects, in all their types: doors, windows, lamps, labels, zone stamps, properties. It is a way of using words, logic and math to create drawing and model elements. In its simplest form, a GDL script says: "Go over there, make something, come back." (The coming back is technically optional, but do it anyway.) The complexity and power come in when the script can say: "Depending on what the user [that's you] does, or on conditions in the environment, make things a certain way, or in a certain quantity, or in a certain arrangement, and if the environment changes, adjust/change/rearrange the things as appropriate". And: "Remember that these things are usually particular building parts, so you should know something about them if anyone asks, which they will."

The ability of objects to change themselves on the fly in response to changes in the environment or decisions by the user is called "parametrics". You can have objects that aren't parametric, such as those saved from the plan or 3D window. Such objects are useful, but they're not flexible, so they tend to be one-offs. Parametric objects can act smart and follow rules, saving you a lot of time. This leads to an axiom:

It is impossible to professionally deploy ArchiCAD without customized, parametric, GDL objects. GDL is the way you get ArchiCAD to do exactly what you want.

From this, it follows that we make objects to solve problems, and we learn GDL so we can solve problems that ArchiCAD can't solve by itself. It also means we learn what we need to solve the problem we have, and leave the window library to someone else. This is because windows are hard, and a lot of people are way ahead of you. But you likely have some problem that no one has worked on yet, and chances are that even a little GDL can help.

GDL is arguably the single most powerful feature of ArchiCAD. That doesn't mean everyone has to do it, but it does mean that one person in each firm has to do it, or at least have access to the skills somewhere.

I would like to offer the opportunity to join an introduction to GDL, i.e., object scripting, for anyone who is interested. And, I would like to not offer it to anyone who is not. Interested.

I'm thinking of a map of the territory, a broad overview, with the goal of demystifying object making, so you can envision creating custom solutions yourself, with help. I'm not envisioning teaching you the whole thing, which no one has ever done for anyone.

I'm pulling together some preliminary reading here, under the category "GDL". If you are interested, browse this material, and then we can set up a meeting.

Let me know what you think.