TDW

Not sure if this should be in discussion or support. Anyone know of a way to toggle `Locked` for robotics parts in the VAB/SPH? Being able to set lock joints before physics loads in would be really useful. They are exposed in the craft file `servoIsLocked = True\False` but going through craft files trying to lock the right parts is awkward.

The bug appears to be caused by the texture quality graphics setting in the ksp main menu. If it is set to half or quarter res the textures for the characters don't load properly. If your system allows i would advise setting your textures to full res while this is looked into.

In kOS on and off are commands and cant be passed as variables. Try using true and false instead: // Pre launch Sequence. Execute before bottom most Stage declare function fn_PreLaunch { parameter b_SAS, b_RCS, b_Lights, f_Throttle, b_Gears. set SAS to b_SAS. // I want to set SAS to the variable b_SAS (Boolean: On / Off; [True or False]) set RCS to b_RCS. set lights to b_Lights. lock throttle to f_Throttle. //Throttle is a decimal from 0.0 to 1.0 set gear to b_Gears. }. // Here is the function call (changeable as needed per rocket and mission needs): fn_PreLaunch (true, true, true, 1, true). also worth noting that if you end the script after calling that function kOS will release the lock on the throttle and it will return to whatever it was before kOS took control. If you want the throttle value to persist try using set ship:control:pilotmainthrottle to f_Throttle. instead. However if it is run as a boot script when you first spawn the vessel on the pad that wont work as the throttle starts off at 0 then ksp sets it to 0.5. You need to wait a second or so before setting the throttle value to avoid it being overwritten by ksp.

Love this tech-tree but am having some issues with it in its current iteration. I am getting a module manager error during start-up that clams to be from this but dont know how to get more specific information about where it thinks the error is. Also when using it with Interstellar Extended the many of the nodes are shifted around and and overlapping (they are not in the positions that the .cfg tells them to be in). dont know what causes this either or if the MM error is responsible. The thought did occur that there may be a max area that the nodes can be in and the interstellar nodes push it outside that, but that is just conjecture. Edit: I am an idiot the CTT config in interstellar was messing with it.

You might like to take a look at how lib_pid.ks works. It handles both looking at data change over time and preserving the old info between function calls. Lists and other complex variables are treated as pointers so if you [set foo to list().] then [set bar to foo.] foo and bar are just 2 ways of calling the same object so changes made to the list by [bar:add( ).] will be seen when you call foo. This lets you create an init function that returns a list and have the parent script decide the variable name. Then when you pass the list name to the running function it can make changes to the list held by the script above it. Since the variable name is set by the parent script naming conflicts can be avoided without needing to dig into the function and change every use of the variable name to something else.

Please do submit it. You can create a pull request for it on the ksLib before it's finished (it can be labelled as "don't merge yet" until you are happy with it). Edit: Sorry I missed this a while back. Yes you should remove that part of the equation. Also worth pointing out that using the accelerometer experiment readings for this means that any unaccounted for forces will be considered to be part of the lift/drag (this includes RCS, Reaction wheels, engine gambol and any phantom forces) which will give odd readings in space. The further the accelerometer is placed from the centre of rotation the larger the false reading will be.

In that case would this F3 = M * a + v(dm/dt) - F1 - M * grav - v(dm/dt) be correct and in fact the v(dm/dt) cancels leaving you with just F3 = M * a - F1 - M * grav and you never need to calculate v(dm/dt) for the purposes of this?

@VFB1210 You seem far more familiar with this than me. can you clarify: should I be taking the +v(dm/dt) into account when calculating the force due to gravity as well as when calculating the force from the thrust? and if so should it be the full velocity or just the component of velocity in the direction of the force (vertical velocity)? Thanks

