Planets and vessels are treated quite differently by orbiter's discrete time propagator, so treating a planet as a "big vessel" isn't really supported by the engine.
- Gravity sources (celestial bodies) are assumed to be analytic, i.e. their states can be computed for arbitrary times.
- At each time step, all gravity sources are updated before any vessels are updated.
- During its propagation step, a vessel has access to the states of any gravity sources at the beginning and end of the current time steps, and any intermediate times if required by the integrator.
- No vessel has access to any other vessel's state except for its state at the beginning of the time step. This ensures that vessel states can be updated independent of each other (e.g. in parallel), and the order of vessel updates does not matter.
- An exemption are docked assemblies. They define a "supervessel" representing the composite structure that is responsible for updating the entire structure. It can collect force contributions from individual subvessels, use them to update the superstructure state, and update the states of the individual elements.
- If vessels were allowed to have a gravity field, i.e. the fields are non-deterministic, then they would all have to be updated simultaneously, i.e. all would have to use the same integration order. This would be quite inefficient.
But there is a provision in the Orbiter API guide, which allows for creating planet modules which update position based on external gravitational forces right?
Planets which are not controlled via a DLL module are updated directly by Orbiter. Depending on the settings in the definition file, Orbiter either uses an unperturbed 2-body approximation, resulting in a conic section trajectory (e.g. an ellipse), or uses a dynamic update procedure based on the gravitational forces acting on the planet. Both methods have limitations: the 2-body approach ignores perturbations and is only valid if no massive bodies other than the orbit reference object are nearby. The dynamic update accumulates numerical errors over time, causing the orbits slowly to diverge from the correct trajectories.
If I understand that correctly, these types of objects, created under CELBODY & CELBODY2, must update after or during the planet update phase, and before any VESSEL/VESSEL2/VESSEL3 objects do. But, what would be nice is if there could be an intermediate class, say CELBODYLITE, which can be programmed more or less identical to a vessel module, but update after CELBODY, before VESSEL, and, last thing (hopefully), take a collision mesh from a basic wireframe mesh, to create landable surfaces. This wouldnt completely necessitate implementing full collision detection for VESSEL-VESSEL & VESSEL-TERRAIN, as Artlav has created a landable vessel before, right here,
http://orbides.1gb.ru/shukra.php
If that option was available, it would be a much better solution to properly mdel asteroids & comets in Orbiter. At present, the CELBODY interface works fairly well right down to the dwarf planets, but trying to land on the long edge of a Potateroid (a pretty common type of asteroid, elongated like a you know what) leaves you stuck hanging 500 m above the asteroids surface. The other area that this would be really nice for would be comets. If there was an option to place an exhaust stream on a comet-vessel, dependent on its solar distance, we could finally have a reasonably accurate comet simulation too.