update objects GDL script on Mac

[Anonymous]

Hi ArchiCAD developpers,

I have recently worked on a GDL object in ArchiCAD 21 and used it in a project in version 23.
I updated several times the script in AC 21 as I needed several changes to the object and it updated flawlesly in AC 23 with all the changes. I use this way of work for compatibility reasons. As I collaborate, I may use the object in a project developed in an older version than 23 and need to keep the script in AC 21.

Yesterday I have done several other changes and had a very strange behavior and wanted to know if somebody can give me a hint. I updated the script in the parameters menu with an array changing it from variable[30][2] to variable[30][3] - changing the number of columns in the array. The update stuck. In AC 23 the object doesn't want to update even if I updated several times the link with the library. The appearance of the menu in AC23 is stuck to an older version of the object even if the newer object is in the library. The same object seen in AC 21 had a different menu in AC23. Worse than that, I worked and saved other things in the project (AC 23). I restarted the computer thinking that maybe it's a memory update that is needed in ArchiCAD 23. Strangely enough, in the library the newer object was updated to an older version done with few days before and the newer version that I worked on it a few hours before disappeared without trace. I couldn't retrieve the newer script and couldn't find the newer object. I use the same library location for years and never had such a weird behavior. I had to redo the script and this time thoroughly copied the newer object in a different folder just in case. I started working on the AC23 project and saved it again. Restarted the computer after several hours as I need to go out. Well, when I restarted it the problem happened again. The older object reappeared in the library replacing the newer one without warning. This time I copied the newer version saved before over the older version in the library. The strange becomes stranger. The newer object copied over the old one is no more recognized in ArchiCAD 23. OK! Now I opened the newer version in AC21 and then saved it over the older version in the library. Hopefully now the object is recognized in AC23 but again with the older version of menu not the newer one that is actually present in the library... There is only one location and only one version of the library, there is no copy of it somewhere else. Never seen this before and I have a long experience in working on GDL objects. Never had problems with versions like this one.

My question is for ArchiCAD developpers. I put a newer version of the AC21 object in the library. From AC 23 the object in the library is seen as an older version (a different menu) but that older version is no longer available on my computer as I updated the object in AC 21 saving the script over the older one. I cannot find the older version in the library and it's not in the Embedded library of the project either (never put it there anyway). Where from does read ArchiCAD this older version of the object? What memory does it use to keep an older version of an object in the project and how to erase it in order to update the object? Has someone an answer to this 20 points question?

[runxel]

If you work on the parameters things like this might happen.
I developed the habit of going into the objects settings of placed objects, and right click on the icon in the left pane, selected "Revert to default settings" (or simliar wording).
Only after this step placed objects will accept the new/changed params fully.

[Anonymous]

Thank you runxel! That's a good tip!

It worked, but let's say "halfway". It updated the object and that is excellent, but nevertheless it changed the parameters to the default ones. The object is complex, it has many (many by a lot) parameters and I have to reintroduce the entire set of values for dimensions, materials and other characteristics. There is one more thing to notice : it has to be done step by step for each instance of the object that is put in the project, at list, this is what I discovered with this project. Strangely, even if they have the same name and ID, the other instances of the object didn't update as expected. If there are many of them used in the same project with different values, then, one has to review the entire project and change every instance... basically rework what was already done before. All this, while the object's name and ID didn't change when the scripting was done... In conclusion it means that the project file stores the values for each version of an object separately.

I reword my question to ArchiCAD developers : Isn't it possible to update an object but keep the project's preexisting set of values for the unchanged parameters of the object's script even if there are new parameters that are introduced in a newer version of it? Setting numbers for the versions of an object (as it is the case now) but let the user access those versions and be able to change the version used in the project would be useful.

[runxel]

You're welcome, Raoul.

Just one more explanation to make it clear:
When placing an object, all parameters "detach" from their origin and become normal variables.
That's also the reason, why you can override parameters in a script by just declaring it again.
And it's the same explanation why one has to use "PARAMETERS foo = bar" in the param script – that's the only way to write a value back to the parameter (which will trigger a rebuild by executing all scripts again).

So as long you don't alter the parameters, making a new version of an object is easy.
If you do however... well. Maybe try the migration script and migrate your objects instead of saving a new version in place.

[Aaron Bourgoin]

Is there any place in the Graphisoft universe that documents how to use the Migration Script? Clearly and concisely?

[runxel]

Aaron wrote:
Is there any place in the Graphisoft universe that documents how to use the Migration Script? Clearly and concisely?

Good question
David Nicholson-Cole doesn't talk about it, and neither does Andrew Watson.
The only thing I know is this small guide.

[Peter Baksa]

Hi Raoul,

A library part has a default parameter list, this is the one shown in GDL editor. The current parameter list that the user sets up is stored in the placed objects, not the library parts. The library part's default list can be loaded into the placed object's in the settings dialog, as a whole, not selectively.

As runxel suggested migration can (and should) be used to handle new and deleted parameters of a library part, keeping unchanged ones.

During loading a library, placed objects' library parts are identified by a GUID, not their names. Different versions of a library part have different GUIDs. Migration can happen between different GUIDs, the name of the library part is not important.

The GUID is not editable in the GDL editor, but the Save As... dialog has an option Create New Library Part when you save to a file, which creates a new GUID. If you work with embedded libraries, giving a new name creates a new GUID. If you need to migrate many objects, it might be easier to use LP_XMLConverter and edit the library part metadata directly in an external editor.

Backward migration happens when the plan is saved as a previous version. The master + backwards migration script is run.
If the script contains a SETMIGRATIONGUID command, the GUID of the placed object is replaced, opening the plan next time will look for the previous version of the library part.
During migration the previous version's parameter list is not known, but parameters can be added using the (counter-intuitively named) NEWPARAMETER command. Any parameters that are not in the default parameter list of the previous version will be deleted during loading.

Forward migration happens each time a library is loaded. AC looks at the migration table of each library part, and if it finds the GUID of a placed libpart, the master + forward migration script is run.
It can access both the old placed objects parameter list and the new libpart's new parameters' default values. Deleted parameters can be accessed using DELETED_PAR_VALUE, kept parameters can be used by just writing their name, new parameters' defaults are accessed by writing their name. PARAMETERS command can be used to change parameters, but you can't rely on the parameter script's mechanisms (multiple run, GLOB_MODPAR_NAME, VALUES, RANGE).
If the script contains a SETMIGRATIONGUID command, the GUID of the placed object is replaced, the master + parameter script is run on the replaced object.

Another type of forward migration is when the migration table entry has the AutoMigration option. This doesn't run the migration script, just replaces the GUID and merges the old parameter list into the new (discarding deleted parameters, setting default value for new ones). We use this only to change the names of library parts, but might be good for your case when the new parameter defaults are OK for any placed object.

SETMIGRATIONGUID "" also refuses the migration (in any direction), the GUID won't be replaced and the object will continue to use the same library part.

These are the outlines, ask if you have further questions.