Kerburettor

Hi, First of all I want to say that I'm a complete newbie when it comes to the inner workings of KSP and its mods. I've got a rudimentary knowledge of C# but I can decode scripts if geven enough time. Also, I haven't found a similar topic that already addresses this topic but if there's already one, I'll be more than glad to append my request to the existing thread and remove this one. Using kOS, I'd like to read aero data for any part of my aircraft (or at the very least parts identified as wings). The kOS-Ferram addon developed by Giulio Dondi helped me get the overall lift and drag of the aircraft via his wrapper that interfaces kOS and FAR. For example, the following command is used to get the value of the vesselLiftCoeff variable defined in FAR: SET lift_coeff TO ADDONS:FAR:CL. However this variable corresponds to the total lift of the aircraft, which I do not need. Is there a means to extract the aerodynamic data for each individual part of a ship? I would like to avoid having to recompile FAR and the kOS-Ferram addon because I simply don't know how to compile these mods (although I'd be more than glad to be walked through the process). But if that's what I need to resort to, here is how I imagine the way forward: Modify the FARAPI.cs code in FAR to extract the lift and drag for any part of the aircraft. Currently, total lift and drag coefficients are extracted thanks to the following static methods in the FAR API: public static double ActiveVesselLiftCoeff() { return VesselLiftCoeff(FlightGlobals.ActiveVessel); } public static double VesselLiftCoeff(Vessel v) { FlightGUI gui = VesselFlightInfo(v); if(gui == null) return 0; else return gui.InfoParameters.liftCoeff; } public static double ActiveVesselDragCoeff() { return VesselDragCoeff(FlightGlobals.ActiveVessel); } public static double VesselDragCoeff(Vessel v) { FlightGUI gui = VesselFlightInfo(v); if(gui == null) return 0; else return gui.InfoParameters.dragCoeff; } I'm still not sure how this could be done but I guess I could loop over all the parts of the current vessel and provided they are a lifting surface, save the liftForce and dragForce attributes of each part in a dictionary (the keys of which correspond to each part of my aircraft) that would be fed to kOS in a lexicon. In the kOS-Ferram addon, add suffixes in the Addon.cs script to extract the lift and drag of an individual part. In the following example, this is the current implementation of suffixes to extract the vessel's total lift/drag coefficients: private void InitializeSuffixes() { AddSuffix(new string[] { "CL", "LIFTCOEF" }, new Suffix<ScalarValue>(GetLiftCoef, "Current vessel's Lift Coefficient.")); AddSuffix(new string[] { "CD", "DRAGCOEF" }, new Suffix<ScalarValue>(GetDragCoef, "Current vessel's Drag Coefficient.")); } and add new entries corresponding to these suffixes, for example: private ScalarValue GetLiftCoef() { if (shared.Vessel != FlightGlobals.ActiveVessel) throw new KOSException("You may only call addons:FAR:LIFTCOEF from the active vessel."); if (Available()) { double? result = FARWrapper.GetFARLiftCoef(); if (result != null) return result; } throw new KOSUnavailableAddonException("LIFTCOEF", "Ferram"); } Add an entry in the FARWrapper.cs wrapper like this one: FARCD = FARAPIType.GetMethod("ActiveVesselDragCoeff"); if (FARCD == null) { SafeHouse.Logger.Log("FARAPI.ActiveVesselDragCoeff method is null."); wrapped = false; return; } which in this example uses the ActiveVesselDragCoeff method from the FAR API. However I'm completely clueless as to what is the best way to proceed. Any help?

Thanks a lot for this very complete answer @DocNappers I'd like to know what I should put inside dist_dir.txt. My guess for 7za_dir.txt, ksp_dir.txt, mono_exe.txt and the such is that they should contain the path of the 7za executable, KSP game path and mono bin respectively, but I don't know what to put in dist_dir... Also, what are PRs? Btw I'm on Windows

Hi, I've got a bit of an amateur question. Do you know how I can build my own version of BDA? Let's say I modify the code, how can I build it for myself to get the adequate dlls? Is there a tutorial I can use for that? Thank you

Could someone tell me if there's a way to replace smokescreen effects used by the B9 props by overriding them with waterfall effects? I'm specifically thinking about replacing the F119's cool but outdated particle trail https://imgur.com/IhTwjrG

Duly noted. I'll apply this procedure should I encounter other crashes

Thanks a lot, your answer may help. I have indeed noticed strange behavior on the behalf of FAR (as in the GUI not displaying any information) but it never dawned on me that it was due to quote characters. I'll test changing the names of these crafts and report back if there's any improvement.

I haven't noticed any notable event that triggers them, but last time it occurred was when I switched to the tracking station from a low münar orbit. Btw I have 32 Gb of RAM and approximately half of it is allocated when I play

