ChevronTango

As stated, its an early alpha I bashed out this weekend. I'm aware that its not just stock parts that are unreadable. I have some rough leads on possible solutions but I imagine this will likely be the hardest part of the mod, so the fact that I have something working around that at the moment I'm counting as a victory, though we're hardly off the starting block with this yet. I've set the default to be colored so that you can see the mod working when loaded(This won't be so in the release, but I figure if people are trying this out it would be good for them to see it working). I'd need to do a check the target color array to make sure it matches the source exactly before defaulting to no Overriden Texture, but with alpha == 0 that's a guarantee, so quicker to do it that way for now and add the comparison in later. I've thought about a single pool of textures from which to draw from and will likely implement this for efficiency at a later point. We're still in the proof of concept phase so little things like that have fallen by the way side, but are on the drawing table. I've currently got the popups using the same popup by reference so I don't think it'll be a stretch to apply this to other parts. The mipmap stuff is very useful to know. I figured there was a flaw in what I'd rather hastily looked up and written in a single weekend so thanks for the pointers there (I started this Saturday Lunchtime and finished Sunday Lunchtime, don't judge me, I do have a life honest... ). ARGB32 is what I'm currently sticking with for now, as its going to be the simplest with regards calculations and such. If there's a good reason to expand beyond this I'll make a move to adopt it but it seems like a good enough sticking point for now. All in all there's still a long way to go but I appreciate the pointers and hopefully should be able to get on to a lot of this in the next few weeks.

Whether a part works or not with this is down to whether the texture it has is readable, which is a Unity Feature that defaults to false for most parts. If it works with a part then you need to select (left click) the part whilst in the ActionGroupEditing mode, not PartEditing mode. If you've used the TextureReplacer I've linked to in the OP then all the wings (not Control Surfaces) will be paintable. b9 by default should all be paintable aswell but I haven't checked every part yet. Please do bare in mind this is a very early alpha release. EDIT: I will be looking at getting this working for all parts, its the highest priority of the current development stream. If anyone has any input on this please PM me.

KSPaint allows for texturing of any part providing its texture is readable. I've tested this with Infernal and B9 with no problems, so its really only the stock parts that are problematic atm, but those will soon be fixed so this becomes universal. The plan is for the Texture Editor in game to have layering and blending similar to most image editing suites, hence the rather large amount of blend modes that seem superfluous with only solid colors atm, but in addition I'm looking to have importable textures, because having hot rod flames, go faster stripes, or the British Airways Tail Fin sounds like a giggle. KerbPaint was an inspiration for this, and in many ways at the time of writing is likely to be a preferred choice for most, but the aim is for KSPaint to become more powerful and universal. Bare in mind this is my first mod so its going to be a little rough around the edges.

This is my first mod, though I've been on the Forums as a lurker for quite a while. Not sure how good this has come out but I thought I'd post where I'm up to and see if Excitement got stirred or if people feel it not worth much. KSPaint is a tool to Color/Skin your spacecraft parts in game, per craft, and per part on craft. While in the VAB or SPH you may select a part and in the ActionGroups Tab, Choose how you'd like it Colored. Many ColorModes are currently implemented but not extensively tested, and more and exciting ones are on the way. The Author recommends sticking with Normal for now. When a part is selected and the PopUp open you choose the blend mode (stick with Normal for now but the others should still work), the Red, Green, Blue values of the color you want and the Alpha (transparency) of the color overlay. IMPORTANT - Not all Textures in game can be edited Due to Factors beyond my control Textures imported by Squad generally aren't readable and so are incompatible with this mod A workaround is to use addods where the Textures are readable (B9 is good) or to use TextureReplacer where the textures are readable on the stock parts I'll Update with more Information soon. Currently I'm not allowing Distrubution or Use of my source by others. This will likely change when later versions come out. Download - MediaFire Still To be Developed: Importing Images Multiple Layers Replacing Non-Readable Textures Improved UI Clone Texture Style From one part to another Update all Textures Parts with multiple Textures Defined

