karamazovnew

That goes without saying... There's only one place where hand controls would sort of work, and that's EVA in space. I remember playing a space game where you would use the hand controls to control the RCS and click on stuff. But mouse and keyboard are better at that as well. - How many actual KSP players would at least try VR KSP? As prices go down and the technology improves, all current KSP players would at least try it in VR at one point, because they'll all own a headset. Those that don't get sick will probably continue to play it like that. That includes you. Maybe in 10 years, but who cares? - How many new player will try KSP because of VR? No idea. But there aren't that many quality VR games on the market. Somebody that might be thrown off by the complexity of KSP, might still be drawn in just to have another VR title in his collection. Point is, right now, a new player might only hear about Kerbal from Indie Top10s or space-sim Top10s. Being in the VR Top10 list give better publicity and will continue to do so for quite some time. - How much it will cost for SQUAD to develop it? Consider that one guy was able to do it in his spare time. So, unless licencing is involved, probably not that much. And they might be able to strike a deal with VR manufacturers. How long would it take to make such a thing? Again, maybe not that long. I have no idea. But Unity 5.4 (which Kerbal runs on) supports VR natively. So Squad wouldn't have to design the game back from scratch for DirectX10 like the IL-2 devs had to do. And I don't see how it would affect new features, because this is an engine/graphics/VR thing which requires a VR specialist programmer, not a "whatever-feature-you-personally-miss" programmer. Now again, I'm not the one to choose to add support to the game. I'm not asking you guys if you agree or not. This isn't a poll. A dev might come and say "nope, never", but they said the same about IL-2 and look how that turned out. The point of this topic is not to debate to death the "so difficult.. much expensive" route. That's for the devs to decide at any point. I'd rather share information and suggestions tailored to the game, based on what I like or what I don't like in other VR games, what would work and what wouldn't work in KSP. I'm also not expecting some of you guys that never tried VR, or have tried it for 5 minutes to understand what 3D would bring to this game. If they add it, after you buy a headset in 5 years, you'll get what the buzz is all about. Till then, At least try to imagine it.

Why? The interface could be made to float in front of your eyes, just as in other VR games. You'd have all of the info and mods that you currently have. You might have to make the text a bit bigger, but that's already supported by the game. And the camera could be made to pivot/zoom by mouse just as it currently does. Head movement would just allow you to look somewhere else. Indeed, all you'd get out of it would be just a bit of 3D, so that would be a slight waste of the technology. From what I've seen so far, a game needs the following interface options (check BigScreen Beta which has all of these): - fake screen size - fake screen depth - fake screen spherical distortion (make it flat or rounded) As for the interiors, as long as the exterior works normally, you can depend on the normal mods, or go full RPM (as we currently do for interior only flights). But, as I've said, and this is not a VR-only request, the devs might help a bit here by allowing stock "probe control room", maybe some stock "display monitor" with better customizable interface than RPM currently has.

Many thanks. At first it seemed to show a slight bug. A blue line was visible above the craft, but would disappear after resetting the trajectories display. However, it would reappear again after changing the view. But then I installed the last Mechjeb dev and the line bug didn't come again. (Is mechjeb a soft dependency?) Also, happy to see that you can use both Mechjeb's and Trajectories's lines at the same time. Trajectories showed an almost perfect prediction (minus the heatshield mass loss and parachute opening, but that's normal), while Mechjeb was off by at least 10 km, as usual.

