Hello, Delta Lima, and thank you for your kind words of encouragement and support!
First, in general, I'm glad to say that EVERYTHING that you mentioned will indeed be possible, or already is. SpacePort, both FSX and P3D versions (which, btw, share the same code base) is not in absolutely any way, shape or form relying on any of P3D's internal aerodynamic or physical properties. P3D is, in a sense, used as a visual display engine - that is it. We have completely overridden P3D's flight, atmospheric and gravitational model and "imposed" our own, astrodynamic/ballistic model. We've accomplished this by integrating a sophisticated third-party physics engine into SpacePort, which, along with precisely simulating ballistic and astrodynamic properties of bodies in motion, also features an incredibly precise collision model which greatly surpasses what is available in P3D. The objects correctly collide and interact with other objects, things fall to the ground and realistically bounce, spin and come to rest with natural feel to it. The best part is, all this was accomplished completely, 100% using pure SimConnect - there are no exotic hacks or anything out of the norm that we needed to implement to accomplish this. We haven't even used any of P3D's expanded SimConnect functionality - the code base for FSX and P3D is nearly identical.
As to your specific questions:
...curious how you'll address the gravitational/orbital limitations of P3D - As I mentioned, we've replaced P3D's physics engine with our own, and indeed, we've implemented Newton's universal gravitational equation which indeed takes distance into account. As for the non-uniform gravity across Earth's surface, we have NOT taken this into account yet, as we feel this can take a bit of a back seat to more important features we are implementing. These mass concentrations (dreaded MASCONS) would be more relevant in lunar operations, but as I mentioned, we will keep this in mind for future development. We already have an idea of how to implement this, and it wouldn't be that difficult at all.
...RCS and translational thrusters are strictly key operated - is that correct? - That is correct, and absolutely, we will implement joystick/peripheral support. We just need to get to it.
...will there be historical mods either included - or through SDK, made possible - Absolutely - and we are counting on 3rd party developers (although, there might be a bit of a learning curve to it ;) ). We have made SpacePort highly modular and flexible. We chose our "test case" SLS because it is relevant and current (and a rather complex assembly of parts), and so that we can develop a complex launcher and iron out all the potential pitfalls. Historical models - Mercury, Gemini, Vostok - are quite a bit simpler, and definitely a prime candidate for a sophisticated, high quality, historically accurate add-on. All the "innards" are in right now - quite frankly, the largest chunk of work would be high quality 3D models, interior and exterior, and obviously, instrumentation. As for DynaSoar - we already have a nice little Dreamchaser model. However, a bit of a showstopper is the flight model - we don't have any. Basically, SpacePort is based on ballistic model, and it has a rudimentary flight model applied to capsules during the reentry (capsules produce lift during reentry and can indeed be steered). However, for more sophisticated lifting bodies (DynaSoar, Shuttle, Dream Chaser), for now, they fall like a rock :) One thing that we hope will work is, we can re-impose P3D flight model at certain speed during re-entry, where the lifting body starts to transition from ballistic to aerodynamic, but we haven't tested that yet.
Perhaps the most powerful feature of SpacePort is its highly flexible scripting engine, a sort of a condition-event driven internal computer (we call them "sequencers"). They are used to tell an object what to do when certain conditions arise. They are written using simple text files and a specific, user-friendly syntax, and can be assigned to any object SpacePort is in control of. They can be very simple - for example, a launch tower has its own sequencer which, using timed triggers, controls various parts of launch tower tasks (retract crew access bridge, start noise suppression system, start ignition sparks, retract umbilicall arms, etc.) They can also be rather sophisticated - we are using one to trigger events after the capsule re-entry, so that the parachute sequence is correctly deployed. Or - we use another sequencer that we attach to solid rocket boosters that basically tells it "when SRB thrust to weight ratio is lower than 1, detach" - basically, when a SRB becomes dead weight, time to discard it. Also, we are using sequencers for the initial azimuth-pitchover maneuvers and pseudo-guidance (GNC) of the launch vehicle. In fact, the entire SLS launch sequence is controlled using user-written script - there is no internal hard code that controls it. There is even a feature where you can write your own text based P3D menu with executable commands, entirely scripted using sequencers (you will see this in action in the upcoming demo). The point is - all of them are user-written, and thus, highly customizable and flexible.
I hope this answers your questions. If you have any more, I'd be happy to answer/elaborate on them.
Cheers,
Mitch
P3D SpacePort Team