If it's pitching up with SAS over a long distance flight then that's because the sas is trying to keep your heading from an orbital point of view, not a surface one. The practical upshot is that if you travel horizontally with SAS, when your 1/4 of the way round the planet you'll be pointing vertically up, similar to what you'd notice if you had a satelite orbiting the planet.

if you have mechjeb installed and your using ASAS then if you set it to surface, with whatever pitch and you like, but a heading of 90.4 then you'll head straight down the runway. For somereason the plane is aligned to 90 degrees on launch but the runway is .4 degrees off this. Tow in and Tow out plays a big part in your corrective steering and your aircrafts beahviour at speed but if its just this slightly bizarre natural drift your worried about then its because the runway is not perfectly aligned east west. As far as I'm aware it is perfectly flat and doesn't slope forward or backward but I'm not sure, and I'm also not sure what circumstances that would truly affect your takeoff adversely.

Well I'm glad progress is being made. Most plane's have some small exentricities that require trimming, otherwise it would be too easy and the game wouldn't need (A)SAS at all. Most RL plane's have some anomalous behaviour unique to them, which pilots often become accustomed to, so airline's tend to keep pilots on the same few aircraft to keep things comfortable. turn on your ASAS and see if the problem goes away, I imagine it would. Best of luck with the future endavours though.

Several things could be causing this. Unbalanced fuel flow, part clipping or perhaps something to do with Landing Gear having no mass and drag. My advice would be to check the symetry on all the parts by removing them and then replacing them carefully in the Hangar, if the problem is a displacement perpedicular to the direction of travel. If the displacement is parallel to the direction of travel then I'd speculate its a fuel flow issue. Its a case of debugging it now to find the solution but if your stubborn enough you'll find the cause. Maybe post the craft file for it on here so we can take a look aswell.

The critism wasn't of your intentions, merely of the wording, which I wanted to clarify less for you, and more for others reading this thread further down the line. Understanding how lift works in Kerbal is not well documented or well understood universally so I just wanted to emphasise the common misconception that most people infer from simply reading "it needs more lift". Moving the wings about won't really help that much in my mind, but worth a shot. My recomendation is to increase the torque at rotate speed by increasing the number of control surfaces, and placing them strategically around the COM and the contact points on the runway to increase the ability to pitch up. Pitching the nose up by repositioning the landing gear would also do a massive amount to help.

I cannot emphasise this enough, and my evangelism across many threads in this forum seems to be doing little to get this point as common knowledge. More lift is indeed what a plane sticking to the runway needs however the runway is a special case. With an angle of attack of zero the wings generate absolutely no lift at all. Whats worse is that if there is a fractional downward angle, say by the front landing gear being slightly higher (even a miniscule ammount) which causes the nose to point down, then you end up generating lift INTO the runway (counter intuitively, but think about when you point the nose down mid flight, or perhaps roll 180 degrees whilst pointing up, the effect is the same conceptually). The solution is either more control surfaces, which on command input will generate a large Torque in the right direction, or to angle the wings upwards slightly using alt+WASD, which assures the wings are in fact generating lift upwards. Adding more wings naievely without adjusting the angle of attack will not affect a solution and in some circumstances may make the problem worse. When you fall off the end of the runway the torque allows the wings to point upwards and they suddenly generate lift, which is why the plane suddenly flies perfectly. With smaller aircraft the problem isn't noticeable because the control surfaces induce a very large torque relative to the mass so you can pitch up easily, then generate lift off the runway.

CrossProduct(velocity, wingRight) is the key here, if you draw a plane between the velocity vector and the line from the wings center to where it joins the fuselage, then the lift is othogonal to this plane, in the direction that the angle of attack logical indicates as up (so simply, flying straight and level with a positive angle of attack the lift would indeed be up relative to the planetary body.) I'm currently working on a relatively advanced Simulation system which would take a craft file, along with various inputs such as height, planetary body, velocity, velocity direction etc and it'll calculate lift and such. It may become a plugin aswell but I'm still not sure where I'm heading with it. The original plugin I submitted in an earlier post on this thread still does a very good job at demonstrating the lift vectors so if you have any queries about directions, where the force is applied, or scaling, I suggest you go play with that to get a better idea of exactly what we're talking about.