if @VFB1210 or anyone else wants to give these a go and fly around with lift and drag arrows coming out their vessel here is my lift/drag script. you will need to stick an accelerometer (the science experiment) on the vessel and the script still produces the occasional spike in lift or drag. feedback with any improvements or fixes would be greatly appreciated. example_lib_lift_drag.ks set ag1 to false. run lib_lift_drag.ks. clearscreen. set drag to vecdrawargs(v(0,0,0),v(0,0,0),red,"Drag",1,True). set lift to vecdrawargs(v(0,0,0),v(0,0,0),blue,"lift",1,True). print "Lift:" at (0,1). print "Drag:" at (0,3). until ag1 { set vec to lift_drag(). set lift:vec to vxcl(ship:srfprograde:vector,vec). set drag:vec to vdot(vec,ship:srfprograde:vector)*ship:srfprograde:vector. print round(lift:vec:mag,2) +" kN " at (6,1). print round(drag:vec:mag,2) +" kN " at (6,3). }. set ag1 to false. lib_lift_drag.ks @LAZYGLOBAL off. function lift_drag { local M is ship:mass. local a is ship:sensors:acc. local grav is -(body:mu/(body:radius+ship:altitude)^2)*up:vector. // negavive magnitude to up vector is down. local thrust is 0. // calculated by queriying the engines local fuel_flow is 0.// calculated by queriying the engines local eng_list is list(). list engines in eng_list. for eng in eng_list { set thrust to thrust+eng:thrust. set fuel_flow to fuel_flow + eng:fuelflow. }. local resultant is M * ( a - grav ) + fuel_flow * vxcl(ship:up:vector,ship:velocity:surface) - thrust * ship:facing:vector. return resultant. }.

Not a silly question. There are two different g values being used here. The g value when calculating mass flow rate is always 1 standard earth gravity (9.80665m/s2, 9.81m/s2 is usually used for most stuff though). However since the ksp exposes the mass flow rate of the engines you don’t need to calculate it, just add it all up from the different engines. The g value in calculating the force due to gravity does decrease with distance and you can see my calculation for it in the code i put up (re-posting the line here for reference) local grav is -(body:mu/(body:radius+ship:altitude)^2)*up:vector. // negavive magnitude to up vector is down. Mostly yes. I am actually defining drag as the force that slows you down and lift as the force causing you to deviate. so the drag being along the surface velocity is correct. And while most of the time the lift is acting through vessel:top i am using the component at right angles to the surface velocity (so it could be coming out the side of your vessel too if you yaw to far.) Yes.

kOS runs the code from top to bottom. Until false { } is an infinite loop as such the trigger is never created as in your script it would do that after completing the loop. Move the when trigger above the loop and it should work

That was my initial thought too but it would have to be on something very small at constant speed (or there are 2 mismatched units that cancel) as i took a plane out and flew it up to max speed. It gave the same value for drag (in kN) as the engine thrust (kN) when at level flight and constant speed.

I was getting readings for drag in space, that turned out to be due to the rocket flexing and the accelerometer being on the command pod (distant from the COM). But i have also been getting long periods of time (not just blips caused by staging engines) where the drag is reading as pulling the rocket upwards.

@VFB1210 Ok I think i am missing something here. I have: ΣF = F[SUB]1[/SUB] + F[SUB]2[/SUB] + F[SUB]3[/SUB] ΣF = M * a + (dm/dt)v Where: F[SUB]1 [/SUB]= Thrust F[SUB]2[/SUB] = force due to gravity = M * grav + (dm/dt)v[SUB]vertical[/SUB] // don't the changing mass apply to the force due to gravity too. F[SUB]3[/SUB] = Drag and lift Rearranged to: F[SUB]3[/SUB] = M * a + (dm/dt)v - F[SUB]1[/SUB] - M * grav - (dm/dt)v[SUB]vertical [/SUB]| (dm/dt)v - (dm/dt)v[SUB]vertical[/SUB] = (dm/dt)v[SUB]horizontal [/SUB]F[SUB]3[/SUB] = M(a-grav) + (dm/dt)v[SUB]horizontal[/SUB] - F[SUB]1[/SUB] In code this gives function lift_drag { local M is ship:mass. local a is ship:sensors:acc. local grav is -(body:mu/(body:radius+ship:altitude)^2)*up:vector. // negavive magnitude to up vector is down. local thrust is 0. // calculated by queriying the engines local fuel_flow is 0.// calculated by queriying the engines local eng_list is list(). list engines in eng_list. for eng in eng_list { set thrust to thrust+eng:thrust. set fuel_flow to fuel_flow + eng:fuelflow. }. local resultant is M * ( a - grav ) + fuel_flow * ship:vleocity:surface - thrust * ship:facing:vector. return resultant. }. but I am getting some odd reasults

@VFB1210 Was not sure if ksp took into account mass loss during a physics tick or just assumed constant mass during a tick (for optimization as it was doing the calculation so frequently). I always seem to lose out (dV wise) under phys-warp, I assumed this was because i was carrying the mass for longer. If it doesn't then assuming this as this is being done live (hopefully during a single physics tick) then mass is constant, otherwise yes you are right it could do with taking it into account. On the subject of the lift always being 0. I was planing to provide a combined vector (or a list of the 2) as the result so that people using it for planes (or vessels with significant body lift) would not have to run 2 separate (but almost identical) functions for the vectors, since the calculation only differs in the final stage. Edit: There are a number of ways to do it. You can look at stage:liquidfuel in the same way that you are using stage:solidfuel . but this wont work for asparagus staging. You can also look at drops in maxthrust. (this means that an engine has shut down) so //at the start of the script. set old_maxthrust to 0. // staging logic If round(ship:maxthrust,2) > old_maxthrust { // The rounding is done to prevent accidental staging due to floating point errors / tiny differences in maxthrust set old_maxthrust to round(ship:maxthrust,2). } else if round(ship:maxthrust,2) < old_maxthrust{ stage. wait 0.1. set old_maxthrust to round(ship:maxthrust,2). }. One advantage of this is that it does not need to differentiate between liquid or solid engines and it works for asparagus staiging. In the above form it requires the engines to be in the same stage as the decouplers, this can be changed but the code becomes more complex. One major thing this cant handle is drop tanks (eg the big orange tank on the space shuttle). An older method I used for this was to repeatedly re-list the engines and check for flame-outs but that has the same disadvantages as the maxthrust method and requires constant refreshing of a list. If you need to handle drop tanks. it is possible to have kOS navigate the part tree and look at the state of fuel tanks on the other side of decouplers, activating the decoupler if all the fuel is gone. Edit 3: (someone else post please so I don’t have to keep doing this with edits) Drag would always be opposite the direction of travel (prograde) if you calculate it using ship:facing then it would show less drag when pancaking :-P

There is a way to get a combined value for drag and lift. You use: total force = mass * acceleration total force = engine thrust + force due to gravity + lift&drag this gives lift&drag = mass * (acceleration - gravity) - thrust It requires the use of an accelerometer for the acceleration as i don't think kOS will let you get the acceleration without one. But it should work. (am trying to put together a lib file for it now) Edit: if drag is assumed to be along the retrograde vector then lift and drag can be split up as well with the lift component being at right angles to the direction of travel. Edit2: it should be noted that this method can only be used on the fly and not for predictive calculations.

Here: http://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html And because a vessel is also an orbitable these too: http://ksp-kos.github.io/KOS_DOC/structures/orbits/orbitable.html

There is a 1.0 compatibility release on the github https://github.com/KSP-KOS/KOS/releases/tag/v0.17.2 There may be some bugs so test you're scripts before relying on them but it is up an working in 1.0.

Vessel:Heading gives a heading to that vessel. So ship:heading is asking for the heading to yourself, hence the realy small number.

What does the stock resource panel show for total liquid fuel and stage liquid fuel?

You can set them both as boot files in the VAB. Name 1 boot_lower.ks and the other boot_upper.ks and set each core to the relevant boot script by right clicking on them.

@KK4TEE A drop in mass will work. Another way of doing it would be to detect that the number of kOS parts on the ship had dropped. set previousNo to 0. set currentNo to 1. until currentNo < previousNo { set previousNo to currentNo. set currentNo to ship:modulesNamed("kOSprocessor"):length. }. If you were using raw controls you could try: wait until status <> "PRELAUNCH". wait until ship:control:neutral. another way of doing it is to use action group triggers (as action group state is the same for all cores on a ship).

Not had this problem with the space bar before (I have it with all other vessel controls) but you could try using this mod to help: http://forum.kerbalspaceprogram.com/threads/108561-0-90-%28Jan25-15%29-Control-Lock-Input-text-into-text-fields-without-issuing-commands-to-your-vessel

Is the file store on the vessel or on archive? If it's on archive then it is a file on you're hard drive either in (old KSP folder)\plugins\plugin data\archive\ Or (old KSP folder)\ships\scripts\ depending on the kOS version. Copy the file from there and put it in (new KSP folder)\ships\scripts\ If it is a .text file change it to .ks If it is running locally on the vessel then: If you are using remote tech and the craft is out of com range then: - Backup save - Remove remote tech .dll from the game data folder (just the dll not the parts) If not using RT or if with com range jump to here. - Load save and open vessel - In the terminal type switch to 1. Or whichever volume it's on - Then list. to get all file names on that volume - Then go through typing copy [my_file] to 0. For each one to put the on the archive. - Go back to the first bit that tells you how to get them off the archive.

it just toggles the power on and off in both cases.