pheonixstorm wrote:No damage from collisions.
Impact elasticity is a matter of choice - though obviously you have to calculate less of them if you make them very inelastic.
And in VS it's global and adjustable as
physics/inelastic_scale.
pheonixstorm wrote:A lot of the objects in game you can fly through (which is down right annoying). When warping you can warp through pretty much any object. Planets, suns, stations...
That's either performance save or more likely plain low precision. Happens in FFE (and VS versions with time acceleration, IIRC).
travists wrote:When dropping you near a significant object it self corrects to place you in that orbit before disengaging.
If the ship
is correctly affected by gravity, this boils down to "use your navigation target's frame of reference on approach", which is the most sane way to do it anyway.
And if it isn't, this won't help because...
klauss wrote:The problem with orbits is it involves acceleration, constant acceleration. Delta-V.
Or simply weak thrusters. Which also would look silly. Right, orbital mechanics is for all or nothing.
klauss wrote:The problem with gravitational maneuvering is that it involves applying Delta-V to change from one frame of reference to the next. It takes a lot of energy and time to do it naively, and people don't want to spend that time.
I already mentioned here that
SPEC changes delta-V at least through tweaking inertial limitations, even if its net result obeys preservation.
And gravity
in the warped effective space
is going to be amplified/attenuated by "warp refraction" (assuming "gravity is force", since using GRT's "gravity is warp" is messier and would get in troubles even other effects in VS).
Which may allow other delta-V changes, unless gravity and inertia tweaks negate each other (this can be said for sure only for a finished physics model, not "in the general direction").
travists wrote:The Delta-v of a ship's afterburners is quite large.
Depends on the type (fuel-guzzling one is obviously worse), though default exhaust velocity of 1/60 c definitely helps.
klauss wrote:Furthermore, we're not talking about highly optimized AI routines, we're talking about modder-friendly AI routines, probably far from optimal. If they were to be CPU-bound, which they are in VS, writing them in python makes them around 100 to 1000 times slower.
Given VS architecture, the issue is compounded. There is no multithreading, so when VS is running AI graphics and everything else freezes. This means AI has to run very very quickly to remain smooth, and it simply cannot do that in pure Python.
So the worst bottleneck is impossibility to break at least graphics, generic physics / main game logic and some parts of AI into separate threads.
That is, the scripted autopilot is good only for handling less time-critical things, and not stuffing all and any standard functions into C code would be counterproductive. Of course.
If the bots (parts of AI choosing actions, such as reading XML aloud to the rest as it does now) were farther from real-time than the parts doing "match velocity" and suchlike, this probably won't ruin everything.
) 
