jwocky wrote:Oh oh ohhhh, a bit careful here, please ...
1.) They go in and out ... obviously. Means, they change dynamically their relevance in lift and drag. Which leads to the effect that is is really dynamic ... as in, the flaps move from one position to the other. Now imagine you have all this in your main lift routine. Every function is internally worked as kind of a little chukn of software inherently blocking other parts of the software from getting to work while this thing runs. So you really want to split it up in smaller chunks.
Another example for such effects (not aerodynamically, but software-wise) is a JSB-fuel system. Looks quite nice on the paper and the theory is so elegant. And of course it runs faster in JSB than it would run in an extra.Nasal module ... however, the cost in blocking core cycles are higher
This seems to be the argument that a complicated flight model uses more processing power than a simple one and as such flight models not being that important we should have the less processing power one so that we can use the extra cycles on something else.
This is a flight modelling forum... I'm a flight modeller... and I'm never going to buy that argument.... afterall following that same premise 3d models should be restricted to 3000 vertexes and textures should be a maximum of 2 off 256x256
How about instead we see how much more detrimental to the output a complex flight model is to a simplistic...
As for tweaking.... nothing wrong with it, if it's your bag.... but there is more than one way of tweaking, you've learnt one method how about learning another ?
Simon
