TDW

Have you turned on remote tech compatability in the config? Config documentation here: http://ksp-kos.github.io/KOS_DOC/structure/config/index.html Edit: also are you running the program from the archive or local storage? If it is from the archive then when RT losses connection to KSC then kOS losses connection with the archive and he programme stops.

The kerbal construction time mod does simulated launches for a minor cost (it also handles spent stage recovery and makes rescue missions challenging when you have a life support mod)

@Trewor007 You should be able to do: set czas to (time + spot:distance/gaz) - time. print czas:clock. This should force the variable from a number to a time, so that you can use :clock. If you want to do it by calculations (i am assuming that czas is the time you have calculated) then Set hours to floor(czas/3600). // 3600 is 60 seconds *60 minutes (note floor always rounds down so 59min will round to 0 hours not 1). Set min to floor((czas-hours*3600)/60). // take the time in seconds then remove the number or hours (in seconds) and / 60 to get minutes. Set sec to round(czas - min*60 - hours*3600). // seconds remaining after you remove the hours and minutes already accounted for.

It does . When it is used in a script LOCK THROTTLE will revert back to the default / what ever it was set to before you ran the script when the script ends. Because your script ends so soon after locking the throttle (possibly within a single physics update) you don't see any sign that it has run.

The scripts are saved to the active volume (either on the current kOS core or whichever you have switched to) Scripts saved to a kOS core are saved in the persistence file (save game file) in the ship structure. Scripts saved to the Archive (volume 0) are in .../Kerbal Space Program/Plugins/PluginData/Archive/. @Astraph Camach did a better job of explaining this than my garbled attempt so i will quote. If you use "WAIT UNTIL" instead of "WHEN .... THEN" your script should work. clearscreen. Print "Initiating landing procedure". Print "Step 1: Retrograde thrust". lock steering to retrograde. wait 10. lock throttle to 1.0. WAIT UNTIL ship:altitude < 100. Print "Step 2: Atmospherical reentry". lock throttle to 0.0. lock steering to prograde. toggle AG2. WAIT UNTIL ship:altitude < 10000. Print "Step 3: Deploying chutes". Stage. wait 2. lock steering to up. toggle legs. WAIT UNTIL ship:surfacespeed = 0. Print "Landed safetly". toggle AG2.

@Cairan The copy command does not currently recognise prog as a variable but instead looks for a file called prog (same apply to the other file I/O commands - found here). The current work around is to log commands to a temporary file then run that. So instead of: COPY prog TO kerbstone. you would need LOG "COPY "+prog+" TO kerbstone." TO temp. // I don’t know if you need prog or prog:name for this. after you have completed the for loop run temp. Worth noting that you cant modify temp after you run it (well you can but you the program wont load the modified file unless you restart the program). e.g. LOG "PRINT 1." TO temp. RUN temp. LOG "print 2." TO temp. RUN temp. This will print 1 1 not 1 1 2.

Read the post after the one you quoted (and the one 2 above it) They include a working script that throttles individual engines and a craft file for a demo craft that uses them. It's part of a much larger script i was working on but have stalled because it I need to re-write it (that or set a silly config:ipu). But that fragment should still work. Engines in that script are identified by putting them in their own stage, however you could identify them by ISP (throttle back the engines with the lowest ISP first, during launch to stay below max q) or use any other engine/part suffix to identify them.

Oops: They are on google docs trying to work out permissions now. EDIT: Fixed (I think) apparently you cant use right click "copy image URL" for google docs:rolleyes:

Ok been away form the PC for a while. Worth noting that this is with KSP 0.24.2 and kOS 0.14 but I doubt that it will make a difference in this. If you feel it would i will be happy to take more pics when i get round to updating, which will probably be this weekend. Image of "rocket" with the above script. After adding R(90,0,0) to the facing you get this: Which is far more usable. However If the engine is rotated as is often the case when using multiple boosters (or symmetry) you get this (without the rotation): But because the rotation is applied around the control parts co-ordinate system (I think) and not the engine parts co-ordinates applying the same rotation does this: Another possible case (possibly the main case) is engines that don't point in the same direction as the vessel in which case you get this (without rotation): With rotation: EDIT: The quoted script has been modified to detect engines in stage 0. I believe the facing being reported by KSP is the "front" facing in the CAD package use to make the mesh and that most engine parts are made upright (engine bell on bottom face) because it makes scene to the modeller, with only control parts being made with much thought to what KSP would report as the facing. Any way, this means that in order to apply the correct rotation to the part you must work out its orientation relative to the control part (and if you know that querying the part:facing of anything other than a control part is moot). And if the engine rotates (using IR parts) then it is impossible to calculate the new direction of thrust. Is there a way to rotate a vector about the co-ordinate system of the part that the facing is being take from and not the one of the current control part? That way while the player would have to work out the orientation of the mesh within the CAD package the rotation would always be the same for that part no matter how it was placed. I will point out that I do have a workaround for this but it is not very nice, it involves part clipping a sepatron between the tank and engine and then querying the facing of the sepatron instead: Note the 0 fuel in the sepatron - really not good if you accidentally stage it wile it is full.

