Taverius

Well, that depends. MechJeb2 will manage your engines if you let it and let you use air all the way to up the edge of the atmosphere by managing throttle, which is how it managed to bring you up to AP 80 all on its own. You can easily do that with the F119 engines which max out at mach 2.8, let alone with the SABREs air mode which goes to mach 5.6+ Which ... is a cheat, really, much as intake abuse is, but if you level off at 23k and max out your speed and then climb again with MJ managing your throttle you can put your Ap at 180k that way, without any intake abuse.

The fuel gauge should be easily fixable. I can't replicate the air bar appearing on ship switch.

The texture line is not necessary, as you can see from the fact that you're overriding model000 with The flow values in the panel are incorrect. Whenever you use unitScalar anything in an intake's right-click ui becomes useless. Both area and unitScalar in those intakes have been multiplied/divided by the same number, which is the mass of the part divided by 0.01. This is because intake drag is also multiplied by mass, and so if you want a part that does not weigh 0.01 to have an intake, you must set its intake size to you desired values, and then divide the size by the part's mass / 0.01, and multiply unitScalar by the part's mass / 0.01. In the case of the ramp intakes, the mass of the parts is 0.4, thus the ratio is 40. area 0.01 / 40 = 0.00025. unitScalar 0.2(the default) * 40 = 8. Thus you can have an intake that does not mass 0.01 while still providing the 'correct' amount of drag per intake area. The downside, as I said, if that the drag and flow values shown in the UI panel are useless. Not that they ever were particularly informative. P.S. This is also why the default AirScoop does 10x as much drag as it should. It weighs 0.1 instead of 0.01, and uses no unitScalar trickery. Now, as to why all this would result in too much drag in FAR, I do not know, but I do know this: Its not an issue with the B9 intakes. Its an issue with FAR. If you actually want it fixed, tell ferram4 about it, because if you just add a 0 to the intake area, you know have intake that's 1/10th the size it should be.

Something is up with your installation. B9 3.0 takes less time to load than the stock parts. Please check that you have the correct KSP version, installed correctly, etc. If you have a 32-bit machine, sorry, you're out of luck. We reduced the memory load of B9 from 1.8Gb to under 800Mb, but if you're running under a 2GB per-process limit there's no way you're going to load this, or any other large packs. I'm not sure what's going on for you. Either you simply do not enough ram to run B9 (we optimized as much as possible but it is still a LOT of parts), you did not follow the installation instructions, or you're not using 0.20.2. We're using it everywhere. Have you noticed how many things can be toggles in VAB? However, you can't get around a KSP limitation with 2 animations affecting the same GameObject. I'll have a talk with ferram about it, to check if there's any other things which need a special name as well. You did not follow the installation instructions. Please follow the installation instructions. They are there for a reason.

Works fine here in GameData/, at any rate.

That's awesome. That will also break any and all mods using 0.20+ database system features. At the cost of sounding like a broken record, allow me to repeat myself: Your organizing system is not compatible with the more advanced features of the KSP mod system. Changing the paths of the files breaks the reference in the configs. You can either: a) abandon it, and install mods where you were told to install them after being told they would break if you did not. change all the paths on every update.

All model, config, texture and sound references in the new system are absolute. Doing what you do breaks B9 right now, and will break even more mods in the future as people start using the new features to save memory and disk space. In other words: Sorry, but you're going to have to deal with installing mods where the creator said they should go, rather than where you want. Squad stuff should be where Squad wanted it, B9 where we want it, and so on. Or, deal with stuff not working. Feel free to go into every .cfg file of every mod which will use a reference to a sound, other config, model or texture and change every single path, on every update.

The SABREs are very heavy for the mount of thrust they give, so I'm fairly sure they're not I'm not sure the small podded fans are being very useful there, seeing as they completely stop providing thrust at around 300m/s. We weren't joking when we said they're subsonic. I'm not sure what you mean? I only really balanced against stock, not KW, looking at them now against KW and considering the mass of the engines as well as their thrust and Isp they don't seem particularly out of line.

Probably MM doesn't know about MODEL {} nodes.

Heh. I told bac9 with 175 parts I was certain there would be a part bug. I am ambivalent about being proved right Fix should be out soon.

It is, but you'll have to ask Snjo about it - he does it for firespitter, and might be able to tell you how to do it without plugin code

That usually happens when there's 2 parts with the same part.name.

We appreciate your enthusiasm, but please don't anger the moderators

That's because the extras for KSPX included in Pizza are the same as the file KasperVLD linked in the OP

Working nice Fel, though I did notice that the global rate = does nothing

Bug reports aren't very helpful without crafts ...

