Gfurst

Seriously for Actual surface speed all you have to do is VESSEL:SURFACESPEED = number in m/s, as per doc. On another note: I've been trying to use pilot input as above, for fine direction correction of vessel while in ascent. Because of FAR I can't simply make big direction changes.... Please check out my new program code below: DECLARE PARAMETER stg1. // Number of stages SET logfile TO ship:shipname + ".log". // Log file name SET text TO "". // General variable to use text SET time0 TO time. // Initial time LOCK time1 TO time - time0. // Elapsed time SET t0 TO time1:seconds. // Reference for delta t LOCK td TO time1:seconds - t0. // Delta t elapsed since last ref IF (stg1 <= 0) { // Check appropriatte parameter SET text TO time1:clock + " Invalid parameter, set number of stages". PRINT text. LOG text TO logfile. //BREAK. // need to add a way to terminate program } ELSE { SET text TO time1:clock + " Beginning program at " + time0:calendar + ", " + time0:clock. PRINT text. LOG text TO logfile. SET text TO time1:clock + " Number of stages parameter: " + stg1. PRINT text. LOG text TO logfile. } WAIT 1.0. SET stg0 TO 0. // Staging count SET throt TO 0. // Throttle track SET cntd0 TO 9. // Launch countdown SET drect TO ship:facing. // Maintain initial direction LOCK throttle TO throt. LOCK steering TO drect. // Launch Countdown SET text TO time1:clock + " Beginning Launch on T-:" + (cntd0+1). PRINT text. LOG text TO logfile. WAIT 1.0. UNTIL ( cntd0 = 0 ) { SET text TO time1:clock + " ..." + cntd0. PRINT text. LOG text TO logfile. SET cntd0 TO cntd0 - 1. // Begin engines burn IF ( cntd0 = 1 ) { SET throt TO 1.0. SET text TO time1:clock + " Engines on". PRINT text. LOG text TO logfile. STAGE. SET stg0 TO stg0 + 1.0. } WAIT 1.0. } // Release launch stabilizers SET text TO time1:clock + " Releasing clamps". PRINT text. LOG text TO logfile. STAGE. SET stg0 TO stg0 + 1.0. // SolidFuel stage IF stage:solidfuel > 0.1 { WHEN (ship:altitude >= 20000) AND (stage:solidfuel < 1) THEN { SET text TO time1:clock + " Releasing SolidFuel boosters". PRINT text. LOG text TO logfile. STAGE. SET stg0 TO stg0 + 1.0. } } // Regular stages WHEN (true) AND (stage:liquidfuel < 0.1) THEN { SET text TO time1:clock + " Fuel depleted, activating next stage". PRINT text. LOG text TO logfile. STAGE. SET stg0 TO stg0 + 1.0. IF ( ship:liquidfuel > stage:liquidfuel ) { PRESERVE. } } // Wait until 4000 for control UNTIL (ship:altitude >= 4000) { IF (td >= 10) { SET t0 TO time1:seconds. SET text TO time1:clock+" alt:"+ROUND(ship:altitude)+" hdg:"+ROUND(ship:heading)+" sfr:"+ROUND(ship:surfacespeed)+" apo:"+ROUND(ship:apoapsis). LOG text TO logfile. } WAIT 0.5. } SET text TO time1:clock + " Reached 4000 meters altitude". PRINT text. LOG text TO logfile. SET text TO time1:clock + " Allowing pilot correction Control". PRINT text. LOG text TO logfile. UNLOCK throttle. SET ship:control:pilotmainthrottle TO 1.0. // Pilot correction control WHEN (true) AND (ABS(ship:control:pilotpitch) > 0.9) THEN { SET crtvl TO ROUND(ship:control:pilotpitch). SET drect TO drect + R(crtvl,0,0). SET text TO time1:clock+" Pitch correction of "+crtvl+", direction pitch of "+ROUND(drect:pitch). LOG text TO logfile. PRESERVE. } WHEN (true) AND (ABS(ship:control:pilotyaw) > 0.9) THEN { SET crtvl TO ROUND(ship:control:pilotyaw). SET drect TO drect + R(0,crtvl,0). SET text TO time1:clock+" Yaw correction of "+crtvl+", direction yaw of "+ROUND(drect:yaw). LOG text TO logfile. PRESERVE. } WHEN (true) AND (ABS(ship:control:pilotroll) > 0.9) THEN { SET crtvl TO ROUND(ship:control:pilotroll). SET drect TO drect + R(0,0,crtvl). SET text TO time1:clock+" Roll correction of "+crtvl+", direction roll of "+ROUND(drect:roll). LOG text TO logfile. PRESERVE. } UNTIL (ship:altitude >= 24000) { IF (td >= 10) { SET t0 TO time1:seconds. SET text TO time1:clock+" alt:"+ROUND(ship:altitude)+" hdg:"+ROUND(ship:heading)+" sfr:"+ROUND(ship:surfacespeed)+" apo:"+ROUND(ship:apoapsis). LOG text TO logfile. } WAIT 0.5. } SET text TO time1:clock + " 24 thousands meters altitude reached". LOG text TO logfile. PRINT text. UNTIL (ship:apoapsis >= 69000) { IF (td >= 10) { SET t0 TO time1:seconds. SET text TO time1:clock+" alt:"+ROUND(ship:altitude)+" hdg:"+ROUND(ship:heading)+" sfr:"+ROUND(ship:surfacespeed)+" apo:"+ROUND(ship:apoapsis). LOG text TO logfile. } WAIT 0.5. } SET text TO time1:clock + " 69k Apoapsis reached". LOG text TO logfile. PRINT text. SET text TO time1:clock + " Closing Program". LOG text TO logfile. PRINT text. SET ship:control:pilotmainthrottle TO 0.0. UNLOCK steering. I'm trying to achieve a direction correction by reading on pilot input and then adding that input to the steering direction: // Pilot correction control WHEN (true) AND (ABS(ship:control:pilotpitch) > 0.9) THEN { SET crtvl TO ROUND(ship:control:pilotpitch). SET drect TO drect + R(crtvl,0,0). SET text TO time1:clock+" Pitch correction of "+crtvl+", direction pitch of "+ROUND(drect:pitch). LOG text TO logfile. PRESERVE. } First issue it seems is that Input from pilot actually responds on the vessel, contradicting that pilot doesn't have control. Second it seems that input from the automated steering is also read as pilot input. AS a result first time I tried this instantly stopped the program for breaking the IPU limit as constantly reading input from the steering. I tried to solve this by limiting the condition to > 0.9 from input, so the ship navigates a bit more but still stops from too much processing inside WHEN loop. The WHEN is triggered several times before responding... Also there might be some oddities which adding of directions that I have yet to figure out. As for the triggers I thought they would only be check each cycle obeying the wait time inside the UNTIL loops, apparently it doesn't. I'll try to find a more elegant way for the coding, but still, the pilot command readings should only read on from actual commands and not from steering itself. On another note, I saw that some things in the Doc already begun to change. Nice! Be sure to check on cpu_hardware page, Its an important topic but doesn't show up on front page.

