Error message in 3D (GDL Code Robustness)

[Anonymous]

When working in 3D or when working on an elevation when the walls are turned on, I sometimes get the following message...

"polygon is degenerated at line 278 in the 3D script of file wa_frame_us_10.gsm"

I have had this happen before when a door height gets accidentally set to zero or something similar to that. In this particular case, I cannot find what is causing the problem. Is there a way to find out what is causing this?

[Anonymous]

Doing a little research, it seems that there is not definite way to figure out what is the problem, just through the process of elimination. There should be a way to jump to the error or the element that is causing the error. This would save many people a lot of time...

[Karl Ottenstein]

Steven wrote:
Doing a little research, it seems that there is not definite way to figure out what is the problem, just through the process of elimination. There should be a way to jump to the error or the element that is causing the error. This would save many people a lot of time...

Actually, the solution is for Graphisoft to produce library parts that work - then nobody will see this and other errors. The problem is that many Graphisoft library parts do not do sufficient error-checking and consistency-checking on their parameters, allowing the entry of values (as you've seen in the past) that cause the part to bomb out.

I would much prefer seeing proper quality control for library releases to better tools for tacking down errors which are not really caused by the user. 😉

Cheers,
Karl

[Anonymous]

But that would make more work for Graphisoft! We wouldn't want that...

[Erika Epstein]

Steven wrote:
But that would make more work for Graphisoft! We wouldn't want that...

Or they could hire Karl. I've been thinking of making this a poll

[Karl Ottenstein]

Erika wrote:
Or they could hire Karl. I've been thinking of making this a poll

Thanks, Erika ... but no thanks. (Said in my best Sarah voice.) Cleaning up the existing library code would be, for me, akin to having to clean the floor of a public restroom on my hands and knees. Ugh.

Cheers,
Karl

[Anonymous]

Karl wrote:
The problem is that many Graphisoft library parts do not do sufficient error-checking and consistency-checking on their parameters, allowing the entry of values (as you've seen in the past) that cause the part to bomb out.

The root of the problem is the GDL language itself. It lucks normal structure-oriented instructions, protection and checking of variables, debugging commands. It looks like a dinosaur from 1980's.

Programmers are people too . And making mistakes is one of their essential quality. But program language has to help programmer think clearly and concentrate on the main point of his/her code, not on fighting with the language.

But I can't make any suggestion. There are lots of things Graphisoft must to do for ArchiCAD looks like a good program. But they prefer continue adding new improvements, which add new errors and bring back old ones...

[Anonymous]

Steven wrote:
There should be a way to jump to the error or the element that is causing the error. This would save many people a lot of time...

You are absolutely right! Even half-by-half elimination process takes 5-10 min, and it can take more, if there are more than one spoiled element...

[Erika Epstein]

Karl wrote:
Cleaning up the existing library code would be, for me, akin to having to clean the floor of a public restroom on my hands and knees. Ugh.

Cheers,
Karl

You really know how to make the poor shmo(s) stuck with the task feel good

[Aaron Bourgoin]

why does it just keep coming back to the potty references?