The reason your script is ending having only done the first when trigger is because when (and on) don't need to be completed for the script to end, they are interrupts but the script finishes before they are triggered. Your script will continue indefinitely (until you press Ctrl+C) if you add a dummy wait at the end eg. WAIT UNTIL 1>2. that will prevent your script from ending and as long as it is still going then the interrupts can be triggered. It may be better though to use something other than WHEN to throttle back your ship.

Is it possible to make the part facing give this? The direction it currently gives is 90deg from the direction of thrust (for the engines I tested), but as rotation is done about the vessel facing i can't think of a way to get it in line. quick test script, identifies an engine in stage 2 and draws its facing. SET vec TO vecdraw(). UNTIL 1 > 2 { List engines in foo. for eng in foo { IF eng:STAGE = 2 { SET dir to eng:facing. }. }. SET vec:VEC TO dir:vector. SET vec:SCALE TO 5. SET vec:SHOW TO true. }. Edit: oops code was wrong, forgot to loop the list engines.

Sorry that was only a segment of a larger script. The first section of the script (where you set all the variables) would need to include: SET done TO FALSE. - done is just a variable that has I have set as a boolean toggle. SET efo TO FALSE. - again efo is another custom toggle set up by the script (standing for engine flame out, but you can use whatever you want). PRESERVE. - when included in a trigger (on / when) means that it can be triggered more than once. info on that here.

The liquidfuel can be replaced with any resource name so just change it to stage:[whatever your engine burns]. My preference for staging is to do this though: When efo THEN { STAGE. SET efo TO FALSE. PRESERVE. }. UNTIL done { LIST ENGINES IN l_eng. SET efo TO FALSE. FOR ENG IN l_eng{ IF ENG:FLAMEOUT{ SET efo TO TRUE. }. }. }. so long as any new engines are in the same stage event as the decouplers that will stage any engine liquid or solid whatever it is burning, and works with asparagus staging too, without having to put in a value for the tank sizes. the rest of the launch script can either be done as when triggers or if conditions inside the until loop.

Oops, realy should close some of these tabs every now and again. fixed. Will get on it, might be a while though as i need to learn C# first. I shall treat this as incentive:). Ok haven't tried a rover script before the equation i posted above is what i have been using to fly hover / vtol craft to a way point (placing a flag in the air was proving tricky:P). Couldn't get LOCK WHEELSTEERING to a heading to work at all. But these comands work; lock wheelsteering to target. lock wheelstering to latlng([latitude],[longitude]). //no need for the equation i posted above on rovers. will look at this for aircraft but probably wont use it as i cant do any correction on it (to pull prograde onto the heading instead of just pointing at it). set ship:control:wheelsteer to [1 to -1]. // if you want raw controls.

@falken IR / generic right click menu support is being worked on (4 posts back ) current support is via action groups and querying part facing. Are you asking for help writing this or for someone to write it for you? If its just a couple of pointers you want then here is how I would start out; - First you need the truss part to be identifiable, with engines you can identify by stage but the truss would need a unique(to the vessel) part in it for this. - Then the axis of rotation for the rotatron (should be the same as its facing, i think). - The vector from you to the sun. - Remove the axis of rotation component from the vector to the sun (vxcl). - Use action group to rotate rotatron until the angle between the truss facing and the flattened of the sun vector approaches 0. - If you want it more advanced then you can take the normal of the truss facing and rotatoron axis and if the angle between that and the flattened sun vector is >90 rotate 1 way and if it is < 90 rotate the other. Edit: The vector maths can be can here http://ksp-kos.github.io/KOS_DOC/structure/vector/index.html Edit 2: I forgot I came here to ask my own question . Is there a way of forcing ROUND(var,2) to give decimal places even if there are none eg. 10.00 instead of 10? not a major thing just trying to neaten up a readout.

@InvertedBlack Gaiiden has a rover script here http://forum.kerbalspaceprogram.com/threads/86177-kOS-12-2P3-Rover-Driver-pre-release . If you want to just use lat & lon as way points (instead of game objects)i would suggest looking into great circle navigation. Which will give you a variable heading for the shortest path between 2 co-ordinates not essential but it helps when navigating near the poles. Edit: Here is the equation for heading (tlat &tlon are target latitude and target longitude respectively) LOCK heading TO ARCTAN2(SIN(tLon-SHIP:LONGITUDE)*COS(tLat),(COS(SHIP:LATITUDE)*SIN(tLat))-(SIN(SHIP:LATITUDE)*COS(tLat)*COS(tLon-SHIP:LONGITUDE))). great circle nav can also be used to find surface distance but i don't have the equation for that to hand.

@foma87 Have you considered just moving the [wait 0.001] to between the [stage.] and [print "staged".] Also unless you are using them for something else then you probably don't need to put the isp and thrust in their own lists. You could try something like this to make the code shorter: FOR eng IN e { IF eng:ignition { SET thrtot to thrtot + eng:maxthrust. SET thrisp to thrisp+(eng:maxthrust/eng:isp). }.

I'm getting the same thing too. (way to many mods to work out which conflict it is but I do have tweak scale so its probably that in my case too). Anyway mostly comenting to say that if you set disableAuto = true in the settings.cfg it fixes it, or at least i havent had the isue since doing that. EDIT:just had it again on reverting to save not on initial launch. EDIT2: will put up the log if it happens again (now that i have found where linux hides it).

Absolutely loving this mod. Just started a new career mode and it is maddeningly frustrating (in a good way), forcing me to do things like start building a rocket before i have finished researching the tech for all the parts then add them in half way through the build. May I be so bold as to make a feature request? This is probably most useful for space planes / reusable rockets but there may be other uses: A recover to storage button so where the vessel is recovered but no funds are received / player charged an amount by distance and the vessel moved to the relevant storage. The player would still need to edit the craft in the vab/sph to refuel etc. I know the build times get faster as i use parts more often and if i already have the parts. But doing it this way seems more like i am re-using the same vessel as opposed to stripping it down for parts every time (and accidentally using those parts in another vessel). Another useful feature would be the ability to build something as a sub-assembly so that you can start building the payload for your space planes next mission before it returns giving you a faster turn around (only needing to refuel, replace damaged parts and fit the new payload) Its quite alright if the answer is no:P on reflection those could be very hard to implement and i don't know if it is possible to retain damage states in the hanger.

Just thought of a (possible) issue with the label maker. Is it possible to override whether or not a part can have surface attachments for the label maker? If not it may be tricky to label some science parts, parachutes, radial engines, rcs etc. Edit: I think editor extensions lets you toggle it on and off without using module manager.

Multiple windows is going to be fun:). On the subject of identifying parts without writing a MM module to every part could this work; Create a surface attachable part (preferably small and discreet) call it a KOM port:rolleyes:, It can then identify the part it is attached to and right clicking on it brings up a text box that lets you input a variable name for that part? Would also have the added "advantage" of making the player think in advance about what they wanted kos to have right-click access to.

Well that will teach me for not reading the post or the readme properly . Work round on the clock issue would be: LOCK timeRemaining to (time + nextnode:eta - (thrustLength/2)) - time. Print timeRemaining:Clock AT (29,3). its not as tidy but it does force timeReamaining into a time instead of a number. Also if/when you look at reading the RCS ISPs you will (at least in the current version of KSP) need to add a check for an isp of 0. For some reason RCS ISPs read as 0.0 until after you fire them for the first time.

Looks good. Don't know if it was deliberate or not but you don't seam to have anything to align the craft to the maneuver node and hold it steady also you may want to look at PRINT timeRemaining:CLOCK AT (29,3). (KOS_DOC) if you are looking to shorten the script. You should also be able to loop that to keep the time to burn up to date.

Had this issue a couple of days ago (cant find the link to the solution) basically if you are on steam you just need to verify integrity and it you should get the button back. When i did it i backed up the gamedata and saves then re-installed it and restored them but that may be over the top. edit: found it here but it tells be that I "do not have permission to access this page". you can still find a cached copy on google though.

The scrip i posted works the issue i am having with it is that while i can set thrustlimit i cant find a way to lock it and would prefer not to loop it. i have included the test craft file in the spoiler if you want to play with it. (ag10 starts the engines if you stage them on the script cant tell which is which) EDIT: does not seem to work and i didn't want to take up that much space. is there a way of attaching text files to a post here? EDIT 2: craft file