I do think the documentation pages are in need of tidy up. Yesterday I've found this page http://ksp-kos.github.io/KOS_DOC/command/variable/index.html and for the life of me couldn't find it again today. Only way to reach it is through the file I/O command page. Ps: I'm aware of the coding fault in the file I've posted above, got a bit confused first time reading those docs.

So I spent all this afternoon squezing out my brains potential to come up with a generic launch algorithm to use with my rockets. Check out my code please and how does this fare, if there could be some faults and improvements. One notable part is the terminal velocity which won't correspond with my used FAR data giving inaccurate speed. Any suggestion how to change that? // General Launch Script // attempt 1 by Gfurst SET thr0 TO 0. SET thr1 TO 1. LOCK throttle TO thr0. SET cntd0 TO 5. SET drct TO ship:facing. SET time0 TO TIME. SET stg0 TO 0. // Pre-launch countdown begin PRINT "Beginning Launch:" UNTIL cntd0 = 0 { PRINT "..." + cntd. SET cntd0 TO cntd0 - 1. WAIT 1. }. PRINT "Launching.". LOCK throttle TO thr1. LOCK steering TO drct. LOCK sfrvlc TO ship:surfacespeed. LOCK trmvlc TO ship:termvelocity. // Launching up WAIT 1. STAGE. SET stg0 TO stg0 + 1. PRINT "Engines on.". WAIT 2. STAGE. SET stg0 TO stg0 + 1. PRINT "Releasing clamps.". // Time delta for loop control interval SET time1 TO TIME. LOCK timed TO TIME - time1. WHEN timed > 1 THEN { SET time1 TO TIME. preserve. }. // Thurst correction SET thrcrt TO true. WHEN (timed >= 1) AND (sfrvlc / trmvlc >= 0.90) THEN { SET thr1 TO thr1 - 0.05. WAIT 0.1. IF thrcrt { preserve. }. }. WHEN (timed >= 1) AND (sfrvlc / trmvlc <= 0.85) THEN { SET thr1 TO thr1 + 0.05. WAIT 0.1. IF thrcrt { preserve. }. }. // If staged with solid fuel boosters IF stage:solidfuel > 0.1 { WHEN (timed >= 1) AND (stage:solidfuel < 1) THEN { PRINT "Releasing SolidFuel boosters.". STAGE. SET stg0 TO stg0 + 1. }. }. // Regular stages WHEN (timed >= 1) AND (stage:liquidfuel < 0.1) THEN { PRINT "Fuel depleted, activating next stage.". STAGE. SET stg0 TO stg0 + 1. IF ship:liquid:fuel > 0.1 { preserve }. }. // Direction correction after 5000 height. WAIT UNTIL ship:altitude >= 5000. SET drctcrt1 TO true. SET drctpitch TO 45 WHEN ( timed >= 1 ) AND ( drct:pitch <> drctpitch ) THEN { IF (drct:ptich > drctpitch) { SET drct:pitch TO drct:pitch - 1. }. IF (drct:ptich < drctpitch) { SET drct:pitch TO drct:pitch + 1. }. WAIT 2. IF drctcrt1 { preserve }. }. // Correction for 25000 altitude WAIT UNTIL ship:altitude >= 24000. SET drctpitch TO 0. WHEN (timed >= 1) AND (thr1 = 1.0) THEN { SET thrcrt TO false. PRINT "Ending throttle control". }. // Now waiting for Apoapsis WAIT UNTIL ship:apoapsis >= 69000. PRINT "Escaped the atmosphere.". PRINT "Shuting down engines.". SET thr1 TO 0.0. SET drctcrt1 TO false. // Wait for circulizing burn Good to know you will consider this. There are all sorts of useful data that makes life that much easier without having to bang your head doing all the calculations yourself. Some simple stuff like delta V, current TWR, terminal velocity, but more complex stuff like impact time, closest approach, and such. Unfortunately the part I've mentioned is only to enable the Engineer window to be viewable in flight, but doesn't show anything it self.

