- Walk inside the cockpit deck (what VR people can already do somehow)
That is not really true. What VR players (myself included here, the Index is great ... which makes the lack of VR in Odyssey even worse) can do is move around the
camera. The body itself remains seated in the pilot's seat. What I highly suspect is that FD didn't solve the issue of multiple coordinate systems.
What does this mean?
Well, Imagine you have a coordinate system (CS from now on) and you want to move an entity in there. You do this in traditional engines like UE or Unity with vectores. Your vector determines orientation, speed/velocity and position in the CS. As your CS is static and does not change, this is a fairly easy task any pupil that just graduated from school should be able to do on paper.
Now, what happens if we throw in a CS in a CS?
Then things get messy. First, a CS can be an entity. Say you have a void of space ... any star system instance and you have nothing but a main star whic hresembles our origin in say CS1. Now you have a ship. Before Odyssey, that was about it. A CS and an entity happily moving around. With ship interiors, said entity now is a CS(2) which on top is not even static, as it is (potentionally) moving in CS1. If you now want to walk around a ship interior you will have another entity, the player, moving in CS2 while that CS2 is moving in CS1. So in order to get correct dispalcement vectors you will need to first get the relative vectors in CS2 and map that to CS1, which is basically nothing more than adding these two together.
However, the messy part is that thing with synchronisation and precision. Have you ever tried to see a ship in supercruise? Well I can tell you it's possible. Ships get rendered in SC if you are within render range of ariound 6-8km. And what happens when you get this close while moving at 30km/s in an open instance? Well you rubberband, a frickin' lot. So much that in one frame you are like 2km away and the next it is 20km.
While it doesn't matter per se for SC travel as collision is not only extremely unlikely but simply gets ignored, having now the ability to walk around a ship that is rubberbanding
at the slowest permitted velocity will cause chaos if it is not synchronised with the respective CS it is moving in. The result would be an unimagineable amount of clipping and more often than not you would find yourself clipped out of your ship, suffocating in deep space.
And now imagine what happens if you transit an entitiy from CS2 into CS1 while it is moving? From a physical point of you, the idea of inertia would simply say that you would keep the relative vector and while transiting to CS1 you would not change your orientation and velocity but mathmatically your vector is now completely different as you are no longer in CS2 but CS1 which does not respect the relative vector of CS2 for your own entitiy's vector. This might be problematic when calculating positional information and could cause further clipping.
Ofcourse, this is only an assumption as I 1. am not part of the dev team responsible for EDO and 2. don't have access to the cobra engine that is running Elite as a whole (which is doing the CS and vector work).
I have had the pleasure of working with a two dimensional problem of the described one above myself and I can tell you it's an absolute pain if you do not know what you are doing.
The math module my friend has been writing for our problem was fortunately well throught through but transforming CSs the whole time will cause chaos. Especially when they are out of synch. Why are they out of synch? Because we have multiple cores and can't wait for each action to complete so we can transform
all existing CS into one another at the end as that would be a huge bottleneck ... at least that was our issue in said two dimensional problem that has this analogy to it.
Now with that in mind, what am I trying to say here?
First, the placeholder-y system is most likely not as simple as it appears as lots of technical and mathmatical works would have been needed to be done where you could do lots of things wrong (just imagine two entities being in the very same location fighting for their rightful position in a CS [violent sounds of vibrations through clipping appear in your head after shortly catapulting one entity far into the sky]) and secondly that FDev simply doesn't have the know-how in their team or didn't want to invest the necessary resources to further develop the cobra engine to allow for such systems to work properly.
And hence the critique.