You mean like this? https://www.youtube.com/watch?v=MJHZyN2Xy-8&t=1113s Or this? https://www.youtube.com/watch?v=DjQauN66rQA&t=13s I've played the latter myself, as I've mentioned. It was it that convinced me that KSP might actually make for an interesting VR game. The only reason we don't have VR already as a mod is that something changed in the Unity version during the 1.2 update, which broke the VR mod, and thus any work on improving it. The devs might be better able to fix that, a simple modder can't. In other words, to make a "5 minute demo", you need the entire VR module to work. There's a possibility that the devs can't fix the Unity VR problem, which would be the only possible reason to say, as you've said, "I don't think this can ever be implemented". Otherwise, "the reasons listed above" have more to do with "will", and not "can", and they're the same ones which I've seen one year ago in the IL-2 forums, which has since received the best VR support of any game, improved sales for the game itself and the VR headsets and has been described as the "second coming of VR Jesus himself" by those who have been fortunate to play it (me included). I hate everything that's trendy and viral. I'm glad that, when I say I like Bach, people always assume I'm talking about that stupid D minor Tocatta. As long as it keeps them from my beloved 849 fugue, or the Busoni version of his first harpsichord concerto, that's fine. I'm glad to say that my favorite actors are Mark Rylance and Ben Whishaw or that I have an absolute crush on Claire Foy. If you're a grandpa, I'm worse, much worse. But I've jumped on the VR wagon last year because I've desired it for 20 years, ever since playing my first flight sim. I too cringe when realizing how it will end up being used, and by whom. Now I can't wait for house-maid robots, but I do realize how those will be used as well. There's no stopping it. I already have a porn VR game. I can already shoot people in the face in VR. In December, I will get Fallout 4 VR which, if modded in a particular way, will allow me not only to shoot people in the face, but "porn" their headless bodies as well. I will have that. Kids everywhere will have that. What we won't have, is KSP VR. Now how sad is that?

It wouldn't make it "easier", but I've recently built my Lego Saturn 5, so yeah... totally agree. It would be really fun to see a toy scaled rocket in a room sized VAB, with tiny tiny kerbals moving on the floor. That's why a customizable world scale (with extra setting for VAB/SPH) is a must.

KSP has been with us for many years now, and judging on how well the game is doing, it will be around for many years more. We've had VR for well over a year now, and although the game market is still small, there are quite a few sims which already fit into the "I can't play this without VR anymore" category. And with future performance boosts from hardware, and better resolution and field of view to come, the VR future is bright enough. Heck, the present isn't bad either with such gems like IL-2, Elite Dangerous, many car sims which are a lot better than what could've been expected from this first generation. So why not KSP as well? Before you ask, yes, I've played the KPS 1.1.3 VR mod. Yes it's slow, buggy and clunky. But I've put RasterPropMonitor and I've made Mun and Minmus landings with it. And boy, what a ride it was. Vomit inducing yes (because of the bugs and low fps), but still a heck of a ride. I did have a lot of experience with "interior only" flights and I am a good KOS user. I didn't manage to put a first person camera mod, so I was robbed of a bit of EVA fun, but overall, it sold me completely to the idea of Kerbal VR. If the devs would manage to make a proper VR implementation, it wouldn't just be a gimmick, it would be awesome. So let's talk implementation... - Difficulty of implementing: it would require a lot of effort, but it would open up the sales to the hungry VR market, so, if it's done properly, it would pay for itself easily. Kerbal is already a fantastic educational game and sim in itself. I mean, how many people ended up buying the pretty basic (so far) Elite Dangerous, just to be able to play one more title in VR? How much did the IL-2 sales jump when it became apparent it was the best VR game? And there have already been VR fans keen on making it KSP VR happen (see the VR mod which is 1 year old). Hire one of those. And don't think twice about making it cost a few extra bucks. I'd buy it in a second. With thousands of hours played - Performance: Kerbal isn't exactly a light game on the processors. With VR requiring 90fps, yeah... Realism Overhaul wouldn't be an option... but most of us have been here in the beta days, struggling with limited RAM and constant crashes. Things improve. Computers improve. By the time Kerbal ends its shelf life, we might be in the 2nd generation of VR, sitting on 200 of extra fps, even with a ton of mods loaded. So as long as the devs manage to crack the Unity VR cookie and provide decent performance for the vanilla game with the current hardware, it should all be fine in the end and RO compatible in a few years. - World scale: Make it customizable from the start. Is that underlined enough for you? For example, in the VR mod for KPS 1.1.3, the world is very "realistically" scaled. So that means that everything is scaled to a kerbal. So it's tiny , with the interiors being very claustrophobic. Just add a slider from the start, to allow people to make the Kerbal 1m high, or human scaled. Also make sure to put the skybox as far away as possible, lest you end up with a bad 3D like Elite Dangerous has (and has yet to fix grrrr). - Gameplay: while I am happy with RPM and KOS, most users might not be. An interior-only game would be sad to see. We need everything to work, VAB, map, the lot. Probes should really get an optional "probe control room" interior variant, but 3rd person camera would still have to work. And first person kerbals are a must (with better control btw). Mouse cursor should work flawlessly (think DCS in VR). There are enough implementation options for game interfaces to get inspiration from. All in all, the game should needs to work normally, as it does now, with head orientation and 3D being there just to improve the overall experience. All normal mods shouldn't be rewritten from scratch. And non-VR modders shouldn't worry about their addon not working in VR. However.... - Gameplay 2: Consider just how far people have gone with the whole addon stuff... moddable interface?... BAM! 1000 mods. One of them is RasterPropMonitor, which is a gem in itself and lovingly maintained. But it needs to be vanilla. Sure, VR would bring more modders to RPM and expand it somewhat, but if the vanilla game itself brings a clever way to display monitors and create an interface layer for it (plus the controls), imagine what mods would come out. Now imagine the other "exterior" mods, such as KIS. How would VR work with that? My point is that any help from the devs, any amount of work they put in the vanilla game, would be improved by modders. Just give them a solid VR base to build on. - Interiors: well... this has to be done anyway, doesn't it? There is no lack of talented modders to create amazing interiors for the crafts. The issue is different: movement. If the devs manage to make a proper movement in the interior of bases and crafts (vanilla parts), with docking ports, doors, artificial gravity, zero gravity, sitting down in a seat, using a particular prop to do something (science experiment, eat, repair, etc) the modders would be able to go crazy with the interiors and that would be benefit everybody (not just VR users). - Hand controllers: meh... I have a Vive but I keep my controllers pretty far from my HOTAS, if you get my drift. But controller support would be able to make an interesting EVA control and be really fun to grab objects and build in KIS. But I'll pass, I think that a more important aspect would be the movement and camera controls, so... - Movement and camera controls: I guess most of us use (or have used) a first person EVA mod or another. What I would like to see is a "helmet" effect, with a visible visor, maybe some form of light filter to dim out the extra bright Mun surface. Rotating your head "inside" the helmet is the way to go. I've played enough VR first person games to know that you should keep it as simple and basic as possible for keyboard and mouse controls. I suggest moving independent from the head position. Rotating the kerbal should be done with keys or mouse, not with the head. Headbobbing and ragdolling your kerbals from the top of a Minmus cliff should be minimized as much as possible. One other problem is the speed at which craft rotate. That can be fixed with various mods (limiting Gforces, or reaction wheel forces). But other effects, such as cockpit shaking can be kept. They'd provide a nice feedback and make life difficult for the pilot, trying to press the small buttons while the craft is shaking like hell.

