dudecon

No. Currently, connections to KSC are modeled as range to the surface of Kerbin. No. Antennas in AR act as both receivers and transmitters, and do not need to be pointed. Any vessel with an antenna will automatically act as a relay where appropriate.

Could we get a checkbox in the config window for this? Then everyone wins!I mean, except for you. 'Cause then you have to write more code, and seperate functionality, and check to see if the network connects to the active probe, and then retroactively disable drawing for the non-displayed lines, but still need to burn processor cycles for all of them in case they become active at some point. That sounds, to me at least, like loosing.

Seems to be working. I didn't initially notice that "require line of sight" was turned off, which caused unexpectedly good connections. After significant time warp, the line draw thing seems to give up, and just point to a random spot near the orbit instead of the actual vessel location. Bugs like that even when returning to normal time warp. It still gives the right idea, but maybe not what you had in mind?

That is not the behavior I observed, so I'm guessing that part isn't working perfectly yet.

I saw what you said. Specifically, nothing horrible. Out-of-range antennas do not display network visualizations, and instead show a single red line back to Kerbin, which I assume is the intended functionality. Haven't yet tested occlusion. In-range switching seems to work, but only tested with a single relay.

Well, range is usually a bigger deal than occlusion (since orbiting generally fixes occlusion problems faster than range). So, if out of range, draw range data (ignoring occlusion). If in range, draw occlusion data (if pertinent). I'm not sure how your com-network optimization code works, so I can't really say what will be easier to code, or if the "otherwise-most-ideal target" even means anything in this context. You might need to do a backward search (from Kerbin outward, instead of from the vessel to Kerbin) in order to find an optimal target.

In my mind, the useful information I'm looking for is:What is my "nominal" and max transmission range? What (if anything) is occluding my transmission? A colorcode sound useful for this: Green lines for valid chains back to Kerbin. Yellow and red lines for invalid links. For links that are out of range, yellow line for the portion that is within range, and red line for the portion that is out of range. (Maybe yellow for up to the "nominal" transmission range, and orange up to the maximum) For links that are occluded, yellow up to the surface of the occluding body, and red continuing to the occluded target. That kind of thing would be really helpful to see where the antenna is trying to transmit to, as well as foreseeing when the link will go down, and when it will come back up. There are two ways I can see this going. One is to link the Tracking Station upgrades with higher gain recievers, so you essentially add to the length of the kerbin reception distance as you upgrade the tracking station. The other way would be to give Kerbin the highest tech antenna that you have researched, implying that the KSP has a distributed network of listening posts with current technology. Either way would help, without the need to put comsats up, though you could reduce the effect for kerbin with the excuse of atmospheric attenuation.

So, basically, the "hard" difficulty has margins that are too large, and goals that are too far apart? I mean, it seems like this is a confusion (perhaps on SQUAD's part) about what the adjective "hard" is referring to. Currently (for experienced players) it is simply "hard to find enough time to make progress." What you are looking for seems more like "hard to plan, design, and fly successful missions" for which, at this point, you may need mods. The mission strategy is fairly linear, vehichle design has a few fairly clear optima, and piloting is (thanks to kerbal pilot abilities) easier than ever. Really, if KSP were to offer a real challenge to current experts, it would have to be deeper in many ways. The suggestions above are a good first step, especially to improve the game for newcomers. For experts, though, I suggest sandbox mode, and then setting your own obstacles.

Change in velocity, in this case, means only the change in velocity caused by your engines. As such, it is independent of atmospheric effects. FAR only affects things having to do with atmosphere. So, the two should not interfere.Gravity isn't accounted for in DV either. If you're traveling straight up in a vacuum, your velocity will be falling as your velocity is converted into potential energy. But this doesn't consume your Delta-V. It's just telling you how much your engines can change your velocity vector, regardless of the effects of atmosphere and gravity. I, too, would like to see Remaining Delta-V in the hud somewhere. Looking forward to the next VOID release!

Ok, here's something that would be handy. I like making balanced a-symmetrical crafts. In the VAB, the visual "CG" and "Center of thrust" markers aren't really good enough to center things up. Can you add some sort of display in the VAB to show the distance between the CG and the thrust vector? Maybe some components or something? Thanks again for this great non-game-breaking mod!

Fantastic! This mod makes my manned "rowboat" style pod look super good! It even works with my existing saved vessel designs! Excellent work! Ooh, clocking docking ports? That would, indeed, be very handy... Kind of seems outside the scope of this mod though, as it involves adding a new part instead of simply modifying existing ones.

It seems that nearly all of the models have been "upgraded" to version 3. The only one I've been able to import is the Mk2 fuselage (I tried quite a few, but not all of them). This is such a great tool, but it doesn't seem to work for most of the KSP models... help? Here's an error that pops up when I try to import the latest "Parts\Engine\microEngine\model.mu" or "Parts\Aero\rocketNoseCone\model.mu" Traceback (most recent call last): File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\__init__.py", line 63, in execute return import_mu.import_mu(self, context, **keywords) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\import_mu.py", line 167, in import_mu if not mu.read(filepath): File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 970, in read self.obj = MuObject().read(self) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 791, in read self.children.append(MuObject().read(mu)) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 809, in read self.renderer = MuRenderer().read(mu) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 552, in read self.materials = mu.read_int(num_mat, True) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 869, in read_int raise EOFError EOFError and here's another slightly different one when I try "Parts\FuelTank\mk3Fuselage\model.mu" Traceback (most recent call last): File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\__init__.py", line 63, in execute return import_mu.import_mu(self, context, **keywords) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\import_mu.py", line 167, in import_mu if not mu.read(filepath): File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 970, in read self.obj = MuObject().read(self) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 791, in read self.children.append(MuObject().read(mu)) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 791, in read self.children.append(MuObject().read(mu)) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 805, in read self.collider = MuCollider(entry_type).read(mu) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 601, in read self.mesh = MuMesh().read(mu) File "C:\Program Files\Blender Foundation\Blender\2.67\scripts\addons\io_object_mu-master\mu.py", line 446, in read raise RuntimeError: No active exception to reraise When I try to open "Parts\Electrical\batteryBankLarge\model.mu" it just says Unrecognized format: 76543 3 So, looks like more than one problem involved here. Looking forward to any progress, as I'd love to have use of this tool back. Thanks!

Turns out pressing Alt+F2 brings up the log output. If you want to get to the debug window with all the neat cheats, press Alt+F12. So, I'm a doofus I guess. Thanks for the help guys.

I was really excited about the new "re-load .cfg files without restarting" feature in 0.20, but I'm having trouble getting it to work. Here's what I see when I open the debug window. No inputs of any kind! If I click just to the right of the "Press Alt+F To Toggle This Window" it starts running the updater, so I suspect there may be some invisible buttons lurking here. Running Windows 7 64bit. Can post more system specs if it matters. How do I use this "console" to input commands? How do I tell it to re-load a particular .cfg file? Thanks. EDIT: Press Alt+F12 instead. Then there's buttons everywhere to do things. This includes infinite fuel cheats, unbreakable part cheats, and stuff like that.

The parts format changed slightly. You need to add text, as follows, to make the old .cfg files work with version 0.20: So, basically, right at the very beginning the word "PART" in all caps, and then enclose the whole body in curlybrackets. Should work fine after that!