[Wish] Scripting in AC

[Karl Ottenstein]

stefan wrote:
--> side thought: I have a very small example running into our internal CAD-tool (still very much pre-alpha) but believe that this is achievable in Archicad as well, as long as I learn how to step through the 3D-geometry and the materials.
--> I don't even know if it'll work through a Rendering-plugin or more as a direct export-plugin.
--> This is actually the kind of things that other applications can perform using scripting.

How do others feel about the advantages of being able to script AC rather than have only the heavy-iron API solution?

For some time, I've thought of writing an add-on that provided scripting facilities for all AC users. As you know, the power of such an add-on would be limited to the functionality exposed by the current API. (Let's make API functionality extension a separate group of wish-topics.)

An alternative (or addition) that I have wished for is a fully exposed server interface to AC so that AC could be scripted from external tools such as Visual Basic, which are more friendly to more users.

A few of the advantages I see to a scripting solution include:

- makes customization more accessible to a wide range of users, not just C++ programmers

- lets the same source-level script be shared on both Mac and Windows platforms, no need to have both a Mac and PC, Codwarrier and Visual Studio ($$ and knowledge) to compile two versions of an add-on

- is safer for the end-user. An add-on can do anything, including erasing the user's disk - by mistake or intentionally. Scripting can be easily controled - limiting the types of operations that can be performed, and user-enabled warning dialogs could be displayed before changes or deletions to the model are made.

Other thoughts?

Karl

[Ralph Wessel]

Karl wrote:
Has anyone in this forum tried Xcode? Or are there features in the API SDK that tie it to CodeWarrior?

I use it, but you can't directly build add-ons for ArchiCAD with XCode because it doesn't support building executables for the old CFM architecture (it only supports Mach-O).
However, you can use bridge technology in the Mac OS to call into a dyld-based bundle from CFM. I used this in GBS Energy because it opens up a wealth of developer resources that aren't otherwise usable in a CFM executable.
In short, you can use XCode, but you will always have to use CodeWarrior as well (for the meantime). I prefer CodeWarrior anyway (it's by far the fastest), but there are many very nice features in XCode.

[stefan]

I like MAXscript in 3ds max. It's not too difficult and is very, very powerfull. If you imagine what plugins have been created using only the scripting language, it's amazing!

---

I also like VBA. I've used it quite a bit in Excel and recently in AutoCAD and it is very approachable. In fact, I think it's better then GDL.

I like the VBA IDE. It's clean, it's usable and it get's the job done. This is the interface that is missing for GDL development.

---

Would it be possible to extend GDL into a complete scripting language, that is usable to control ArchiCAD completely? In that case, a lot of Add-ons could be built in GDL.

Or am I missing the point completely?

Free GDL from it's objects. Make it able to reach the whole project and the whole application.

[stefan]

It's quiet in this forum...

[Karl Ottenstein]

stefan wrote:
It's quiet in this forum...

Shhhh. We were sleeping! 😉

stefan wrote:
I like the VBA IDE. It's clean, it's usable and it get's the job done. This is the interface that is missing for GDL development.

I agree! ... but for API development as well: compare building a dialog box in the VBA environment and making it function properly to doing the same task with the dialog resources in the API SDK. Being platform independent (Windows/Mac OS) has its downsides ... GS would have to build or purchase a platform independent IDE, which I suspect would cost much more than the potential financial return to them. I sure hate reality sometimes. 😉

Would it be possible to extend GDL into a complete scripting language, that is usable to control ArchiCAD completely? In that case, a lot of Add-ons could be built in GDL.

I don't see why not ... I've built several compilers and interpreters in my day. I just see that the GDL language and environment is so primitive now, that doing this would be a bit of work ... and, as above, think GS would have to see how to get a return on their investment before thinking about it.

It is possible to write an independent scripting add-on, and I've thought about doing that ... but frankly and IMHO the API does not provide the needed functionality at present. Too much information is read-only, or not accessible. Yes, add-ons can be written that do remarkable things, but for scripting, IMHO, you should minimally be able to 'automate' every menu command and dialog ... and this is not possible at present. (An example: you can retrieve the current ghost story index, but you cannot set the ghost story to another floor. Another: publisher settings are not available.)

Money can solve all of these things of course... but what argument could be made to GS that they would make enough new sales if they made the investment?

There is a poll happening at:
http://archicad-talk.graphisoft.com/viewtopic.php?p=21589#21589
perhaps more feedback there will tell all of us what the user community feels.

Karl

[Anonymous]

This topic has been quiet a while, but I think it's a great idea.

What about Python? It's cross platform, very flexible, easy to learn...no fees. It can be compiled which might give you some speed advantage over normal scripting, but at the same time it's easy to modify.

Not sure what would be required, but there are bindings for Python to MANY languages, C++ included.

I've done scripting for Bentley Microstation for a while now. For most problems, their C-based MDL requires too much effort- the ability to script really enables even average users to speed up repetitive or specialized processes.

[Anonymous]

A program of that magnitude without scripting is unacceptaple.
GDL is very good for creating basic objects BUT it lacks even basic user interaction.

A vba like solution whould be very very good.
I hope we will get some sort of solution soon.

[stefan]

Ruby is used in SketchUp. It's Object-Oriented and Cross-platform.
I think Python and Javascript are good options too.

VBA is nice, but tied to Windows.

In fact, AutoCAD, 3ds max, Softimage XSI, Maya and others support more then one interaction:

C++ development for add-ons (only for developers)
Scripting for (experienced) end-users
Macro-recording for less experienced end-users.

Some go as far as supporting several programming languages: e.g. AutoCAD can use command scripts, Lisp, VBA, C++, .NET and probably some others too. And look at what it has done to the market for AutoCAD add-ons!

[Anonymous]

Matthew wrote:
...One of my favorite RAD tools (which is also cross platform) is 4D (4th Dimension) which isn't really a RAD tool but a database that can build standalone apps. I actually built a wood framing add-on demo for AC with it about 12 years ago...

Matthew,
What ever happened with that wood framing add-on? Wasn't it called "FrameMaster" something like that? I remember meeting you in San Francisco and seeing a printout about it back around 1992... I think I still have a copy of the printout buried deep somewhere in my files.

This "scripting in AC" thread is timely and interesting. There are so many specialized features/uses an end users might need ...we all need a better ability to tweak ArchiCAD to meet our "unique" requirements.

ArchiCAD is a powerful tool but I find it amazing that 15 years or so after entering the US market it still doesn't have a useable suite of floor, wall, and roof framing tools. It looks like CadImage may be filling that gap with its new framing add-on but AFAIK this is only for wall framing.

Any possibilty of resurrecting FrameMaster and building a more complete suite of framing tools?

Dan K