- This topic has 7 replies, 3 voices, and was last updated 6 years, 9 months ago by
.
-
Posts
-
-
Hi all,
I have a bit of a sticky situation here in one of our projects and I am wondering if there is an easy solution for this.
We have a few PLNs (“Building PLN”) hot-linking to the same file (“Component PLN”). The client requested ONE of the Building PLNs show doors with 45 degrees opening, while the same doors from the GA plans of another Building PLN has to stay 90 degrees.
The doors in question are standard Graphisoft “Door 19.gsm”.
I know the proper solution is to
1. create a new door together with an MVO object setting the door openings,
2. then get rid of the ArchiCAD Standard Library;
3. forward migrate every single door to the new object.
but I hope you would agree that its a very elaborate solution for a simple problem.What I want to do instead is to
1. write a new door object with the same GUID as “Door 19.gsm”. Put “gs_open_2D=45: call ‘Door 19’ parameters all” in Master Script.
2. load this object into the special Building PLN in question;
3. trick ArchiCAD into believing that this is a more updated version of Door 19.gsmNo3 is what I failed to do. ArchiCAD knows that they are duplicate objects, but refuses to replace it with the custom one.
Is there any ways to force ArchiCAD to prioritise a particular version of a GSM over the other “multiple versions”?
Many thanks,
Denny
Bond Bryan Architects, Westerham, UK
-
-
-
I am a bit confused.
The angle of the door swing is not set in the MVO currently as far as I know (I don’t actually use the GS library but I just had a quick look).Why don’t you just manually set the angle of the doors in that one plan to 45°.
What ever angle you set them to is what they should be even when used in a hot-link.Barry.
Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit -
Hi Denny,
It’s not a single problem, it is adding a new function to the standard library. This should be done with the proper workflow as you mentioned first, there is no other solution, teher is no migration between duplicates…
Thanks Gergely. It is a bit disappointing if ArchiCAD just select one of the duplicate at random but it is what it is.
I am a bit confused.
The angle of the door swing is not set in the MVO currently as far as I know (I don’t actually use the GS library but I just had a quick look).Why don’t you just manually set the angle of the doors in that one plan to 45°.
What ever angle you set them to is what they should be even when used in a hot-link.Barry.
Hi Barry, our problem is we produce GA plans from one file where the doors need to be 90° while the same door when hotlinked to another PLN needs to be 45° on a Sales Brochure plan. Whatever angle I set it in the Component PLN will affect both plans.
The GS doors swings do not use MVO as you say; this is something I need to add to the 2D script which will solve the above problem. It is not difficult at all, but in order for that to take effect I have to remove the default GS door from the loaded library of Sales Brochure PLN; otherwise AC will load the same old GS door every time. I am hoping to avoid extracting the entirety of the ArchiCAD Library LCF just to remove one gsm from one single file of a project… hence the question.
Bond Bryan Architects, Westerham, UK
-
OK I see now.
I would say you have a couple of options.Modify the existing object so it has the MVO option (and of course add the option to the MVO).
Of course the problem with this is if GS ever update the library, you will not be able to update this door or the MVO scripts without losing all the work you have done.So you really have no choice except to create a new door object.
I would ‘save as’ the door so it has a new GUID.
Add the MVO settings and create a new MVO interface page that controls this setting.
Now you have two objects that won’t ever get updated – you just have to load them together with any new library.
Except now you have the problem of replacing all the doors in you file.
If not too many I would do it manually – transferring the parameters as you swap the object.
If there is a lot to change then I would add a migration script to the new door.
You will have to extract the LCF library so you can temporarily delete the original door.
The door object should now swap for your new one.
Re-load the original LCF library together with your new door and MVO and you should be fine.
Just to be on the safe side I would remove the migration script in the new door object.Barry.
Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit -
Thanks Barry,
I guess extracting the LCF is not avoidable in any case, which is a bit of a burden when it comes to forward compatibility. Our office is going to move to AC21 in the coming month – there’s no worse timing to create a duplicate library.
In terms of replacing the door there 300+ of them but that’s not a problem at all. I can simply
1. load the new door with a FWM referencing the old door
2. unload the GS default library – Door 19.gsm is gone and therefore all doors get GUIDs migrated
3. load the new library with the new door
…then you are all set. By doing step 1 first (i.e. not just swap the library) it allows Door 19.gsm to live in the new library – potentially to be called as a Macro from the new Door. This will simplify the process when going to AC21 as Door 21.gsm will get called instead (through cached GUID within the new Door).Still debating about extracting LCFs though….
Bond Bryan Architects, Westerham, UK
-
-
- The forum ‘Library migration’ is closed to new topics and replies.