Search the Community

Clearly orbital mechanics is a challenge. Making planets orbit the sun and rotate adds several vectors to the players, ships and everything that must be tracked and adjusted for. I can see two possible solutions, one easy one hard: Daily Update: Once a day at a predictable time everything is moved together, with a planetary bounding box being used; the box would be 1 or 2 planetary diameters and it would be moved 1 or 2 degrees around the sun. Note if the sun is orbiting the planets, the easy option, this is really a change of angles of all of the worlds to each other while either maintaining their distance from the sun or adjusting it slightly to emulate elliptical orbits. Any ship in the way is moved 1.5 planetary diameters to the side, sun ward. If it is still in the way it is moved another half planetary diameter in the direction of the orbit. If it is within 20 km of another orbiting object it is moved 20 km away from the planet. If it is not clear of objects now then you need a space traffic cop! From the players point of view the sun seems to teleport but only once per day. If timed to correspond with night on the major planetary safe zone/ city, where most would be, it would go unnoticed. It would be a normal thing so would break immersion much less than a minecraft modded multiplayer day night shift which is quite common and often unnoticed. This would only be a 2 degree orbit shift from the point of view of the player seeing it. Frames of reference: Another method would be to give every player and ship a frame of reference state with 5 to 8 frames of reference. You need this for boarding actions in ship to ship combat and docking anyway. At some point the person needs to be 'In the ship' as opposed to being in space or in another ship. Why not planets, atmospheres. The frame of reference call is a velocity, vector and orientation call. (The last thing will already be defined by a ship or stations gravity unit so may be ignored. If you want fancy space stations and ships where you can EVA on a belly of without falling off, the orientation call can be useful) The reference frames would be: star, planet orbital, planet equator or Planet by latitude, Ship, Inverted, station, space station centrifuge. All in the same frame of reference are given the same velocity and the same vector relative to the local down. The star would not have a velocity or vector. A non moving space station is in the stars reference. a station is in the planets orbital frame. Planet orbit is the velocity and tangential vector of the planet in orbit. It would effect all things in the planets gravity and stations within a few planetary diameters. In the case of planet equator or Planet by latitude it would be the velocity of planets local surface & atmosphere [even on vacuum worlds. ] The atmospheric stickiness. It would have a primary component in the direction of spin and tiny downward component and a hand off component from planetary orbit. Planet high latitude would grade off as you approach the pole but would be the same value for all in a given latitude. Ships taking off in the direction of spin end up transitioning to the stars frame of reference faster. However this transition will only occur is at an altitude of 1.1 planetary diameters of the core. Like wise a ship entering transitions fast if going in the opposite direction to spin. To avoid ship planet collision we could add a bounce angle, a real thing in space. If you approach a planet at the wrong angle you bounce off the atmosphere at a shallow angle. In the case of Ship the reference frame is defined by the gravity unit and directional unit. Any one in the ship is given the ships vector. This is already planned so you can run around in the ship. In the case of inverted, which can be set on a station, this frame of reference is set by a inversion hatch or door element. Gravity is flipped but the vector is unchanged. If you jump from space to a ship/stations belly and these gravity inversion elements are closer to you than the gravity generator then you transition to inverted. Pass though the inversion hatch or door element it flips inverted to ship or station frame. A rotating tunnel or monkey bar may help the transition (purely cosmetic). In the case of space station centrifuge this is a frame of reference generated by a special centrifugal gravity unit. (This is a long term thing not something I would expect in the game in alpha or beta or the first year.) This draws less power than a normal gravity unit and defines an axis. Down is relative to that axis and away from it. Gravity is proportional to radius in metres/ 1000. If the station has a static 1 RPM roll around the axis then the vector of the frame of reference is 16 m/s with a tiny down component. The floor stops you from flying off like a stone from a sling (until someone blows a hole under you). I've included this for completeness and future proofing. In short the frame of reference is a state with a velocity and vector that is pre-calculated for all in the same reference frame relative to that reference frames gravity direction and type. This is summed with the payers/ constructs active velocity and vector. All players, etc with the same frame of reference on a given server can skip the frame of reference calculations and treat it as zero relative to the ship/ planet. Collision with a moving planet causes you to bounce off the atmosphere. Only crewed ships can avoid this bounce. (if AFK you bounce. ) All movable objects may need the frame of reference component. Rocks and trees may need it (this may be a problem ). If it works for planetary rotation it should also work for planetary orbital mechanics. OK now is time for a dev to shoot me down with the reason why this wont work. Both look obvious so I may be missing something.