Snjo

I was wondering about that myself. The sub nodes sound like the absolute best solution. It would take all the guesswork and hackiness out of modules. And we want modules! In my mind, the thing that will make Kerbtown truly meaningful, aside from awesome scenery, is interactive (or just active) stuff on the ground. If it could use fields the same way as parts do, it would be awesome. So a [KTField] will be saved and loaded into a StaticModule/MonoBehavior automatically.

The creation change explains why I had to move my OnStart code for the fuel pumps from the flight scene to ... unrestricted. Interesting! The idea with persistence is that there's a module loaded onto the static, but there is no set of persistent values saved to the instance of that static/pump in the world. Either each static should have a unique identifier, much like the runways can have a name, so that that can be read by a module which handles its own data files, or it the static reference in the cfg should be able to store a new node inside itself for custom values. It doesn't take much, but Raz never got around to it, as far as I know. My idea involved extending something other than MonoBehavior in order to fetch values. He did a partial job on that, but something didn't work there for me. So for instance GasPump extends StaticModule, which in turn is extending MonoBehavior. StaticModule lists values for world position, unique ID, persistent values etc. These are saved in the cfg file.

It's currently infinite. Could be made limited. It wasn't previously possible because I was waiting for Raz to implement persistent values to KT, but since that won't happen, I'll just have to implement it in some other way, writing to some text files. Assuming of course I can read out what separates one fuel pump from the next. (Otherwise they would all share the same pool) Hopefully they all have some unique identifier. Or maybe I can read the lat/long. edit: Yeah, they are crazy! He styled them so they would match the FS biplanes too

Now that Kerbtown hath risen, You might be interested in the small runway, fuel pump and whale skeleton I made back in the day. Updated them to work with the new version. https://dl.dropboxusercontent.com/u/22972712/FShousingProgram.zip Can't find a good image of the runway on file, but it's in the background here.

The easiest and sturdiest way to do it is to have pre placed transforms in the skirt part, one for each corner for instance. You can see in the buoyancy code how it looks at a specific transform an applies force there. The trick is that there are four of these modules defined in for instance a boat hull. (Or a single point in something like the seaplane floats, cause they are added in multiples). Each of these check the height of their assigned transform and applies force to the central rigidbody at that point. It's a pretty stable system. In case ov hovercraft you just need to substitute altitude above the planet core for raycasting.

He says coyly, not divulging the juicy details.

It's a 15 minute hack job, and I know you can do better, but sure! Part + Project: https://dl.dropboxusercontent.com/u/22972712/ksp%20forum/FShoverEngine.zip edit: The FSbuoyancy code is probably a better starting point for a new piece of code, as it handles multi point float etc

The issue isn't getting it off the ground, it's predicting a rise in the landscape and avoiding it in time when you are doing 50m/s straight forward. If the rise is 10m ahead, that gives the engines 1/5th of a second to react in time and push you up. In real life you could just vrush against the ground, but in KSP it would cause a collision with either destruction, a nasty bounce or a flip. If you are flying higher you of course have more time to react, but it looks less fun. Basically, you need something that has a shock absorption system like wheels, repulsing you when needed, but nice and floaty, and without the sideways friction. If I knew how the wheel colliders (or any collider) keep you off the ground, I would be able to work something out, but I have no idea.

I'm fuzzy on the details, but yeah, there was this thing: It worked OK as long as you didn't try to go up hill at high speed, cause it would ram into the ground, and it needed to be hovering a bit higher than looked good to avoid terrain collisions... If you have good ideas for keeping it JUST off the ground, I'm all ears.

No, there's still some minor geometry work to do. After that I'll throw it in there using the default engine code, but the final version will need a better piece of code to respond properly. Also, Dirt Merchant was all excited about finding some sweet sounds, so I'm looking forward to that.

The nose cones and adapters are in the pre-release, now listed in github releases

Making a rear exhaust port that didn't look like ass, carving out a round hole from the mesh was not going well at all, until I saw the picture here, which I think looks awesome, and is also a lot easier to model. There's something Portal/Star Warsy about it.