Finally gathering enough courage to delve into this type of automated flight. One quick question: Does SHIP:TERMVELOCITY actually gathers out terminal velocity, as in FAR flightdata, or does it calculate in a stock way? In other words, does it show a FAR compatible value? And one quick suggestion: Maybe you could think of linking up with the Kerbal Engineer mod , if its enabled, and use some of its reading data and stuff. After all it can require a part as simulation of the data being processed. This could reduce the same data being processed in two different mods, but the main advantage is to make kOS a whole lot more intuitive to use. Reduce the need of the user on burning his brain trying to come up with even simplest stuff. And potentially be more welcoming to lot of new users. Lastly, how updated is the doc stuff?

Hey there magico, me again buging you on yet another one of your mods Playing yesterday something happened which I didn't know was possible: Stage burned in atmosphere Is this normal or is because I have 'deadly reentry' enabled? How can I avoid this?

Has anyone delved into the info drive? This little part is amazing at solving some of my most complicated action group issues. Has anyone seen some other mod for that reason specifically or knows how to add the module to a command part?

May I ask you first, which are the prob engines you're using? FireSpitter? I would liek to try me some front engines too. To answer your (non-existing) question, when you reach higher altitudes, air gets thinner and thinner, having less air density requires a greater air speed to maintain same lift. Its a natural trade-off. However most engines tend to lose power going higher, jets will flame-out due to less oxygen. But this is specially more important on propeller engines, propellers works as airfoils, little wings rotating, as such their power depends on air density(less density less lift). Though, I'm sure prob engines don't work as such on KSP, they are simulated by loosing power with height. 25km and up is around the edges of space, very low air density (read above). The edge between controllable atmosphere and non controllable is a weird place where aerodynamics don't always work as we think. Around that altitude and above wing don't provide as much lift, and control surfaces specially will barely provide any control, so be ready to switch to SAS units and RCS, this will greatly help you to control your craft. As for pitch up spin, I bet its the air-intake causing it, for reason they provide an weird drag when going out of air, be ready to close all intakes and shutdown air engines (action group key). Hope this helps.

