Sacred Aardvark

Okay, not sure if this has been discussed, I have vague memories of something 30-40 pages back but a cursory glance didn't locate anything and this might well be an engine limitation and not a bug, but here goes. I have satellites next to Minmus and Mun, pointing one dish towards the body they're next to and another towards Kerbin. The Minmus dish towards Kerbin has a cone angle that's wider than the orbit of the Mun, however a ship orbiting the Mun cannot get a signal from the Minmus satellite. Minmus is in LoS: http://imgur.com/dtLlGsh Satellite in range, no connection: http://imgur.com/QUQ69Hx Note that in the second link the Mun satellite does get a connection to the Minmus satellite, since it's not actually inside the Muns SOI, but some 500km behind it on an identical orbital period, same thing with the Minmus one, just outside Minmus SOI in Kerbin orbit. Then, when moving out of the Muns SOI the connection to Minmus is regained. http://imgur.com/1Z2GO3t I've also started up the dishes pointing at the geosync satellites and the Mun satellite, hence the extra line towards Kerbin, curiously I can get a signal from the Mun satellite, despite it targeting the Mun with it's dish and my ship being outside the Muns SOI. I suspect this might have to do with the satellite and ship being in the same SOI. [edit] scratch that, it was an omni it was connecting on *facepalm* Dish setup for the satellites: http://imgur.com/X7zgH8h Not a big problem, easily worked around and I probably wouldn't have even run into it if my science probe hadn't had the right amount of fuel to take off from Minmus, realize that's about all I can do and then coax it into a fake L5(or is it L4). No problems were discovered (since the Mun-sat is in Kerbin orbit) until the first manned Munar mission attempted to further the comms trickery and bounce their science from the far side of the Mun via the Minmus-sat and couldn't get a signal. Infact it's so easy to work around that I'm not even sure if it is worth spending too much effort in fixing it (and if it isn't just user error), an extra dish at my Minmus-sat pointing at the Mun would have done it, and never would have noticed if I had already set up my satellite network in Mun orbit, which I have to do anyway, instead of going Ned Moar Science! and shoving some kerbals in a rocket and shooting them towards the Mun without a proper communication network to abuse science with. I'm rambling aren't I? So, in a nutshell, tl:dr, or whatever: If the cone of a Dish pointed at a Body contains a Second Body, the Dish will not connect to objects inside the SOI of the Second Body. Technical limitation, design choice for performance, a bug, or user error? Regardless, a situational minor inconvenience, probably not worth wasting too much time or energy on. Hopefully I didn't forget anything important, except posting this in github and providing log and persistence file, which might set off some automated alarms, sorry :/ I'll try to remember to do that if someone else cares to confirm that this is an issue in 1.2.6 and it's not one of my other mods doing something wonky somewhere? In case it matters, I don't have signal delay, nor NathanKells antenna range thingy on. (was planning on turning it on but saw Cilphs post asking not to) Reading that I went: "Huh? He's gonna start doing localizations? " *facepalm* christ.... I think I might be tired or something

Depends on the height. If you're a second off on your kerbostationary you'll be 10% off after 540 days, if I didn't muck up my math too badly.(looking at the numbers I probably did) however being 1s off on a ~420km orbit (~57½ minute orbit) will be noticeable in under two weeks as I've discovered. Do you have fine control enabled for your RCS adjustments? Anyway, instead of RCS, use the flight computer and burn with your main engine. Doing 0.68% thrust for 0.01s burn time makes for some tiny adjustments in orbit. That burn addition to SASS is absolute grade-A 100% pure awesomesauce for matching orbital period/semimajor axis of satellite constellations. Okay, that spectacular crash with 1.2.0 isn't happening, I can't make it misbehave too badly so I shall update. Flight computer delays seemed to be a bit buggy when out of contact, but I might have just been out of power as well as out of contact so can't confirm. One issue I found was that a satellite around kerbin with a dish pointed at minmus, and a satellite in orbit of minmus with a dish pointed at kerbin, can't communicate to each other. If one of them then changes their target from the Celestial Body to the Satellite, it works just fine. [edit] Nevermind, I was being stupid, the satellite I was trying to catch wasn't actually at minmus, it was in Kerbin SOI right next to minmus at the same orbit, which is why aiming at Mun didn't link it despite it being in the cone. Next bit is still valid though: Also a dish at minmus pointed at kerbin, with a cone wider than the orbit of the Mun, doesn't catch objects inside Muns SOI despite them being in LOS and range of the dish, though this might be an engine limitation? If those have been fixed after 1.2.0 or are WaI, nevermind. Else, I'll get some shots and a log next time I'm playing

