Snjo

I know what you mean (I also have made some bad ones). I've been searching my ass off trying to find some Unity examples of lift code, but it seems no one cares about planes. The examples posted are no more than stray thoughts on AoA, and the one good example I've seen is closed source. In the end I had to get the lift equation from the NASA site. If you don't mind a 180 MB file, just look at my project The two pieces of code that matter is the liftSurface and the planeController (for rotating surfaces). The lift surface relies on a placed transform on the wing with z pointing forwards, y up. You should also add some tweak to the control surface range at high speeds to reduce over steer.

Ferram helped me out with some drag issues due to bad lift vector, so now you can actually glide the plane instead of just falling out of the sky when the engine is off. Totally made my day I updated the lift demo and pre-release with the improved code. Still to do is controlling the amount of control input the surfaces will accept at higher speeds, so it doesn't act too crazy, and so I can tune it to do more at lower speeds. And of course the lift info arrows in the hangar.

Great work! I'm pretty sure this will be more efficient than my implementation with all those gameObjects, since code is so much faster to run than rendering. I'll definitely want to use your raster technique to un-lag my monitors! Interesting note about bracket replacement, since you said you are used to archaic programming languages. Since many keyboards had a hard time of making { and [ in the old days, in Turbo Pascal, you could use (* and *) as { and }, and (. and .) as [ and ]. (You only used { or (* for comments)

What's the difference between a pusher prop plane and a puller prop flying backwards anyway? I mean apart from the efficiency of the wing shape. Just need more Angle of Attack. And sure, it's awkward having the ailerons in front of the wing surface, but I bet you it could be done. For adventurous backwards flyers, the pre-release has some alternate wings with the new lift code. Look for the jet wings marked "special aero", or try the example craft F-86 S. I found out the F-86 leading edges auto deploy/retract based on air pressure (slow speeds or high AoA), so now mine do too in this test v5.7 pre-release Download Changes: -New alternate lift code -Alternate "special aero" wings: fighter jet wing, elevator, rudder, and the fighter wing Todo: -Separate air brakes/control surfaces -Updating the lift helper arrow in the hangar. (You will be building blind for now)

Great progress on the wings. As a test, I set up the F-86 wings to use the new code, it now does: Ailerons only respond to roll, ignores pitch/yaw (configurable) Working flaps. They are small lifting surfaces on the inner part of the wing which creates lots of drag if at a steep angle, so they work as air brakes too. The leading edge functionality now actually makes sense. When toggled on, they simply increase the surface area variable of the main lifting surface, so they give more lift and drag. In this wing, the flaps are the plain type, which just rotate. In another wing, you would combine the leading edge fucntionality (but renamed), to extend the flap backwards, and the rotate them. That way you get both increased area and alter the lift vector. When I get a GUI set up, any wing/control surface can be set to respond to roll, pitch, yaw and flap input independent of where they are on the craft, in either the positive or negative direction. (In the hangar) The thing that's missing, and which makes it hard to build with right now is the missing lift indicator arrow in the hangar. Gotta do some math to get that matched up with the stock lift values.

For people interested in the new wing code, here's a playable version of my unity test: http://snjo.net/unity/plane/ Controls: WS: pitch AD: roll QE: yaw F: flappy air brakes Pull the throttle slider up to go fast, or below the starting point to reverse. (engine 2 and 3 are on each wing for testing, 1 is centered)

That new engine code is actually InfiniteDice's work, but we're chatting about it back and forth, so I'm gonna contribute some stuff here and there. I'm not sure what the time frame is, there's a few pieces to fit together. I guess it depends on how much free time we both have, or how boring work gets

I tried this, but couldn't reproduce it on my own machine, but it's possible that it works in the b9 stuff because at that size there are no cracks between the plates, and with no transparency that might mean fewer draw calls. Interesting! I'll have to look into some optimization ideas I have for these things. A simpler shader, and disabling the rear ones unless you turn it on with the green button for instance.

I've been chatting with InfiniteDice about his Internal Combustion Engine stuff, and we are working on some GUI stuff for it so that you can control each engine independently. I'm thinking it would work well as an optional add on that replaces the engines in FS. I've been testing some of that stuff along with some new wing code in Unity: Lots of debug boxes to display active lift amounts The wings use the proper lift calculations, and work well, excpet for some reason the rudder acts oddly in reverse If it survives to conversion to a KSP thing, I can make better flaps, air brakes and independently controlled control surfaces, like some of the FAR stuff. To be clear, the goal is not to replace FAR flight physics, but to be able to do extra features on wings that just can't be done with the stock wing code. IF FAR is present it will detect that and shut itself off.

Considering the exhaust ports have quite a few tris on them relative to their size, and since they are so small, I just used a black end cap. They are however not unique meshes. Each exhaust port in the unity project is a duplicate of the first one, so that's eight gameObjects using a single mesh. But on the other hand, the argument could be made that several gameObjects are worse than a single united one in terms of rendering time. I saw this clearly in the cockpit monitors. Four monitors with a total of almost 1600 separate identical gameObjects, with two tris each, kills the frame rate way, way more than thousands of tris in a single part ever could. Thanks for compliments on the beech! For figuring out the node positions, I just keep the whole part on 0,0,0. I then create an empty gameObject outside the part and place it where I want the attach node. I read the xyz values off it, and input it into the cfg.

You'll see that all my folder names are mismatched with the part names in the cfg. the folder are called FS_something, while the parts are called FSsomething. If you need the correct names, there's no harm in renaming the folders to whatever is listed in the part.cfg.

That looks sweet! Something about it is kind of... Art Deco? I don't know, have a hard time remembering art styles. If you need anything else, let me know, happy to help a beginning modder.

I tried to model in the radiator or air intake hole in the front of the nose cone when I made it, but never got it to look good. And I was making it with a Mustang in mind, which has that big thing on the bottom anyways, so I skipped it. I'll see how I did the geometry in the new engines and see if that would make sense in this case...

There isn't another solution I'm afraid. The whole thing has always been held together with bobby pins and duct tape. Most of the time it works, the rest it doesn't.

Yeah, something like that would make sense. I'd have to have a warning to remove the old parts for the version where I actually renamed or moved stuff around of course so people wouldn't get duplicates. Regardless, it's a good idea for future parts to put themed parts in a separate folder. Now I just have to actually make them

As you can probably tell, texturing is not my passion, but what I have done is make it easy-ish to improve upon them. First, I have all my textures in the png format so that it's easy to create new ones, or add to the existing ones. For most of them there isn't a separate image to show you the UV mapping of the faces, but if you need one, just let me know and I can send you the ones I have in the source folder. The second thing is the texture switcher module, which allows you to have several textures on a part. You can use the standard light skin to go with the other parts, or maybe you want a green military scheme to go with another plane. Using the module, it's no either or, you can have both side by side without creating duplicate parts. (Look at the oblung fuel tank or bomber cockpits for examples. The reason I don't already make duplicates for each part (aside from the work it takes), is that for memory reasons, I can't put two or three textures on every part in the pack, since they will all be loaded, and crash the game for people with several mods. So why don't I just make one set of actually good textures you say? Because I like mine. I like simple flat colours and red stuff, and so do at least a few other people. The solution of course is that I could do an addon pack that would replace or add textures for people who want them, just like there are low res packs for other stuff. If anyone wants to supply some alternate textures for such a thing I will happily bundle them up or allow you to do so yourself. In some cases the parts in question are just very old, and could do with an overhaul (mesh and tex) while maintaining the same style as the other parts. The helicopter rotors for instance are due for some work. On a related note, to save you from part spam and memory issues, I'm thinking of bundling up new parts in separate packs. For instance, I want to create some Lancaster and maybe more Spitfire or bi-plane stuff. I would release each as a complete set instead of adding it to the existing packs. What do you guys think? Is that more of a hassle, or would it actually save you from manually trimming stuff out? (I am never offended when people tell me they delete all except X, it just means you really like X)

Hmmm, blades flying off at high speed, hitting other parts, stuff exploding!

Well, in that case, I'd try moving the other mods out for a test, and do a vanilla+FS test. If that works you can see where the conflict arises when you move the others back in. If vanilla+FS fails, you are doing something out of the ordinary. Make sure both KSP and FS are at the latest version (try the pre-release), and follow the guide or

Either you didn't actually start the engines (usually just press space), or you don't have the plugin installed. There isn't really anything another plugin can do to stop it from spinning its children, short of removing the module by force, or make the whole plugin fail. That would typically produce some red error messages in the alt+f2 log that can be analyzed by sharing your output log file. (KSP_win\KSP_Data\output_log.txt) If you for some reason have duplicates of firespitter.dll, remove the ones not in GameData\Firespitter\Plugins.

That's very weird. It doesn't do that for me. The difference between those part is that the cockpit has no set rescaleFactor so it should default to 1.25, but in your case it looks like something is overriding it to 1.0. Try going into Parts\Command\FS_bomberCockpit\part.cfg and adding the line: rescaleFactor = 1.25

In some cases if the game takes too long to launch your vessel, the move to water code may fail. If that's consistently the case, try to increase the time it attempts to move you by altering the timer value in the cfg file: File: Parts\utility\FS_moveCraftGadget.cfg MODULE { name = FSmoveCraftAtLaunch moveAtLaunch = True launchPosition = -2033.4, -29.9, -3071.4 timer = 4.0 // in seconds } Since it's annoying having to wait for the craft to be released, I can't just throw it to 10, but I might increase it a tad, cause I saw this issue after 0.22 for the first time on my machine, so it might be that the load is sometimes slower now... (It didn't occur on a revert to launch, when the assets were already loaded)

I think I had some problems a while back with the precision of the tail gear, beause the wheelCollider was too small, so I scaled it up a bit, and made the actual visual part almost as big. (wheelColliders are invisible physics objects that do the actual rolling and friction work) I don't remember if it used to be another size, but it might perform badly in some situations if it's too small. If re-scaling works for you, that's good news, but just to be safe, I think I should keep it at the current size. The main thing for me is that it's short, so it makes tail draggers possible, or other places where the stock gear is too long. Now the bi-plane gears were originally made as a joke, end then tweaked a bit to actually work, so I admit I didn't put a lot of though into their size. If you guys have any feedback on it, it's very welcome. (Not just visually, but for what kinds of plane setups you can build, or can't with its current configuration) It does spawn into the hangar at an odd angle, but I don't think I can do anything about that. It was the only way I could get it to perform correctly in symmetry.

I haven't tested your mod yet, but I saw in your wishlist you wanted to do terrain height hover. I've done that for my hover code here, using raycast and pqsAltitude: https://github.com/snjo/Firespitter/blob/master/Firespitter/engine/FShoverThrottle.cs And some other non terrain hover code here: https://github.com/snjo/Firespitter/blob/master/Firespitter/engine/FScopterThrottle.cs Hope that can help you edit: Oh, and if you want an example of multi point hover code in a single part, I do that in my buoyancy code: https://github.com/snjo/Firespitter/blob/master/Firespitter/water/FSbuoyancy.cs

I've been looking over the code to find the launch bug, but I can't see anything obvious. I had a similar issue with the FS water launch module (which is similar to the ID boat launch module), so I hoped it was related. It seems Raz went a very different way to get the launches done (A better one as it happens). As it stands, we'll probably have to wait for him to fix that piece of code. In the mean time, Extraplanetary Launchpads could serve you well. If you have other bugs, these two recompiled dll files may solve it: Kerbtown.dll KerbtownExtension.dll (But keep you old ones handy, cause it may also break stuff. Exciting times!)

It's in the pre-release file as always