20,000 km? WOW! I wanna know what spaceplane your using. Where can I get one. But that aside its a balancing act between height, speed, lift and drag always. I use mechjeb to control the flight as not only does the throttle control prevent this vary senario, the MechJeb Advanced SAS when set to surface can maintain a constant heading pitch and roll which makes flights dead easy and further helps to prevent such problems as flameout induced flatspins.

I don't want to get into a debate on the subject, I'd feel antsy about it if I were them I suppose, but whatever happens now and however you look at it, we at least now have some solid formula's for lift and drag and a couple bug reports lodged that should hopefully help a few people out.

The drag is just nativeDrag when the intake is deactivated/closed. This is yet another bug in the game, where when deactivated we set the intakedrag variable, which isn't being used by anything, to equal the nativeDrag variable, presumably as placeholder. The Upshot of this however is that the variable is used in the GUI, so when closed its simply the nativeDrag and when open its the intakeDrag without the NativeDrag. I shall lodge another bug report on this one. My decompiler didn't quite catch all the private properties and variable names correctly with this one so I can't be as specific in the bug report as I'd like.

Air Intakes are trickier. The base part has a native drag that's static, (for the ram Air Intake 0.3 defined in the part cfg) and that performs universally like all other drag on any object, however there is an additional intake drag on this part aswell which has some interesting maths. I'll try and sum up both these in one equation to make life easier. d = NativeDrag + Clamp(0.6 * velocityMagnitude * intakeSurfaceArea * cos(AoA), 0, 2) where Clamp(in, min, max); is equal to Max(0,Min(1,in)); or rather Clamp(in, min, max) { if (in<=min) return min; if (in>=max) return max; return in; } so in summation the maximum drag for the Ram Air Intake is when its facing the velocity vector dead on and at sufficient speed, at which point the drag becomes 2.3, and when its side on perpendicular or backwards to the direction of travel its 0.3 I'm going to relook at this soon to make sure I haven't done something monumentally thick. The fact that we're using VelocityMagnitude is surprising to me, so if someone can check my research and/or maths I'd apreciate it. Assuming those preconditions about the lift surfaces, yes, that's right, where otherDrag presumably is the rest of the craft's drag.

not quite, and this does raise a slight issue with the terminology I chose. If you assume velocity is always in the plane created by the upwards and forwards velocities then your reduction hold true, however if there is a sideslip then the AoA I mentioned no longer is completely accurate, as its the angle between the velocity and the forward vector, which is no longer zero, despite the StupidAoA I mentioned staying at pi/2 (ie the wingUp vector is still perpendicular to the velocity) in this example. My naming of variables was a little off here so I apologise for any confusion it may have caused. Assuming velocity is only ever forward, which for most simple calculations is a fair assumption, your simplification is valid.

for reference, the drag values of the parachutes are: stowedDrag = 0.22 semiDeployedDrag = 1 fullyDeployedDrag = 500 and the force can be calculated by the usual method, though the drag force for each parachute is proportional to its as mass, vis-a-vi Kerbal Physics

the drag equations for all parts in kerbal are as found on the atmosphere page of the wiki. the coefficient of Drag used in the wiki is calculated by the winglet thusly: d = Abs(cos(StupidAoA))*NativeDragCoefficient; where NativeDragCoefficient is the drag of the wing specified in the parts.cfg for it, and also noted in the VAB and SPH display for the part. StupidAoA is as mentioned previously, the angle between the velocity vector and the wings upwards vector. so a wing has no drag when its angle of attack is zero and maximum drag when the wing is perpendicular to the direction of travel, which makes sense when all things are considered. Edit: It should be noted that with a breif look through the rest of Kerbals Source, this is the only example I can find of a parts drag not being constant

