Ruedii

If you want to help, you should head over to the Github page and take a look at the code. Yes, ideally the base price and weight should both be based on surface area multiplied by wall thickness. KSP already handles fuel price for you so volume doesn't need to be in the equation.

Could you add an updated version of the B9-Aerospace Mk1 parts? (1.25m round space plane parts matching the Mk2 parts)

Well, if you want something more in between you can always use something between 1x and 10x. I might go and try either 2x or 3x. Is there a way you can scale down aerodynamic failures. I'm already getting them a lot at 1x, and I hate to imagine what 2x or 3x might do. BTW, if you like the stock overpowered air-breathers, you can remove the segments on them. I recommend leaving the more realistic warm up and spin-down times as well as the better velocity curves, even if you remove the reduced thrust. Just remember, normal jet engines aren't normally run at full throttle any time other than take off. In fact, I was considering an alternate realistic limitation that would make them overheat after a few minutes at full throttle. (Ferram4 is free to try out this realism method if he wants to.)

Considering you are using the same license as B9 Aerospace, you could include an updated version of B9-Interim while you are at it. (Go ahead and include module manager files to put a temporary balance on costs for 0.24.x as well.) If you start using github from your project, you can create a reference to auto-pull the latest B9-Interim tree for your packages.

How's it coming along making a cost-balanced upgrade for SXT. BTW, if you put it up on GitHub, I'll gladly help fill in the descriptions (so long as you don't mind that I have a sense of humor a bit like the KSP Devs.) I presume you want to cost-balance things yourself.

Could we get a 3.75m SAS unit to go with this too?

I added a feature request on the issue page for the addition of contracts for SCANsat. I'm thinking I might add a request for integration with KSP's new integrated toolbar, but I figured it wasn't a high enough priority.

Is this mod compatable with FAR. I've noticed a lot of mods that utilize drag information aren't. This could be the reason for some other people's problems.

Any chance of a 0.24.2 update?

Simply find contracts you want and do them. By your ambition, it looks like "3 star" contracts with massive reputation should be your terms at this point. Turn down everything else.

One thing I was thinking, while you are rebalancing the parts for 0.24, maybe you should go and redesign your realistic rebalanced curves for the stock jet engines. I personally think the stock turbojet should be a "simple turbojet" (as in having a simple non-compound compressor, a simple non-compound output turbine, no gearing between the output turbine and the compressor turbine (just blade design differences) and no exhaust port shaping (only a simple gimble shroud over the back of the exhaust port.) The only advantage of this is that it's cheaper, lighter, and you get it earlier in the tech tree. This sort of very simple engine is like early jet engines, hence it's early place on the tech tree. It would have a rather limited "ideal" operating range in both altitude and airspeed. It would also consume significantly more fuel than it's counterpart. As of the stock turbofan, it should be given the behavior curve a "hybrid low-bypass high-compression turbofan" with a two-stage gearboxed compressor behind the turbofan compressor, a bypass port variable geometry and deactivation system for the turbofan and an adjustable-geometry output vent. This of course means much higher efficiency and more consistent thrust at all ranges and altitudes, at the cost of slower changes in speed, increased weight and increased cost. Efficiency should still cut-out pretty rapidly shortly above supersonic speed, but it should continue to function well into the hypersonic speeds. The same should happen at higher altitudes or any other time there is a shortage of intake air. (Reduction in intake air should cause it to change modes and divert it's bypass air to intake air.) To do this with 100% accuracy, you would have to create pair of resource called "Engine torque" and "compressed air." There would technically be two engines inside the engine, plus one added conversion part. One engine burns fuel and compressed air while generating torque and thrust, while the other just uses compressed to generate thrust, then there is an added conversion part that converts torque and intake air into compressed air. Torque cannot be moved and cannot be stored. Compressed air can be moved and stored, but the unit has minimal storage, and consumes far more than can be stored. It may be possible to even rig it so that you can limit the rate that it can be transfered to prevent the use of it for large engines, but allow it to be used for other usages if moved around.

Just curious, does this also have a lower performance impact than FAR?

Love the plugin. Could you get some pics up on the first post.

I know they are still functional in 0.24, but is their cost balancing already correct. (They should cost about the same as the stock lights.)

It depends on the turboprop type if they can theoretically exceed Mach 1. If impeller blades are used (that rely on the compression on the back side of the blade, making it essentially an non-shrouded turbofan,) then a turboprop can exceed mach-1, but not by much. However, in the real world you could never get that much power out of anything short of a high-compression low-bypass turbofan. Of course, if a pure-propeller type is used, which relies on lift on the front of the blade, theoretically it should not be able to exceed Mach 1 no matter how fast you turn it, and will hit it's limit shortly below Mach-1. The vast majority of turbo-props are hybrid props that utilize both lifting and impeller principals, because the lifting principals provide the highest efficiency at low speeds and altitudes, but the impeller principal does the same at higher speeds and altitudes. Of course, it may also be simply an issue with the parts.

I ran into a bug in the latest version on Linux. It seems the keypad no longer works for inputing numbers. The type-through bug in Linux (upstream in Unity, but there may be a workaround) is also still present. Also, is there a way we could get integration with the Integrated Plugin API toolbar as well as Blitzy's Toolbar Plugin. (No rush!) I'll check if each of these are in the Github bug-tracker yet, if not I'll submit them. I just thought I'd submit them here so people know these bugs exist for other users. :D/

For temporary compatibility between DebRefund and RealChutes on my system, I will be simply removing the modulemanager files to make the stock chutes realchute-based. That way I can use the stock chutes, compatible with DebRefund on my discard stages and use RealChutes on my main module. I thought I'd tell everyone the genius little hack while I was at it so they could use the two mods together. I also mentioned this in the RealChute thread.

For temporary compatibility with DebRefund, I will be simply removing the modulemanager files to make the stock chutes realchute-based. That way I can use the stock chutes, compatible with DebRefund on my discard stages and use RealChutes on my main module. I thought I'd tell everyone the genius little hack while I was at it so they could use the two mods together. I'll also mention this on the DebRefund thread.

While I think getting your name, nickname or handle placed in the name generator's bank is a pretty good prize, they could add in the names on the credits as "community contributors." It's not really that big a deal, I see it as a "nice thing to do" on Squad's part, not an obligation.

The DLL simply needs to be recompiled, to support both 64bit and 0.24 If someone wants to, they can fetch the code from github and grab the appropriate tools. I'd do it myself, but setting up those tools under Wine is not exactly the easiest thing in the world (and I'm enjoying KSP 0.24 too much!)

Anyone test if there are any needed changes needed to get this working in 0.24?

Anyone tested this on 0.24? It worked on 0.23.5 without any changes? However, it may need price rebalancing now.

Could we get linkified mod names in this thread?

I personally think that the better aerodynamics in FAR should be stock. When this is done, we need some sort of fairings and/or cargo bays in stock. Other things that should be stock are the "grab" and "attach" functions of KAS. (I don't think the winches are necessarily needed.) Obviously some of the more tweakable mods should have their tweakable options added to stock. We always can use larger rocket parts, especially now that the rubber-rocket issue has been tamed. We also could use a bigger selection of probe engines. This is similar to the ones in RLA Stockalike. We also need bigger wings, control fins and jet engines. Also, high-bypass turbofan engines with lower fuel usage in exchange for requiring much more intake air. The current turbofan should be listed as a high-compression low-bypass turbofan, since it behaves like one anyway. As of parts that I don't know if any mods have not been built yet, realistic nuclear engines would be nice (ones that JUST use liquid fuel.)

You could simply debind the keys for loading quicksaves. Sure, it would be nice if once Squad has completely slain the Space Kracken if they could enable this from start to have some sort of pretty emblem on your safe file. Otherwise, I really don't see the point.