LibraryGlobals13 has been replaced by Objects_MVOSettings ?

[Laurentiu]

I've started learning some GDL in Archicad 27 and have been using the LibraryGlobals13 to control the LOD of objects.

I'm now using Archicad 28, and have gone over some of the code to refresh my memory, and everything that I've coded before seems to still work fine with LibraryGlobals13.

I did however notice that I can not open the LibraryGlobals13 macro anymore, so I dug a bit deeper and found that Graphisoft objects now use these two macros GetObjectGlobals & Objects_MVOSettings.

I did manage to adjust my script to map to the new Objects_MVOSettings values, so I got it working fine with the new macro.

My first question is, for future objects should I keep using the LibraryGlobals13? or would it be better to just update everything to the new macros, considering that I'm most likely not going back to AC27.

My second question is, considering past experiences, is there a possibility the old macro will not work in future Archicad versions?

And lastly, how come the LibraryGlobals13 still works, even though the macro isn't openable/accessible ? is there something working in the background that makes it work?

[runxel]

The MVO was introduced in version 13, that's why they named it "LibraryGlobals13" – only to realize a hot minute later that this was an undeniably bad idea for very obvious reasons, and so it stuck for compatibility reasons with us for another fourteen versions. 

With the Global Library this birth defect could be rectified, so now its called a bit more explanatory and is also versionless (like the rest of the lib).

If you already did the switch to the new Global Lib there is no need to cling to the LibraryGlobals13 object, just use the new one instead.

I am wondering that it still worked for you tho. Are you sure you didn't accidentally had it loaded?

[Laurentiu]

Thanks for the clarifications. I'll use the new macro from now on.

Regarding the LibraryGlobal13, I created a new file in AC28, deleted everything from the library manager, even cleared up all errors , and copy pasted two objects inside. One object uses the old macro, and the other the new one.

The MVO switching still works, for both LibraryGlobals13 and Objects_MVOSettings.

Here's the file in case you wanna see that switching between MVO works both in 2D and 3D.

Maybe the macros are somehow automatically added if they are detected in an object. I don't really know.

[scottjm]

My understanding of this is that calls to macros and MVO global object names are able to reference the migration table of the object it’s looking for and therefore know their legacy object name, so as to maintain compatibility even if you are using their old name. 

I had thought all of the new objects in the global library had their migration tables removed (hence why you can’t migrate these objects from the monolith library). 
I wonder if the new MVO object still has a migration table item with LibraryGlobal13 included. 

[runxel · Accepted solution]

So, usually the logic here is that every .gsm saves all called macros to the aptly named "calledmacros" xml (you can see that when using the LPXML_Converter with the HSF format).

This was a change when Archicad learned what GUIDs are some long time ago. In the olden™ times calling only worked via the name – that's the reason why we can't have objects with the same name loaded at the same time. For backwards compatibility this is still the same.

Nowadays tho you can easily rename an object and the reference won't break, because every object basically has their own lookup table integrated. Smart move!

That's actually the first step. If there is no match found AC will try to fetch by the macro's name, and only if neither matches the libpart breaks.

But in this case there is no clear continuity between those parts. The name changed, and the GUID did too (I just checked). The migration lookup table is empty as well, as like for any other library part in the new Global Library. There is no connection. So my best guess is that this is actually hardwired internally, or I could as well imagine a mechanism that if neither is found it will walk just through all MVO objects (usually there are not that many loaded anyway, so this is something I would do as a programmer because it makes everything more robust while sacrificing little to no resources) and look for the requested parameter name.

But only GS folks can convincingly comment on that.

In any case I'm amazed it actually works, which out of huge curiosity I just tried.

[Laurentiu]

Oh well, I'm guessing this is as good as an answer we're gonna get. Ty both @runxel & @scottjm 😁