JoCRaM

Ooops, you're right, it was R(0-Pitch, Yaw, Roll). The three argument form was in 0.92 - https://github.com/Nivekk/KOS/blob/f87b56f0ec27019798ef2ef85451133dd84e137d/Expression.cs#L434-L444

Ah, you lost the optional third argument when you tidied it up. I can use this instead, but it would be nice if it could find it's way back into the language.... LOCK STEERING TO HEADING(0,0)*R(0-Pitch, Yaw, Roll).

So... what replaced heading(pitch,roll,yaw)? - It still produces a R()otation, but if you try to use it it gives a cast error? SET Pitch to 90. SET Roll to -90. SET Yaw TO 0. LOCK STEERING TO HEADING(Pitch, Yaw, Roll). Now gives "cannot cast from source type to destination type. (Cannot show kOS Error Location - error might really be internal. See kOS devs.)"

their main property is that they improve prograde stability, as demonstrated in the video.

here you go, a test I did to demonstrate the effect of nose cones the longer your rocket, the more pronounced the effect - cones in front of CoM = stability, cones behind = instability - which is not the case if it was "angular drag". Kasula's "turning slower" and landing cone down are explained by the same prograde stability that pushing the centre of drag behind the center of mass causes. however, for the effect to be of much use. the nose cones have to constitute a significant portion of the mass of your vessel... which makes them a bit of a problem. use canards instead.

the vessel contains Kerbal(s).

lander & launcher it was a SPH craft, so I launch it from the runway. The launcher is unstable 30km throttle to full, stage, , sas on at 500m, drop throttle to 12 when the overheat bar comes on. wait 'till 20K for a very gradual gravity turn to horizontal at 30K. (or start a gravity turn at 4km, never pushing the craft facing above the top edge of the prograde marker)

Poppycock. I've already stated my opinion that kOS isn't ready for this sort of challenge, I've expanded the kOS issue tracker for this with further variable types that cause issues. there are actually three bugs here the kebalscript interpreter can't parse its state dumps. (that's an "in game" bug, and like the unterminated string or brace bugs I'm happy for them to stand) the seconds is that the kOS game mod allows kerbalscript bugs to break it. unterminated strings, missing closing braces and state dump problems should simply result in a briked kOS computer, that a reboot may or may not fix. the third is a KSP bug, a mod thorwing an exception should not cause the craft to load nor the game to fail. Well, in the real world, the KeralScript bug would brick the kOS computer. your mission is still screwed. You work around the probelms in the run-time envrironment. Stop pretending that the fact it breaks "physics" makes it a special case.

version 1 version 2, full flight, 14 aerobraking dips and a 15th lithobraking entry. Highlights: Final re-entry starts around 11:40; 30,000M for renerty plasma at 13:15; the craft finally gets enough atmospheric bite at 6500m 14:50; actual ship landing starts at 16:25 version 2 landing in/on water

Sorry, I was unclear: a well written KerbalScript 0.9.2 prgram clears problematic varibales before it finsihes. in general it's only a few that you need to worry about - strings, and values that may become very small or large, and vessels That one works around problems in the software envirnment is a real world practice, and as an anecdote, back in 1991, I wrote chemical plant control software and the compilers' optimiser had a glitch whereby it would fail to return the value of a variable it had optimised into a register. To work around this many of my functions ended return val; stoopid_compiler(*val); } And, tongue in cheek, it's just possible that failure to do this, coupled with failure of mechanical saftey systms may well have caused half a (pressure) vessel to (metaphorically) disappear from reality. DECLARE PARAMETER att_message. DECLARE PARAMETER att_start. SET att_plus TO "+". IF TIME:SECONDS<att_start {SET att_plus to "-".}. PRINT att_message + " at t"+att_plus+ ROUND(time:seconds-att_start,1). LOG time:seconds +"|"+ att_start +"|"+ MISSIONTIME +"|"+ VESSELNAME +"|"+ VELOCITY:ORBIT:VEC +"|"+ BODY +"|"+ BODY(BODY):POSITION +"|"+ att_message TO missionlog. //load/save bug... SET att_plus TO 0. SET att_message TO 0.

well, a well written program cleans up it's dangerous variables before shutting down for a save, so strictly speaking not needed.... when my lunar module separates from my command/support module and lands on the target, the C/SM is "unloaded" by KSP as soon as the craft are 2.5km apart. In order for the C/SM to retrieve the LM (once it has taken off and established a low orbit), the user needs to switch to the C/SM, open the kOS module and manually run something. Currently There are several mods that purport to prevent KSP from unloading craft, which would mean that the C/SM would be able to automatically retreive the LM once it had taken off without intervention. That's a silly restriction - a manuever node is simply a time and a vector, if it's legitimate for you to type run "donode(27,V(100,10,0))." then all you're doing is making it awkward for someone to do that - and as the OP pointed out in their question that's just the sort of thing that happens in real life. If a participant's mission entirely consisted of them setting up nodes for the program to follow (following the interaction rules) it would be a legit automated mission, but we, the audience, wouldn't be very impressed. however, if someone can't figure out how to automate one aspect of the mission then I'd rather see what they have done than see nothing.

most of those should be done by doing, instead of precaclulating absolutely - a system like this would have dot and cross product hardware (and probably triple and quad product) - but I only have a little free time, and my planned modifcations to the language are about forth in line of my KSP things to do.