You might have not installed right, or maybe you're using the ModuleManager version of FAR? I'm not sure what happens if you do that, since I setup the rescales of the default parts in the same file as the originals. I never did have small aerospikes, though I can see why they might be useful. I'll add them for the next version.

There are 2 meshes (one for normal, one for the collider but not set as a collider) attached to 2 bones, Tip and Root. When the wing is changed, new positions/scales are applied to the bones, a SkinnedMeshRenderer on the invisible mesh-to-be-collider bakes a copy of itself into a new Mesh, and then the actual collider is pointed to this new mesh. The collider stuff might sound a little convoluted, but you cannot scale or transform a collider mesh once its been set as a collider, so this is the only way you can have a collider that moves that is not a parametric collider like a unity box collider.

Me too. I remember the old way, and while it might have been more intuitive this works better.

Sure, you just need to use a 1.25m or other part with a stack node first at the wing end, and then attach the engine to that. careo (who developed the gimbal plugin) was doing just that, on a plane with no other control surfaces. Small problem is he kept crashing when he throttled down to land because then he had no control

That's kind of why I'd like to use it. Currently the B9 3.0 VTOL-RCS uses air and electricity to make B9CompressedAir, and that works fine, but the generator must be manually turned on (most convenient is to attach it to the RCS special action group) and its always drawing IntakeAir and ElectricCharge even when its tank is full. Fel, the resource is flowMode = NO_FLOW and transfer = NONE, density 0.01, and there's a small (0.1) size tank in each RCS port along with the generator.

If you have parts that share a model or texture but not the other, you can use model nodes: MODEL { model = Squad/Parts/Command/landerCabinSmall/model texture = model000, Squad/Parts/Command/mk1pod/model000 texture = model001, Squad/Parts/Command/probeStackSmall/model001 parent = myTransformName position = 0.1, 3.0, 5.0 scale = 2.0, 2.0, 2.0 rotation = 0, 60, 225 } For example, B9 has many variants of tanks (structural, LF, LFO) which share a texture map with slightly different models. We give the models different names (Structural.mu, LFO.mu) in the directory of the part type, then in the part.cfgs we do: MODEL { model = Path/to/model/file/<model name> } This is because the mesh line ignores the contents if there's any .mu models in the directory and just loads the first model it finds. Or, if you have parts with the same model and different textures: MODEL { model = Path/to/model/file/<model name> texture = <original texture name>, Path/to/new/texture/<texture name> } This is obviously less economical in terms of memory usage than sharing a texture, but it still means instantiating only one copy of the geometry for n different parts with different textures Things to keep in mind, when using model nodes: all file-names are without the extensions paths are always absolute starting from inside Gamedata, as you can see in the new debug menu. the texture name in the first part of the texture line is the original name of the texture the .mu refers to. With part tools of version 0.18 or earlier, this is always model000, model001. When 0.20 comes out this can be other than model<index>, which can trip you if you're trying to save memory and disk space by sharing textures. If in doubt you can see it by opening the .mu with a hex editor and looking at the end of the file. the texture you want to override must exist. if it doesn't exist when the model loads, you cannot override it with another later. Using such trickery we got B9 3.0, which was 160 megabytes of PNG(!), down to 95Mb. Optimizing the PNGs got us down to 77Mb on-disk, and that's with 173 parts. You can also use model nodes to make parts made of multiple models using the full node syntax, though this is of little interest generally to original part makers

You still have to load everything once when you load the game.

I cannot see the problem here ;D Since we're asking for the moon, does FAR do any accounting for ground effect? I wanna make an Ekranoplane

Swap doesn't matter, your amount of RAM (if over 4GB) doesn't matter, your bus width doesn't matter, your specs (really) don't matter. KSP is a 32-bit application, and when you go over the process limit for your machine, it crashes. End of. Loading PNG textures in 0.20.1 takes way more memory than it should. You're not getting crashes because a) B9 2.5 is a lot smaller than 3.0 and there's only 2 large mods using png textures, B9 and Firespitter. Its not that load png under 0.20.1 -> crash, its that load png under 0.20.1 -> png textures take 3-4x as much memory as they should. Its possible to load 2-5 under 0.20.1, but not 3.0 AND do anything, because you will be well over 3gb just at the loading screen, and that's before you load the flight scene and a craft into it. With enough mods, its possible to crash while loading in 0.20.1, just because of that. x32 was never an issue because you'd hit the 2GB process limit just loading base KSP and B9 2.5. Anyway, this is all a non-discussion. The issue is confirmed, Squad is working on it, and 0.20.2 is on the way Soon; with a a few other fixes too, I bet.