GDL Script - User Origin Offset

[Patrick M]

When I create GDL objects, I often combine scripted and saved elements. As such, my method always involves saving from or related to a position intentionally at/near 0,0,0.
I have a file, when saving objects at 0,0,0, it thinks they are saved -650,-1780 from the project origin. 
I have checked the coordinates, there is no user defined origin I could be inadvertently saving from. I have checked the model primitives I'm saving, to ensure there is no cover fill handle or rotation axis/origin that is hundreds/thousands offset from 0,0,0.

View rotation is 0º in the plan view I am saving from.
...

 

 

Anyone else ever see an object save with absurd add commands in the resultant geometry?
My trouble is, if I place a scripted component or modify the script, it is virtually impossible to get things lined up with the saved geometry.

There has to be something I'm missing here!

Operating system used: Mac Apple Silicon

[runxel]

Patrick, can you confirm this also happens in a clean file started from an OOTB template?

The only reason I can think of is that at some point you saved this file and opened it again, with elements far away from the actual origin. In this case Archicad recalculates an offset to mitigate the "too far from origin" issue. This can not be seen in the interface, but GDL still refers to the original origin.

Other than that I have not seen this before.

[Pertti_Paasky]

I have wondered that, too. Try to draw 3d elements in the right place. If You later move them they possibly remember their original coordinates. That is my impression.

[Patrick M]

@runxel the elements copied into a blank file do save with the correct user origin, so there is nothing attached to or part of a group, including fill handles or radius center point, away from 0,0,0 when saving.
I have confirmed that with the saved elements isolated and selected, there is nothing else in the 3d view. The project I am saving it into DOES have elements farther from the project origin than I'd like, and htey have routinely failed the project audit on that point. But these elements are not part of the saved objects. If the script is somehow injecting those elements into the script, there is something broken. 
What is even weirder, when I punch in the 615, 1780, 0 xyz coordinates (in any order) there is nothing near those coordinate points at all, in any of the 4 quadrants.

[Patrick M]

maybe, but I use the save as object method a lot. and I never model at 0,0,0; I always model to the side and shift them over. Maybe these were modeled at 615/1780 points, and there is some breaking point for how far from 0,0 is 'safe', but again, that can't be by intent, making it a bug.

[Patrick M]

also, I can't replicate this from a blank file, making me think there has to be something buggy in this file triggering the issue

[runxel]

Well, before we enter the world of the bugs (which honestly is still very likely) I really want to exclude my theory.

That there is nothing at those coordinates was predictable, they do not mean anything.

You can try and use GLOB_WORLD_ORIGO_OFFSET_X /_Y. That's the magic Glob that holds the virtual origo – if it's set.

(Btw: that one will be only be set on opening. So anybody trying this in a new file: You will see nothing while testing like that. Save it and open it again. Also you need some elements far away, but the delta between the items must also still be small. So one element at zero and one at one miles away will not trigger it.)

Of course an open and repair might fix things up; but I also witnessed funny files that could not be helped. If no other file is affected it still might just be that: a funny file. Happens 🤷🏻‍♂️