27 Dec 2016 10:32
Suggestion:
Currently, as you bring the camera near a planet manually, you remain following the last object you left until you are within a few tens of kilometres of the surface (or maybe it's a percentage of the planet's radius of the surface or something), whereupon you suddenly snap into following that planet.
I like to play with the gamepad a lot, and I adore flying between objects Gly apart in one smooth motion. When I get to my target planet, though, I will be fighting the "follow" of the departure object to keep station with the destination object. Then, when I get within that few-tens-of-km threshold, I am suddenly switched to "follow" the destination object, which usually results in my inputs (which were fighting to keep pace with the destination) catapulting me into the ground before I can react.
I suggest that that change of "follow" target for the camera in Free Flight, Aircraft and Spacecraft camera modes be changed from an instantaneous switch-over to more of a gradual sync-up with the nearby object's motion.
I don't want it so gradual that I don't notice it happening - I love that Space Engine makes it clear that planets are orbiting different stars at different speeds, ranges, directions, and rotation rates - but I would like to be able to react to the change before I get buried in the landscape 0.01 seconds after dropping below the Karman line.
I know some people want a gradual transition that would mask the little difficulties introduced by things like differing planetary motion. If you're willing to lose the insight provided by that sensation of different motion, you could have a slider control how abrupt the transition is from following one object to another.
At the extreme end of the scale, your "follow", unless explicitly selected inside the presently local system, would be an average of all the objects in range, sorted by distance and heavily weighted towards the nearest objects. I would rarely use this end.
At the other end, it could transition to the local object's motion over the course of 1->5% of the object's radius when within 20% of an object's radius (for example - substituting the accurate numbers for what's presently happening).
Another option for doing this would be to keep the snap, but preserve the relative speed and direction of the camera with the new follow destination across the transition, and then re-centre the controls on the new "follow" target once input ceases. Example, I'm approaching a planet, pass through the threshold, and my HUD-displayed "Following" thingy changes to the nearby planet. However, the camera doesn't change its motion relative to the destination until I let go of the stick or let-up on the keys. Until then, the centre point of the controls is temporarily offset by the difference between the departure "follow" and the destination "follow". That way, I could cross the boundary without catapulting, and then come to a stop gently. That sounds a little more unintuitive than the other way.
If I understand correctly, it's just a matter of doing a little math on the vector variables for the camera's "rest state" versus nearby objects, right?
----------------------------------------------
One other suggestion: The splash screen tends to freeze and act like it has crashed if you click on it. If you leave it, it will load up just fine, but Windows may throw up a appcrash message until it does load up. That could be generating some false alarm crash reports and user dissatisfaction among the less-patient. It also makes the program appear less-polished than it is otherwise. If there is some way of simply handling mouse clicks on the splash screen without hanging the splash, it would be a good "user confidence" improvement.
----------------------------------------------
Kchamp, I second the call for running lights. They will be useful, but they also just look cool.
I remember hearing that Space Engineer didn't want to implement shipboard lights (originally including emissive textures) until he could do proper volumetric self-illumination from them - meaning you could place lights on the ship that would illuminate the hull, but also that the emissive textures would splash-light the hull of their own ship and any nearby ships (important in deep space or in eclipse shadows).
That sounds computationally insanely expensive - but I see game engines doing that now, like Frostbite, UE4, and whatever Elite: Dangerous is built on. That'll be sooooo cool when it's implemented.
Speaking of model textures: Alpha blended transparency mapping, pls!
Last edited by
Destructor1701 on 27 Dec 2016 20:42, edited 1 time in total.