Updating Objects Made with Library Part Maker

[aarkell]

Does anyone know a good way to allow objects made with LPM in AC25 to auto update once changes are made to the object. We have an office library with custom objects on our BIMcloud, and I made some slight changes to a few and thought when the library is updated in library manager, that the newer version would replace the ones currently placed in the file given they have the same name. Unfortunately I got an error that some objects were missing. Is this a quirk with objects made with LPM, in which something in the code is different so it is not understanding how to replace even though the name is identical?

[Lingwisyer]

Objects are designate by their GUID rather than name. My assumption would be that in saving a new object with LMP that it would be assigned a new GUID. I have not used LMP since AC19. If you know the GUID of the old object, you could try using the Migration Script to substitute it with your new object. This is usually for between AC versions, but it might work here.

Ling.

[DGSketcher]

The GUID mentioned by @Lingwisyer is probably the source of the problem, but if you aren’t familiar with GDL it could be a challenge fixing it.

I would think the original drawing containing the LPM source object assigns a GUID, and as long as you only update that LPM source the GUID wont change when it is saved. I would hope that also applies when the original drawing is opened in an updated AC version. If you create a copy object even with the same name then I would expect the GUID will change.

@aarkell You may have raised a serious issue on maintaining LPM objects that would benefit from an official response from @GRAPHISOFT . Please share any solution or further problems on this issue here as LPM is still quite new. 

[aarkell]

@DGSketcher and @Lingwisyer thanks for your responses! As a test I made a change to one of the objects using the original drawing containing the LPM sources, saved with the same name, and placed in a separate folder. I then loaded that folder into a new project that also contains the original LPM objects and I did get an error for duplicate objects. So that makes me think you could update an office library with revised LPM objects assuming you use the same name. I think in my previous question I had some older objects in my embedded library that were messing with the macros when I was saving out the LPM object. What this means is that updated objects will have to have the same name, so if you name your objects with a version at the end, which helps to ensure your users are using the correct version, they won't automatically replace. You would have to go in and manually update those objects. Wonder if @GRAPHISOFT  has a solution for "migrating" custom objects? For example, if I create "Custom Toilet Object_AC25" and then make some updates and resave it as "Custom Toilet Object_AC26", is there a way we could automatically update those similar to how Graphisoft's out of the box objects migrate to a higher version number?

[Lingwisyer]

The solution to migrating is the Migration Script which I mentioned before. It basically says that if Object X is found in the project replace it with Object Y given that parameter Ax = parameter Ay, parameter Bx = parameter By etc.

The name fallback was something from AC16(?) when they changed how objects were referenced and by the sounds of it, it still works?

"original drawing containing the LPM sources"

So when you used the same file that originally created the objects, it worked? This would imply that the addon keeps track of the objects made within the file. Was this also in TW?

"so if you name your objects with a version at the end, which helps to ensure your users are using the correct version, they won't automatically replace."

Would that be when you save out the object or when you rename the object afterwards? With standard GDL objects, a save-as will create a new GUID meaning that they will not replace previous versions since they are identified as different objects.

Ling.

[aarkell]

Ling, did a few more experiments and found the following:

1. When using LPM, if you save over the same object in the embedded library in the same source file, you can then export it to a folder on your computer. Here you can rename it, such as adding the version after the name, and when that folder is loaded as a library to a project it will automatically replace the old object. Interestingly, the objects seemingly know to update to the newer version without any manual updating or resetting the file path of the object--they immediately replaced themselves with the renamed counterpart once the new library was loaded. I also got duplicate object errors before deleting the older library, which tells me the GUID must be the same.

2. If you try to save out the object with any changes to the name, and export same as #1 above, it won't replace the object and you won't get any duplication errors. This must mean that the GUID is different if the object is saved out with a different name, and LPM is registering that as a completely new object. Overwriting with a rename after seems to be the best solution.

3. It seems you'll want to keep your LPM source file as clean as possible, with no extraneous objects in the embedded library. I originally had my older objects created without LPM in my source file as reference while I was building out the new versions with LPM, but when saving I think that was causing issues with the macros per my previous posts. So it would make sense to archive a file before changes are made, in case old objects need to be referenced.

4. What I don't know is what will happen when I migrate this LPM source file to the next version of AC, and need to save out new versions to the these same objects. Guess I'll have to provide an update once AC27 comes out.