I’m often using “unlink” option for referenced components to clean up my list of referenced objects in a scene. However it seems that once I unlink the components, new components show up (i guess those are nested inside unlinked components). Could you modify the command so that those get unlinked also?
I’m trying to keep my Reference Manager clean with only a couple of linked components that often need reloading…
I can see there is a use cases for this, but there are also cases where you’d want to keep the references in the children. For instance, if you unlink an apartment before modifying it to a unique gable apartment, you probably still want the chairs and stoves and kitchen modules to link to their files, so they can be reloaded as needed.
What components do you typically want to remove nested references from?
Btw, I don’t do much plugin development these days as it is too close to my daytime job, so I may not have the time to do any changes, but it’s still interesting to think about.
I usually break down each building project into the following components:
existing building
new building parts
plumbing
electricity
furnishing
We share those between the team as ‘xrefs’ so each one can load and work on the parts that they are responsible for.
If there’s a case where nested component needs to stay linked I can relink it manualy at any time later, so that’s not a problem in our case since that’s quite rare.
I installed the trial version but for some reason it made my SU application unbearably laggy. I am talking about 10-15 seconds between clicks! I couldn’t even get the extension manager working properly to remove it so had to force-quit SU. I did have a large-ish model open with lots of references.
Eventually I opened a blank SU file and was able to remove the extension. Is this common?
I haven’t seen that amount of lag myself, but there can be some lag in checking the references, especially when they are located on unavailable drives. The system freezes when trying to connect to such drive, before it can say if the file is there or not.
You can go to the extension settings (Extensions > Eneroth reference Manager > Settings) and set the time interval to 0 to disable these file update checks. Doing this in an empty template rather than inside of a huge model should be free of lag.
Hi, I’m using a lot this reference and it is being great!! I have a doubt: I don’t know how to deactivate the section of one component linked in the whole model when I section the whole model.
Would it be possible to have an option where reloading a component would impose it’s sub components in the model too.
Imagine a House, WindowA, WindowB, and a Handle.
WindowA and WindowB are Xrefs.
Handle is not a Xref but exists in both Window Component.
I’m working on House model and someone working on WindowA, changes the Handle. Every instance of WindowA get updated as they should. However I’d want the Handle to be updated into all instances of WindowB too, this won’t happen in Sketchup.
Could this be done?
Maybe we would be able to choose some components which would spread changes of their sub components throughout the model, when reloaded.
I don’t think it can be done automatically. I guess you could simply use ‘replace component’ plugin to replace all the handels in window B with new definiton.
Btw. I’m working with Fredo on a new XRef plugin that is dedicatd to multi-user workflow. Should be ready for release quite soon I think (couple of weeks).
Hi jure, I know in Sketchup that cannot happen natively. I do use component replacer in my projects. I was thinking it would be cool to have Eneroth considering this as a feature request. I wouldn’t want all components to have this action by default, but some of them or sometimes it would be great to have.
ChatGPT conversation with Stable Diffusion:
“Hé, do you remember that arqitect from Portugal?”
“The one with the craziest ideas? What I’ve heard, even Perplexity AI could not satisfy his needs or proposals!”
Yes, I can certainly see how this could be useful. However it’s not a trivial thing to implement because it may lead to problems in other scenarios.
Say you wanted to replace all the ‘handleX’ (sub)components in WindowA when updating WindowB. Let’s also say that WindowB is updated in a separate file where old ‘handleX’ is changed to ‘handleY’.
So when you reload WindowB with new version there is no way for plugin to know that you actually want to replace ‘handleX’ with ‘handleY’, unless there is some extra information stored that defines relationship between WindowA and WindowB ‘handle’ component.
Also sometimes you may even want to have some windows with X and some with Y handle and so there would also need to be a way to handle those cases…
Syncing all aspects of a complex project, isn’t simple, so a Xref manager, isn’t simple to develop… I know.
In your case, one could change the name of a component, when editing a xref, if one wants it to be different. So, if I want to create a modification in Window A, without affecting Window B component, I can create a new component for the handle that doesn’t exist in the project yet. Otherwise the changes made to the handle should impose, as they are the most recent version of the handle component.
However, in my feature request, I was talking about options. We could have an option to state if this particular Xref would or wouldn’t enforce changes into other existing components. So, in the references list, I would choose some that would have this behaviour and some that wouldn’t, effectively being able to manage things in another way.
Maybe we could have an option for a conflict list too. That option would let us know which subcomponents had been modified that also existed in the model, and let us tell how to sync them. This is an option on file sync apps to solve conflicts.
Again, options for solving conflicts are only options because there isn’t a best way to deal with this kind of conflicts. Allowing us to have options would help a lot.
Yes, (I think) I understand what you are saying.
But think again about what I wrote above: unless there is some extra information stored that defines relationship between WindowA ‘handle’ and WindowB ‘handle’, a plugin cannot know that you may want to replace one with another. Plugin doesn’t even know that WindowA and WindowB are variations of a ‘Window’… For a plugin it’s just another component in the list that might be window, TV, a chair or whatever. So if you wanted the behavior you describe then we’d first need a way to identify that the two components share some relationship (i.e. same handle)… Otherwise you could get ‘options’ in cases you don’t really want them. I guess you can se how deep this rabbit hole can get then…
I wouldn’t want such a complex thing. Just that any changed sub component that came with the xref and existeed in the model already, would also be updated in the model.