arkie87

Yes, it would be cool to know. Also, it could be integrated into contract system via contracts like "land a kerbal on two moons" or "land a level 2 kerbal on X" which means you first have to level up your kerbals by performing other missions with them, and provides further penalties for killing kerbals. Or maybe, your cash rewards from contracts are multiplied by larger factors if more experienced kerbals complete them (if you do every contract with one kerbal, you would earn a lot more, making you really sad when you finally kill him). This could probably also integrate into the courage-stupidity rating system that currently does nothing... Thoughts?

Has it bothered anyone else that there is no infinite electricity option in debug menu? Sometimes, when you want to mess around by crashing 100 km/s into Kerbin, and half way out, you run out of battery and have to start over...

Your solution is fine for players who dont want to simulate aerobreaking or orbital decay. But i agree, if we are just looking for a landing and receiving credit for parts, than simulating physics is a waste, and the player should just get their recovered parts/kerbucks. Personally, i think something like what i proposed above would be great for a plugin to perform an aero-breaking prediction and should be FAR/NEAR compatible (it wouldnt manually change the path from what patched conics predicts, it would just show a prediction). I could easily program it in a fake language like MATLAB, but not so much in C#....

I think OP intended that rather than simulating physics using PhysX engine, the trajectory will be calculated separately using a custom ODE equation the solution of which will be used to modify the trajectory, thereby ignoring what patched conics predicts (is that possible?) This would mean all simulations can be performed whenever and time warp isnt a problem (as long as the simulations are completed before time warp is entered). For stock aerodynamics, since drag is independent of orientation, the calculations would be simple and 4th order Runge-Kutta integration can be used to obtain accurate predictions with very few points (probably between 100-1000) which is trivial on any computer made this decade. This scheme can be implicit (iterative) or explicit (non-iterative). For NEAR or FAR, an assumption will have to be made about the piloting, most notably the Angle of Attack (constant angle of attack can be abused since the craft might not be able to maintain it if it doesnt have enough torque or if the vector is unstable) . Thus, more likely, the player will have to choose prograde or retrograde, or NEAR/FAR will automatically enforce the most stable orientation (retrograde for pods, and prograde for aircraft). Nevertheless, if the angle of attack is given, the problem is the same as stock KSP, and 4th order integration schemes can be used no problem.

Yes, Kasuha pointed this out. It is basically the result of using explicit time integration (forces are calculated based on displacements, velocities etc... of current time step) rather than implicit integration, where forces are recursively updated based on values at future time step. It is well-known that implicit integration schemes are more stable than explicit (in general).

Am i the only that wants 1,000,000x to speed up interplanetary transfers?

I think this is exactly what i was saying above: you basically treat the ship as one part to conserve momentum. And afterwards, you calculate forces and torques on parts to see if they break. This will make the physics and physics warp a lot more stable. Unfortunately, it seems like PhysX is in control here and for the sake of generality, solves the physics for each part separately and then applies forces between parts. However, i suppose its still possible to fix it, by telling PhysX the ship is a rigid body and calculating stresses and displacements manually afterward.

Mr. Ferram, I think what OP meant to say is that the stabilizers do not produce lift (and negligible drag) at 0 AoA i.e. the cross section of the wing is symmetric in the horizontal plane (and thin). However, what OP failed to understand is that any wing/flat plate will produce lift (and drag) for non-zero AoA, which in turn, causes the corrective/stabilizing torque if the CoM is in front of the CoL. Thus, the CoL calculations must still include a horizontal flat plate since for non-zero AoA it will come into the equation. AmIRight?

*Ergonomical* In all seriousness though , good idea. When I read the description I thought you meant a button to switch better VAB and SPH without having to go to space center. This is not as trivial of a change as it sounds because if you are building a rover, you can launch it from either VAB or SPH and editor extension plugin won't change launch location (only building symmetry)

