hey face I am confused. when you say "see the other persons nosecones open" do you mean animation ? that would be no because you disabled them correct? verbal communication in Teamspeak3 is how we know that the other persons nosecone is open. it is the first thing you ask when docking does not "stick"
Ok, we are getting closer...
When I say "see the other persons nosecone open", I actually mean "see the other vessel's nosecone open". If you do not see this in your own simulation, the not sticking effect is almost certainly appearing.
I did NOT disable animations. They are just not supported by the propagation system by default. This is why an animation event on one user's computer is not propagated to the other person's computer, thus not causing a local cone-opening to happen on the remote machine, too.
You see, it is very simple: what you see on your machine is what your simulation is doing. If you do not see your docking partner's cone open in your simulation, of course docking will not work properly with vessels that take this into account. No matter what he tells you what he is seeing on his end. This is also true for the docking partner.
The confusing part is when only one partner is realizing this and thinks it is enough to open the opposite cone himself. Because in this case what I described already is happening.
OMP is not changing vessels and their behaviour, it tries to synchronize the states of the local vessel with the remote counter-part in order to create a distributed simulation network. Unfortunately, the already implemented recorder event propagation (that would cover a large part of the animation support) is not working properly due to some Orbiter core limitations. I've deactivated this animation SUPPORT, not the animations themselves.
My suggestion for such sessions would be like so: if you want to dock, you're first question should not be "is your cone open?", but "do you see our cones open?" . If the answer is no, give advice to direct the docking partner to open both cones in his simulation. Of course you should do the same thing.
This suggestion holds not only for docking. If you have other means of coorporation - like e.g. attachments - both parts have to do them on all vessels to see the expected result everywhere.
So basically, if other users report a status that is not the same as the status you see on your machine for that user's vessel, do not expect things to work perfectly.
Example: crash the XR2, so that wings/gears are destroyed. Due to the flight operation, this will happen on both machines, the owner and the viewer. Now repair your XR2 on your side. This operation is changing the status of your vessel on your machine, but not the vessel on the viewer's machine. Now fly around with this repaired vessel again. The viewer will see this vessel flying around, too, but behaving strangely with a kind of hick-ups. This is due to the changed aerodynamic profile implemented in the vessel for the status "damaged". This status "damaged" is still active on the viewer machine, but not on the owner machine. There you are back to status "normal".
All those bugs fall into the same category: incomplete state transfer.
regards,
Face