#379 ExternalObjec: Loop detection and private mode
Currently it is possible to build refernce loops with ExternalObjects. When such a loop occurs the files end up opening each others in an endless cycle and the opening sequence never finishes. I have two ideas that should help the situation:
1) Automatic loop detection. There are two working modes to this:
a) Loop detection at creation time. If an ExternalObject that is being created refers to a file with ExternalObjects this should recursively check that the curren file will not bew referenced by itself. If a loop is, the user is warned to take an apptopriate action to prevent the loop from occuring.
b) Loop detection at file open. When a file is being opened and a loop is detected, the External object causing the loop is disabled. Preferably there should be a way for the user to study the refernce hierachy so the user could break the loop at an appropriate point.
2) Private mode to ExternalObeject. This is for situations, when a parent object is needed for refernce to crate/modify a child ExternalObject. The in private mode an ExternalObject would not be "visible" or "active" to a parent file, that is referencing the file it is in. This would also act as an effective way of preventing reference loops from ovccuring. Private mode could be set defalult at creatin time and if visibility throug several refernces is required, the user could set the mode "public", "through", "recursive" or what ever the best term for that migh be.
During work on an animation with lots of details on a computer of a smaller dimension than professional workstations (like the older laptop of mine) it's a welcomed feature in AoI to link all by external objects. But the problem of parent-child is also in that situation - as by the way already described in the earlier handbook - that the child won't follow the movements of the parent skeleton- or posetrack, if there is no bone on both parts which can close this gap by following (or look at) each other. To install this exactly you then simply do need references. In the workflow you normally will not think about reference loops up to that moment you stumbled into the trap installing one unconsciously in two files opened at the same time. The trap closes in closing the files: Instead of reopening they then will run in circles. To solve this problem is quite simple, as Pete showed to me, (i.e. by temporarily changing the directory for one file and deleting its external objekt link to break the circle). But (like me) not every user will think of this, or is able to analyse what has gone wrong. So I appreciate this feature request of Pete very much! Especially his point 1a for instants with a little message like 'There already exists another external link with the file you want to link to. A Reference loop is not permitted.' would have prevented me from doing wrong.
I could imagine a reference loop coming up over more than two files, too: That should be one thing more to think about, shouldn't it?
Last edit: Konrad W. 2017-06-24
To clarify:You can link several objects from one file as long as there is no link back.
That's right. Reference loops can happen over several links.
For one thing, an ExternalObject is like any object and it can be linked forwars either as a child of another object or as itself, but to create a chain of links ExternalObjects do not have to be linked forward. As long as they are there, they force opening the next file.
The devious part is, that you can link from file A to file B, B to file C and C back to A and things work fine as long as the files are open. Problems only emerge, when youtry to reopen a saved file. The good thing is that a loop needs to be broken only in one point and things work again.
Last edit: Pete 2017-06-24
That's what I thought, thanks for clearing it here again. In the meantime I had to think a bit about all this. Therefore I'd like to change my upper messaging proposal.
For all of Your described cases the displayed dialog could eventually look similar to this:
'Detecting looped external object links. Those Reference loops cause problems with all included files at reopening. Choose 'OK' to avoid.'
Underneath that two buttons: One for the 'OK' and the other for 'Exit'.
'Exit' means in Your case 1a undoing the choice, in Your case 1b stopping fileopening and eventually leaving back an empty instance of AoI UI (for faster access) if there isn't another one already.
'OK' should be able to set the whole detected circle temporarily in the Private Mode You're describing. Just before saving the opened file, there should then come up an opportunity for the user to decide to keep and save the Private Mode (for all files of that circle?), too, or where to break that circle best, as You wrote.
From my 'users view' this would be the most comfortable way to get the benefits of this feature with UI.
But this leads me to my next question, too: If loop recognition and 'Private Mode' together are solving the problem of looping references for all future, is there any reason why not building this in as a fully automated 'filecare under the hood' (i.e. without any UI)?