Here's some food for thought, I hope this provides some ideas. - create multiple mirrors for every biome in the game. These will not actually be on the planets, just placeholders for the stock experiments mechanic. - each mirror would be the value of the anomaly: Very Low, Low, Normal, High, Very High. Better names would be Common, Uncommon, Valuable, Rare, Exotic (or others). - as you roam the planet, the scanner will check not the landing position, but the place of the last experiment done in a biome (not just scanned). When the scanner creates an anomaly, instead of using diminishing returns, it will just decrease the chance to get good ones. This chance will improve as you travel further from your last experiment made. In effect, at the start, you'll find interesting rocks everywhere. But after a long time and many experiments done, it will stop be worth your time if you don't travel far away. But even so, you might still get that 1% chance to see a good rock 10 meters away from your old Mun base. - when you enter a hotspot, the corresponding mirror biome is revealed and you can do the actual stock (or DMagic) experiments. This means that a fully equipped rover/craft would be worth a LOT more than a cart on wheels with just a thermometer. - as long as the experiments for that biome are properly configured for each experiment, you can then rely on the stock mechanic of dimishing returns. For example, just measuring the pressure around the anomaly might be cool the first time, but doing the ablation experiment would be worth doing multiple times. One-time-use experiments should yield no science. A config file would help us decide if we want 10 or 100 or 1000 high value rocks before we can consider a biome "cleared". And a science multiplier would help us decide just how much science we can get from that biome (all types of anomalies considered). Check out how Scansat does the whole partial scan data transmission. - Data values should be kept very low for the full experiments. Otherwise, the ScienceLabs would just be even more overpowered. - Upgrades to the rover system should stick to the current range, prediction, but also sensitivity. Sensitivity would mean that even if the system creates 100 possible anomalies around you, you'd only be shown a few, the others would be missed by the low quality camera. Prediction and range would work as they do now. - Distances between anomalies should be much greater and be biome dependant. This would allow you to make Icy Poles scares, while small planetoids could be quite rich. One aspect to consider is the difficulty of traversing rough terrain. Minmus's Flats for example would give you bad science, while the more dangerous Slopes would yield more. But smaller planets should yield more than large gravity ones, where your rover is harder to tip over. - The best way to achieve this is to create a fake resource for the anomaly probability (all 5 of them). The Rover scanner would invisibly work just as a resource scanner and the percentage found would give the chance to spawn the actual anomalies. That would be an easy way to control the distance between anomalies. - This shouldn't be restricted to rovers (stuff with wheels). Kerbals should have this option as well, acting as a starting Rover with no upgrades. You can create a carriable (with KIS) scanner for them, or just a simple right click menu button called "Scan for shiny!". A crew report and a surface sample would be cool and a good reason to hop around the landing site instead of just launching back in 2 minutes. Of course, it shouldn't be called Rover Science then, but something like "Real Science" or "Surface Science" or whatever. This would revolutionize the way we do missions, all of them.

