Crzyrndm

The problem is not when he loads it, but how he loads it. Module Manager applies patches to ConfigNodes in GameDatabase. Anything that loads through GameDatabase is almost guaranteed to be ModuleManager compatible. Diazo is not using GameDatabase to load his settings, he's reading the file from the hard drive when he needs it. This is why MM can have no effect on his settings file. @Diazo The best way I found to do this is to load the settings file into an object the first time you enter the main menu that persists while the game is running. Thus it is affected by MM and persistent between flights and saves. Any changes made you write to that object and to hard drive (or rather, update the object and then save it). You can see this approach here where I have a class handling all my presets for Pilot Assistant. GameDatabase.Instance.GetConfigNode(string url) would be the load function needed for AGX I believe

This is going to sound counter-intuitive, but it may help to decrease the scalar (increase it's aggresiveness). High altitude wobbles are generally the big and slow type where it isn't reacting early enough, so it gets some significant error and then overcompensates. Increasing Kp on it's own may also help. PS I totally agree with how useful stacking SAS and Pilot Assistant can be. Easily one of the best improvements made possible by 0.90.

It's terrible because it's static and generic. It doesn't account for how your vessel will respond in the slightest, it does the exact same thing for a heavyweight craft with barely any control as a 0.1t super twitchy thing. PID controllers are used by MJ (auto tuned AFAIK) and Pilot Assistant (manual tuning). The behaviour achieved by either of them showcases what they can do a whole lot better.

Nothing at all, and I really doubt there will be anything like that at this stage. I think the best we can hope for is that they've really clamped down hard on the leaks.

Pretty much why I brought it up. A bit more background now I'm at my dev PC: Unity GUI is all one-shot. You have to redraw it every frame and as soon as you stop telling it to draw it dissapears. The Squad GUI object that displays the extended strategy description (class: RUIScrollableRichTextArea) is not one-shot. You tell it what to draw once and it keeps drawing the same things. Now, when you tell it to change what it's drawing (in my case updating the text), the memory usage increases slightly. If you force it to draw every frame (as I was doing initally, being used to Unity GUI being one-shot.) that small increase becomes a very noticeable increase. http://youtu.be/EUYC9vFkzlk Because of how things are handled, while I plugged the original leak I caused, you can still force it through ^^ EDIT YT is taking it's sweet time... (and finally...)

No and it's not something I'll add either. After doing some testing of the stock SAS target modes, I'm seriously considering over-riding them with the stability assistance tuning they're so out of whack.

Ok, so I took some time to examine this a little closer and while I was mostly correct, I got this a little backwards. If you observe the indicators/pips in the bottom left corner while one of the target modes is active, you'll notice that it is extremely jiggly. This is generally a symptom of excessive damping in a PID loop, and sure enough, I can replicate behaviour almost exactly by raising the Kd of the stability SAS mode (by a HUGE amount. Someone may have added an extra zero HUGE amount) Video to show my testing 0:30-0:45 is stability Assist tweaked to behave terribly, then a target hold for comparison, then stability assist with it's default tuning from 1:10 (all done with infinite RCS so there's no change in mass or anything like that) Just for comparison: [TABLE=class: grid, width: 500] [TR] [TD][/TD] [TD]Stability normal[/TD] [TD]Stability target[/TD] [/TR] [TR] [TD]Kp[/TD] [TD]15k[/TD] [TD]20k[/TD] [/TR] [TR] [TD]Ki[/TD] [TD]0[/TD] [TD]0[/TD] [/TR] [TR] [TD]Kd[/TD] [TD]2k[/TD] [TD]60k[/TD] [/TR] [/TABLE] Seriously considering adding an override to make those modes use the stability settings now

That reminds me: Yemo (or others), any thoughts regarding the numbers used for Sane Strategies? (this being the only place where there's a semblance of balance across most of the board...) I haven't had much game time post-0.90, the major change I'm worried about would be how funds tends to be a lot more restricted early game with building upgrades (which could be alleviated by reducing startup costs without shifting the lategame paradigm much).

The running out of resources even though you have excess generation bit sounds like storage is being capped (you need enough storage for the amount of resource per physics tick even if you use them instantly, timewarp drastically increases that storage requirement because the game time per tick is proportional to warp rate)

Your assumption is probably reversed anyway. At best, reality says it doesn't care (this is how KSP models it). At worst, they reduce effective torque the further from CoM (both cases are provided because I still can't prove the worst case scenario, but it seems to be the likely outcome) Linear forces (ie. engines, RCS) on the other hand increase in effectiveness as they distance themselves from the CoM because they increase the lever arm they have to apply their force.

A) KSP is 32-bit unless otherwise specified (which should only be done on linux anyway...) which limits it to ~3-3.5GB KSP's memory management is almost non-existent. Everything gets loaded at the start so adding a dozen parts increases memory usage even if you never use them. C) v0.90 has developed or emphasised a rather alarming number of memory leaks. Basically, monitoring and reducing memory usage is a rather large priority for modded KSP. Using Active Texture Management, forcing it to use OpenGL or Dx11 on windows and pruning unused parts from the GameData folder are all common ways to reduce memory footprint.

This looks very similar to a leak I accidentally caused in the past through some GUI code (Sane Strategies, that little bit of extra text on the strategies window was doing a few MB/s initially). What happened with me was that every time the element was redrawn, the old version was overwritten but not erased. Now, this doesn't happen with the base Unity Gui code, but that piece of text was written on a custom Squad class. It still leaks like mad when you switch strategies or change commitment , but it only does it when parameters change now(ie. you can force it, but thats not on me any more). I have a feeling the tweakables suffer from something similar. Instead of drawing the same object, they are updating the object even when no changes are made and the old object is not being discarded properly.

Source: https://github.com/ferram4/Ferram-Aerospace-Research/blob/master/GameData/FerramAerospaceResearch/FerramAerospaceResearch.cfg#L694 Generic 50% thrust for all engines that use intake air as a propellant Turbojet: Reduced thrust to 110kN, reduced max effective velocity to 1800m/s (compared to 2400 stock...) Rapier: Reduced thrust to 100kN in airbreathing mode, reduced max effective velocity to 1700m/s Basic Jet: Still (?) 150kN, reduced max velocity to approx mach 1

As the developer, I would also recommend waiting a while (how long a while is depends on my ability to find time to work on it...). The current version *works* in that force is dependent on a psuedo resource, but I haven't got to a state where I'd consider it as a "release" (One, I still haven't even attempted to explore the variations the mechanic could create. Two, I doubt anyone else appreciates my logging dumps being generated every second. Three, it's still using average torque in a few places that don't make sense).

You can't build a controllable craft of only massless parts, so you can't get infinite acceleration (all pods and probes have mass, as does a kerbal in a command seat)

RE: How much wing is enough In the static analysis tab, you can determine what your level flight AoA will be for a given speed, altitude, and flap setting (for takeoff). It's on the right above the stability derivatives (as is Cl / Cd, velocity in m/s, and a few other useful numbers). If that number is too high you're going to be stalling or descending (can't maintain level flight). If it's too low (one of my planes cruises at 25km with <1 degree AoA...) you probably have too much wing. I normally try and keep it around 5 degrees. NOTE: AoA refers to wing AoA. If you tilt the wing up a few degrees, your nose can be right on prograde while maintaining level flight and FAR will report it as such For the most part, use deflection to set how much reaction you have, and set the response to 0 or +/- 100% depending on what you want it to do. Other %'s are more for when you have a multi-tasking control and you want to set it's priorities a bit different. For example: elevons control pitch and roll, but you often want all of their reaction for pitch, but only a small amount for roll. You set the control deflection based on 100% pitch and then reduce the roll % so that it doesn't use full deflection when it doesn't need to. Thats how I do it anyway. Much simpler than trying to work out % deflection for everything.

Note when I said stability mode. The new vector holding stuff is on an entirely different system (and that system is FUBAR compared to the stability assistance mode). Not to mention that whatever control system they're using for it is locked up tight so I can't even modify it's behaviour without completely rewriting it. Problem 1: Roll control => damping only (has no target) and much, much too aggresive about it Problem 2: Pitch/yaw control => Aggresive P control (probably), no where near enough damping tl;dr Someone re-invented the wheel with corners and threw that in for the new modes (while the original system would have done the job just fine). It's probably doing the same thing, just (even more) terribly tuned

Control software probably based off the same principals as stock SAS (simple PID could definitely work, but then so could a number of other systems they could be using), but has a little more smarts for things that SAS doesn't have to worry about. They also have a single system so the software can (and will) be perfectly tuned for that particular object, while Squad has to make do with a middle of the road choice unless they want to get into auto tuning (*blegh*). On your other point, note that centering the wheels means you can make them larger within the same boundaries, and makes centering CoM easier. There are more possible reasons than just torque to locate them that way. EDIT And now I want to make one. That would be an amusing thing to trot out (except then I'd need to build it -.-; Software: Check, Electronics: Check, Construction: MIA...)

That is exactly what it is doing. Each axis of Stock SAS (in stability mode) is run by a PID controller (I believe this is still the same as the original, but I wasn't around that far back to verify that ). The default configuration has integral (I) response set to zero, so all it is doing is saying: a) How far am I from my target (P control) How fast am I moving towards my target (D control) Integral control is disabled by default because it's not useful in space where there is no force preventing the target being reached. A whole other story for planes ofcourse, this lack of Intregral action is what prevents them holding pitch where you want them to. The "I give up and will just track prograde" is something Squad added on top of that to prevent some general insanity from what I've read here. It is possible, just somewhat annoying to handle automatically. You need an estimate of how much torque you have available (which depends on speed, atmospheric density, stalling, and location for control surfaces in a sane atmosphere), the current rotational inertia of the vessel, and an estimate of the level of natural aerodynamic damping at current conditions (which is probably related to the seperation of CoP and CoM). From that you could recalculate Kp/Ki/Kd fairly well with a bit of experimentation. It likely would still fall over occasionally, but thats just going to happen with as many variables as you have in craft design. NOTE: I built my own SAS system for Pilot Assistant (because stock SAS just can't handle planes) and have tried to tackle this exact issue several times. So far it has proved itself beyond my levels of understanding so take what I have to say with a grain of salt

All systems can result in smooth flight. Which one's to use are all on what you want to do (eg. gliding into the runway is easier with the VSpeed control, while long distance flight is normally easier with the altitude controller) No, there is no "click/site target" system in Pilot Assistant, it's a much more basic level of control than something like that (pretty much, what you see is what you get). You didn't press pitch up/down or Yaw left/right keys by any chance? Further inquiries should be directed to their respective threads though. This one is for FAR...

Version 1.3.1 Fix for random "freezes" in control system caused by a misplaced clamp Cleanup of some minor GUI issues

A fairly thorough shakedown has failed to knock anything loose, so I'm going to need as much information as you can get on this Could be of use: Presets.cfg (and which one of them you've had the issue with) craft file Video or pictures with the AoA controller open (minimise the VSpeed controller) Log file Add anything you think it may even be remotely related. The more information I get, the more things I can atleast knock things *off* the list of possible causes EDIT And right after I post that, I get the exact issue, except on the throttle controller... (still looking for more info unless I update that I've found and fixed it) What I'm seeing is that it gets stuck at a certain offset from the setpoint, so I can change the setpoint and it comes back to the same SP + offset position it was in before. EDIT2 Alright, it was the silliest little thing and explains quite a few other silly little things that I've been noticing, but bug is found and squashed

Ofcourse, if you can change the shape of the front of the intake instead of only thinking of the internals... *doh* And if you don't want to mess around with Pilot Assistant's tuning, there's my other control mod which lets you use the mouse to smoothly direct your planes (you still want to use trim for that though)

Alright, looks like I have some digging to do. This is happening: with WASD control inputs (only?) with the vertical speed control mode What happens when you change the SP while its stuck? EDIT Cleaned up the OP somewhat, added a Issues 101 note

Stock is stupid and sets it to zero IIRC (it's been a while though so I could be wrong...), current FAR version has it constant or very nearly so, and unless there's some wierd aero effects going on reality would probably drastically increase the drag from closing them.