Point. I'll have to try and keep that in mind as well

Wow, biiig change Same question as Steven So rounding out numbers when possible before storing them in a variable is recommended? I'm off to check the rounding syntax then.

I think that since we're still early in the challenge the first suggestion can be taken care of by just recalculating the points if the scoring changes and updating the scores accordingly, and the second suggestion of listing the achievements amounting to that score would make updates and comparing scores easier.

I think the simplest way is to reward returning from interplanetary space, since thrusting to interplanetary isn't much effort, but returning or getting an encounter is trickier. Unless you flip the craft right after exiting Kerbin SOI... Damn it, why do I keep trying to break the scoring? Sooo... "# points for returning to Kerbin SOI from an encounter outside Kerbins SOI." or something? Probably might want to give more points for entering the SOI of other planets, keep the 1 point for moons though. Maybe up the points for landings outside Kerbin SOI as well, though I'm not sure about that, since the actual landing on eve and kerbin is basically the same for kOS. Actually, looking at the scoring you have currently in the first post, I think I'd do these changes and leave the rest as is: 1 point: Enter the SOI of any moon. //was: "body (excluding Kerbol and Kerbin)." 5 points: Perform an interplanetary transfer. // was: "As a part of your mission, enter interplanetary space." That way you have the added incentive for traveling interplanetary space, without some derp like me burning three meters outside the Kerbins SOI and going "yay points! back to kerbin" And as a bonus you get 5 extra points returning your kOS from another planet than you get returning from Mun/Minmus, due to the extra planetary transfer returning from where ever to Kerbin. *shrug* who knows... Any thoughts on those?

What? Thought we didn't get points for stable orbit around Kerbol? Or did you mean Interstellar? Still, getting to both is basically "lock steering to up. when altitude>70000 then lock steering to prograde. lock throttle to 1. if stage:liquidfuel < 1 {stage.}" and then over engineering the ship to have enough dV to burn into Kerbol SOI (interplanetary space) or blast out of the solar system into interstellar space. Interplanetary space is easier than a circular orbit around Kerbin, from kOS programming point of view anyway. (and if you're just going for cheap points, not a real mission) I'll happily go fetch my quick 10 points if this change sticks, while building my RT network is taking my time away from attempting this for realz :/ I'd say max 1 point for entering interplanetary(or -stellar) space, but returning from interplanetary space could be worth points

FTFY print "Hoverscript engaged for " + hovertime1 + " seconds, to hover at " + altset1 + "meters.". Here's your problem("): hovertime1 + " seconds + " to hover at " + altset1 Could do this as well: hovertime1 + " seconds " + " to hover at " + altset1 Weird that it locks up though, I usually get a syntax error on missing/extra quotation marks.

You only need one, and usually want the one with the newer date, several mods use the same dll in gamedata [edit] apparently I'm out of date, see NathanKells response below.

Yeah, it's a dirty hack that sort of works. I'm pretty sure at some point I just forgot why I was doing what I was doing and sledgehammered out a solution to get it over with Just to clarify and nitpick a bit, you can set your target to your current SOI, or ship:body, but keeping that target is a whole another story. That "hack" exploits the fact that it takes a split second for the game to clear your target, before which kOS can yank a command or twos worth of info on it into variables. However it is hardly reliable, since a slight hiccup and lag in kOS and you'll miss your window. Not recommended for use, but I'll leave it there as a quirk of ksp or whatever.