Well that was fast, thanks I'll try it out tomorrow.

Hello fellow space explorers. Wanted to check with you on some weird behaviour. While in flight scene in game, input stuff and numbers into boxes, from mods and whatnots for whatever reason, can cause certain mayhem, inputs pass along to controls and such can activate action groups, engines, move around and etc. This apparently is a very known issue, however someone told me we could use keypad instead, and I've found this weird, keypad doesn't input anything. Yes, numlock is on! I thought this to be a very common issue as the above, is it not? Is it a Linux specific issue? Could I fix it somehow? Please let me know, cheers!

Hey guys, So I've run into this weird issue. Never Noticed it before but for sure it worked in 0.24 Saving some sub-assemblies, I'd write some text description for it and I like to put on a weight rate for the payload its supposed to carry. Trying that yesterday, I found that game sort of crashes, well it doesn't actually crashes but glitches out, window closes, can't click anything else, can't exit the screen, can only alt+F4 to exit game. This is reproducible every time, parts doesn't matter, input number on other boxes doesn't matter too. I have several mods in use, some that might be relevant are, FAR, editor extensions, KCT.... Debian Linux KSP 0.25 64-bit

Sooooo, I find that the ejection option is really useful but the ejection part is really cumbersome and out-of-place. Already scaled down the part to half its size but its still ugly, specially with some other small parts I have to attach on the capsule. Sooooo, does anyone knows if its possible to add this eject module to regular capsules/cockpits? Maybe a simple cfg file would do the trick, anyone?

Tested the v0.6 features yesterday, and it works perfectly. The WASD is really a fine feature and helps a lot on controlling. Just one small oddity, during test I tried to maintain level flight while cutting throttle. So to stay level pitch and angle of attack would need to increase while speed is dropping, eventually reaching stall. However with speed dropping the aircraft doesn't pitch up to increase AoA even though I've set an high limit on PiD limits. The pic below shows it Anyway, I have to advise on overcomplicating the mod too much as it greatly increases chances of conflicts and issues, as well a escaping its original scope. Ohhh and btw, how would like me to do a showcasing video of the mod? Oh yeah, I almost forgot about the keypad thing, numlock is on, is just doesn't do anything, wonder if its only an issue for me or general to the linux version.

