majic79

I'd be happy if up/down keys worked the same way as left/right keys - I want to invert up/down for a flight sim where I'm not using the artificial horizon as my attitude indicator, it's almost (but not quite!) completely nonsensical in KSP to my mind and the number of times I've got up/down crosswise due to a rotation and re-alignment of my axis in relation to the dockng target - grrrrr

I think you'll find that bernoulli's principle doesn't dictate how wings produce lift, for that you always require Angle of Attack (Bernoulli's principle does explain why you get clear air turbulence behind an aircraft, as it produces a rotating flow around the wing which generates a vortex) I'm sure that I've seen wings mounted with an inherent angle of attack on stock KSP (I watched over my mates shoulder when he was playing on his mac and he hit a key to change the angle of a single wing)

All is forgiven - you still make a valid contribution and I welcome constructive criticism With regard to parts embedded within other parts, there is a solution that doesn't tax things too much if you do it on a face by face basis for each part (module) and reduce the surface area of the part by the amount that's embedded in the other part and the model should work for those cases also. I've been thinking about it and most faces are flat (coefficient for that face=1), the only problem parts are curves (nosecones) and you'd have to work out the mathematical function that describes the curve and then work out drag based on that function. Most 3D parts are constructed of polygonal faces (usually triangles to prevent concave side problems) and if the curve is approximated in 3D using polygons, then it becomes a simple solution (but more time intensive, but linear in relation to the number sides, so not a drastic performance impact)

Ferram4 - technically occlusion is correct (see meteorological and dentistry definition) in the context it was intended (ie, Include/exclude - the category for exclusion from the calculation is it's direct contacting faces which can either completely or partially reduce the drag calculation for a face), and while I appreciate that it's similar, it's not the same as shadow (air != light) and I've no intention that this idea should introduce shadow effects of drag (which does occur, due to turbulence and diminished airflow - I know first hand as I get to experience it sailing inland or with terrain features that interfere with wind) and I don't want shadowing of airflow to affect control surfaces due to high angles of attack Supersonic transition creates a shock, with a corresponding re-merging of the disturbed shock front with the surrounding air, this has a speed and a distance and is therefore a wave (a standing wave in relation to the moving body, a sonic boom to an observer) during the transition from subsonic to supersonic flight, and that distance is the wave length (and causes some quite sever effects in turbulence around the body until it passes a critical mach number) and really is only an interesting point for discussion in the transonic region - but as I'm not interested in simulating aerodynamic effects to this level, it's irrelevant to the discussion. I think you've misunderstood what I mean by a "light function" - I've never done ray-tracing (it's too slow for me) and simple vector maths IS what I'm proposing And by interfere, I thought it was implicit that I'm more concerned about impacting on performance - naturally a new drag model will affect the behavior of the simulation

Well, I'll add I'm still fairly new to Kerbal, but I'm not new to flight sims (or flight for that matter - I have some time logged in a Cessna 152) and I wasn't aware you'd done experiments in drag Ferram - but it's interesting to see, and I can understand why you interpretted "occlusion" in the manner you did (yes, it was the wrong choice of words for me) I do work in a fluid flow environment so I've some knowledge of the technology (which is a whole lot more complex than my suggestion, but that suggestion is aimed at providing a slightly better model with minimal impact on performance) Plus keep the discussion going as I'm only trying to get thoughts going and see if there's something to be gained from it

This is pretty much what I'm going for - the normal to the surface and angle in relation to the direction of travel will dictate the amount of drag the face will be subject to (and magnitude of deflection can be determined for the same angle giving a vector thrust reaction to apply to the module - total module deflection is then the sum of all affected faces and node breakdown occurs above a critical force/vector) - for subsonic flight this model should be fairly simplistic and effective - it also doesn't take into account transonic turbulence, so should make things easier (not having to design/counter this effect should make it easier on the player) and doesn't overload the system trying to handle too work out the cross sectional area of the whole, or an appropriate aerodynamic drag factor in relation to the whole, whilst still retaining the ability of the system to simulate aerodynamic reaction, catastrophic failure etc

Actually, by occlusion, I meant faces in direct contact - occlusion of non-contact faces (shadowing) would only work for speeds exceeding the speed of sound at distances less than the wavelength of the shock wave (a function of the speed of propagation of the shockwave and the speed of the body through the fluid) - so please read the suggestion as for that of faces in direct contact with each other, and not for faces that are only in shadow (for it to work properly at supersonic speeds, then you must take into account distances between faces and then calculate the speed of the shockwave to see if there's an interaction or not) Perhaps "occlusion" was the wrong word, but the intention was only to omit faces of an object that are in direct contact with another object, not faces that are "shadowed" and the method I propose is not CPU intensive - it's very similar to a common lighting problem (flat shading and gouraud shading were one of the first colouring techniques I learnt in 3D graphics before 3D enabled hardware became common) which is readily handled by OpenGL and could potentially offload the calc to a GPU during physics/aerodynamic areas of the trajectory I realise that this doesn't take into account re-adjustment of airflow as it passes around objects, but it does give a better first order approximation of drag effects and lift, without interfering with the remainder of the simulation

I had a look but couldn't find anything, so I started thinking about the modular nature of KSP and how drag can work (and why the current situation causes problems). So currently, an object has drag x which just stacks up, regardless of orientation, and then goes through a drag calculation (which doesn't take into account cross sectional area) and gives a universal figure of drag I propose the following modifications: each face has it's own drag coefficient of drag and a pre-calculated surface area. Calculating drag then becomes a function of summing all non-occluded faces (Faces that are not hidden by other faces, if they partially overlap, then there's got to be a calculation to determine the amount of "shadow" that the occluding face provides) that lie within 90 degrees of the direction of travel (faces 90-degrees to the direction of travel can maybe carry a parasitic drag factor?) multiplied by the sine of the angle of normal to the direction of travel. This function is fairly similar to incidental light calculations for flat shading, so the CPU load to calculate should be fairly insignificant for moderate sized rockets, perhaps insignificant on larger vehicles? Further optimisation becomes available in using tabled sine values for the multiplication and the automatic elimination of occluded faces can be done on leaving the VAB (the only time they will ever change is if a module is disconnected at the occluding face) As a first approximation, this then permits nose cones to provide a positive effects on drag reduction, whilst also providing module force effects in atmosphere that are a little more true to life, without also going in depth to deal with actual aerodynamics. This could also be used as the aerodynamic system, as the drag force is also what provides uplift (via angle of attack). Supersonic flow is the same formula, however heat effects come into play and make things a little more tricky - it'd be nice to see it included, but not essential?

Going EVA after creating a maneuver node will lose the maneuver node when Jeb re-enters the command module. To my mind, planned maneuvers belong as part of mission control - so should persist for the duration of the command module, regardless of where the kerbonaut gets to. To aid gameplay, I'd suggest limiting maneuver nodes to one initially - this prevents the development of overcomplex trajectories early on in the game. An add-on (Kerbcomp?) module that can be installed in the command module (or upgraded command modules, e.g MK2, MK3 etc) can synchronise and automatically execute the maneuver on time, provided SAS/RCS is active and it has time to align to the maneuver prograde target. I'd suggest it uses electrical charge to perform synchronisation (and requires a comms device) and to store it's target requires a trickle of electricity I've not played with any mods yet - having played the demo for a few days and then splurging on the full game, my gameplay path went: Demo->Tutorials, Demo->Sandbox, Full Game->Career mode, so I may have missed some learning aspects, otherwise, I'm loving this game - always enjoyed a bit of rocketry!