Sacred Aardvark

Your response is predicated on the idea that all programs that are open sourced use a copyleft license. Just because programs with an open source are usually combined with a license that allows using the source, does not mean that the term open source explicitly grants these rights. I will concur that usually, and in casual conversation open source does tend to mean that you're also granted extensive rights on the code. And yes, open sourced programs tend to as a rule (figure of speech, it isn't a rule) allow modification, but distributing said changes, while again commonly allowed, is not a guaranteed thing. The forum requires the source and a license to be posted, and usual recommendation for modders without licenses is "just say all rights reserved until you decide", but according to you, if it's open source it can't have all rights reserved, since being open source already makes it free to be modified and then distributed. Or it could well be a language barrier on my part, how do you say "a program that has it's source code available but isn't allowed to be distributed as a changed version" in English? It's "open source" (avoin lähdekoodi) here, and generally programs with freedom to alter and distribute altered code are referred to as "free software" (vapaa ohjelmisto). (that's free as in freedom, not as without-cost) Of course for the purposes of kOS, this discussion is moot, since it does come with a copyleft license.

He has an impossible to fulfill until loop so he kinda does need the break. Or just rephrasing the whole bit like you said. I'm still trying to wrap my head around the fact that some programmers think "until 0 {" is fine, after the flak coders tend to give on "goto", either infinite loops are bad or they aren't. Hell, "until 0 {" doesn't even make sense, I mean I shudder at Maddings way of "until done {" because the condition is implied, but at least that makes logical sense, since it's basically "until done=true" or "until done != 0" and ends the loop with "set done to 1.", but how is "until false = true" or "until 0 != 0" supposed to work, even theoretically? P.S. Don't mind me, if it works for you, it works. Y'all do whatever you like.

No. That is just not correct. The fact that it's open source has nothing to do with the fact that yes, it's perfectly legal to fork it and make a new project for it. The GNU GPL "copyleft" license is what makes it legal, and despite people seeming to have the idea that open source means freedom to do what you like with it, the license is still what matters. You can have open source with all rights reserved. You probably knew this and it's what you meant, but I thought it worth clarifying so that people who don't know aren't getting the wrong idea.

Disclaimer: The following is accurate to the best of my knowledge, but is based mostly on conjecture and what I remember reading, along with some empirical evidence backing it up. It however it could well be incorrect or come to the right results for the wrong reasons, I haven't checked the kOS source to see what it's actually doing under the hood. I'm under the impression that KSP internally uses euler angles and kOS (and some other mods) are just handling the math of converting the user friendly input of heading by pitch on the navball into an appropriate euler rotation. If you're at level flight and rolled 90 degrees, your pitch controls will affect heading in relation to the ground, despite still controlling pitch in relation to the craft. You'll need at that point craft-yaw to alter ground-pitch. kOS tries to sort this out for you, but isn't perfect in it's execution. When launching from the pad, changing to 45 degrees pitch with heading 90 and roll 0, requires rolling 90 degrees and pitching down. A human operator can see that this can be easily achieved by yawing to 45 degrees and then rolling, or rolling and then pitching down, etc. What kOS is doing is trying to satisfy both at the same time, pitching down to 45 while rolling 90 degrees, which results in the heading going towards south by southwest, because from the pad the pitch vector is north-south and the craft is rolling to make the pitch vector west-east, so kOS corrects by adding yaw towards the correct heading and since it's still doing the roll and pitch it can take a while sorting itself out towards the right heading and pitch. Like you've noticed, setting the values separately and letting it sort out the roll before pitching down should work, since it has a clear thing to do. Engineering your craft to have superb roll control and sluggish pitch and yaw can also serve as a workaround, since it'll manage to roll the craft to near the correct orientation before managing to alter the pitch too badly in the wrong direction, but it's hardly reliable. TL;DR: Pitching while rolling causes yaw in addition to pitch, and yawing while rolling causes pitch in addition to yaw, which can cause issues for kOS finding the correct heading, so don't do it. (or expect the potential issues if you do)

Righto, off to install PF then I think I chose KW back in the day, when I just wanted them for looks, because I figured it'd be more likely to work with mods than PF... I chose, poorly.