THANK YOU! I think that makes a lot of sense and explains it. What you are saying is the PhysX engine applies physics directly to the parts with thrust and integrates the equations of motion for each part, causing the engines to displace farther and pull on the ship to accelerate it. What would be smarter/better is to treat the ship as a rigid body for the purpose of conserving overall linear and angular momentum, and then resolve all forces/torques between all parts in the rigid body. i.e. instead of treating each parts displacement on an absolute scale (with no realization that the parts of the ship are connected), treat the ship as a whole on an absolute scale and then each individual part locally. Unfortunately, if this is true, there is no way to change this without changing PhysX itself. Maybe i should make my own engine? Edit: I think this is a direct result of performing explicit integration rather than implicit. If implicit integration were used, the parts undergoing thrust would not displace as much, because the external forces on the part would be calculated implicitly i.e. based on the future displacement (rather than the present displacement i.e. explicit).

This is why you cant think about math .... without math. Increasing time step does not change the forces, it just changes the deltaV over that time step. The fact that it messes with forces/torques/displacements implies the time step is not really a physics time-step.

They are linear with distance and linear with rotation. There is such a thing as a linear torsional springs as well... This is accounted for in the stiffness tensor.

Is there a practical difference (in the control system, for instance) between air-to-air and air-to-ground guided missiles? It seems to me that air-to-air missiles are programmed to to try to get behind the aircraft, whereas air-to-ground just try to hit the vehicle. Also, any chance on adding in the AIM54-Phoenix (super-long range air-to-air missile). It looks a lot like the AGM65 maverick, so not much new modeling work is required? Also, correct me if im wrong, but the AGM-65 can be TV guided. Any chance we could get a small pop-up window that would allow us to guide it? :-)

Force of thrust should not be scaled with time-step.

This doesnt make sense to me. If joints are modeled as linear springs, then displacement is related to force, and force is constant regardless of time warp... m*dV/dt = F If dt becomes larger, then dV becomes larger for constant F (and m)

Maybe, but its labelled as discussion, and it seems to me this is an artifact of the way KSP treats time steps, hence a suggestion to fix it.

I assume the way displacements apply force is by modeling joints as linear springs. This, however, has nothing to do with changing the time step. The force applied is constant with time step; the displacement should be constant too. Or are you suggesting that there is no "time-step" used in Unity/PhysX at all; the time step is merely simulated in KSP. This would explain why my intake air multiplies by a factor of 4 when i enter 4x time warp (the air flowrate in kg/s should remain constant with time step). Do you have any references for what you are saying? I am interested in learning more.

I agree there should be an option for this built into KSP, and i would even say it should be enabled default so that beginners dont even notice the issues associated with placing engines slightly offset from CoM. However, there are several plugins that currently do this: http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-(April-6) http://forum.kerbalspaceprogram.com/threads/38069-0-24-Davon-Throttle-Control-systems-mod Furthermore, with the addition of the vernier engines, it is easier to obtain necessary counter-torques to maintain stability (although it wastes fuel). I think the best/most general solution would be tweakables which allow you to select whether engines are active under regular "thrust" and/or RCS. For instance, VTOL aircraft can be created using vernier engines with RCS turned on and using the IJKLHN keys. The obvious advantage of RCS is that its thrust is always applied at CoM (if possible). It would be better if we could set any engines to work with RCS and vice versa. Thus, for craft with asymmetry engines, (but engines at either side of CoM), they could be set to work with RCS and controlled with IJKLHN keys. However, the only problem with this is that IJKLHN are all-or-nothing and does not allow you to throttle your thrust. hmmm......

This is something that has confused me for a long time: if you have a simple spaceplane with two jet engines mounted at the wingtips, entering physics-warp will bend the wings forward. This implies that the thrusts (and therefore torques) are simply increased, rather than actually changing the value of the time step used in physics calculations. What is going on?

Thanks for the link. Very interesting. Though i dont support implementation of n-body physics, i do support use of higher-order integration schemes so that 100x physical time warp is possible. In particular, the equations ive provided can be used to obtain higher order accuracy even under numerical integration, though they are not necessary.