Yeah, it was. The base part and its lighting module were both fine but the landing gear module was updating the parent part to have no PhysicsSignificance, for reasons beyond my comprehension.

Check fuel aswell. If one of your fuel tanks drains before another your CoM can shift making your ship lop sided and when your engines fire you just end up spinning around the CoM

You can just adjust the mass to your liking. The default one adds about 2 tons to most of my planes which coupled with the drag makes previously easily takeoffs much more hairy. It's rather fun actually. Deploying gear mid flight now gives a noticeable deceleration. Hopefully next update might have this in along with more sensible mass values. Edit: Newly Discovered Problem, and perhaps the reason why physics for the landing gear was turned off in the first place, on landing or takeing off with larger aircraft the force on the wheels can be enough to break them. Solution: Turn up the crashTolerance, breakingForce, and breaking Torque. revised and slightly more sensible part.cfg for the smallgearbay

I have actually fixed the problem now. It turns out that the reason for it not counting mass and drag, despite all the properties being present, was on Load it was told to discount any sort of physical presence of the landing gear, Intentionally. One rogue line of code was all it took to cause all this. Bright side, I can fix the problem easily with a small plugin, bad news, you'll need to alter the landing gears cfg with a couple extra lines so it uses the fix, not perfectly ideal really. The attached plugin is the fixed class for landing gear. You'll need to go into the part cfg for small landing gear and change: MODULE { name = ModuleLandingGear } to MODULE { name = ModuleLandingGearFix stowedDragMin = 0.1 stowedDragMax = 0.1 deployedDragMin = 0.7 deployedDragMax = 0.7 } and then install the plugin. That should give landing gear drag and weight as needed. The only thing of note is that the mass of landing gear is 0.5 Tons, which is a lot, but that's not the problem I'm trying to solve. Feel free to edit the cfg and reduce that if you so wish. It's made a lot of my planes suddenly very heavy. plugin: http://www./download/oxzjx5uydph8f4c/ModuleLandingGearFix.dll Source: http://www./view/3re8r5ncdb49npa/ModuleLandingGearFix.cs

if its a slow gradual pitch up I find its caused by the SAS not following the curve of the planet. if its a more sudden pitch up it could be something to do with fuel weight changing as the flight progresses. Multiple tanks draining in odd orders can shift the CoM , past the CoL and cause odd behaviour not present in the flight earlier. By reducing speed you reduce lift on the wings and hence reduce the moment which may explain your phenomenon

I've found on some cases that a fractional downward angle of attack on a wing can cause lift down into the runway. It may not even be noticeable but a fix is to angle the wings back slightly. You get the most lift from a wing at 25 degrees to its velocity vector however just tilting it back 5 degrees I find is enough to fix the sticky runway problem. When you fall off the runway at the end, you pitch up in the fractional drop and thats usually enough to generate the lift needed on the wings, so if that matches your behaviour then your wings are generating lift into the runway.

Strangely enough, I think I may have narrowed in on the exact cause of this little bug, so if any kerbal developers are watching please take a look at this. The parts class, which almost all part use as base module either directly or as an extension module, uses a rigidbody property to set things like mass and drag and pass it on to the unity physics engine, however, for reasons beyond my understanding the parts module has a "Rigidbody" property in addition to the "rigidbody" property defined its its base class, namely the unity component class. For all parts these two distinct properties are in sync, ie the same, however for the landing gear they are out of sync, specifically the inherited component property "rigidbody" is null, meaning the Part class has had to instantiate a new Rigidbody for its own use, and obviously this is not good. when they are in sync they're fine, however quite a few of the calculations, namely mass and drag, rely on this object, which is null. The precise reasons for this being null on the landing gear is as of yet unknown to me as my debugging of the kerbal source is very limited, but I'm sure this may be of some interest to any developer working on the problem.