Camacha

I'm kind of wondering whether those drops flying off aren't a problem. Doensn't seem like something you'd want aboard a craft full of electronics and fragile stuff.

As long as you actually are within the gravitational field, this is true. I think I should remeasure Kerbin's field again, but I seem to remember it zeros out quite fast. Edit: not quite zero at a 1000 kilometers, so if gravitational drag is implemented (which some sources suggest it is) using it in LKO to stay aligned might be feasable.

Thanks for the answers, that all helped a lot. I was thinking something along these lines, though with a different train of thought. The problem with the ISS appears to be its flatness and not its mass per se, although its relative mass to a device or part making use of the gravity gradient might be. Alignment is plausible, but not something that is easily achieved. I think gravity in KSP drops off dramatically and as such, gravity driven schemes are a bit useless, most of the time.

A minor quibble I've found is not being able to program any mission parameters or vectors in advance. I real life, temporarily losing contact is not a big problem, as long as it is planned and a connection can be re-established somehow. Launching satellites into orbit without contact should not be a major problem, since everything could be programmed in advanced, with the craft looking for contact afterwards. I think this is a general problem with KSP though, the problem is just somewhat more visible due to this mod. Except for that little bit this mod adds a lot of realism and - in my book - fun! I had a little test around. Adding just an antenna to a part does not work, unless you add some kind of command module. The only exception is the RemoteTech RC antenna, which functions as a command module too.

That made that a lot clearer, thanks! I overlooked the slight shift in earth's position around the sun influencing the day period as perceived from a fixed position on earth. That sounds quite plausible. Not really a factor in KSP, but in real life keeping your satellites/clocks up to date is essential, of course. I later realized that one could calculate the orbit times and use the KSP mission timer to space out the satellites pretty much dead on. I think that must be an approximation of how they do it in real life too, which is somewhat of a concern to me. Maybe not essential for proper operation, but something that scratches my OCD itches Actually, I think there is military technology used in cruise missiles that works in such a way when necessary. I dug into that a little bit and these missiles are guided by different, often redundant sysems. The well known Tomahawk uses four; GPS, DSMAC, TERCOM and IGS. - GPS we all know and love, though the military variety is a bit more accurate. - IGS (Inertia Guidance System) is, for as far as I know, used in a lot of space craft too but called INS. It just measures all the forces and calculates the corresponding position. Major disadvantage is that errors tend to accumulate over time, so as a stand alone device it might not be ideal. - TERCOM (Terrain Contour Matching) uses radar data matched to a 3D map to position itself. I think this is what makes it capable of low level flight. - DSMAC (Digital Scene Matching Area Correlation) is somewhat similar, though it is optical. I believe this is only used for final target acquisition and comes in handy when targeting something moving. Of course, that is just some outdated technology we know about. Some way more advanced gadgets are probably killing unsuspecting suspects around the world I also could image that you could use some funky triangulation when you are , for example, on the earth side of the moon. Using signals from satellites or ground stations it should be possible for an orbiter or ground vehicle to roughly determine its position. Using something like ground radar and know previous positions even less than three signals might suffice. Remember that ISA isn't very accurate either Of course this all is not quite up to GPS standards, but I can imagine it being more practical when on interplanetary missions where GPS is simply not available or financially feasible. An orbiter that scans the surface optically and/or differently and relays positional information to a lander, perhaps aided by a signal from said lander seems plausible using know technology. Of course, current missions don't move around the surface enough to warrant such technology - Mars landers are visually checked upon - but I do not see any reason it would or could not work. Even guidance by meansof a stored on the surface seems plausible, though some problems might arise from atmospheric changes on planets like Mars. All said and done, your mod does add a lot of realism and fun, so no reason not to use it!

I can imagine that being a bit light, but still I think a lot can be gained from extensive tweaking I'm more of a desktop guy, since they offer a bit more computing power for the same amount of money.

What kind of computer do you run? I say tweaking is an art, since I ran it in a playable fasion on my old Pentium 4. It was far from ideal, but hey, it was playable.

Since they don't despawn at the break of dawn. Paying attention and - when appropiate - running like hell is the key.

Not much less, I presume. The advances in technology would presumably be cancelled out by concerns for safety. Remember comparable cars only got heavier the past few decades, so I guess that might also be true for rocket crafts.

Well, booting is only half the story. A friend of mine was here with his laptop and booting Photoshop was just painful compared to starting it from my SSD. And not just that, everything is just a bit easier. In hindsight it would have been financially sensible to wait a bit longer to buy a SSD, but in all honesty I never really regretted it. The only thing is I'm already looking for an upgrade, since I like it that much SSD's are hands down the biggest thing to happen to PC's in the past 5 years, maybe even 10.

