Jump to content

BevoLJ

Members
  • Posts

    155
  • Joined

  • Last visited

Posts posted by BevoLJ

  1. On 3/9/2017 at 7:48 PM, Nittany Tiger said:

    If you're using TOA, then you'd just flip the sign or flip a difference in the calculation.  The calculation for TOA is somewhere.

    I actually changed to monitoring vertical velocity and having the code aim for zero vertical acceleration.  It works, but it's still a bit inaccurate.  When I launch manually, I always check apoapsis and vertical velocity and aim to get my vertical velocity at zero right at SECO to get a circular orbit.  As for a preset apoapsis, that might depend on initial pitch deflection.

    This is a fun thread!  Will need to set aside time this weekend to read it.  =)

    I do something somewhat similar but rather than vertical speed I use orbital velocities.  set desired parking orbit and then get the required orbital velocity I will need to achieve that desired parking orbit.

    _mu = gravitational_parameter
    _radius = parkingOrbit_radius             # (parking orbit altitude + parent body radius)
    
    desiredVelocity = sqrt(_mu / _radius)

    I can then use the semi-major axis during launch to predict what my current velocity is at my apoapsis (if I were to cut engines during launch and just go there).  That way during launch I can see how much I need to change the velocity (deltaV) of my apoapsis to achieve the desired parking orbit I want.

    Here is my predictive apoapsis speed using semi-major axis:

    _mu = gravitational_parameter
    _r_pe = periapsis_radius                  # (current periapsis altitude + parent body radius)
    _r_ap = apoapsis_radius                   # (current apoapsis altitude + parent body radius)
    
    predicted_apoapsis_Velocity = sqrt((2 * _mu * _r_pe) / (_r_ap * (_r_ap + _r_pe)))

    using the known needed deltaV for the desired parking orbit I can now easily adjust my pitch during launch to achieve that altitude.

    parkingOrbit_required_deltaV = desiredVelocity - predicted_apoapsis_Velocity

    (Note: previous reply to @stratochief66 where I also use (mean anomaly - 180) to keep in mind where the ap is and include pitch adjustments for that aswell)

     

    All of the above is ideal for doing Hohmann Xfers but a launch is basicly just a fancy Hohmann Xfer that (from Earth) include atmospheric flight.  :P

  2. On 3/9/2017 at 11:28 AM, stratochief66 said:

    I'll have to check the tank type, try that again. I thought I changed it, but I may have gone to BalloonCryo, which perhaps isn't as good. If you find and share the setting you changed that you know worked, i'd appreciate it. :)

    We could/should start (or find a pre-existing) threat for complex RSS/RF automation like kOS or KRPC. IIIRC, I used "time to apo" as an input for my final orbital insertion program, but I had to do something clever so that it turned into a negative number when I was past AP, rather than a very large number. I think I used the orbital period, like: usefulAP = timeToAP -  orbitalPeriod when timeToAP was greater than 1000 seconds or something. I know @Agathorn and @BevoLJ have strong kOS/KRPC automation skills.

    o/ Chief!  =)

    If we are talking about pitch adjustments for circularising orbits at ap or pe, I use mean anomaly.

    _ap_deltaDeg = np.rad2deg(self.mean_anomaly()) - 180  # launch circ and hohmann xfers

    for hohmann xfer burns at pe, I just use the mean anomaly straight for pitch adjustments.  =)

  3. Just looked to find the function I used for that, but looks like I didn't upload any of my pre-launch code.  =(

     

    A couple things I remember is that one of the hardest things about that module was the warp-to part in RSS.  Due to latency and how fast the time-warping is in RSS, it was a challenge, and a robust RSS time warp function was essential part of my libs.  Especially for that particular pre-launch function.

     

    For the launch time part, I will poke around some of my archives to see if I can dig my py script up.  But for now you can just check how sarbian does it: MechJeb

  4. Oh, opps.  I totally just misunderstood what you were asking.  Utilization.  I for some reason read that as thrust.  My bad @Jovus.  /facepalm 

    I have used utilization a few times but only for very particular cases.  Almost always best to just set to 100%.

    The main cases I go lower is to put more mass at the top of the rocket.  As far from the engines as is possible.  This gives the engine gimbles far better control of the rocket.  Mostly this is useful to get through MaxQ, but can even be useful in a vacuum as better control authority is always helpful regardless.

  5. On 9/25/2016 at 7:42 PM, Jovus said:

    What's the deal with utilization?

    Specifically, why wouldn't I just push it to 100%?

    I recognize that it's useful for replicating rockets, because it allows you to play with mass and delta-V without deviating from the specc'ed dimensions, but what if I'm not concerned with replicas?

    Is there some downside, either coded or style-wise, to just pushing that slider all the way to the right?

    In a vacuum I can't think of a reason not to push it all the way to the right.  But most missions start on Earth, so not in a vacuum.  Limiting thrust can help set ideal TWR for launches and timing gravity turn events. (ex: staging during MaxQ typically has explosive results. :P )

    /facepalm  Sorry read that as thrust. I added a situation for what you were asking in post two down.

  6. On 5/16/2016 at 0:19 PM, Malah said:

    Hello, I've an idea how to correct this. I will make some test on it. Thanks for the report :wink:

    Also just noticed this issue using Quick Hide, where it hid the icon for @Agathorn's Test Flight.  Already mentioned it to him and he is looking at it. 

     

    Edit: All other mods are working fine.  Also TF does show up in the Quick Hide settings, but nothing seems to get it to show up on toolbar.

    f0ea171e25.jpg

  7. Wondering if someone could help me out. Derpy question, no doubt, but having trouble with the celestial bodies. I'm trying to get mu but having a hard time.

    How could I print the name, mu, or anything from celestial bodies? I've tried:

    import krpc
    conn = krpc.connect(name='WTB a mu')
    print(conn.space_center.CelestialBody.name)

    that works (kinda) but what it returns is "property object at [stuff]"

    *using .name for sake of testing

  8. 16 minutes ago, pellinor said:

    I don't see what this is supposed to do. Furthermore it does not depend on the 'eng' variable so why is it inside of the FOR loop?

    In my understanding ship:partstagged("something") will return a list of parts. Probably the IF is trying to convert that list to a bool. In some languages this is equivalent to "the list is non-empty", but I don't think that kOS supports that.

    What I am trying to do is get the information from only certain engines. I can figure out how to list engines.  And I can figure out how to get info like eng:maxthrust or eng:visp. But I'd like to get that info for only some engines, not all.

    So my thinking was for the engines in a list if one is tagged something then it gets the info from that engine. Maybe if I pulled its UID out? Or any suggestions on another direction I could go to try to get the info?

  9. Thanks for the suggestion! I tested that code and it is still giving the same error.  It is still erroring on the ship:partstagged("CoreEng"). If I could get that to work, that would open up tons of new opportunities in RO/RSS being able automate calculations. For now I think I will just stick to uploading manual updates from my own pen/paper calculations to the vessel prior to ullage.

    Thanks anyway! =)

  10. 30 minutes ago, hvacengi said:

    We do not currently support getting information off of inactive engines.  It's a topic that has been discussed multiple times but honestly we have things higher than it on the priority list.  I am curious about the error however.  Where does it throw the error, in the string addition or elsewhere?

     

    LRssUru.png

  11. Wondering if anyone might be able to help point me in a correct direction. I am currently trying to get info (visp, thrust, ...) on non-active engines to plan burn times and such prior to ullage. Tried a few things, but none are working out how I'd like.

    One is listing my engines but can't get thrust info. So for example:

    local en is list(). LIST ENGINES IN en. local enlength is (en:length-1).
    
    LOCAL Eng_isp is en[enlength]:visp.	LOCAL eng_maxthrust is en[enlength]:FUELFLOW.
    
    print "An engine exists with ISP = " + Eng_isp.
    print "An engine exists with mTh = " + eng_maxthrust. //can't get thrust to work

    So I thought I'd change how I do my ullage and activate the engine with throttle at 0 so I don't waist any ignitions. That sort of works, but code gets messy if ullaging with solids for obvious reasons.

    Another idea I had was tagging the stages in VAB.

    LOCAL en is list(). LIST engines IN en.
    FOR eng IN en IF ship:partstagged("CoreEng") 
    	{ LOCAL Eng_isp is eng:visp. }
    
    print "An engine exists with ISP = " + Eng_isp.

    I feel this would be a perfect way to accomplish what I'd like, but it doesn't work.  I can't figure out why. It gives an error saying it can't cast to destination type, but I don't understand what that means. Perhaps someone who is more knowledgeable might be able to enlighten me? =)

  12. On 4/16/2016 at 11:52 AM, DanMingle said:

    Hi, i'm having a problem where I can't get the right click interface with any of the experiments! I can use the many unit but not any of the attach-ables. I download the mod straight through CKAN and it's currently the only mod (along with the generic science module thingy and KIS/KAS) on right now. I am also not getting the "structural girder" attachment point on the main unit when I use any tool yet the node does appear when try to attach the wire connectors

     

    On 4/16/2016 at 2:33 PM, cyberpunkdreams said:

    So it wasn't just me after all!

    Was having same thing.  As Zeta mentioned, downgrading to  DMagicScienceAnimate .11 fixed it for me.

  13. EDIT: Nevermind!  After spending an hour on this I figured it out moments after asking for help on the forums! =D  For anyone wondering I just changed it to: 

    local en is list().
    	LIST ENGINES IN en. FOR ENGINE IN en { IF ( ENGINE:ignition ) { print "An engine exists with ISP = " + ENGINE:ISP.}}

    _____________________________________________________________________________________________________________________________________________

     

    Another question if you don't mind.  I am having trouble trying to find my engine stats for some calcs.  I have been through the documentation and seen many examples others use, but can't seem to get them to work (except for final stages).  The example engine code on the documentation (below): 

    local en is list().
    	LIST ENGINES IN en. FOR eng IN en {
    		print "An engine exists with ISP = " + eng:ISP.
    	}

    gives me:

    Quote

    An engine exists with ISP = 0

    An engine exists with ISP = 0

    An engine exists with ISP = 320

    An engine exists with ISP = 0

    An engine exists with ISP = 0

    An engine exists with ISP = 0

    I have been searching around on Reddit and such seeing how folks pull the needed ISP from that and all the code I have found show they use en[0]:ISP.  But on my ship en[0]:ISP returns 0 rather than 320. Which is a problem since the calculation I am using ISP in is dividing by 0. However just doing en[2]:ISP works great for getting this particular stages info.  I however lack understanding on how the numbers in [] correlate to stages or engines on the ship.  I would like to just get the ISP of the engine on the current stage without needing a new function for each stage.  But as I understand if I use the en[2] my function probably wouldn't work for the previous and following stages and engines?  Any possible suggestions or examples on only pulling isp and thrust from current stage engines rather than en[0]:ISP/...?

  14. Having a bit of trouble with my script since the update.  I have a when statement that runs my faring function.  It says it is taking to long to be done in a trigger. I have never had any issues with this when statement before so was hoping someone could take a look at my code and help me make it a bit faster.  I use this function for many other purposes, and trying to avoid adding faring specific code (not really much room left on my cpu) but do you think that is the only option?

    Spoiler

    FUNCTION Event_allparts { PARAMETER module,event. LOCAL Part_list is list(). LIST parts in Part_list. FOR p in Part_list {
        IF p:modules:contains(module) { LOCAL m is p:getmodule(module). m:doevent(event). }}}

    WHEN alt:Radar > 30000 Then {Event_allparts("ProceduralFairingDecoupler","jettison").} 

     

  15. I have been having a lot of trouble with KSP Interstellar.  Hoping someone might be able to help.  When I load into my save I get a popup that tells me "KSP is unable to find files it needs... pls check WarpPlugin folder.." or some such. I've installed mods countless times over the years in KSP, so I know it is there.  KSP Add-on Version checker in the main menu sees it: (Bottom of Spoiler)

    Spoiler

    KSP: 1.0.5 (Win32) - Unity: 4.6.4f1 - OS: Windows 8.1  (6.3.10240) 64bit
    Filter Extensions - 2.4.1.3
    Ambient Light Adjustment - 1.5.4.2
    Community Resource Pack - 0.4.9
    Contract Configurator - 1.9.6
    CC-CP-SCANSat - 0.6
    Contract Pack: RemoteTech - 2.0.1
    Contracts Window Plus - 1.0.6
    Crowd Sourced Science - 3.0.2
    CustomBarnKit - 1.1.3
    Engine Lighting - 1.4.1
    Firespitter - 7.1.5
    Interstellar Fuel Switch - 1.18
    RasterPropMonitor - 0.24.2
    Kerbal Attachment System - 0.5.5
    Kerbal Engineer Redux - 1.0.19.4
    Kerbal Joint Reinforcement - 3.1.4
    KIS - 1.2.3
    kOS - 0.18.2
    KSP-AVC Plugin - 1.1.5
    Modular Rocket Systems - 1.11.1
    Docking Port Alignment Indicator - 6.2
    NearFutureConstruction - 0.5.5
    NearFutureElectrical - 0.6.1
    NearFuturePropulsion - 0.5.4
    NearFutureSolar - 0.5.5
    NearFutureSpacecraft - 0.4.4
    S.A.V.E - 1.2.4.1314
    Outer Planets Mod - 1.9.2
    QuickHide - 3.0.3
    QuickSearch - 1.2.1
    RCS Build Aid - 0.7.7
    RealChute - 1.3.2.7
    RemoteTech - 1.6.9
    SETI-RemoteTech - 1.0
    SCANsat - 1.1.4.8
    SETI-Contracts - 0.9.6
    SETI-CommunityTechTree - 0.9.6.3
    SETI-BalanceMod - 0.9.6.1
    ShipManifest - 4.4.2
    Sigma Binary - 1.4
    SpaceY Expanded - 1.1.5
    SpaceY Lifters - 1.10
    StationPartsExpansion - 0.3.4
    TAC Fuel Balancer - 2.5.1.7
    TarsierSpaceTechnology - 5.8
    TextureReplacer - 2.4.12
    TAC Life Support - 0.11.2.1
    Kerbal Alarm Clock - 3.5
    Transfer Window Planner - 1.4
    TweakScale - 2.2.6
    VenStockRevamp - 1.9
    KSP Interstellar Extended - 1.6.8
    Waypoint Manager - 2.4.5

    But upon loading the save it doesn't see it, and none of the parts are available in the VAB or RnD center.

    Edit to add log: https://www.dropbox.com/s/6qv89dmlfqy7a3n/output_log.zip?dl=0

  16. On 1/29/2016 at 11:59 AM, TeeGee said:

    Audio: Simulate what sound would really be like if we were to travel faster than the speed of sound and in vacuum of space. Proper rocket, rcs and airbreathing engine sounds please. IVA sounds. Comms chatter. 

    Sound requires a medium (like air) to travel through. It is a wave of vibrations/changes in pressure through those air particles.  Obviously there is no air in the vacuum of space so no sound.

    Inside the cabin where the Kerbals are, there is (pretend) air. So the IVA, Comms and such sounds do exist.  However that air (and the sound waves within it) is moving with the space ship.  This is a very different situation from on Earth where the air is traveling around Earth rather than with an airplane whose speed/direction would cause difference in pitch or sonic booms.

×
×
  • Create New...