Hey guys, I was about to comment on the jet launch smoke weirdness. Usually I have to disable it manually, but just now I was looking into the configs files for something obvious. So I think this will solve the issue, though I haven't tested and may be horribly wrong: On MP_Nazari/launch_hotrockets.cfg, I'm assuming is the one responsible to adding the Launch smoke to solid fuel booster. It begins with: @PART[*]:HAS[@MODULE[ModuleEnginesFX],!PROPELLANT[Oxidizer]]:FINAL { Which I'm guessing is directed at rocket engines that don't have Oxidizer as propellant, thus the Boosters, but it mistakenly accepts the Jet engine that only has LiquidFuel as propellant. So I think this will fix it, BUT again, I'm only guessing... @PART[*]:HAS[@MODULE[ModuleEnginesFX],PROPELLANT[SolidFuel]]:FINAL { Please let me know if this works.

Hey there, thanks I'll be trying it soon. I actually have keypad but I don't think it works in KSP. This happens to be a common issue for me, having to go to map screen to be able to input stuff without screwing everything up. Mostly necessary with with RemoteTech flight computer and maybe others. About the blizzy toolbar, would you consider it?

Hey there, just saw and tested this mod yesterday, pretty awesome. Been looking for something like this for ages. Unfortunately I can't input the numbers directly without activating a bunch of action buttons. But its fine eitherway... Anyway, I thought to suggest for you to move the button to blizzy's toolbar if that available. Just cus you know, it offers more flexibility.

LoL, how many 'release candidates' versions are there? *hint hint* you're supposed to scrap the RC after you have good enough version of what you want. Anyway, just dropped by to thank you on the mod. I have great mastermind plans to categorize ever part in the context it deserves to, but I don't know if I'll ever get to it...

Hey, first of all much thanks for this great mod. Just a little bit of a request: could you make it so that if Blizzy toolbar is installed to use that instead of stock? Just trying to reduce a bit UI clutter.

Hey there, thanks for the add-on. Just dropped to ask for small request: could you make so that the mod detects if there is Blizzy's toolbar installed, and use it instead of Stock, just so we can reduce UI clutter a bit? edit: scratch that, fiddle a bit again and found out its already implemented... Thanks and sorry

Hey there, thanks for the awesome mod, should be implemented to stock KSP. I have just a little request to make: can you implement that if detects blizzy toolbar installed, then it will use it instead of stock, leaving it in the same place if not found. (just to clear some UI clutter) And one additional, not so small request: maybe adding a transfer button to the CLS window, to use as an alternative to the stock transfer tool. Thanks and cheers.

Just thought I drop in to mention that apparently Part Catalog also needs to be on the blacklist, no icons or buttons appearing for me.

Awesome, pretty new stuff and exactly what I was thinking of, thanks!

Hey guys, this has been brought in quite a few times, but there is still a lack of this type. A very simple auto-guidance switch, that holds heading and altitude, relative to the body its flying in. Really simple stuff, very similar to auto-pilot system you would find in most general aviation. Note that still no mods currently present this actual implementation. ( and if there is any, please tell me) Additionally there could be some more interface to alter trajectory, like set up a climb rate, roll rate, that stuff. And of course looking this to use with FAR aerodynamics, but can't why it shouldn't work with stock. Please share your thoughts on this. I'll try to implement this sort of auto-pilot with the existing scripting auto-pilot mods out there, but still don't know how to. Cheers, and sorry if text is a bit confusing, I'm a bit light-headed.

LoL, quite an adventure han? Some more advices then: before installing the proprietary AMD drivers, try up with stock Xorg drivers, they might work better specially for Multi-screen setup. I can't help you with multiple monitors since I never delved into it and saw a necessity. Since most of the issues you're getting are more OS related, be sure to head up to the Ubuntu forums, more likely where there will be a lot of helpful people to assist you. Try to stick with Ubuntu , but I would recommend using another graphical environment instead of it stock Unity, Xfce is light and flexible, ideal if you're only going to game on it.

Yeah, about to suggest too, alt+f is the same for FPS viewer, and usually I don't a need to open the window with a quick key. But what is your f key activating?

You took my advice, awesome . Very happy to see that, will report back if I notice anything wrong. And of course, thanks for the awesome addon.