A second, similar design, landed with no damage both attempts I made, the first on land (after 8 hours of dipping into the atmosphere) the second flight didn't actually go above 8000m, but successfully landed on water in exactly the same way it would have done had it gone through the whole orbital procedure. Video/craft to follow. The mountain problem is still a threat, so I might see if I can minimise that by designing the lander to cricle. but my desire for atmospheric simulation (with simplification by hard-bodying if performance really is an issue) is far more about letting the carrier aircraft glide while I take the second stage to orbit, before returning to the carrier to land it properly. I don't really care if it freezes in place, does a full simulation or a simplified one, just don't destroy it without good reason.

it's trivial to do - most toy plane kits before radio control managed to land without crashing. it took me 5 mintes to build my test craft - it took me longer to build the launch vehicle that could cope with the aerodynamics pulling it off course - in retrospect I should have simply put two landers on top of the rocket belly to belly. (last night was my first visit to the forum since my previous post) I imagine so, it worked on the first flight I got out of atmosphere. Unfortunately my upgrade to windows 8 destroyed my filesystem, but pretty much all of my space planes would have large parts of the assmbly survive an unsupervised landing. (since the rebuild I've been concetrating on kOS - my initial goal was to emulate a skylon mission, but I detoured into a fully automated Apollo style mission as a way of learning it.) I don't know, "enough lift" is calcuable, as is offset center of drag for directional stability, but lifting surfaces can be used for that instead. offset conter of mass to provide roll stability is probably important.

I know what a pull request is, and they implement omniscience - e.g. adammada's position of a node; and ORB:ECCENTRICITY - both of which I hope are rejected, should Kevin ever return.

Done. The wings snapped off, but the pilot survived. If it had landed "on land" without crashing into a mountain it would probably survive in one piece.

It's made people ask for a lot of things, wether they are good or not is a different matter - several of the "pull requests" and "issues" are pushing for omniscience.

Can I use an unload preventer mod? I am currently prompting to go and wake the other processor, but it's messy.

I wrote a control loop solution to inclination, but it slowed the game to 3 FPS when running.... I unpacked the LOCK statements and it takes a side of printerpaper to write out by hand, so I'm going to go back to calculating a node then running it - it's a pain, it means I do a rough adjustment, then half an orbit and a fine adjustment, but.... even doubling clock speed on the CPU would still leave it on it's knees and I don't see a 7.5GHz processor happening any time soon

SET burnNode TO NODE(TIME:SECONDS, 0) <launch> <circularise> UNITL WonTheGame = 1 { PRINT "Waiting for transfer window at "+ETA:SECONDS. UNTIL burnNode:ETA > TIME:SECONDS { WAIT 10. RUN VESSEL:NAME+"nextburn". } ADD burnNode. LOCK STEERING TO burnNode. SET dT TO burnNode:DELTAV:MAG*MASS/MAXTHRUST. WHEN TIME:SECONDS > burnNode:ETA - (dT/2) THEN LOCK THROTTLE TO 1. WAIT burnNode:ETA+(dt/22)-TIME:SECONDS. LOCK THROTTLE TO 0. REMOVE burnNode. } } Then when you messed up your encounter you can edit your "myshipnextburn" file to add a line to the bottom - SET burnNode(12553, 10, 50, 300). WHEN TIME:SECONDS < 12553 THEN BREAK. (The when/break isn't needed, you could just replace the file, but this way is cool because you can then replay the mission....)

they're aliens. just add "Jane Kerman", who is space crazy in a orange jumpsuit and increase the name generator dictionary to include names that we might associate with hujman females. I'm thinking Alex, Bill, Chris, Drew, Emery, Frankie, Gale, Harley, Irma, Jackie, Kasey, Loren, Marion, Nikita, Ollie, Pat, Quinn, Robin, Sidney, Tracy, Urma, ?, Whitney, ?, ?, ?

the system loads the program into memory before running it, so you can safely go out of range, or edit it back at ground control.

Absolutely - here's my launcher program COPY att TO 1. COPY tail TO 1. COPY periapsis TO 1. COPY tryinlight TO 1. //amusements... IF STATUS = "PRELAUNCH" { clearscreen. IF STATUS = "PRELAUNCH" OR STATUS = "FLYING" { RUN tan_ascent(72000,2.2). //Target Altitude, Gs of thrust }. print "Well, at least Jeb looks happy". if STATUS = "SUB ORBITAL" { RUN periapsis(73000,19). //target altitude, m/s acceleration }. SWITCH TO 1. //do not rely on ground control... if STATUS = "ORBITING" { PRINT "you can have some snacks when it's a neat circle". UNTIL PERIAPSIS > 74000 and APOAPSIS > 74000 { //yeah, I will write better circulariser one day... WAIT 15. RUN periapsis(74000,19). }. }.

I was talking about the general case, not the "exceptional" periods. Otherwise you could simply have your main program be "switch to 0.until 0{run nextcommand.}.

accessing stuff fromk the archive is... going against the premise of the challenge - that things should be local to the craft to avoid problems with the speed of light. Personally I think kOS is still a little immature for this challenge, but I'm hoping to add a PROM and mid 70s stlye boot loader - once I've finished fiddling with using kOS to do the efficiency challenge - I'm at 8 units of fuel so far, I will get it to double figures..... but my next mission may well be an automated apollo style moon landing.