kcs123

I have put action group in example above to ON command as most obvious and easiest to use. But it can be tied to any other variable that can change value. You can also use WHEN command instead, for example, to send STAGE button when craft is run out of fuel/thrust. Also, in future versions of kOS you can build GUI window for command imput instead of terminal, to enter values trough buttons, checkboxes adn similar. There was discussion about it couple months ago, you can find it in this thread 10 -20 pages back. Example from alpha GUI version of kOS: On picture is shown GUI to choose autopilot flight mode, to execute maneuver node in space, gently land powered rocket or to hover at certain altitude or to maintain desired vertical speed. You can choose to lock steering trough input boxes or you can continue to control craft trough WASD keys while autopilot control throttle to do hovering. That is just simple example, you can build even more advanced stuff, but under the hud is similar code structure like shown in previous post. You can also use parameter at begining of script for desired display mode. The following is example from my rocket launch script that actualy use only sequence of commands until reaching orbit without endless loop. // Arguments for program must be on top parameter MyHeading is 90. // initial heading for orbit - influence starting inclination parameter MyApoapsis is 120000. // Desired APOAPSIS of orbit parameter ApETA is 27. // time before reaching Apoapsis when circularization burn start clearscreen. // example of usage to run from terminal print "Use double quote and numbers for parameters". print "Example: runpath('/rlaunch',90,120000)". // function that will display dynamic data on terminal function DynamicDisplay{ parameter output. // dynamic data - mandatory parameter parameter startCol is 17. parameter startRow is 9. // define where the block of text should be positioned print output at (startCol,startRow). print round(SHIP:AIRSPEED,2) + " "at (10,startRow+1). print round(SHIP:ALTITUDE,2) at (10,startRow+2). }. wait until SHIP:MAXTHRUST > 0. // waiting idle until staged once for launch // kOS is not aware of triggers yet. It will not automaticaly stage on it's own // staging whenever ship is out of fuel // "WHEN" command is trigger or event. Command inside brackets will run when condition is met // "PRESERVE." command ensure that event will be triggered again when craft run out of fuel again // kOS CPU is not aware of this until it reached for first time when SHIP:MAXTHRUST = 0 then { STAGE. print "Staged". DynamicDisplay("Staged "). preserve. }. // after this point kOS is aware of trigger and it will stage craft when it is out of fuel/thrust // put some other code here to lock steering/thrust to something until desired apoapsis is reached // some more code to circularize orbit when craft is near apoapsis Now, instead of heading and apoapsis as arguments, you can use display_mode as argument, to display data that you need on terminal. And inside of DynamicDisplay function you can put additional IF command that will print output only for desired display mode. You can also tie WHEN trigger to craft speed or altitude that will execute display function only when craft reach certain speed instead on each physical frame tick. Above is just rude example of usage, not whole script code. Only your imagination is limit of possible usage in your own scripts.

Huh. I thought that "wait 0." is exactly same that you want to wait just one physical thick, or in other word not have to wait at all. Anyhow, I actualy have that command in some of my scripts, but for reasons that I was experimenting with various values above zero and zero. Haven't noticed issues using it or not inside loop and it didn't cause significant change in EC consuption. But also, it has been a while since I played KSP. I almost skiped whole 1.2.2. release and 1.2.3. is almost published, things might be changed in both, kOS and KSP. I always tend to put commands that belongs to some "if" condition inside curly brackets even if there is just single line of code. Just my old habit for easier reading and understanding code when you revised it after several months. That also saved me from nasty bugs that come out of blue. Anyhow, above is just example of loop usage without any actual calculations/commands inside.

@eberkain, quite opposite. That is why we have triggers or events that can be created with WHEN or ON commands. In your example, you should use UNTIL loop, instead of WHEN trigger. Also, you should avoid to declare variable names with same as keyword/command used in kOS language. Any programming language will be confused with it. I pointing to "run" variable that is also legacy command for "runpath". You should also avoid to clear screen inside loop, you will get bad flickering effect on terminal screen because of that. Also, since you have said that you have experience with C++ and C# languages, you can take advantage of functions to make all code more "clear" adn easier to read and understand. Here is some example what I mean: set terminate to false. // main variable preventing script to end set output to "". set MyAction to false. clearscreen. // this will be printed only once on terminal, to avoid flickering print "kOS autopilot Keys: ". // Row 0. print " Action Group 4 : Toggle something ". print " ". print " ". print " Press CTRL + C to terminate program ". print "--------------------------------------------". print " ". // Row No:6 print "Speed : ". // Row No:7 print "Altitude: ". // Row No:8 // some simple function to display data on demand inside loop function display_block{ parameter output. // mandatory parameter parameter startCol is 0. // optional parameter parameter startRow is 6. // define where the block of text should be positioned print output at (startCol,startRow). print round(SHIP:AIRSPEED,2) + " "at (10,startRow+1). print round(SHIP:ALTITUDE,2) at (10,startRow+2). }. // kOS will be aware of this function existance in rest of code // Defining trigger or event with "ON" command on AG4 { toggle MyAction. // if it was false value will be true or oposite if MyAction = true { set output to "Autopilot is active ". } else { set output to "Autopilot is passive". // you can put some other commands here, to unlock controls or something }. preserve. // ensurance that AG is triggered again on demand }. // --- end of trigger definitions ---- // -------- initialization of script before main loop set some_other_variable to "something." // to be used for something in main program // ------------------------------------------- // main program executing in loop until CTRL+C until terminate { // Print dynamic data on terminal display_block(output). // function call if MyAction = true { // put some custom code here when kOS control craft }. }. // end of main program // ------------------------------------------- And I got ninjaed while writting this example