I built this about a year ago to replace a truly ancient P4 machine. It was built with silent power mind mind, and as a Photoshop and Solidworks (mainly workstation) machine that should be able to play some games too. Might get some upgrades soon, but money is a bit tight at the moment. I'm loving it, it is quite fast and incredibly silent, it is everything I built it for. After years holding out and working with old gear, I finally have some proper kit. i5 2500K Asrock P67 Extreme 4 Gen 3 Samsung 830 128 GB SSD (they are much more affordable now) 8 GB DDR3 1600 RAM Asus GTS 450 1 GB GDDR5 with Arctic Accelero S1 Rev. 2 (silence!) Antec P180 Windows 7 Pro (Windows 8 Upgrade purchased) Creative X-Fi XtremeMusic Scythe Mugen 2 Rev. B NZXT Sentry 2 Nexus Real Silent Fans (5x) Nexus Value 430 PSU 2 GB Caviar Green as an external HDD via USB3 1 GB Caviar Black for internal storage, though currently not installed. Upgrades would be a new keyboard and mouse, as the wireless ones I'm using now are causing trouble. After that a RAM upgrade would be first and maybe a new GPU after that, although the ones I'd like to buy are a bit too expensive right now (HD7870 XT or GTX 660 (Ti)). On the other hand, almost everything works pretty decent (bar the keyboard), so upgrading is a bit of a luxury.

Happy pi to the twelfth to you too!

Minecraft was the last game before KSP that I was truly obsessed with. Just now I picked it up again, now I'm building a megalomaniac fortress on extreme hills. I'm trying to distribute between games, so I don't grow tired of either anymore. I always tend to build my houses on extreme hills, since they provide decent protection. The height is equally lethal for players though... I just wish the mobs were a little more intelligent, so defensive positions would actually be useful.

Do you know why it works like that? I know, not the most refined question, but I'm trying to understand the basic mechanics. Any sources on this subject are also welcome.

Silly me, I forgot to assign a category in the title.

Allright, this might be a simple question, but I Googled quite a bit and I could not find any satisfactory answer. My question is how your orientation behaves when in orbit. Since it is a bit hard to explain I made a nifty schematic to clarify. Scenario A - red triangles on the left: In KSP you always face the same direction - not touching the controls of course. Since you are orbiting a planet, this means the position of the planet seems to move around you and returns to your starting point after one rotation. In KSP this is most visible in the navigation ball. Your perceived orientation moves all the time, ending up where you started again. Scenario B - blue triangles on the right: This is how I always imagined it. It is more like begin attached to a string and flung around. Looking down on the planet I would be facing the planet the entire orbit. Looking at space stations this also seems to be the logical way to go, but I might be entirely wrong. When I check movies from the ISS however, it seems to be true. What is accurate for real life? And more importantly, why? Is it indeed because of centrifugal forces like an object on a string would experience?

Correct me if I'm wrong, but wouldn't that leave the poles uncovered? I think you'd need an additional three satellites rotating over the pole(s) to be able to communicate from whatever point to any other point.

Well, if you would want to be a bit rash you could all call those abilities to feel instead of strictly touch. However, I'd have to agree that the traditional view of five senses is a bit limited. Maybe one could speak of sensors instead of senses, since science tells us we are pretty much all mechanical anyway and just very fancy machines. I often wonder what it is like to detect heat like a snake, to have the spatial perception of a small bird or the trinocular vision of a Mantis Shrimp with eyes that have not three, but sixteen different kinds of color receptors. The somewhat sad truth is we will never know, since our hardware is so different that we cannot even imagine. When we do try, it always ends up translating those things to sensory input we know (like the thermal imaging we all know and love from Predator) and that - of course - does not get us anywhere we haven't been before. We even shaped the world around us to match our internal wiring. As monkeys that lived on plains we don't do well with complex three dimensional spaces. Instead we simplify those into series of surfaces - or floors - that we do easily understand. Maybe that we will learn to artificially build new organs in the distant future along with a brain structure to operate them. Those developments have already started in the shape of kidneys being experimentally printed in laboratories, but it will probably take generations before we can match the quality of real organs, so improved and new organs are a long long way off. Only then it might be possible to finally perceive those things we were never able to feel, see or touch before.

