We value your input!
Please participate in Archicad 28 Home Screen and Tooltips/Quick Tutorials survey

Libraries & objects
About Archicad and BIMcloud libraries, their management and migration, objects and other library parts, etc.

US Library Door Problem

Anonymous
Not applicable
Is it just me or are the US library doors and windows simply hopeless?

The main problem I am having is that when I select "custom" as the door panel type I am not able to enter anything into the custom field. I have tried in both the AC13 and AC12 libraries.

I had the Cadimage tools installed earlier to test them, and they had inserted their own (uneditable) panel type. Perhaps this is a residual problem?

Is this working for other folks? Do I have to do a more aggressive removal of Door and Window Builder?

BTW: Have others noticed that the GS door and window parts are now script locked? I understand that they don't want to get support calls about parts someone has modified, but it prevents me from investigating the issue
17 REPLIES 17
Peter wrote:
The whole object is controlled by the gs_general_door_macro. The other scripts are empty! The only job it does is to specify which gs_doorcode to use.
This is similar to what they did with the S/E Markers in AC11 -- the scripts for all Markers are in a single macro. And the gs_general_door_macro came about in AC12.
MacBook Pro Apple M2 Max, 96 GB of RAM
AC27 US (5003) on Mac OS Ventura 13.6.2
Started on AC4.0 in 91/92/93; full-time user since AC8.1 in 2004
Karl Ottenstein
Moderator
Hi Peter,

Very interesting (scary) diagram. The US library uses different macros ... and a different tree. But mind-boggling complexity that makes modification or debugging a challenge I think.

Matthew,

No, nothing is hidden - there is only that call in the Master Script. It is not possible to truly hide GDL code BTW... you can always get to it in one way or another.

Cheers,
Karl

PS After opening macros quite deeply, I went back to the Master Script of gs_general_door_macro_USA which is where each door has its name mapped to an integer code. These integers are then used in all of the other macros to 'do the right thing'. Keeping these 'door type' codes straight seems insane to me ... take a look, or otherwise just imagine the number of IF statements doing different things based on these code numbers. Think of how things would break when a new door is added, or an old one deleted!
gs_door_type = 0
if gs_doorcode = "D1 Entrance"				then gs_door_type = 1
if gs_doorcode = "D1 Entrance Side1"		then gs_door_type = 2
if gs_doorcode = "D1 Entrance Side2"		then gs_door_type = 3
if gs_doorcode = "D1"						then gs_door_type = 4
if gs_doorcode = "D1 Int Door"				then gs_door_type = 5
if gs_doorcode = "D1 Transom"				then gs_door_type = 6
if gs_doorcode = "D1 1Sidelight"			then gs_door_type = 7
if gs_doorcode = "D1 1Sidelight Transom"	then gs_door_type = 8
if gs_doorcode = "D1 2Sidelight"			then gs_door_type = 9
if gs_doorcode = "D1 2Sidelight Transom"	then gs_door_type = 10
if gs_doorcode = "D1 Double Acting"			then gs_door_type = 11
if gs_doorcode = "D1 Int Asymmetric Door"	then gs_door_type = 12
if gs_doorcode = "D2"						then gs_door_type = 13
if gs_doorcode = "D2 Int Doubledoor"		then gs_door_type = 14
if gs_doorcode = "D2 Transom"				then gs_door_type = 15
if gs_doorcode = "D2 1Sidelight"			then gs_door_type = 16
if gs_doorcode = "D2 1Sidelight Transom"	then gs_door_type = 17
if gs_doorcode = "D2 2Sidelight"			then gs_door_type = 18
if gs_doorcode = "D2 2Sidelight Transom"	then gs_door_type = 19
if gs_doorcode = "D2 Double Acting"			then gs_door_type = 20
if gs_doorcode = "D2 Double Egress"			then gs_door_type = 21
if gs_doorcode = "D1 Segmented"				then gs_door_type = 22
if gs_doorcode = "D1 Segmented Transom"		then gs_door_type = 23
if gs_doorcode = "D2 Segmented"				then gs_door_type = 24
if gs_doorcode = "D2 Segmented Transom"		then gs_door_type = 25
if gs_doorcode = "D1 Bifold"				then gs_door_type = 26
if gs_doorcode = "D2 Bifold"				then gs_door_type = 27
if gs_doorcode = "D1 Garage 1"				then gs_door_type = 28
if gs_doorcode = "D1 Garage 2"				then gs_door_type = 29
if gs_doorcode = "D1 Garage 3"				then gs_door_type = 30
if gs_doorcode = "D1 Garage 4"				then gs_door_type = 31
if gs_doorcode = "D1 Segmented Garage 1"	then gs_door_type = 32
if gs_doorcode = "D1 Segmented Garage 2"	then gs_door_type = 33
if gs_doorcode = "D1 Segmented Garage 3"	then gs_door_type = 34
if gs_doorcode = "D2 Sliding"				then gs_door_type = 35
if gs_doorcode = "D3 Sliding 1"				then gs_door_type = 36
if gs_doorcode = "D3 Sliding 2"				then gs_door_type = 37
if gs_doorcode = "D4 Sliding"				then gs_door_type = 38
if gs_doorcode = "D1 Pocket"				then gs_door_type = 39
if gs_doorcode = "D2 Pocket"				then gs_door_type = 40
if gs_doorcode = "D1 Sliding Ext"			then gs_door_type = 41
if gs_doorcode = "D2 Sliding Ext"			then gs_door_type = 42
if gs_doorcode = "D1 Commercial"			then gs_door_type = 43
if gs_doorcode = "D2 Commercial"			then gs_door_type = 44
if gs_doorcode = "D1 Combi Commercial"		then gs_door_type = 45
if gs_doorcode = "D Empty"					then gs_door_type = 46
if gs_doorcode = "D1 Metal"					then gs_door_type = 47
if gs_doorcode = "D2 Metal"					then gs_door_type = 48
One of the forum moderators
AC 28 USA and earlier   •   macOS Sonoma 14.7.1, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Karl Ottenstein
Moderator
OMG. I just traced one snippet of code and don't think I can bear to look any more.