First, try only one object at a time, restarting the game for each attempt (annoying but necessary). An incorrect object will throw an error, stopping a correct object later in the list from getting the tex swap.

Working on a turboprop

The code I saw you had posted did not seem to include anything that told me there was a common system up and running. I only read the first and last few pages though... edit: I re-read the code I had just glanced at previously and saw that it does handle multiple mods running the same piece of code, so I'll try to use your code.

There aren't any known incompatabilities, but that's mostly because it hasn't been tested for that. As I've said before, this is not using an elegant method for moving vessels, it's held together using duct tape and bobby pins. Other than increasing the time even further if your game is super slow to load the flight scene, I don't have any good ideas I'm afraid. I may improve upon the module later based on some awesome research done by HoneyFox for Kerbtown, but right now it's a nice bonus if it does work, and not much I can do when it doesn't. As always, try just KSP + FS and see if the issue persists. If not, re add mods until the bleeding stops or the patient expires. Use of mod may cause nullreference ear drums, involuntary bow movement, loss of mission, or spontaneous combobulation. Dividing by zero when operating propulsion devices may cause Krakenitis. Do not operate heavy machinery within 48 hours of self medicating. Consult your physicist before taking FlamSputex.

Just found this thread, I think the warning is a good idea. Just implemented the simplest version of it myself, just giving a warning, but not disabling stuff, since I seldom see game breaking bugs due to the nature of my part modules. Their version errors are usually only constrained to themselves.

InfiniteDice, I found a bug you might want to fix. In IDskillfulIFF.cs Source

Finally did the simple job of creating some rounded nose pieces. One short and one three times longer. If I can focus, I will try to knock out some more pieces from the ol' wishlist. And cause I know PolecatEZ is doing some pretty cool retexturing, I am including the UV guides with the parts.

Never knew this existed. Awesome work! edit: Cause I'm lazy I'll have to get back to work

New version, v6.2 for the new ARM KSP version -Landing gear tires bump, screech and smoke when touching down, and have rolling and retract sounds. -Overhauled the Water launch system. Save your current position to re-use in new vessels. Launch anywhere on Kerbin! More reliable coordinate saving. -Scaled f-86 wing lift back to 72%, which should be around the realistic lift amount (still more than stock lift) -Subtle braking sound. -Fixed some old tail gear scaling and floating point error rendering issues (Scale has changed a little bit) -Support for part effects (sounds etc) in the animation module. There may be some rough edges that I have forgotten about. If you notice any weirdness in new features, or bugs in general, let me know.

The replay dummy model assembly assumes that there is a mu file for each part, in its folder. if it is using some fancy system, or if anythin else goes wrong in the assembly process, it throws an error, defaulting back to the old sphere. There can be a million things that go wrong, but because there is no way I know of to retrieve the information necessary to perform a better, smarter assembly from unknown parts, I doubt it's an easy fix.

Oh, so 0.23.5 is out! Time to get to work! I'll be debugging the code in the new version and throwing out one that has the features that were already complete in the pre-release. Not sure what is going on with out of control spin in your case, but I have observed that in 0.23, due to some change in the way resources are handled, you can run an engine on a single resource in some rare cases. An electric engine would keep running while it was out of power as long as it had "air" coming in. edit: the issue where spin speed is detached from lift, and you take off very soon is due to the fact that you can't separate engine rev up speed from the throttle/fake collective in stock engines. I'm working on that in a new module, using actual blade lift based on rotor speed. I've added spin direction controls for the future helicopter engines, so when I extend that to other engines, it should follow along with that, if I choose to use that module for those engines Turboprops have been suggested many times. To be clear, are you thinking of a design that hangs out from the wing or fuselage, much like the VTOL? Any examples you're all imagining when suggesting stuff is helpful. The pre-release has buoyancy sliders. For the moment they are accessible both in flight and in the hangar if I remember correctly.

Well, that's a new one So you have gravity turned on, right? For fun, try rebuilding the craft, but with a decoupler between the fuselage and the rotor, and see if it acts that way before and after you detach the rotor. Can't think of any reason the rotor would keep spinning unless it is some prototype engine you downloaded separately and forgot to delete...