Wthout any additional mod, you can use stock autostrut "bug" as feature. While in flight, right click on arm tip part and turn on autostruting to root, grandparent or heaviest craft part, whatever suit better on your craft design. It should help a bit while in transit. Once you need to use arm, you need to disable those autostruts. You can use autostrut in editor and in flight. To acess that feature, you need to enable advanced tweakables trough game menu. Beside those, i found also useful B9 struts that have ability to act as decoupler too. I stiffed my rover legs while in transit to Mun. Once landed, i decoupled struts and continue to use rover as intended.

KJR does similar autostruting to all parts like wheels/landing gear does in stock game. You either need to edit XML config file for KJR to stop autostruting all parts to each other or use newer developer beta version. Use links from few pages back. This one from github might work too. https://github.com/MagicSmokeIndustries/InfernalRobotics/issues/146 or you can use this info: Basicaly same thing.

Sounds like autorstrut issue. It can come from landing legs/wheels near robotic arm or if you use KJR mod, use latest dev version. There is several posts on this topic. Just search few page back (might be even 10 or more, things get buried quickly here) You can also follow link in my signature for craft exchange thread. I put some info for IR there too.

Unless you use until or for loops, it execute commands in sequence until end of file is reached. Exceptions from that rule are functions and triggers. Function only need to be declared once in code. I'm kind of old school programmer, so i like to have all global variables and function declared on top of file. Then after that some initialization code following by one endless loop that ends only on certain action group triggered or only trough CTRL+C. WHEN and ON command is a bit trickier to understand. In C++ or C# world better term would be "event". Meaning, once you wrote that block of command, it is executed when certain condition is met. If you use preserve keyword inside when block, it means that same part of code will be executed again if same conditions are met. However, when part of code must be executed in sequence at least once, to be active, before you start loop for your main program. I hope that above make some sense, english is not my native language, so I don't know if it is explained properly.

It looks like conflict with mixing manual and CKAN automatic installs. Also, keep in mind, when you uninstall something trough CKAN, it may not always remove some folders properly. Because of failed folder removal, new install might recognize that something is already installed. Backup everything first, of course, but try to uninstall both, TCA and MKS. Then delete any reamaining folders that CKAN was not able to remove. After that install both mods trough CKAN again. It should work.

I just checked in game, atlas is rocket engine that is more noticable to be sluggish in throttle response. I was not sure about exact engine names when I posted first time. Other engines probably have some latency too, most likely each engine behave slightly different. They provide some trust immediately, but for full thrust they need some time. It will be hard to create compleately universal script that will work on all crafts. In one of mine kOS scripts I have used combination of full throttles and when closer to target for smooth slow down I used PID controled throttle. Still need to work on fine tuning PID constants to get one smooth burst instead of short bursts, but it work much better that just ON/OFF with full throttle.

Yes, they got. Not so noticable as jet engines, but can screw timings, like in your scenario. That was giving me hard times with customizing some of mine kOS scripts until I used that in account. Try to keep right click engine info opened and track current thrust. As you put full throttle from idle, you will not get always full available engine thrust imediately. It is not so noticable difference like with jet engines, but when very tight timing is required it can ruin your day. Anyhow, I'm glad that you overcome issue. Looking forward for next version of TCA.

You might found more info about console update in thread opened just for consoles: http://forum.kerbalspaceprogram.com/index.php?/forum/81-technical-support-playstation-4-xbox-one/ Your question might be easy missed by developers here.

Hmm. @allista, I see two possible issues here. ateroid location is calculated from center of mass, not from edge of surface engines does not have full thrust immedietaly when started. It takes few ms up to few sec to have full calculated thrust Therefore, when you calculate time when you need to start engines, you need to substract 1-2 sec for engine start and add 50m or so to distance from targets. Once engaged, PIDs should take care of stoping too early, but can't compensate if they were not started on time.