Hi, I started encountering frequent crashes since last week after installing and updating a few mods Initially thought this was due to "Kerbal Engineering Redux" so I uninstalled it but the crashes have continued occurring once in a while. Here's the full log of my last session (which ended in a crash at 4:28 PM UTC+1): https://file.io/erBRbCSa9eTq

@Tonas1997 To answer your question on the old thread, I think the best way to proceed is to play with the specular map. As it is, the CRFP mod contains vanilla textures which are quite bright and reflective and as such you do not see the expected shade. What I did is I replaced the specular map by a black image using Gimp to get matte textures.

That's because the issue resolved itself (or at least disappeared) when I uninstalled a few mods and reinstalled some of them. Procedure was faulty, should've tested one mod at a time, but I was in a rush to make this work. Sorry.

Just know that there seems to be a bug. If I use this mod along with Kerbal Foundries 2 (with its dependencies: kerbal wheels & textures unlimited), I cannot customize my CRFP fuel tank anymore.

Hi, I have two rotors on both sides of my aircraft and would like to make them rotate in opposite directions. But they were placed using mirror symmetry, so I can't change the orientation of a rotor independently from its mirror copy. What should I do? The end goal is to achieve hovering flight without creating a net torque about the centroid of my four rotors (there are two at the back in a similar arrangement). It's not a quadcopter since rotors are placed using mirror symmetry, and not central symmetry. I also do not want to remove each blade from symmetry separately. If there is a way to remove one of the rotors (and all the blades attached to it) in one go, I'm all for it. Thanks.

Hi, Whenever I spawn a ship with vessel mover and then go back to my probe (a missile with a missile core, the pilot AI module and a probe core for good measure), I can't control the missile anymore. Is this a documented bug/issue?

I doubt clipping would work in this specific case (except if the only goal is to add mass) because I'm using FAR. Basically FAR approximates the shape of the aircraft using voxels, calculating the resulting lift and drag based on the exposed shape of the geometry, its curvature, etc. Stock geometry assumes that each part has its own performance and as far as I know adds them all up. Sometimes, clipping can be used as an exploit to get more or less drag resulting in some weird contraptions. You don't really get that with FAR. By the way, said voxels seem to be calculated once and for all, regardless of any geometry transformation along the way. This is actually pretty funny because I thought voxels would move with the geometry but it turns out that they stayed where they were, which means that drag should be no different between a retracted vs. a deployed wing setup regarding drag, althought shape shifting moves the CoM forward or backwards, which is rather interesting. I'll show you tomorrow but now is sleeping time.

Okay I think I've got something: It's not perfect but the rear landing gear doesn't bounce off straight off the bat. What worries me is the distance required to stop the aircraft altogether. It takes almost the entire runway for it to come to a still. I have only one option at this point, which is to find a way to decrease stall speed without tinkering too much with the aircraft's design: this is a re-creation so it needs to be esthetically faithful to the original model while keeping sideslip/pitching/yaw stability (which I worked way too much to get).

I'm aware of this ground effect mod, but it didn't exist back in the day, or at least not when Paolo Incarnation devised his adjustable landing gears, so I think he managed to get his smooth landing either with stock aerodynamics or with FAR, or simply because the collision model for these new landing gears was much better than Unity's. I find that placing wheels right beneath the CoM should work best to get the same result, because if the CoM and the contact point between the wheels and the ground aren't vertically aligned with each other, the weight of the aircraft creates torque around the contact point. But if it was that easy, I think I would've achieved the same kind of landing already. One additional difficulty is that my airplanes have a high stall velocity (north of 100 m/s) which means that I'm coming in too fast. This causes quite a lot of stress on the wheels which is not ideal. Also, due to this important stall speed, it is difficult to achieve a vertical velocity close to 1 m/s when approaching the airstrip. And there are many constraints imposed by design such as the position of the CoL which dictates where the CoM has to be for dynamic stability, which in turn dictates where the landing gears should be. Anyway, Imma keep trying until I come close!

I did two other tests. I used the same aircraft as the one I shared on KerbalX for reproductibility reasons (even though one engine flames out which causes the aircraft to veer at the start) but this time tested it using a fully-stock game: I deleted all mods and dependencies in another instance of the game using Ckan. The aircraft wobbles a little bit during the braking phase but manages to travel the entire distance without tumbling sideways. Again, braking is not very powerful when rear landing gears are set to 95% strength and it takes quite a long distance for the plane to come to a stop. I ran the test one last time by increasing braking strength to 100%, and got this: This, to me, shows that there's something wrong about the braking curve for this particular landing gear in KSP. But I can't believe that I'm the first person to notice such a peculiar behavior. There has to be another topic on the exact same problem (i.e. transitioning from 95% to 100% causes wheel lock-up) EDIT: @Caerfinon Thanks for testing! I see that both braking strength and friction are fairly close between the rear and front gears. I usually opt to have wayyyy more friction applied to the rear wheels so as to minimize the risk for sideslip-induced yaw instabilities during takeoff. But this only means I've got to modify the aerodynamics, not the landing gear I also tried setting both spring strength and damping to auto, but this only made the plane bounce a bit more, which is not ideal. I don't really know what to put so whenever I don't want a yaw or roll-unstable craft (or on the verge of instability as I like to put it) to start entering an amplification loop, I increase spring strength and reduce damping a little bit to prevent the springs from bouncing up and down too much, while allowing them to slightly bounce otherwise the mass-spring-damper system becomes too slow and doesn't respond well to sudden accelerations. To me, the holy Grail would be figuring out how to get this to work on nearly any airplane: https://thumbs.gfycat.com/HatefulLankyAmericantoad-mobile.mp4 and not like this: or this: (see landing at the end)

@vv3k70r That's a very insightful answer! I have been using flaps until recently to provide more lift during descent but I've never tested them as a braking apparatus on the runway (after touchdown). What's really been bugging me these past few weeks is that I can't make my aircraft nose up after touching down on the rear landing gears so as to generate more drag in an attempt to significantly dissipate kinetic energy before the front wheels can touch the ground. You know, that's how landing is usually performed in real life. Modelling aerodynamics with FAR is great for such things but it's also a pain in the rear-end to make everything work as intended since I'm trying to recreate fictional planes and they often don't fly so well and don't behave as smoothly as they do with stock aerodynamics. Successfully . Anyway, I thought I would've gotten more braking power from the wheels but apparently I shouldn't expect to. This is great to know and in the meantime I found a few other threads that mention the same issue, such as this one for instance: So yeah, the main takeaway is that I shouldn't rely on landing gears to absorb most of the aircraft velocity.

Haha thanks for this very in-depth performance review but I just wanted to test braking distance which is why I never bothered to make the airplane flyable. This serves as a mockup for three other serious (means flyable) aircraft I'm working on at the moment. My only priority here was to build this testbench so it reaches a velocity of roughly 100 m/s close to the mid section of the runway so I can verify whether or not it manages to stop before the end of the runway. That's what I'm going for. But you're right, the intakes are too small which is not ideal for speed buildup. I was just too lazy to build a better aircraft But what you're telling me about your modified version coming to a stop using only 1/4th of the runway is taking my undivided attention. Mind to share a craft file so I can test it this time?

Sure! Here it is: https://kerbalx.com/Kerburettor/test_braking FAR is listed in the mods required to run this thing but I think you can safely disregard that.

@fourfa I tried what was suggested by both of you, to no avail. Well, it does look like the aircraft doesn't decelerate that much as long as it remains stable, but having a high amount of friction on the front gear causes oversteer even when friction is more pronounced on the rear landing gears:

@Caerfinon : Will test what you suggest. It makes sense that more friction on the front landing gear will help dissipate more energy. Until now, I was a bit reluctant to do so because my aircraft tend to engage in side to side oscillations during take off.

Hi, I'm working on a plane and want to adjust braking strength so it stops before the end of the runway, but not too abruptly since this locks up the rear wheels, tends to cause sideslip which usually ends with a rapid unplanned disassembly. However, I noticed that anything short of 100% braking strength (including 95%) is not sufficient: the plane is stable upon landing but continues to ride along the runway until it just runs out of braking distance. If I suddenly set braking strength to 100% though, the rear wheels lock up instantly and if my speed is roughly south of 80 m/s without any sideslip, all is fine even though the plane and its occupants are a little bit shaken. Otherwise, I end up tumbling and exploding depending on how much the rear landing wheels are separated. Is this a known bug in KSP or is this expected behavior? Is there a way to modify the config files to mitigate this problem? Also I have to let you know that I'm playing a modded game but the only mod that would potentially act on braking strength is tweakScale since the landing gears have been resized. I didn't write this thread in the modding section of the forum though because I assume mods are irrelevant: This also happened on an non-modded aircraft, using only stock parts and resources. Potentially important info: - I use FAR and Kerbal Joint Reinforcement - Friction control is set to 5.0 for the rear wheels and 0.2 for the front landing gear. - braking strength is set to 95% for the rear wheels and 15% for the front wheels (using 55% for the front wheels for instance doesn't seem to improve braking performance). - I use a plethora of mods but I don't think they influence braking behavior since I also had the same issue with unscaled landing gear installed on a lighter and fully-stock spaceplane. Other quality-of-life mods include visual mods such as EVE and Scatterer, others like Physics Range Extender (which is deactivated right now) and lots of parts mods. TL;DR: LY-35 brakes not enough if Brakes < 100% and too much if Brakes >= 100%

How good! I tried to implement something real quick yesterday but got no sound nor fx showing, this will help me heaps! Thanks

Thanks a lot, I wasn't familiar with modules but now I'll dig into them.