I really wish CRP wasn't bundled with the mods that use it. Although it's not the only bundled mod in KPS, it's the one that seems to be updated the most often. It makes keeping mods updated very confusing, especially for a JSGME user such as myself and probably for the modders as well. At the very least, could modders pretty please stop adding extra files to the CommunityResourcePack folder? One of them even deleted one of the original files (you know who you are, btw love your mods ).

That looks like GemFX. It's a pain to set up, but it doesn't affect framerates at all. You can get very interesting results with it. Even with the default settings I remember screaming out in amazement the first time the game loaded. Honestly, maybe Proot can take a look at it and work his magic with it as well.

Absolutely amazing. My GC went from 8 seconds to 50 seconds. Thank you so much for this.

Check the settings. Make sure that the Hab Effect (Vet) is set to None and that the Vet Names list include "Valentina".

This is the first time I can actually play with it Though I did have to take out a few stuff - deleted the kerbin textures in "GameData\KSPRC\PluginData" - deleted all volumetric effects for clouds. - disabled shadows for dark and top clouds. - disabled godrays and shadows from Scatterer. And it still looks stunning with 70 mods or so. In fact, I quite like having the game at around 30 fps or so, since I don't get those stupid garbage collection stutters.

I know that, but It's just a quick boot test script... Anyway, I am not using them at the same time. The script is not a loop, just a few one-time commands with delay between them. LOCK STEERING TO HEADING(70,50). WAIT 10. SET SHIP:CONTROL:NEUTRALIZE to True. //sorry, I left out the beginning of script that first tested the controls on all axis, doesn't matter... //at this point steering is still locked, but the script will end after the next line anwyay. SAS ON. //last command in the script. So it's just like having an UNLOCK STEERING command just after it, because the controls are returned to the player anyway when the script ends after this line. Before you ask, I did have an UNLOCK STEERING before it, I just replaced it with the last PRINT line since for the last tests where I liked to keep control and do manual "LOCK STEERING TO HEADING" commands in the terminal. Regardless of SAS on or off, results were the same, that thing was irrelevant for my tests. And yes, my take-offs were at 50% engine power small rocket, big engine. Didn't feel the need to include throttle controls