Not exactly same thing, but I used struts from B9 mod. Those have new function to act as decoupler. Unfortunately, you can't use them to attach on something in flight like grapler parts. @Elmetian have mentioned that he used quantum struts for similar purpose. I don't know what exact mod is for quantum struts, though.

Looks like wheel/landing leg autostrut issue. Or if you use KJR, use dev version, check out links couple of posts above.

You are welcome. I'm glad that I was able to help. But it will be good to tell where you get file #3, so other users can be warned about it and be less confused about install procedure in future.

From where you get file #3 ? When unpacked "GameData" is not file, it is directory (linux/dos term) or folder how it is called on windows OS. You need #1 and #2 that have "GameData" directory that need to be copied into KSP game folder. Be sure that you don't copy GameData inside GameData folder in nested way. You only need one "GameData" directory in main KSP game directory. Optionaly, instead of legacy parts, or on top of it you can use ZodiusInfuser reworked parts. You can find proper download links in this post: It looks that you downloaded IR from some other source that contain additional directory that should not copy-pasted just like that, but I can't be more specific as I don't know what you have downloaded and from what source.

Download and unpack files, each archive in separate folder outside of KSP game. When properly unpacked, each archive contain Gamedata subfolder. For IR core pack and IR part pack you can find MagicSmokeIndustries subfolder. Copy that MagicSmokeIndustries subfolder in your main KSP Gamedata folder. Besides folders for IR mod, you will also need module manager plugin. It is dll file that should be in KSP Gamedata root folder. Without it almost non of mod will work in KSP. Pretty much any mod made for KSP have it's own folder and files that belong to it. That mod specific folder is always copied into KSP main gamedata folder. Tricky part is that some authors pack archive with "Gamedata" folder inside while some mod authors don't. So, you should pay attention what you copy and where you copy. It might be good if you are new with using mods in KSP to try out some other mods, to get familiar how moding works in KSP in the first place. IR is still in BETA stage for latest KSP version, some things does not work as desired, so it might not be a good choice for new users. Try to search for some info how mods works in KSP, there is plenty of info in forums about it, before going deeper with IR mod.

By definition, MAX function will return bigger value from two that is given as parameter. In your case, one value is constant "5" and other is result from equation 90 * (1 - SHIP:APOAPSIS/50000) Now, that equation will reduce pitching based on percentage how far your craft is away from 50000 m. At sea level you will get 90 * (1 - 0), meaning your craft will pitch at 90 degree as it will be larger than value of "5". As craft climb up, pitching will decrease smoothly until you reach 50000. After that, if there is no MAX function, your craft would start to pitch down. So, when you reach 50 km, your craft will continue to accelerate at fixed 5 degree pitch, until told otherwise in some other part of script. EDIT: I can only suggest that you change fixed number constants with variables. So, instead of 50000 define something like this: set Final_AP to 50000. // put some other nasty code here until SHIP:APOAPSIS >= Final_AP { set V1 to max(5, 90 * (1 - SHIP:APOAPSIS / Final_AP)). // put some other piece of code here too } That way, if you need to tune your script, you only need to change values at begining of script, without need to change rest of code. Further down the road, you can run whole script with parameters , so instead of fixed value for Final_AP you can use passed parameter. Just few examples of possible usages from top of my head.

I guess that leveled level 1 runway should be better than forcing players to use grass. At least when there is still no penalty from taking off / landing on grass nearby. If SQUAD ever deceide to change behaviour of other terrain surfaces than it might have sence to have more bumpy runway, but with better friction than grass or something similar.

I posted some info how to workaround of that issue with wheels/landing legs, but it get buried quickly in forum thread. This is link for reposted info and galery for workaround. If it going to work or not depends highly how you design your craft. However, turning autostrut visualisation helps a lot with design process.

Unfortunately no. It is hardcoded within game exe.

There is no full IDE compatible with kOS, at not least one that I'm aware of. However there is some tools for various editors that help with keywords highlights and such: https://github.com/KSP-KOS/EditorTools It does not give you list of available object properties when you write "." after object name like modern IDE do, but above are some help at least.

you just need to delete configs for tweakscaling other parts and left only those regarding IR parts. I think that all config files regarding TweakScale are in Tweakscale folder, but it is always possible that some moder wrote those scaling configs inside their own mod.

It is hard to tell withot any log or additional info, but my best guess here is that CKAN "registry.json" file become corrupted or something similar. Be sure that you backup everything in CKAN folder elsewhere. Then delete whole CKAN folder, leave just ckan.exe. Then try to run ckan again. It should re-create necessary files/folders again. You can then copy backup download folder, so you don't need to downlad all mods again. You might going to reinstall those mods, though, so CKAN can handle them in future, or just leave it as it is and uninstall / install some mod when it is updated. Btw, my windows 10 at work have updating some system files today, still need to do similar on my home machine, don't know if that is reason for crash, though.

**sigh** From a page far, far away: