Migration again: (when) does FWM script run?

[Sam Karli]

In a previous topic I have already tried to understand the circumstances of custom migration of ArchiCAD objects ( https://community.graphisoft.com/t5/GDL/How-to-migrate-OFF-Archicad-library-object/td-p/343848 ), now I need it, again, and it still doesn't work.

To condensate my question to the simplest form, it is:

when migrating, if I write an one liner FWM script:

parameters sSomeParameter = "Some Value"

(and nothing more) should be value of the (obviously existing) sSomeParameter's value set to "Some Value"?
Note that for me migration DOES occur, migration table is filled out, old objects are changed to new objects accordingly, but I have never saw any effects of FWM script and don't now what the problem is.

Code samples of FWM Scripts look like they are filled with **beep** (irrelevant looking subroutine calls etc.) that doesn't seem to be must-be (like TO_GUID, FROM_GUID etc.)

But who knows, maybe FWM scripts have a must-have format, sequence, etc.

Thanks in advance.

[Dominic Wyss · Accepted solution]

Hi Sam,
I had the same questions and issues. The crucial part is that in the migration table, "AutoMigration" is turned off. Only then are the migration scripts executed. Regarding the example script, you are right... it has quite a bit of boilerplate. Even simpler scripts work well. However, the most important thing is at the end, passing the current GUID of the new object with "setmigrationguid." Otherwise, the migration fails. This can also be used intentionally to make the migration fail by setting "setmigrationguid" to "".

!! only runs when AutoMigration is turned off in migration table !!

!-- get value of deleted parameter
if deleted_par_value("oldPar", _oldPar_val) then parameters newPar = _oldPar_val

!-- just set value of new parameter
parameters migrated = "yes"

!-- most important: set to new guuid
setmigrationguid "6DF48F44-A977-4A50-94E7-35084538DC4D" ! GUUID of the new object

 HTH

[Sam Karli]

Wow, success.

So, to summarize it, there are two possibilities of migrating:

• Automigrate is ON: this way it is only needed to fill out the migration table BUT the Forward Migration Script doesn't run.
• Automigrate is OFF: this way the Forward Migration Script runs BUT there must be a setmigrationguid command that actually changes the object.

PS now the only thing is to explore is the versioning of the object ie. the "second part" of the guid. As far as I remember ArchiCAD has two guids, the first being the same for, like, Door 26 and Door 27 and only the second one is different. How to migrate this way,

[Barry Kelly]

---

@Sam Karli wrote:

PS now the only thing is to explore is the versioning of the object ie. the "second part" of the guid. As far as I remember ArchiCAD has two guids, the first being the same for, like, Door 26 and Door 27 and only the second one is different. How to migrate this way,

---

There is a sub-type GUID but that is not used in the migration.

That should stay constant - a door is a door.

The GUID you see in the migration table is unique for every object, and that is what you need to use.

I use the migration table to find the GUID of the new object as well as the old ones you want to migrate.

Just be sure to delete the new object GUID from the table list once you have it in the migration script.

Otherwise your objects will not migrate.

Barry.

[Peter Baksa]

Hi,

the second part - revision ID - (shown in subtype hierarchy window) is not important (and not visible) to GDL.

Migration only happens when the main GUID is not in the loaded libraries. Same main ID, different revision ID is considered a match, the currently loaded .gsm is used without running migration script.

https://gdl.graphisoft.com/gdl-style-guide/library-part-format

[Sam Karli]

That is rather sad.

That is because I'm thinking of systematically modifying objects in projects architects work already on by migrating.

Typical situation is as follows:

• We have objects already placed
• For (a part of) objects we want to change a parameter systematically, so
• We unload the (existing) library, load up the "new" library, having a new version of the objects
• This is the point we want to run FWM script to modify params etc.

For this, we have to have a new guid for the (same) libpart, which is not elegant.

(Yes, it is possible to change params manually, but it is prone to errors, time consuming, architects have to do this etc., so not preferred)

A concrete situation was as follows:
In AC25 or WC26, there were Shower Plates (already placed) in a project. These had two types:

• Drain in the middle
• Drain in the corner

Architects wanted a third option, drain having at the middle of one side, so I added xDrain and yDrain to enable them to place the drain anywhere.

So we wanted to change all the Shower plates that have Drain in, say, the middle of the plate but unchanged ones that have drains in the corner.

Thx.

[Peter Baksa]

---

For this, we have to have a new guid for the (same) libpart, which is not elegant.

---

This is how migration is designed to work.

Placed objects store their parameter list and GUID of the script in the plan. The drawing refreshes by executing the script from the currently loaded library.

The new libpart in your case isn't the same, because it has two more parameters. If we would give the parameter list of the new shower to the old script, it could draw it differently, because it ignores the new parameters.

[Sam Karli]

But when, for example, migrating current AC versions, what happens as, like, Door 26 and Door 27 have the same main UUIDs GUIDs ? For newer ArchiCADs the main UUIDs GUIDs stay the same but I think the migration occurs, and I don't think it's only based on different names and/or different parametrization (none is guaranteed to change).

Thx

[Barry Kelly]

The name of the object can be different in each version.

If the GUID is the same in each version, there is no migration as such.

It is just loading the same object as it has the same GUID - it will just have the new name automatically.

Archicad does not load objects based on the name, only by the GUID.

If there are no changes, only minor changes to an object, or new features that only 'add' to the object, then there is no need to migrate, and the GSID can remain the same.

If you have two objects loaded (can be in the same of different libraries) with the same GSID (the objects can have different names), that is when you get a warning in the Library Manager that there are duplicated objects.

That is why you need to delete the old object from your library and it will simply get swapped for the new one (with the same GSID).

If parameters in the new object have been removed, new features added that will affect the existing object settings, or you need to force a parameter value change, then the object needs to be migrated to a new object with a new GSID.

In the migration script, you can control the setting of new and existing parameters.

You will have the new object in the library, but the old original one needs to be removed for the migration to happen.

When you load the library, if the object is missing Archicad can obviously not load it.

But Archicad also looks through all of the migration scripts to see if there is one that contains the now missing GSID and then swaps it for the new object with the new GSID.

If you don't remove the old object from the library, you will simply end up with two objects to chose from and no migration will occur.

Sometimes, new objects are just so different, it is not wise to migrate them.

In that case you can make the original object 'Obsolete'.

You will have bot the obsolete object and the new object in the library.

This means when placing a new object, it will not be seen in the selection settings - you will only see the new object.

But if you have an existing object in the plan already, you will still see the original object and its settings when you select it.

It took me quite a while to figure out how it all worked.

I am sure I am probably still missing things.

But I can now migrate my own library objects with the new settings or mark them as obsolete.

Barry.

[Lingwisyer]

You can sort of force a uniform change in a parameter by deleting the relevant parameter, reloading the object, then adding the parameter back with it's new value.

 but unchanged ones that have drains in the corner.

What do you mean by this?

Ling.