Roger on everything. It does make sense, according to what I've seen so far. Anyway, I'm blaming FAR for this one, as even the stock autopilot now has problems with controlling a craft just with the fins. Tuning the steering? Yes, no effect. Raw controls working just fine. Code? Something very simple: WAIT 2. CLEARSCREEN. STAGE. SET now to time:seconds. WAIT 5. print ("Alter steering, should be 5. "+ (time:seconds - now)). LOCK STEERING TO HEADING(90,70). SET now to time:seconds. WAIT 10. print ("Alter steering, should be 10. "+ (time:seconds - now)). LOCK STEERING TO HEADING(70,50). WAIT 10. print ("finished. "+ (time:seconds - now)). SET SHIP:CONTROL:NEUTRALIZE to True. SAS ON. Just a simple rocket with 4 AV-R8 fins. Mods? Just clean install with KOS, Module Manager and FAR. Here's how it goes... - any rocket with authority such as reaction wheels or engine gimbals or stock fins.... all ok, working as expected in any combination and at any intensity (any reaction wheel power, engine gimbal angle). - any rocket that also has FAR fins? It seems that if the vessel doesn't have any other good authority in one particular axis, the command on that axis varies wildly very very fast (much worse that stock autopilot), so fins don't get the chance to actually turn at all, they just wiggle fast at 1-2 degrees or so, basically maintaining the axis stable and preventing any turning. So as an example, a rocket without reaction wheels (all disabled) and just one gimbal engine will have good auto control on the pitch and yaw axes (stable commands)from the engine, the fins will not twitch on those axis, but the roll axis will twitch as long as the STEERING is LOCKED to anything. After a while, the roll starts to happen so then the other axis start to twitch as well, screwing up the gimbal on the engine. Basically, without a good Reaction wheel, the craft will simply not be able to stay straight. The reason why this problem messed me up every time during launch was that I have a small mod that cuts all reaction wheels power to something like 5%. Otherwise I never would've noticed this bug and would've blamed more extreme examples on aero forces. The exact same rocket can work fine with stock reaction wheel, then freeze with my 1/20 reduction, all the time working just fine in space. Just for fun, I've copied the fins part and disabled FAR for it. Guess what... with 4 non-FAR and 4 FAR fins on the rocket, they all refused to work, with the FAR fins messing the others up. You need to see this for yourself, I don't think logs would help here. Oh and of course, FAR Flight Assistant was off. I'm ok with my current stock fins, they work just fine.And for my scripts, I'll just use a custom autopilot. I'll try again when I see Far fins are more stable in stock autopilot. No use now, really . Anyway, since these mods are a must for Realism Overhaul, it's good to know in advance what to expect when I start that

Many thanks . But until I actually have a framework of what can be done, I'll sit back and gather some inspiration. Plus, I'm out for the weekend (stupid vacation!). Meanwhile, just use the files RPM or B9 have, the proportions are all in there, just change the colors a bit. The rest is just transparent filters and text colors in RPM's code. I think B9 used the most features of what RPM can do. Once your main files are up and running I'd love to give it a go. Maybe I'll take a shot at RPM itself, long overdue to be honest Here's something cool: http://www.awn.com/vfxworld/interfacing-mars-territory-studio-and-martian Although there's something about Orbiter's simple interface which still gets to me.

Sounds like a challenge |----------------------------------------| |LABEL LABEL LABEL LABEL LABEL LABEL EXIT| |kOS Terminal: kCPU 0 | |DEBUG FLAG FLAG FLAG FLAG FLAG FLAG FLAG| |FLAGS FLAG FLAG FLAG FLAG FLAG FLAG FLAG| | | |kOS Operating System | |KerboScript v0.20.1 | |Proceed. | |PRINT "REPEAT AFTER ME". | |REPEAT AFTER ME | |PRINT "NOT YET!". | |NOT YET! | |PRINT "STOP IT!". | |STOP IT! | |PRINT "CUT IT OUT!". | |CUT IT OUT! | |PRINT "YOU'RE SILLY". | |YES YOU ARE. | | | |LABEL LABEL LABEL LABEL LABEL LABEL HELP| |----------------------------------------| Here's a photoshop mockup: As long as you can change the background image when you press one of the buttons (no idea if possible, really), you can do a lot of cool stuff. Because 40 characters is not enough for 7 labels of 5 characters, why not sacrifice the two right buttons for something else? I've labeled them HELP and EXIT here but they could be anything. And of course, only the set labels would appear, not all of them That means that we can still make long labels, as long as we ignore the nearby buttons. The same goes with the flags. I simply can't fit more. But 4 letters should be enough for most applications. I think you can also put images ON TOP of the text, so a nice grid semi-transparent "buttons" image would look nice for the lights. Oh and, to save a bit of space, the "enabled/disabled" state for the processor would need to be shown by the color of the name. EDIT: oh and you can have 13 lines of code, or 12 and separate the lights more or do something else with the extra line. No idea if as you enter code you overwrite the labels below.

