TDW

Members
  • Content Count

    77
  • Joined

  • Last visited

Community Reputation

11 Good

About TDW

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. @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
  9. 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. }.
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. @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
  15. @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