*scratches head* Okay. set x to ship:body. // assuming orbiting mun print x:body. // this then prints kerbin? Or can I not do that either? I really should open up KSP and just try this stuff out myself [edit] yeah that didn't work, nevermind x) [edit 2] So this works: set y to ship:body. // on kerbin, since you can't target your current body, when you set target to y. // target kerbin, the game will clear your target a moment later set x to target:body. // but before that happens(YMMV), you can store the body of the target print x. // and then print out BODY("Sun") I'm drawing a blank on why I started thinking about this to begin with, so I'll just leave that there in case it's of any use to someone Doing "set target to ship:body." probably works too, not sure why I did the extra step. Due to the timings required that does need to be in a program, preferably without a lot of other stuff going on with kOS

Because from the satellites perspective it isn't obvious. Until the satellite has aligned its dish in a suitable direction, it doesn't even know it's being yelled at for pointing in the wrong direction. (from a gaming perspective it's a little bit tedious, but I don't mind enough to care ) Ofc in certain situations the dish would in reality be pointed in the right direction and pick up the hail, but we don't have physical aiming of dishes. (thank god, that'd drive me nuts )

I spent last night playing with 1.2.0 expecting it to blow up, but couldn't find any fault in it. Didn't try the kOS integration though, was too busy setting up my satellite network. Absolutely Loving the flight computer after I figured out the queue, dat burn control <3 Only minor thing with it is that I'd like an off button to mash repeatedly when things go pear shaped due to clicking the wrong thing Yayy, can't wait

I'd allow it. Neat, I'll have to keep this in mind Would have saved a few (hundred) "copy ascent from archive." while tuning my ascent script. Still though, I'm not sure if accessing the archive with a program and/or running everything from the archive is a major issue. Okay you'd be circumventing the 10k size limit, but adding additional kOS modules for more hard disk space on a rocket isn't going to alter the dV much since a kOS unit doesn't weigh much. Do you have an example in mind where one could get a noticeable benefit from purely using the archive instead of storing the programs locally? I'm not against something like "programs can access the archive only in situations where the user would be allowed to input commands, i.e. in stable orbit or landed.", just can't think of a harm or benefit from accessing the archive with a program so I'm not sure if limiting it matters to me. Speaking of stable orbits... Does a Munar(or Eeloo if time matters) injection right after the burn that is heading straight for the Muns surface count as a "stable" "orbit" for the purpose of user interaction? Since you'll have several hours of travel time between then and when the non-stability of the orbit becomes a very real issue. Then again, not sure where to cut it off if such a thing was allowed.. "if you have 6 hours to impact you can, if you have 5h 59min 59 sec then you can't!" Oo! How about "Orbit is considered "stable" when the vessel will not impact the surface or enter the atmosphere of it's current parent body." So on my earlier example you could load programs and input commands up to the point where you entered the Muns SoI, at which point it's hands off and any programs needed to be running should already be running. Miss the injection and don't get an encounter while your periapsis is below 70km? Tough. You're not on a stable orbit and aren't allowed to give commands even though you have ages before hitting the atmosphere... Yeah it has it's faults... (though what were you doing making a munar injection straight off the ascent? showoff. )

So extrapolating from that, it would be ship:body:body:name to get the parent body of the current body the ship is orbiting? e.g. when orbiting Kerbin, ship:body:body:name would return the sun, and when orbiting the Mun/Minmus it would return Kerbin, yes?

I seem to remember there being something along these lines mentioned in the latest updates video, I'll check... Okay, so you can get the parent body of a target at least with target:body, not sure about an untargeted celestial body.

set target to "shipname". if target:distance < 1000 { set direction to target:heading. wait 5. lock throttle to 1. } That probably wont work without some additional code, but since only I spent under 5 minutes glancing over the readme and typing that up, it might not work even with more work, I take no responsibility for typos, incorrect variable names or silly code, YMMV. If you intend to dock, that can be a bit tricker, since I don't think there is RCS translation control in kOS yet and afaik it isn't possible to target parts(e.g. docking ports) of a ship yet.

Wait what? You can run stuff straight from the archive? What happens if you have an archive program running and you go OoR of the archive? What happens if you have a running archive program that you edit externally?

Yes, definitely. I have a follow up question though. What does this setup look like after a few years of warping? Is it somehow immune to the orbit drift, or is the slow apo-speed and wildly different orbits causing the drift to take a longer time to become apparent? Based on quick math, my current hastily built (temporary) network is in a few weeks-months going to have drifted to a point where it's not really usable anymore, so I'm in the market for a new network pattern

I think you're looking for MechJeb. Though even for that I think you'll need to figure out yourself what the closest ship is. I can't even think of a reason why one would want to "move to the nearest ship", since I'd think usually you would want to be moving to a specific ship, not just a random one that's near, even if that specific ship happens to be the nearest ship. But my inability to see a situation where it would be useful is a fault of mine and not yours. And yes, you can code kOS to move towards a specific ship. (I have an outline of the code in my head, but haven't actually tried doing it yet) If you're looking for an easy, out of the box autopilot, I recommend MechJeb. If you're looking for tools to code an autopilot yourself you're in the right place, but it will take some effort to design the programs and get them working. The wiki, readme and to some extent the introductory videos are good places to start.