Works now, but seriously, the font is too small And yeah, the input lag is.... quite big Took me a bit of time (I just spent 1 hour writing useless tips), but I finally realized just how brilliant your method is. It basically does 99% of what I was about to suggest and all in one screen. Wow.... One minor bug, I usually test my flights with KCT's simulations. But if I exit the flight back to VAB while in "keyboard focus" mode, the interface is stuck and I have to exit the game. Mouse moves, right click works but camera controls and left click don't work. Don't worry about the arrow keys, we can disable them in the game's main menu. The only problem is that some other addons shortcuts (such as KAS which opens his interface on pressing P) still trigger, but that's true of the normal kOS terminal as well. In fact, in IVA I can't even use the kOS terminal unless I first press your button, so good job on that. If you could find a solution, make sure to tell the guys at KOS as well . Regarding the "has keyboard focus" is it possible to just alter the background color of that RPM screen? By the way, why don't you use a transparent image layer to replace most of the #### characters and gain some extra space? Lights could keep them as I like how they push eachother outside the screen. But can't they be more "like lights"? I mean something like green background for the characters? Maybe even add two more properties for them: background and fontcolor. More questions: - Is it possible to use the name of the CPU (if altered) instead of the "kCPUx" names in the processor list? It could remain as default. - Is there any event when changing the active processor? I'd like to change the button labels and the lights based on what processor is active through a "refresh gui" script. - RPM has one button currently bugged, the Engine Ignitor button. You could use that for your main page. Instead of leaving it as standalone, you could attach it to that and use some of the other buttons more wisely. For example: X as CTRL-C (probably will jump us out of IVA), Green Arrow as activate/deactivate processor, LEFT-RIGHT for selecting processor, UP-DOWN for resolution, PREV-NEXT for line history (or just make arrow keys work and use them for something else), and finally Standby for standard RPM standby. So you don't actually loose any of the "customizable" buttons. Heck, one more option would be to even use the STANDBY button itself and replace the "boot" page of RPM. THIS: This gives me hope. Ship telemetry with proper delay and only available when probe has signal? Been wanting that for AGES. Combined with buttons that can alter the scripts that alter the page? HOLY MOLY! The only thing missing would be the RPM assets to actually take their data from the scripts and ignore the "realtime" telemetry. That would be cool. Having a probe run out of fuel 10 minutes before you see it happen in ProbeControlRoom. Torture. By the way, since I can't test this now, if I show the kPM page on multiple RPM monitors, what would I see? Would they all be identical? If not, nesting pages would be cooler than ice But I don't see how you could add link between the active monitor, active page, last button pressed conditionals and events into KOS. If you could... wow boy. But let's leave that for later, what we have is nice enough if polished. Still... wow...

Hi there, here's Ferram's reply to me: No idea what you guys are talking about, but hope this helps. Meanwhile, I've kept 2-3 rocket fins from getting FAR and they work great with KOS on their own. Happy camper waiting for a fix EDIT: actually to help a bit, almost forgot to mention: while messing around with those fins, I turned one of them into a FAR wing with stock ModuleControlSurface. kOS worked with it (sort of). So I'm assuming that @dragCoeff = 0 @deflectionLiftCoeff = 0 which FAR puts somehow break KOS's ability to alter course, while still having them try to maintain stability. Hope that helps.

Uhmm... this can't be right... getting spammed with and none of the screens working [Exception]: ArgumentOutOfRangeException:Argument is out of range Parameter name:index. http://i.imgur.com/wbeATgb.jpg?1 When I press the O button it does input to the KOS terminal, but not into RPM. Maybe creating a separate prop is a bad idea? I liked having just a page for it. By the way, you can still "overwrite" the buttons even within a page. You could make a separate prop with just KOS so people can change their interiors if they want. Here's a comment I made a long time ago, the method might still work. http://forum.kerbalspaceprogram.com/index.php?/topic/83570-112-b9-aerospace-release-611-updated-030516/&do=findComment&comment=1621235 It describes page nesting and blocking specific buttons from accessing other pages freeing them up for other uses (the buttons on top and bottom of the screen). So you could build different pages with whatever background you want, just for kOS. I recommend leaving the top right button on default setting, so you can exit KOS at any time, and set the X button to bring you back to the default KOS screen, while still accessing it like in the previous version and leaving everything else in RPM unchanged . Also, is it possible to make the Left-Right buttons move the cursor and the UP button show the previous commands (as the normal kos terminal does it?). Also, pressing the input button needs a more "visible" reminder that the keyboard is locked. I recommend putting an overlay with a label, sort of like how the Navball displays "ORB" and "SURF" when you press the same button.

