[Zipper730]

Because CIG is making very stupid decisions based around Chris Roberts' ego rather than any technical necessity.

Can you explain in more detail?

[The E]

Let's take one of croberts early mandates as an example. In the early presentations, Roberts was very clear that there would be no cheating the physics in SC. If a ship wants to move, it needs actual thrusters doing actual work to do so. While this sounds interesting, it's a giant headache in reality, both in terms of implementation and game balance.
In implementation terms, doing a physically accurate simulation of forces acting on a rigid body is possible, but complicated to set up and maintain, which is why actual games use more simplified models that are accurate enough for game use.
Another early mandate was that there be no instancing ever, every player was supposed to be present in a single global game instance. This, again, sounds neat in theory but is incredibly complex to set up; that the cryengine netcode this was all based on was built around simple multi-player matches doesn't help matters.

Basically, CIG have a history of announcing features that sound cool but (to people who know what is and isn't feasible in a real time game) are easily recognizable as pipe dreams.
Compare and contrast this with Frontier and Elite Dangerous: that game has delivered a large chunk of what CIG wants to do, on a much smaller budget and in less time, and is successful enough to continue to operate.

[Nightmare]

Any thoughts on this?

At appears that the skybox issue could be fixed though. When I set a mission in subspace (which- to my limited understanding - acts basically like a skybox as well) I'm not having any problems even when I put my ship 500km off the mission center.

[Zipper730]

Unreal has the ship/camera as the center of the universe with things only rendered in area of highest percentage? 
What about Unity?

[The E]

Unreal has the ship/camera as the center of the universe with things only rendered in area of highest percentage? 
What about Unity?

That's the sort of question you should find the answer to by yourself by reading the relevant documentation.

[Zipper730]

That's the sort of question you should find the answer to by yourself by reading the relevant documentation.

I've already started sorting all that stuff out...

[Zipper730]

Seems that it be yes

[chief1983]

Seeing how much breaks from switching to stationary player/moving universe could actually be a fun way to start.  It's always possible that everything is abstracted well enough that it just works with making the updates to the core calculations.  Only things that _change_ an object's position relative to whatever 0,0 is should need to be updated.  Once positions are determined each frame, nothing else should be any different, I can't think of any assumptions after that point that would matter.

So you start at 0,0 (2D for simplicity's sake) and everyone else starts at some x,y.  Let's say you accelerate along the y-axis and another ship was moving along the x-axis.  You would have moved 5 in the course of a frame along that axis, and the other ship moved 10 (arbitrary units).  Right now you have a calc that says ok, your new position is 0,0+5.  The ship at x,y at the start of the frame is now at x+10, y.  Now, you would instead keep your location as the 0,0 reference.  So the other ship (to maintain the same relative position to you as before) would not only move the distance along the x vector it was before, it would move along the y vector in the opposite direction, or x+10, y-5.  If jumping a large distance in mission that should be accomplishable the same way, whatever vector would have been applied to the player to jump far away, apply that to all the other objects instead, accomplishing the same goal.

TL;DR:  Formula should just be to add the opposite player movement vector to all objects in mission and leave the player at 0,0.

Ok, I do see one gotcha.  Any code that references absolute coordinates after the mission has started would somehow need to be updated every frame or something, or a vector containing how the player has moved since the mission began would have to be maintained so that any time absolute coordinates are used, that vector would applied, or probably many other solutions that I'm not aware of for a problem like that.  But they could probably all be updated every frame just like all object positions are updated, although updating many things that weren't changing before might have a performance impact.

[Nightmare]

As just for Skyboxes

At appears that the skybox issue could be fixed though. When I set a mission in subspace (which- to my limited understanding - acts basically like a skybox as well) I'm not having any problems even when I put my ship 500km off the mission center.