Ran into a slight hiccup while doing an sub-orbital hop to the pole for giggles. I had KW rocketry fairings on the vessel, like I've had on all my ships for aesthetics since they haven't really gone up fast enough for it to matter in stock, however since I now had a lot more TWR and wasn't really worried about getting out of the atmo I went more horizontal, got more speed and figured I'll just throttle back if the flames start licking the fairings, which I realized was a bad idea when the parachutes on the payload inside the fairing overheated and blew up. Further investigation proved that the fairing "is shielded", while the bits inside the fairing are blasting away through the shockwave they were supposedly protected from The KW-fairings are attached to a part below, so I'm guessing DRE isn't understanding where the actual cone bits are located because of it? Anyhoo, long story short is there something I can do to fix the fairings functionality? (or can someone recommend a fairing mod that does work with DRE?) Thought about adding a heatshield module to the fairings, but since it already thinks they are shielded I'm not confident it would help. I seem to remember reading about a similar issue someone had and fixes being suggested, but a quick browse through the thread and didn't spot anything that would help and a quick google run just found someone else asking if KW-fairings could be made compatible with DRE, but no solutions that I could spot.

I've noted an issue with mechjebs rover autopilot as well (and I understand that kOS autopilot was at least partially cannibalized from MJ), where a probe core on top of the rover works fine while on flat ground, but goes loopy on angled terrain (my Mun rover flash backed to it's gymnast days and did a 180 half flip with tuck). Reason being that for the probe core "forward" is in fact "up", meaning if you drive to heading 90 and go from flat ground to a hill, your up vector is now pointing slightly back so your heading "is" 180, autopilot goes "EEP! Where am I going?" and turns the wheels, when in reality you were still traveling in the right direction. Easily fixed (probably) by turning your rovers probe core 90 degrees, so that top of the probe core points towards the front of the rover. edit: Goes without saying but I'll say it anyway: Obviously said angled probe core shouldn't then be used for flying, it Will crash.

Do you have Infinite EVA fuel on? Someone reported a few pages back that having it on made LoS not matter. [edit] Found it: http://forum.kerbalspaceprogram.com/showthread.php?p=807854#post807854 http://forum.kerbalspaceprogram.com/threads/56399-0-22-RemoteTech-2-v1-2-6-November-16-Flight-Computer!?p=807851&viewfull=1#post807851

I can't understand half the things you guys are talking about most of the time, so I'll just settle for QFT Lot of the stuff I do in kOS probably doesn't work like its supposed to, and I've done stuff that definitely doesn't work like it's supposed to, but it does work for what I use it for which is all that matters in the end, to me anyway. edit: Just to clarify a bit, I'm all for fixing broken stuff if there's a viable alternative to whatever can be done with the broken thing.

I have a better one; why do you think you can't control any satellite without that screen? I didn't have a clue what it was (cheers sonicsst), but my networks work fine. And since we now know that screen isn't in the current version of the mod, it can hardly be necessary for its functions. Nice I wound up doing a network of satellites (2x6, +-30 deg inc, poles are a bit spotty) on 420km orbit so that a dipole on the ground will reach them, but yours doesn't require stationkeeping. So how do you communicate in atmosphere when KSC is behind the horizon? With the dishes that don't break? They weight a ton (or a half a ton for kr-7) You said LKO not KSO, pay attention me. I'm assuming LKO in this case means low enough for dipole to pick it up on the ground? http://forum.kerbalspaceprogram.com/threads/56399-0-22-RemoteTech-2-v1-2-6-November-16-Flight-Computer!?p=808427&viewfull=1#post808427

Ha. Okay then Ãâ€_o Never seen that before

http://forum.kerbalspaceprogram.com/threads/56399-0-22-RemoteTech-2-v1-2-6-November-16-Flight-Computer!?p=804772&viewfull=1#post804772 Or does that button not work/exist? Or are you talking about something completely different?

Only works for the active ship and when it is focused, if your focus is for example the body you're orbiting, the connection path to the ship isn't drawn. I've had a couple issues outside of that where the path wasn't visible, but nothing I've been able to reliably replicate :/ I agree with KerbMav, "huh?" with a slice of wth?

"To Infinity... and beyond!"

Left to right; path of active connection to KSC / Command center visual indicator for cone angles (if you have any dishes targeting planets/moons) potential connection paths (cycles: omni, dish, omni+dish, none) menu for setting up dish targets (needs an active connection (i think))