Well, to quote the kOS authors: So that's that. Anyway, solved it by copying the basic canards and giving them another name, so that FAR leaves them stock. Seems to work fine, but I'm not sure how much I'm loosing physics wise. In your opinion, would it be better to force the new parts to use the FAR model (but the stock control)? @PART[kOSAdvancedCanard]:AFTER[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 MODULE { name = FARWingAerodynamicModel MAC = 0.93122 MidChordSweep = 37.044 b_2 = 1.7904 TaperRatio = 0.139074 } } So i'm leaving the stock deflectionLiftCoeff, ctrlSurfaceRange and ctrlSurfaceArea as stock, while using your FARControllableSurface module parameters for a FARWingAerodynamicModel module. This seems to work but I'm not sure if I'm breaking anything. Is it ok? Or should I just leave them stock? EDIT: Oh and... @dragCoeff = 0 @deflectionLiftCoeff = 0 In stock they sit in the ModuleControlSurface so I thought I might not need to touch them? Or should I zero out them as well?

Hi Ferram, I've just started using KOS and I seem to have a problem controlling the vessel with any FAR v0.15.6.5 related control surfaces (no idea if it happened in previous versions). I'm trying to use LOCK STEERING TO HEADING(x,y) during the ascent. If I don't use any gimbaled engines, the control surfaces twitch on all axis very fast, while the craft remains pointing up and "stable". The vessel ignores any Heading commands, both from the script and the console. With gimbaled engines added, the craft behaves normally on yaw and pitch axis, except for the roll axis which again twitches wildly, but the craft is "stable" on that axis as well. After removing FAR, everything works normally. Oh and reaction wheels work fine in all cases. The following log appears in all cases, no errors, nothing bad from FAR either. I already informed the kOS guys, but thought you might have an idea. If you want to give it a go, just make a simple rocket and input "LOCK STEERING TO HEADING (20,20)." in KOS terminal. After you launch, if the rocket stays straight instead of turning, it means I'm not crazy

I seem to have a problem controlling the vessel with any FAR v0.15.6.5 related control surfaces. I'm trying to use LOCK STEERING TO HEADING(x,y) during the ascent. If I don't use any gimbaled engines, the winglets twitch on all axis very fast, while the craft remains pointing up and "stable". The vessel ignores any Heading commands, both from the script and the console. With gimbaled engines added, the craft behaves normally on yaw and pitch axis, except for the roll axis which again twitches wildly, but the craft is "stable" on that axis as well. After removing FAR, everything works normally. Oh and reaction wheels work fine in all cases. The following log appears in all cases, no errors. [LOG 11:13:09.577] kOS: FlightControlManager: ToggleFlyByWire: steering True [LOG 11:13:09.577] kOS: FlightCtrlParam: Enabled: steering False => True [LOG 11:13:09.578] kOS: FlightCtrlParam: toggle steering parameter

Thank you so much for this!

Roger that and thanks. Don't worry, I know about the negative timer feature. Been seeing it a lot .

Aye aye. That's why I used quote marks . I can't imagine how I could've played early Hard career with my current settings. But you're wrong on the second one. Yes you can set the grace period, but in flight there is no indication that you've entered it because you ran out of EC, how much time has passed since then, or, better, how long you have until your kerbals suffer from it. Here, my kerbals are seconds from dying, after EC ran out "2 days ago": My suggestion is to add a bit of code to the Sup timer. If you run out of EC but have supplies, the timer turns BLUE and starts to count down from your currently set Supply Time. When you have EC but don't have supplies (or both), timer acts the same way, but in red. Possible?