Crzyrndm

Bac9, one more little fix for the buttons (seriously, I don't know what I was thinking when I wrote that bit). The RMB section should be +/- increment01 (ie. LMB >> increment large, RMB >> standard increment). I really should make a bitbucket account so I can just make pulls for this stuff >.> - - - Updated - - - kcs, I can't reproduce FAR repeatedly voxelising with just PWings and FAR installed

FAR repeated voxelisation with right click menu open is a known FAR issue FAR is entirely in control of wing mass, not much to be done there (craft mass should be changing though, I don't think the FAR readout accounts for resources) I still can't reproduce this memory leak with the control surfaces.

Well that beats my lazy "lets just reduce all the numbers" hands down. Integral action is inherently unstable, and from my testing is even more unstable than usual with the RSAS module. I haven't properly looked at how Claw is doing this yet, but so long as the Proportional reaction is strong enough KSP doesn't benefit much from using the integral action. RE: Stock tuning I don't see how there can be a tuning technique for a static set of values. They may have been used to determine the original values against a reference vessel, but from that point on they may as well be arbitrary because no one knows what the reference vessel looks like.

Another thing that may want to be considered, according to NathanKell stock lift coefficient (edit: and PorkJet says mass as well) should be purely based on surface area (area / 3.52 if his number is correct). Stock makes a lot of handwavy assumptions about part shape on it's own so doing it twice may not be a good idea. - - - Updated - - - This should do it (assemblyFARmass, is there a way to use FAR without it? This doesn't cover that possibility because I don't believe it to be the case. Edit: it isn't. If FAR can't find the value it uses a default)

Oops, looks like I forgot to normalise the large increment (when I added the right click stuff to that function I also changed the sliders to be <0-1> range for some reason I can't recall. Probably because I needed the range variable anyway and dealing with percentages is much easier). Fix is to divide increment large by range (for left click only, right click is already accounted for in increment01). EDIT Derp. Sometimes I amaze myself with my own stupidity. Right click buttons can just do one normal increment I already have a function to not update some FAR stuff until geometry editing has finished (half second delay), can just use the same thing for stock. Fix is to move drag cube calculation to the same function and make sure it gets called for both stock and FAR. E: Actually, the whole "calculate aero" could be shifted into that function. Would reduce complexity a bit. Tentative change to achieve this (testing now. E: Seems to work just fine)

And it doesn't make any mention of "SAS parts" (fairly common usage for what should be reaction wheels. SAS is the control system that decides how much torque to use). Dissapointed

This should kill any atmospheric use completely (when I say completely, even the very upper reaches of the atmo are going to be horrendous), and gives it a small throttle delay time @PART[ionEngine] { @MODULE[ModuleEngines] { %useEngineResponseTime = True %engineAccelerationSpeed = 0.1 %engineDecelerationSpeed = 0.1 -atmosphereCurve {} // remove the old one for clarity atmosphereCurve { key = 0 4200 0 -1 key = 0.001 0.001 0 0 } } }

Decides it's own versioning between all present .dll's All MM essentially does is add information to a text file, what happens after that is in the hands of the various mods and/or KSP itself

Poodle/Tunguska - Engine mass: The extra 1.5t dry weight is significant in a vessel of 10-15t total mass. Try it pushing a decent payload so the 1.5t extra isn't 10% of the vessel weight Skipper/Tunguska - Not enough fuel. For the same tank volume you get less hydrogen by mass because of it's low density (and therefore less dV). Add another tank and it will surpass it Cryo engines need 50-100% more tankage than their LFO equivalents in my experience. They still end up notably lighter though.

Wobbling back and forth can result from both under and over damped behaviour because of the discrete nature of calculations (~40-50x per ingame second default IIRC). In an analog implementation, there is no way for the derivative response to become too strong, however the discrete nature of the controller, and a very coarse one at that, means over correction is an entirely possible (even common) result from excessive damping and most of the vector SAS behaviour can be attributed to it. Ofcourse, once vessels get a lot of inertia and the increasing torque doesn't match that, response shifts through critical and becomes underdamped. tl;dr The response you see depends on the vessel, selected SAS mode, and current conditions (running engines, atmosphere (with or without control surfaces), etc.) RE: Where it locks onto, it's probably something similar to what I have done for SSAS. It would certainly explain some of the more vexing behaviours it has (roll vibrations causing it to "unlock" and slide) if it only used derivative response when the angular rate was above some setpoint (not an issue for me because the axes are treated completely separately ). Quite seriously: if you can derive the solution to that problem, then please do. Even if we drop body lift from the equations, it's not something that's a simple derivation. I know and understand how MJ does it's tuning now (torque/MoI ratio and inertia), but I'm always interested in a new approach

Debug.Log(), and lots of it... (yea, it's a right PITA)

No, TACLS would have to access that file by path so it wouldn't be able to find it if it was moved

Getting started is described pretty well on the wiki, including getting setup: Visual Studio (Windows only) or Mono Develop (any platform) NOTE: Don't skip the step where you set the project to compile against .NET 3.5, it's not outdated information.

It's underdamped when you have a heavy vessel with low torque. For a typical lightweight / low inertia vessel vector SAS is already heavily overdamped to the point of being non-functional (Mk1 pod, FLT-400, 909 => random vibrations). This all comes down to SAS having a static tuning that doesn't adjust to your vessel (it would be nice to have multiple tuings available, but I can see people FUBAR'ing something because they have no idea what they're doing). If you want it to be behave differently, add or remove torque (or get a mod to re-tune it).

GameEvents.onVesselChange is the event that fires when switching between vessels.

Yay for things that work first time Who better to answer your question

Great work as usual Nertea Only stock heating system (sunlight exposure, shock heating, engines) to add heat. Heat Control just gives a few things to move the energy around in a more controlled manner.

What happens if the engines use throttle response (aka spooling)? It could be relatively quick to the level of unnoticeable, but if the spool up / spool down ratio is small enough it could reduce that effect. May also help in the case of out of power probes (although that depends on what the spooling does when it runs low on resources). E: Instant deceleration and <0.1 for acceleration "should" (if KSP behaves as it described, which isn't guaranteed) solve both issues, although it's a little less nice for the over thrusting. As soon as it runs out of resources, it cuts out, but when it cuts back in it won't be using all the EC for a few frames (accel time dependent). Spam 'x' and the probe should shut down so long as it isn't running right on the edge. The engine also can't overthrust, avg. thrust would be <= sustained thrust (exponential saw tooth thrust profile, should be about equal if EC storage isn't really tight).

Doesn't do anything for the default SAS mode (stability) which is the only stock one that could be of any use for planes (but isn't because it will constantly increase pitch). It's the reason I added a surface SAS module to Pilot Assistant. Stock SAS and planes just don't mix well.

You need to change the Utility subcategory definition to block those parts. Utility is defined here, but you should do it via Module Manager so my updates don't break anything (example code below requires MM) The fastest way to do it is to copy all your conditions into an inverted Check type (if they show up in the other category, it will block them) @SUBCATEGORY[Utility] { @FILTER,* { CHECK { type = check invert = true ///////////// // copy all your subcategory's conditions here ///////////// // eg. CHECK { type = path value = ThunderAerospace/LS // put the actual conditions you used here } } } } For parts to be visible when using FE, they need to be visible if FE wasn't installed (stock categories or mod categories). This is to prevent asteroids, kerbals, and other parts that aren't intended to be visible (including mod parts) from showing up. If you want to block something, you change the subcategory rather than the part.

Diazo's Action Groups Extended

I would suggest trying ModuleResourceConverter using the same resource in/out but with different ratios rather than engines If you want to do it with an engine, the best way I can think of is to set the vac ISP to something very high and sea level ISP to something very close to zero. Use max thrust to change the rate at which it drains fuel. It will produce thrust, but not on a noticeable level because of thrust scaling with ISP, but the fuel usage will be constant.

Most plausible reason is that a module manager patch is adding something with significant impact (of which FAR certainly could be doing) or something that is heavily spamming the log.

Have you tried the following? (note: I don't actually know what the difference will be between these) part.externalTemperature vessel.externalTemperature vessel.atmosphericTemperature If those don't work, there is a lot of temperature related data in vessel.mainBody that you should be able to calculate it from (remembering temperature varies with altitude, latitude, sun exposure, etc.)

You either need: A) To write your own plugin Use the plugin from Filter Extensions and write your own configuration files for it (Feel free to ask questions in the mod thread ) If you want to go the plugin route, just find a mod that adds a category to use as a template (probably best not to look at FE for this). eg, the IR category uses the presence of an IR module to indicate parts that should be included in the category. The FE equivalent config would be (using Module Manager to add in the call from Filter by Function to make the IR Category. This assumes it is already defined fully somewhere else): SUBCATEGORY { name = IR Category icon = icon_filter_off // FE makes icons out of pairs of textures, one as listed and the other ending in _selected (eg. icon and icon_selected). IR doesn't follow this premise so a second state will be procedurally generated FILTER { CHECK { type = moduleName value = MuMechToggle } } } @CATEGORY[Filter?by?Function] { @SUBCATEGORIES { list = IR Category } }