Snjo

When you DO unlock the VTOL engines, you could change the fuel they use to the same setup as the electric propellers in the config file...

That's what the VTOL engines are for. The other propellers don't support the advanced steering modes. It may work. There were two critical fixes made to stay compatible when 0.23.5 rolled out, but none of those pieces of code actually run in any parts used. (So critical in the sense of, they would break the game IF they had been in use)

Was able to login normally, maybe your username field is case sensitive?

I wasn't able to log in, the site claims I use the wrong password, even though it was saved in Lastpass (tried email address and username), and the Password Reset page throws a 500.

Try this dll, and see if there is less bounce: Download

If the floats go from high float force to being airborne, and then go back down, it will create an oscillation like that, which is a common problem in hover code or float code. The floats have a range of one meter where they go from no float power to full float power, so they should be able to find a resting spot, but it may be that you have too much floating power for it to come to rest, in which case some floating sections will be technically airborne at times. That isn't stable. Try tweaking the floating power one the float to a lower value and see if it helps. Of course there is also the issue of the floats consisting of several parts which can flex and make the amount of float they provide unstable. That can't be fixed in a multi-section float, or even a single rigid body with multiple float points, causing a bobbing that looks too quick to be from imaginary waves. This also happens in nature, but due to other factors, like water/air drag, it quickly goes away. That stuff ins't modelled as well here, and the precisions available is low. I'll try to increase the precision from floats to doubles to see if that helps (since I am looking at the distance to the planet core)

You forgot the trailing slash in the texture root folder

Why do you have all those question marks in "B9?Mk1?Tail?R"? Also, try the other object names too in order. Add the line debugMode = true, and you will see additional messages in the log about what's happening, and any stuff the module is unhappy with as it does its start routine and switching.

I know how now, so yes It'a a tag in the unity setup called Icon_Hidden

You add it in the part.cfg, as shown in the docs linked in my previous post. It supports all the textures KSP can load, like tga, png etc.

If you didn't make the model yourself, and therefore don't know the name of the meshes that hold the textures, you can turn on showListButton = true Then, if you right click the part, you can click a button that will spit out the names of all objects inside the model to the error log. One of those is the one you want. If you want to do fewer restarts of the game, and use more up to date code, you might want to use FStextureSwitch2 instead, which is also explained in the docs

Nonono, don't resist. Go big, or go home!

This is why there are three axis AND an altitude: Kerbin is round. The coordinate system is not. This means any objects coordinate is seen as a position in a 3D cube system. In the image above, Y is not UP for the player, it's the direction from the south to the north pole. X and Z is similarly meaningless as long/lat. at the equator, in the western hemisphere, +X may be skywards. at the south pole, -Y is skywards. This should also tell you why moving an object along a single axis, it both moves left, AND a bit up for instance. So that explains the three numbers, what about the altitude number? It's simply a helper. If you have the prop in the correct position, it just moves the object closer to or further away from the planet core for you so you can stop thinking in three crazy dimensions. Now there are ways to use actual Long/Lat instead, but that's obviously not what we are doing in this case.

Until you do, you might want to edit the OP, because a lot of people are confused about the current state, and try to download the old files.

Oh right! I actually commented out an input option that uses pgup/pgdn and some other stuff for fine control. Maybe I should put those back in. Just have to make the key option toggle better.

-Autogyros: Tricky how? How are you building it, and what is wrong? (Assuming you are thinking of gyrocopters, and not auto rotation landing, which should work, although I had to nerf it a lot to avoid upside down super speed) -Maybe I forgot the action groups, will have to check. Thanks! -The electric folding rotor is using a different code right now, the same as the propeller engines in fact, so there's still some work to do on those. I used them to test FScoolant-less electrics. BTW: Some electric engines may still be on the old system, not sure. -Assuming you are thinking of the gas driven heli rotor, the lift is produced by the lift capacity of the blades, so when you throw it to full collective, it will do all it can right away. If it has less power to do that, it will also have less power to fly around, and to recover from a dive. I have never piloted a helicopter in real life, but I assume you CAN take off very fast, but it's probably not wise. If you make your helicopter rotor less powerful, you will struggle to even get off the ground, so if you want it to look real, you gotta both tweak the engine, and mind the collective. On the other hand, if you were thinking of the electric rotor taking off to fast, then yes, it's not doing blade math at all yet.

