@everyone else:
Since there seem to be misconceptions floating around how things work which complicate the troubleshooting process, I'll explain this in a bit of detail.
When placing the Shuttle in launch position at an arbitrary location, we have to deal with two things
a) FG assumes a craft on the ground has gear out and rests on its gear
b) by the time FG wants to place the craft on the ground, no Nasal is active and hence we can not place any pad on the ground
Any craft in FG with similar needs has to hack around these things (Vostok-1 for instance introduces a weird coordinate system in which 'forward' really is 'down' - which places the Euler singularity into an awkward position in orbit - the F-14b for a carrier start really probes the terrain with a loop whether the carrier is already there and then repositions onto the flightdeck).
For the Shuttle, we address a) by deploying gear in the FDM while on the pad and automatically retracting it after liftoff - this is not visible because the logic for the gear animation is done differently). If we would *not* do this, we'd have weird ground interactions.
Point b) we address by placing the Shuttle 10.000 ft high in the air. On a normal init some time passes and it falls, but eventually Nasal becomes available and issues a command to place a pad. Some more time passes, and the init script then issues a placement command to let the Shuttle appear with all velocity nulled right above the pad, it falls into a tripod (we want it to stand, on two points it's precarious, so we cheat) of contact points which have a high damping, so oscillations cease quickly and we stand on the pad.
If we would *not* init in the air, the Shuttle would start staying on the ground, the pad would be placed on the ground around us, so we'd be *inside* the pad, which not only looks odd but gives a devastating kick once the contact points move *above* the pad surface and the ground interaction code triggers.
Normally, that's about when the splash screen fades, there may be some small residual oscillations from the drop onto the pad or not., but we're in vertical position with a launch pad underneath.
What can potentially go wrong with this is
a) there may be another object on the ground/nearby which gives a ground interaction when the Shuttle is placed on the pad - this can topple the stack.
b) there may be so much in the scenery loading queue that the command to place the pad into the scenery has been issued, but not yet executed by the time we reposition, so pad placement and Shuttle reposition overlap - this can either place us in the pad, or also topple the steck - theoretically this should be fixable by starting paused (to give the queue time to finish and the pad time to appear) and then unpause (or by changing the delay variable). This however is conjectured, as I've never seen this happen on any of my three setups that can run the Shuttle.
c) the procedure is complicated, so there may be some other timing issue not yet found - for which someone who experiences the issue would need to run tests
But one upshot is - if you start paused and find the Shuttle floating in mid-air when the splash fades, this is completely normal - that is how this needs to be. On the other hand, putting in an altitude into the commandline
probably overrides the altitude setting made by the *-set.xml file and can potentially de-rail the whole procedure. So can trying to put the pad onto sloped ground I suspect (?) - though I've never tried.
@slaintemaith
Nevermind. I'm 99.9999999999999% certain that even assuming this does get set up that it will break early and often upon use.
After sleeping it over, I agree with you - given your way of dealing with information given to you, it is unlikely you'd enjoy the simulation very much - it really requires you to read lots of manuals thoroughly, and if that doesn't happen, it will continue to break for not being operated correctly - and all that breakage is actually simulated.