Inside gs_general_door_macro_USA there is an IF block for segmented garage doors that calls "dp_segm_gar_usa" with the following parameter assignment:
gs_optype_m					= 1*(gs_door_type=34)+10*(gs_door_type=32)+11*(gs_door_type=33)
The gs_opttype_m parameter will either be 1, 10 or 11 because a gs_door_type can only be one of 32, 33 or 34 (type of garage door - see list in PS of last post). So, they are doing this decimal multiplication and complex formula simply to make 33 become 11, 32 become 10 and 34 become 1... An expensive (multiplication) and confusing (by a 1 line formula) way of mapping one set of integers to another.

Then, inside the gs_sgem_gar_usa macro, they have this:
IF gs_optype_m=1 THEN
...
ENDIF
IF gs_optype_m=10 OR gs_optype_m=11 THEN
...
ENDIF
Which is the same as doing the first block for a door_type of 34 and the second for types 32 or 33. Is the mapping confusion necessary? Maybe if some other doors call this macro and the optype (operation type?) code is required for them as well. But, then document it for goodness sake. I should mention that no code - door type, optype - nothing - is ever documented with comment lines in these obscure macros.

This is not code that lends itself to modification and maintenance, especially the addition of new library parts or modification of old ones. It is the antithesis of software as a "kit of reusable parts", much less any object oriented thinking. I'm impressed that people like Laura and Peter have even ventured to modify these things. Good for you two! 🙂

Cheers,
Karl
One of the forum moderators
AC 28 USA and earlier   •   macOS Sonoma 14.7.1, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
Karl wrote:
.....I'm impressed that people like Laura and Peter have even ventured to modify these things. Good for you two! 🙂
To be honest, I have never 'successfully' modified any of the doors or windows They are a little beyond my abilities! I can only say I have done a little probing to try to see how they work.

I did manage to get the hidden demolition parameters to semi-work by editing 3 submacros to unlock the necessary parameters. It's difficult to tell if I was completely successful because the feature I guess is still only partially implemented in the script and doesn't seem to work properly yet.

I also found this library developer guide quite useful in helping work out what the different parameters in each macro actually control -

http://www.graphisoft.com/ftp/techsupport/documentation/developer_docs/BasicLibraryDoc/13/
Erich
Booster
Peter wrote:
As an exercise I analysed the one of the simplest windows in the library
Quite an impressive diagram Peter. You are a very patient person to have tackled this. I started down that road awhile ago and ultimately decided that it was much easier and more effective to just write my own doors (windows to eventually).
Erich

AC 19 6006 & AC 20
Mac OS 10.11.5
15" Retina MacBook Pro 2.6
27" iMac Retina 5K
Anonymous
Not applicable
Wow. I didn't expect my little questions to lead to so much interesting discussion. I'm reminded why I gave up modifying the standard parts a long time ago.
Barry Kelly
Moderator
These library parts are getting so complex and convoluted that it would be impossible for the average (even advanced) user to make any modifications or bug fixes themselves.
Which means anyone using these parts has to rely on GS to modify and bug fix them and hopefully release a library hotfix (that doesn't break something else).
Then how many times have you heard GS say that it will be fixed in the next version - I saw this mentioned just a little while ago though I can't remember what library part it was refering to.
If there is a problem with a library part we need it fixed in this version and now.
Don't wait for a whole library hotfix - just issue the amended part and necessary macros.
Or keep the whole library up to date on a server that can be downloaded at any time.

And with scripts this complex am I crazy in thinking that GS have a much more advanced GDL editing system than they give us in Archicad?
How do they keep track of all the parameters and macro calls and if, when,while, etc. routines?
And all without explanitory comments in the scripts.

There, I've had my Monday morning rant.
I feel much better now - until next time I have to deal with a GS object.

Barry.
One of the forum moderators.
Versions 6.5 to 27
i7-10700 @ 2.9Ghz, 32GB ram, GeForce RTX 2060 (6GB), Windows 10
Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11
Frank Beister
Moderator
Doors an windows are the king class of GDL programing. MHO.

I have modified a lot of original GS objects. The last window I changed was in ArchiCAD 6.5. The actual versions are really to complex.
Which is the same as doing the first block for a door_type of 34 and the second for types 32 or 33. Is the mapping confusion necessary?
I think much of the confusing code is, that the macros are extended version by version for new functions, but they have to work with older d/w versions because of the migration libraries. I think this is a possible reason for doing remapping of indices. Sometimes its easier to to a remapping instead of crawling through the whole code.

When GS started to standardize the general parameter names (AC 8?) most objects have been adapted by a large mapping table in master script. Quick and ... dirty.
And with scripts this complex am I crazy in thinking that GS have a much more advanced GDL editing system than they give us in Archicad?
How do they keep track of all the parameters and macro calls and if, when,while, etc. routines?
And additional multilingual! Much objects and macros exist in localised versions!

Once I asked GS for a better IDE for GDL development. They told me, that GS develops a new internal system for their standard library development. But nothing for the great unwashed.

How amazing, if it would give a plugin for eclipse or ...
bim author since 1994 | bim manager since 2018 | author of selfGDL.de | openGDL | skewed archicad user hall of fame | author of bim-all-doors.gsm