It's one thing to suggest an idea, its another to present in detail how it can be implemented.

True, for large ships driven by LV-N, there still might be wibble-wobble. Personally, i think wibble-wobble is stupid, since struts will fix the problem, and are massless, so you could just overload on struts. In the end, it makes the most sense to treat the vehicle like a rigid body when thrusting in time warp, and it might just be a necessary sacrifice to make certain burns possible. If you think about it though, most wibble-wobble could be dealt with simply by reducing throttle or turning throttle on, then off, damping wobble and/or correcting aim, then turning back on etc... and so, this feature would just save the player the hassle of doing this. However, the only problem i see is that this would enable engines with CoT misaligned with CoM to fly straight, which would be a problem in my book. To fix this, a simple check could be conducted to determine if too much rotation is being experienced, and if so, refuse time warp (sort of like it already does). Solar charging is a function of angle, distance from kerbol, and shading etc... but the game already calculates this during time warp (not sure how; its probably inaccurate or uses forward time-stepping allowing you to receive charge for the whole time step if you start the time-step with a view of kerbol). Thus, this problem is already dealt with (somehow).

Yes, but its possible to get around this issue, as Master Tao explained. - - - Updated - - - Are you saying orbit manipulator series uses the same method/equations i provided?

I agree that there are other issues to consider, such as wibble-wobble. However, time warping with thrust would only be allowed if the acceleration is low, such that no wibble-wobble would be encountered, such as usually the case with nuclear engines, and almost always the case with ion engines. Alternatively, time warping with thrust would just assume the body is rigid i.e. infinite struts (which are massless anyway). The game already calculates energy flux on solar panels and battery charging during time warp, so i dont think that will be a problem. Furthermore, since charging/discharging/thrusting is always linear, these effects would not be difficult to incorporate.

I think it is possible to have a "non-physical" on-the-rails time warp while thrusting using the fact that an analytical solution for this case exists. For a constant thrust (over a frame or time-step), the differential equation for mass is: Eq. (1): dm(t)/dt = -k where k is a constant (though its value can change from frame to frame or time-step to time-step). In space (or the absence of drag), conservation of momentum takes the form: Eq. (2): m(t)*dv(t)/dt + ISP*dm(t)/dt = 0 where ISP*dm/dt is the thrust term. Finally, by definition, velocity is related to position by: Eq. (3): dx(t)/dt = v Thus, Eqs. (1)-(3) form a system of linear ordinary differential equations, the analytical solutions of which are: Eq. (4): m(t) = m0 - k*t = m0*c1 Eq. (5): v(t) = v0 + ISP*ln(1/c1) Eq. (6): x(t) = x0 + v0*t + ISP*(1 + c1/(1-c1)*ln(c1))*t where c1 is a convenient parameter defined as the ratio of the mass at time t to total mass: Eq. (7): c1 = (m0-k*t)/m0 = m(t)/m0 It is worth noting that Eq. 6 for position includes an additional term beyond simple Euler integration, namely, ISP*(1 + c1/(1-c1)*ln(c1))*t. This term accounts for the known way that the ship accelerates during a constant burn, and calculates the extra distance the ship has traveled. Similarly, Eq. (5) for velocity includes an analytical acceleration term, and Eq. (4) for mass is linear. Thus, even large time steps will exactly match the correct (analytical) solution, enabling time-warping with thrust. However, a small correction will have to be added to make sure the craft has enough fuel (and if an ion engine-- enough electricity) to burn for the whole time-step, if the time-step is large enough. There are two options: (1) Time warp is automatically killed until the time-step is small enough that all the fuel/electricity will not be consumed. (2) The value of k can be changed such that m(t) = m0 - k*t = 0 i.e. k = m0/t, so that conservation of mass is not violated. What do you guys think? Can this be implemented in KSP via a plugin or would it have to be hacked into PhysX/Unity?