Oh, alrighty then, must have missed (or forgot) that. Did you ever get your planetary targeting working btw?

Okay, did a test, 1400m/s burn via the flight computer in a ship with 1499m/s dV. End result was that the node shows the burn to be 54.4m/s incomplete and MechJeb showing 147m/s dV left in the stage. Second test, quickloaded and did the same burn, but orbit prograde instead of node. End result was that the node shows 166m/s to completion (more as was expected since we're burning in a off-direction), MJ says we have 192m/s left in the tank. (wth? ) Conclusion: I don't know. But my previous hypothesis has been shot down I think. I'm not sure if there's any relevant info to be found there so I didn't post them, but if someone wants I can up my screenshots. Moar testing nao ->

Yeaaah... *cough* I remembered the delay to be "up to minutes near Jool", and Eve is closer so figured that it might not get a 60s signal lag. Having now checked, it was "up to 15 minutes near Jool"

I wont start arguing this too badly since I'm not all that confident I'm even in the right ballpark with this hypothesis. However, I'd like to point out that you are not burning prograde, but towards the maneuver node, which might somewhat explain the reduced increase from expected in orbital velocity, though it probably doesn't.. Think I need to start up KSP and do some experiments before embarrassing myself any further I do suspect that I'm way off base, since I've had at most a 10% difference in burns and you're missing a freaking third of the burn You do have 900m/s of dV left in the stage, right? (had to ask, sorry ) [edit]: Is this active connection via omni, or targeted dish? If the latter, is the dish targeting the mothership, or active vessel? If the latter (deja vu), then the connection to the mothership gets cut when you swap to the subsat as the subsat is now the active vessel. The delay is for the execution of the event on the ship, not for sending it to the ship. The delay is there exactly so you can queue stuff up to be done when you are out of contact. (unless you meant [edit: he did mean] a 60s signal delay, not a custom delay, I'm not playing with signal lag atm so can't comment on that)

Are you actually getting only 600m/s of burn, or is there 300m/s left on the node after your 900m/s burn is complete? You're not making an instant velocity change that the burn node "assumes" you would, hence the longer the burn the larger the difference in actual burn and perceived burn dV. Like with the nodes path display after burn differing slightly from the real path after the burn. At least that's what I think is happening. I've only guesses and empirical evidence for it Also, your second link gives a 404, and neither of the img tags work for me, had to quote you to see the links.

I'm thinking: But not a clue beyond that. The Communotron 16 ? Working as Intended, if it's deployed it will break under high dynamic pressure, i.e. when moving through the atmosphere at speed. You need to have a sturdier antenna, couple of the dishes don't mind being active in atmo, or there's the 500km dipole antenna (Reflectron DP-10) that's activated from the start and doesn't break in atmosphere.

When you mouse over the part in VAB-parts list it should show the cone angle and the range of the dish. (possibly also in the right click menu of the antenna after launch, not sure). And like someone mentioned you can get a visual indicator in the map view from the buttons in the lower right corner. But basically anything longer than DTS-M1 (45 deg) or KR-7 (25 deg), such as the Communotron 88-88 (0.06 deg) which I think you are using on the probe, will have such a narrow cone that inside Kerbin system planetary targeting won't hit squat and direct targeting is required on such dishes. Haven't ventured outside the Kerbin system with RT myself yet, so can't comment on how far out the 88-88 becomes useful for planetary targeting. (and I cba doing the trigonometry (okay I lied, though wasn't paying attention and didn't double check the numbers, but I think the 88-88 has a cone as wide as Kerbin around 1Gm distance and GSO around 6.5Gm. Don't quote me on that though )

Quickie before heading to bed: Cone angle large enough?

Request for additional information: What is the Chatterer 1 connecting to? Connections must be two-way. I'm guessing Chat-1 targets active ship and KSC/Kerbin (or is KSC via omni? not that it matters in this hypothesis). Which is why Chatterer 2 works on it's own via Chatterer 1. You need a connection from Chat-1 towards Chat-2 as well if you want to use Chat-2 as a relay to bounce the signal to Chat-1 when chat-2 is not the active vessel.

Do you mean this menu? http://i.imgur.com/fFXd6lV.jpg It's the button on the lower right corner, visible on that picture as a green-ish yellow button with an image of a dish on it.