Jump to content

ElWanderer

Members
  • Posts

    397
  • Joined

  • Last visited

Posts posted by ElWanderer

  1. 44 minutes ago, maculator said:

    Thank you. I don't understand a thing for now, but I guess the wiki and some testing will help me. All I'm learning in KOS is based on small steps and alot of wiki consulting.

    I looked up a previous solution I've given for your kind of question (https://www.reddit.com/r/Kos/comments/66pdll/question_about_steering_and_vectors/). It does involve even more vector manipulation than my previous example, I'm afraid:
    
    // VELOCITY:SURFACE should be the same as SRFPROGRADE:VECTOR
    LOCK horizon TO VXCL(UP:VECTOR,VELOCITY:SURFACE). 
    LOCK STEERING TO 
        LOOKDIRUP(ANGLEAXIS(pitchAngle(),
                            VCRS(horizon,BODY:POSITION))*horizon,
                  UP:VECTOR).

    That pitches up (or possibly down), by whatever number the pitchAngle() function returns. The VCRS (vector cross) of the horizon and a vector pointed at the centre of the planet (straight down, I guess, should be equivalent to -UP:VECTOR) returns a vector that is at 90 degrees to both (pointed at the horizon to starboard), meaning it can be used as an axis to rotate our steering vector around, to pitch up or down.

  2. 1 hour ago, maculator said:

    Is there a way to tell it to just hold the direction unaffected by compass?

    Depends exactly what you want. The following would orient to the current velocity vector, but  aimed at the horizon, also keeping the top of the aircraft upwards:

    LOCK STEERING TO LOOKDIRUP(VXCL(UP:VECTOR,SRFPROGRADE:VECTOR), UP:VECTOR).

    The vector exclude removes all up from the surface prograde vector, so the resultant vector points at the horizon. However, you may want to pitch up or down a certain amount, which would mean rotating the resulting vector. I've posted something like that before... now to see if I can find it.

  3. 6 hours ago, infinite_monkey said:

    I'm having trouble RCS-steering my Tundra Exploration rockets. Steering seems to counteract itself, resulting in veeeeery slow or no movement at all. The control pod's reaction wheels have virtually no torque, so steering has to rely solely on RCS. When I manually enable SAS, it starts moving. Since that shouldn't be used together with LOCK STEERING and results in heavily oversteering, i keep enabling and disabling SAS until orientation is close to where it should be.

    Is this a bug or can I do something about it?

    I think the kOS steering manager is much less effective when a craft doesn't have much/any reaction wheel torque. It is optimised for "medium torque":

    http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#advantages-disadvantages

    You may be able to adjust the steering manager settings to something that works better for this particular craft.

  4. 3 minutes ago, maculator said:

    Is there a way to make a thing like this work:

    
    function get {
    	parameter folder, file.
    	copypath("0:/folder/file.ks","1:/file.ks").
    }

    (This obviously doesn't work and is there to illustrate my problem)

    function get {

        parameter folder, file.

        copypath("0:/" + folder + "/" + file + ".ks", "1:/" + file + ".ks").

    }

  5. 7 hours ago, maculator said:

    I'm unable to access the function hudmessage from the script the bootscript loads.

    Does your boot script end, then you run tourist.ks manually? Functions and variables set by a script only stay available while that script is running.

    My approach is to set-up the mission files as boot scripts and have each one run common library/init scripts on start-up.

    If your boot script is copying tourist.ks into place then running it, that should work.

     

  6. It's been a while since I did a Jool-5, but:

    I kept the mothership in mid Jool orbit, rather than taking all that mass from moon to moon.

    I had a nuclear powered tug for transfering Landers about.

    As has been suggested a lot, I had a multi-stage lander that would leave the descent stage on Tylo, the upper stage had enough delta-v to do Vall descent and ascent, then (short-fueled to help the tug) both moons in one go. I had a Laythe spaceplane.

    In your original post, I think some of your delta-v estimates are on the low side. I could've sworn it took me 1200m/s each way to land on and return from Vall, for example, and unless you have a very efficient autopilot, you'll want at least 3km/s to land on Tylo (the more the better if landing manually) and the same again to ascend (though that can be done more cheaply if you get a good gravity turn going).

  7. 12 hours ago, dafidge9898 said:

    Hello everyone! I have a question regarding my code; I am at a loss as to why one piece of it doesn't work. It's a when statement and its contents from line 39 to 44. It's supposed to start and finish a gravity turn. In the past (maybe one or two years ago) I used this same statement to perform gravity turns, and it worked out fine. I have since started playing again and it doesn't work for some reason. Some background info: I have many mods, including Realism Overhaul and its required mods.

    Code: https://pastebin.com/uBi6eTyA

    Thank you in advance!

    Try commenting out lines 39 and 44.

    The UNTIL block you have above ensures that the conditions of the WHEN will be met immediately. So you may as well run lines 40-43 right away.

    To put it another way, it is really confusing to mix imperative UNTIL statements with WHEN interrupts/triggers in this way. Triggers should be used for something that you anticipate happening, but don't know when (in relation to the rest of your code).

    As to why it doesn't work now: from memory the lock steering command (which itself sets up a trigger) within a trigger is not actually applied until the trigger block exits, at which point it'll immediately be countermanded by the lock steering in the UNTIL block below, so it'll never be used. I think this is a known issue: https://github.com/KSP-KOS/KOS/issues/2191

  8. 3 hours ago, PsychoMuffin said:

    Here is a link to my predicament: https://ibb.co/fkEVHc

    As you can see, I am very close to the lower of the three, but not yet in it. Can you tell which way I need to go? I cannot zoom in any more.

    I may be completely wrong in this, but I thought the location of the waypoint was at the tip/bottom of the marker. With that in mind, I'd aim Southwards initially, correcting once pitched over enough to see the marker on the navball...

  9. 21 hours ago, MindChirp said:

    wait until alt:radar > 70000. global pitch is 90. lock steering to heading(90,pitch).

    This will try to steer upwards, rather than towards the horizon. Surely you should be aiming at a pitch of 0 here?

    Doesn't answer why you don't see RCS firing, of course. That is a bit inexplicable without more information (e.g. what does your rocket look like?)

    Also, you have that code within the for loop, when it really belongs outside it.

  10. 1 hour ago, Whateverest said:

    there is a way to change the navball setting by using SET NAVMODE TO value.

    Ah, I didn't know that! :)

    57 minutes ago, Whateverest said:

    UNLOCK STEERING.
    WAIT 0.5.                                  // so sas has time to recognize navball change
    SAS on.
    SET NAVMODE TO "Surface".
    WAIT 1.                                       // so sas has time to recognize navball change
    SET SASMODE TO "Prograde".

    The waits here could probably be just one tick (WAIT 0).

    Alternatively, you could use the kOS steering to follow prograde instead of SAS:

    LOCK STEERING TO SRFPROGRADE.

    or

    LOCK STEERING TO LOOKDIRUP(SRFPROGRADE:VECTOR, FACING:TOPVECTOR).

    The first of those will roll to keep the ship's "top" facing upwards; the second of those will prevent that. It depends on what you're launching as to which is better.

  11. 3 hours ago, kcs123 said:

    I recently got similar NullReferenceException error in otherwise prooven working script that I used a lot of time. It is set to be executed at boot time. Rather simple script, to execute  maneuver node burning. Case when it failed is on complex craft with lot of parts and possible other installed mods too.

    I solved issue by adding wait 1. command, to allow game physics to settle down before starting any calculation when some of ship parts/properties not being completely unpacked on scene change. Or something similar that caused issue. Just something to keep on mind when starting up scripts on boot/scene change.

    Yes, I've had my common initialisation script call 'WAIT UNTIL SHIP:UNPACKED.' for a while, to avoid weird issues. Though I think most of mine were due to booting up (after regaining power) during time warp.

  12. 6 hours ago, Whateverest said:

    UNTIL APOAPSIS {    IF SHIP:MAXTHRUST < 0.2                   // if the thrust decreases the stage is burnt out
                {    STAGE.                        // decouples empty stage, activates retros, activates next engine
                    SET SASMODE TO PROGRADE.            // switching from surface to orbital prograde
                }
                ELSE { WAIT 1. }.                    // to avoid kOS doing too many calculations

    This section seems to be missing a closing curly bracket, so your "UNTIL APOAPSIS" (does that have a greater than comparison, or did it get eaten?) loop encompasses the rest of your script, down to your comment about having to add a curly bracket in. That probably means it won't work as expected.

  13. 6 hours ago, Whateverest said:

    And Im trying to SET SASMODE TO "SRFPROGRADE"

    Try "PROGRADE" instead. Though it's up to you (as the player, not script writer) to ensure the navball is in surface mode.

    Edit: remember the SASMODE is just replicating the user interface to the SAS options to the left of the navball. You can only pick values KSP knows about.

    https://ksp-kos.github.io/KOS/commands/flight/systems.html?highlight=sasmode

  14. 26 minutes ago, sevenperforce said:

    But how high are they, really? And what are they really made of? How do we know they aren't, like, balloons?

     

    I clicked on that tweet hoping there would be a sassy reply from Elon... sadly no one at all seems to have responded.

  15. 10 minutes ago, Yahnyx said:

    And when it finally reach the desired rotation, the rocket starts to roll quickly, and never stops.

    The likely reason for it rolling once the ship is pointed towards the desired vector is that by default it is trying to match your ship's "up" facing with the "up" facing of the RETROGRADE direction. Try using "LOCK STEERING TO LOOKDIRUP(RETROGRADE:VECTOR,FACING:UPVECTOR)." That creates a direction formed of the vector you want to point towards, with the ship's "up" pointed where it is already facing. It shouldn't keep rolling though - you don't have SAS enabled, do you? If so, turn it off as it'll fight kOS's steering commands.

    If you're entering the atmosphere, you may prefer SRFRETROGRADE (surface retrograde) to RETROGRADE (orbital retrograde).

  16. 1 minute ago, Gargamel said:

    No, No... Don't Panic is a much better reference for a car in space.    I betcha there's a towel in the trunk too. 

    Hopefully that displays properly... (you may have to click into the tweet, then the left-hand image to see the towel reference)

  17. 2 minutes ago, Brainlord Mesomorph said:

    I don't know about internally but we used to call those size 0,1,2, and 3

    so you're saying they've added "Size 1 and a half", and 4.

    What I meant by "internally", is that the part config file for the TR-38-D 3.75m decoupler (for example), has these lines:

    name = size3Decoupler

    bulkheadProfiles = size3

    You wouldn't normally see "size3" within the game, though I understand you mean they are common terms to refer to the various diameters.

    And yes, they could refer to 5m parts as size4, and the 1.875m parts as... ???!

  18. On 25/01/2018 at 11:14 AM, kerboman25 said:

    - yes i build the shuttle in the SPH and attached it to the fuel tank in the VAB. The root part was always on the cocpit of the shuttle. I rerouted the root part to the tank to change it again to the cocpit to make sure it is routed correctly.

    -after the decoupling i'm able to control the craft myself via SAS but that's not what i intend to do with the program. I want to make orbit without doing any inputs to the craft control.

    I'm afraid I'm out of ideas of things to check/try. Oh, other than...

    ...did you know there has recently been a KSP v1.2.2-compatible release of the latest kOS (v1.1.5.1)? https://github.com/KSP-KOS/KOS/releases/tag/v1.1.5.1

×
×
  • Create New...