There are only two mods that matter, RemoteTech and kOS. Everything else can either play nice with them or stay off my KSP If kOS and RT don't work together... *shudder* the horror! D: (though then I'd just run two installations, one with rt and one with kos ) Think I'll keep running 1.2.0 for a bit and see if I can't get some spectacular crash with some lovely error data to lighten your day. (thinking about trying other style tech trees anyway, so risking breaking my save isn't currently a big deal)

Are you accounting for roll? From the launchpad, pitch input will correlate to north-south, you'll need to do a 90 degree roll to get pitch control aligned with east-west, doing the pitch and roll at the same time tends to result in the type of behaviour you described. I start from the pad with "heading 90 by 90." (well, x by y, but whatever), which causes the ship to roll it's navball belly to east immediately on takeoff, after which changing to "90 by 45" or whatever pitches directly east, without passing north or collecting 200$. YMMW if you're using the other methods of guiding direction. TBH that behaviour drives me bonkers in MechJeb (which does it too in it's SASS), but I don't really notice it in kOS, I tend to account for it in the programs, whereas with MJ it catches me off guard Or I could have completely misunderstood your problem and spent the last few minutes rambling about something irrelevant [edit] Sma beat me to it.

I was going to say that there is an update to RT coming "at the end of the week", but it seems to have been released pretty much -now-, though it seems to require some patched dll. See RT-thread for details. haven't had the chance to do a proper read through it yet myself. http://forum.kerbalspaceprogram.com/threads/56399-0-22-RemoteTech-2-v1-1-0-November-7-Build-those-satellite-networks!?p=781796&viewfull=1#post781796

Good morning, gave it a go and after running your ascent script to get into orbit, I was able to run the deorbit script without an error. http://i.imgur.com/ZgGhYuH.jpg If that mystical invisible arrow thingy isn't the culprit, the problem could be one of your other mods, since the scripts work. (at least in the sense that they run and don't produce errors, deorb could use more delay between steering to retro and starting burn ) You are using the latest version, yes? 0.92, with the display glitch of showing version 0.91 in the console?

Only times I've had issues with variables, was when I had "someexessivelylongdescriptivevariablename", and the other was when I was using "alt" as a variable(fixed by changing to "alti"), probably because it's also used for "alt:radar" and such. Your example has "alt" and "time", both of which can be called in other situations, so maybe the parser gets confused there. I'm purely guessing here, it might have nothing to do with what I just said.