The running sound is just here to emulate stock engine sounds, where the jet engines have a low whine that is not tied to thrust or throttle. If the engine is on, that sound is on. I've never even used it myself. If it had been tied to throttle, it would just have been the same as the power sound. If you want to be sure of what fields are valid in any part module, there is only one way to do that: Check the source. You don't need to understand the code further down, but check the KSPFIELDs at the top of any source file, and you will see all values that can be listed in the cfg (with the exception of nodes, which are different). Look at the engine sound source for instance. You will also see other variables which don't have KSPFIELD above them. Those are not exposed to the cfg, because it would probably break some stuff, or make no sense. edit: In general, if I have documented a module, all the possible values are listed. A few KSPFIELDS might be absent, but in those cases, it's just because they are there for save persistence, not for putting in the cfg. And if you are missing docs for a module, just let me know, and I will add it.

This must be an error with PartCatalog's parsing, not something I can solve. The field MapNames (with a capital M) probably is not an FS field. There happens to be a "mapNames", but that's different. I would report it in the PartCatalog thread. The values are explained in the docs. No idea what happened to your delay. I agree with you plan for settings the fade ins and outs. Would probably make it look like this: power = idleSound, 0.0, 0.25, 0.0, 0.1; normalPowerSound, 0.25, 0.9, 0.2, 0.05; afterburnerSound, 0.9, 1.0, 0.05, 0.0; etc, etc. where the values are: sound_effect_name, lowThreshold, highThreshold, fadeIn, fadeOut

Yes, I suppose that is possible. Right now it has a fixed mulitplier, but I could expose that probably. It does look a bit odd when you scale it too much that direction, because it's non-uniform in the width/height, so for some models you get ovals instead of round parts. In case you haven't tried it in the later versions of the dll, all the different sounds are now implemented, like shutdown, flameout and running. They were dead for a long time. The power sounds would need to transition between them in some way, question is if it should be based on time or current thrust. -If it's time based, when one sound ends and another begins, the ramp up and down at a set speed. So when you go from 60% to 60.1% thrust, it spins the old sound down for half a second. You will never hear both sounds at the same time for long -If it's thrust based, sound1 is volume 100 at 55% thrust and goes down to volume 0 at 60% thrust. Sound2 is volume 0 at 55%, and volume 100 at 60%. This means, if you rest your engine at 57%, you will always be in the mix zone. I prefer method 1 in most cases, but method2 is better for cases where the thrust fluctuates due to efficiency curves etc.

I forgot I turned off dropbox syncinc Should be OK now. Yeah, I'll try to remember the file name with version in the future.

New pre-release version Download v7.0.PRE2 -Some parts moved to the Firespitter Legacy Parts Pack. Download that to keep using existing craft files. Other parts have had major changes but have the same name. -Tweakable engines! Adjust the number of propeller blades, their length, and the engine size in the hangar! -Updated helicopter engine and tail rotors/fenestrons using aerodynamic blade lift, and a much improved hover code. -Modular fuel tanks. A single part with alternate texutres and fuel tanks. Toggle through the choices in the hangar. (oblong multi-tank and fuel drop tank) -Wheel alignment guides end the scourge of crooked gear placement. Press F2 to toggle guide lines. -New tail boom model added to the old tail boom (Switch model in hangar) (WIP, untextured) -A new engine module that supports atmospheric engines much better, separates engine start up time from throttle response, and allows for electric engines without the extra FScoolant resource. -Apache cockpit monitors are off by default to reduce lag. Click a button to turn them on. -Helicopter engines display a guide arrow to assist in putting them on the right way. -New texture switch, mesh switch and fuel tank switch modules allows for many varieties in a single part -Added optional Part Catalog icon from Kwirkilee -Added visual brake response to flight control pedals -Various bug fixes Apache craft file

Uhm... nope! I like to have full control of which part have which texture. I don't want them all from the same set all the time. Having this as the default would make that a pain. Not having it as default would make it just as hard to do per vessel as the current way. It's simply not worth it. Also, it's mindbogglingly complex to integrate into all of the other handling stuff that's keeping this thing from crashing

While I'm sure it's quite possible, there are too many variables in play, like folders with combinations of diffuse and normal maps, number or order of files changing, etc. that I'd rather keep it as hard references. You are of course free to modify the code for your own purposes.

That slider is from another mod. The hovercraft engine may or may not work, haven't tried it in a year, and it was never completed.

What's the balance slider? The hover skirt is in here