I have a few questions. Your explanation above helps a lot (and provides insight in a solution I didn't know before), but a few details elude me. - What is the difference between a solar day and the rotational period? - According to Wikipedia the solar day of earth varies, depending on the time of the year. Is this different (.ie stable) on Kerbin? - What is the reason for choosing an orbital period of half a solar day? - Also, I would like to know how you time the orbits and know when to burn to maintain exact spacing, since there are no fixed points that I know of. You are really putting the science in KSP Thanks a bunch!

Damned Robotics is a nice mod to make foldable things It provides hinges, pistons and other stuff.

Since the kraken ate my previous post; is it possible to keep the dish from turning while not in orbit? I'm trying to build some nifty nosecones, but the MapSat dish seem to want to poke its nose out by turning.

I am trying to merge Remote Tech parts with the existing FAR setup I had. So far I think I succeeded in adding RT to the stock probe parts by copying the extra RT code into the FAR configs. Some code seems to be doubled up, but it seems to work, so I am not sure I should fix it. name = probeCoreCube module = CommandPod author = NovaSilisko mesh = model.mu rescaleFactor = 1 CrewCapacity = 0 node_stack_bottom = 0.0, -0.2845967, 0.0, 0.0, 1.0, 0.0, 0 node_stack_top = 0.0, 0.2845967, 0.0, 0.0, 1.0, 0.0, 0 cost = 500 category = Pods subcategory = 0 title = Probodobodyne QBE manufacturer = Probodobodyne Inc. description = QBE is a sturdy, cubic, and relatively lightweight probe core. It also can survive higher heat loads than its counterparts. Its simplistic shape also appeals to modern art collectors. Truly, something for everyone. attachRules = 1,0,1,1,0 mass = 0.08 dragModelType = override maximum_drag = 0 minimum_drag = 0 angularDrag = 0 crashTolerance = 30 maxTemp = 3100 explosionPotential = 0 rotPower = 0.5 linPower = 0.5 Kp = 1.0 Kd = 1.0 vesselType = Probe MODULE { name = ModuleCommand minimumCrew = 0 RESOURCE { name = ElectricCharge rate = 0.02777778 } } RESOURCE { name = ElectricCharge amount = 5 maxAmount = 5 } MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 0.5 CdCurve { key = -1 0 key = 0 0.3 key = 1.0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 0 key = -0.5 -0.01 key = 0 0 key = 0.5 0.01 key = 1 0 } } // --- RemoteTech parameters --- MODULE { name = ModuleRemoteTechSPU minimumCrew = 0 EnergyDrain = 0.02777778 isRemoteCommand = false } RESOURCE { name = ElectricCharge amount = 5 maxAmount = 5 } However, there are a few command modules/rings that come with RT and I guess those are not FAR compatible. Should I go the same route and simply paste the following FAR code into those configs? I was also wondering whether the order of modules in the config file makes any difference. Cheers!

So just to be clear; in addition to the regular requirement of having a probe body or kerbonaut to control a (part of a) vessel, I now also have to have an antenna and contact? The probe body is still mandatory for unmanned flight, since that contains the flight computer? For example, the ProbeCoreCube config has become: name = probeCoreCube module = CommandPod author = NovaSilisko mesh = model.mu rescaleFactor = 1 CrewCapacity = 0 node_stack_bottom = 0.0, -0.2845967, 0.0, 0.0, 1.0, 0.0, 0 node_stack_top = 0.0, 0.2845967, 0.0, 0.0, 1.0, 0.0, 0 cost = 500 category = Pods subcategory = 0 title = Probodobodyne QBE manufacturer = Probodobodyne Inc. description = QBE is a sturdy, cubic, and relatively lightweight probe core. It also can survive higher heat loads than its counterparts. Its simplistic shape also appeals to modern art collectors. Truly, something for everyone. attachRules = 1,0,1,1,0 mass = 0.08 dragModelType = override maximum_drag = 0 minimum_drag = 0 angularDrag = 0 crashTolerance = 30 maxTemp = 3100 explosionPotential = 0 rotPower = 0.5 linPower = 0.5 Kp = 1.0 Kd = 1.0 vesselType = Probe MODULE { name = ModuleCommand minimumCrew = 0 RESOURCE { name = ElectricCharge rate = 0.02777778 } } RESOURCE { name = ElectricCharge amount = 5 maxAmount = 5 } MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 0.5 CdCurve { key = -1 0 key = 0 0.3 key = 1.0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 0 key = -0.5 -0.01 key = 0 0 key = 0.5 0.01 key = 1 0 } } // --- RemoteTech parameters --- MODULE { name = ModuleRemoteTechSPU minimumCrew = 0 EnergyDrain = 0.02777778 isRemoteCommand = false } RESOURCE { name = ElectricCharge amount = 5 maxAmount = 5 } I just added the RT code to the FAR configs, but I see that the ModuleCommand you mentioned is still there. The resources also seem to be defined twice. I should remove those or is it not really a problem? It does seem to work, but I'm not sure it might cause problems. I also just realised I will need to add FAR code to the Remote Tech command pods/rings, because I think those won't work properly otherwise. Finally I noticed that Damned Robotics parts are still controllable when the connection is lost. It doesn't change much gameplay wise and I think I understand why it works like that, but it feels a bit weird

So, I notice the stock parts are edited to include specific modules for Remote Tech to work. However, I'm also using FAR. How can I make sure both mods work like they are supposed to? Just add the following/corresponding code under the FAR code in each CFG file?