Kaleb

If you use ModuleManager, you can create a custom cfg that adds this to all the pods/cores. That's what I do. It looks like this: @PART[cupola] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } ...only repeated for each pod and core. Make sure the name in the square brackets matches the name in each of the part's cfg files.

The maps should get written out as png files somewhere in the mod's PluginData directory. If they aren't, maybe check you have write permissions for that folder? There's also a setting in the Kerbalpedia section of the mod for how often that file gets updated.

Ooh! That sounds like a good idea! I hadn't thought about that possibility... Has anyone tried this? How easy is it? This would allow me to begin building a new RT2-compatible infrastructure now (and decommission my existing one), instead of sitting on my thumbs, unable to build anything until this comes out.

That doesn't matter to copyright laws (at least in the US). As soon as you create an original work, regardless of whether it is professional, registered, licensed, whatever, it is automatically copyrighted. In the strictest sense, I think forwarding an email without its author's consent could even be viewed as copyright infringement. Edit: That said, there's nothing preventing the creator from granting a more reasonable license, such as CC, GPL, or (my personal favorite) the "do-whatever-you-want-with-this-source-code general public license" that comes with Actions on the Fly.

I love this mod, but if this were a mandatory part of this mod, I'd probably stop using it regularly. I'm already considering doing that anyway, which pains me... So far (with the old version) I've only been traveling within the Kerbin/Mun/Minmus system, so signal delay hasn't been an issue, and I don't think I've once had to touch the existing flight computer. I'm a programmer at my day job, and I'm not really sure I want to do more of the same when I'm playing. Maybe once I start moving out of the system, I'd take another look at that option, but at that point I'd probably rather just set up a manned remote command post. For the short term, I'd rather just have the actual parts, and the ability to create a network, so I can get back to building up my infrastructure in 0.21... Edit: To clarify, I'm not against having this functionality, I just think that it isn't necessarily needed in the first release, and definitely shouldn't be required for everything (from Kimberly's post it sounds like it won't be. I hope that's true). To me it feels more like an addon, or a secondary, compatible mod. Aren't there already mods that do this, anyway?

Nice! I enjoyed reading this. Interesting, though, you can see the missing fuel lines still attached in the VAB, but then they're missing in flight. Must be gremlins (kremlins?).

I really want to see this too, and also can't find information about if/when/where it will be released theatrically in my area. I mean, August 2nd is its theatrical release date, but the theaters here don't seem to carry it (the June date was apparently the on-demand release date). I've never used video on demand, iTunes, etc... so I'm hoping to avoid that route if possible. I did manage to find, here, that the DVD release date is October 8th, so maybe I'll just wait for that, and redbox it?

Reading through this thread, I'm still a bit confused about exactly what I need to do with this mod (the dev version on the blog) for best results in 0.21. I have old maps of Kerbin and Minmus that I created in 0.20 (but not of the Mun yet... I'm en route). - I have already checked the setting to update the hilo.dat file. - Do I also need to delete the existing hilo.dat, or not? (I've seen both suggestions posted here) - Is the Kerbin map different now? (Looks like fewer extreme peaks, more midlands?) - If so, do I need to manually delete my existing map of Kerbin before remapping it? - Do I need to delete the anomalies file to pick those up again? - For that matter, are the anomalies different between versions, and would mapsat pick it up if they were? I thought I'd heard they were hard-coded, in which case, there'd be no point deleting this file? - Is my old Minmus map still valid? - Does Mapsat pick up the new Munar craters? (I guess I'll find out soon enough...)

FWIW, I'm not currently so interested in the programming aspect of this mod (that may change later, once I go outside Kerbin's SoI). I'm using it more to create an interesting limitation on automated flights, and therefore as a justification for manned flights. Unfortunately, I've now got my entire main pseudo-career game on hold waiting for a playable version of this mod. I've made peace with the fact that my current KEO relay network will need to be reinstalled, and that my existing space telescope and mapsat will need to be replaced (because all their antenna parts will disappear). I can justify this in-game as the result of a catastrophic meteor swarm -- the same one that recently pummeled the Mun and triggered rapid tectonic activity on Kerbin. Fine... But I can't start designing or flying their replacements until this mod gets updated. And I really want to map the new Mun... So I guess for the immediate future I'll either be keeping RT1, or just bumming around on Kerbin.

I finally brought Jebediah back from his Minmus tour (which had been my first landing). The return trajectory had a Pe around 20-30km to try aerobraking. I wasn't expecting the (non-firing) NERVA to overheat and explode in the atmosphere (I didn't think the reentry affects added heat?). It took out most of the in-space stage along with it, except for the docking port, control core, batteries, and a structural plate. Fortunately, that structural plate must have shielded the actual lander from the explosion and the heat, and the lander survived in tact.

Nope. One of the first things I did in the game was to create a bunch of ion probes to start unmanned exploration. I fired one up and went to go do something else at the space center (I didn't even know about time warping at the time), and I had *no idea* why I was unable to leave the flight without ending it. The space center option was grayed out without any explanation of why. Eventually I discovered the restriction on leaving (or time-warping) with throttled-up craft, and I've been disappointed with it ever since. I love designing with Ion engines, but I hate trying to fly them for this exact reason. The other problem with them is that they don't really work with the Maneuver Node system, since it (reasonably) assumes instantaneous impulse burns, rather than long continuous burns. Imagine what you could do if you could set up an ion engine to fire continuously (even at <10% power) and set it on a course towards Duna or Jool. For short distances like the Mun, it may not make sense, but over the long haul, long periods of low thrust may get you there faster and more efficiently. Unfortunately, I'm not sure what can be done about this, since continuous low-thrust trajectories are still an active area of research, and are much more difficult to compute than standard Hohmann transfers. But I would love for Squad to do something about this, if possible. BTW, with only one Ion engine, you should only need 1 gigantor array to run it at full thrust (around Kerbin, assuming its unobstructed, and oriented towards Kerbol). Definitely not six. The rough rule of thumb is 1 gigantor per ion engine. However, Gigantors are also heavier than the equivalent amount of smaller panels (1x6 or 2x3 panels) needed to produce the same amount of electricity. IIRC, 8 smaller panels produce the same amount as 1 gigantor, but weigh less. You can also cut the burn time down somewhat by adding on additional engines, but this requires additional solar panels, which drive up the mass, and reduce the dV. But this approach seems to miss the whole point of ion engines, which is long periods of low-thrust.

I haven't tried the big telescope yet, but the small telescope generally works fine... as long as you don't try looking through it on the launchpad, like I did. I'm actually wondering if the larger telescope will need to be updated, since it is listed as a command pod.

Good news: KER was just updated this afternoon to be 0.21 compatible!

Yay! Update! Glad you're still around, Cybutek. And ouch! That's sad about all that time spent in vain. I can certainly understand how that might dampen your enthusiasm. In the meantime, I've been thinking about possibly writing a mod of my own, along a similar line to this one (or maybe even something that could be incorporated into it) -- "Kerbal Electrical Engineer". It would list all parts that produce, store, or consume electricity, and show you things like whether you have a power surplus or deficit, how long your batteries would last in shadow, or how long they would take to recharge. I was trying to compute that for a satellite a while back, and wishing I had a mod to do it for me.

Aviation Lights

I refer you to post #225, four posts above your own... Edit: For anyone else considering looking at this, I think I found the problem in the source code, with attaching the BuildEngineer module directly to the root part, but unfortunately, I don't have time to test fixing it at the moment. Maybe later this week? (Warning: Tech-speak ahead) The method BuildEngineer.OnEditorAttach() contains the following condition: I think the entire second half of the AND condition should go away, so it would just read "if (IsPrimary)". Looking at the cfg files between .20 and .21, command pods just have "module = part" now, rather than "module = CommandPod", so "(this.part is CommandPod)" is probably always false, which mean if there is no parent part (i.e. when it's the root part) then the entire condition would fail. I don't know why that condition was there in the first place, so who knows what kind of other problems it might cause removing it, but I think that's the root cause of the problem.

After a bit more testing tonight, I've concluded I was completely wrong about this. Adding the Build Engineer module to a part cfg will work if-and-only-if the part it is added to is *not* a root part -- regardless of whether or not the part is a pod/core (or whether it also has SAS/RW functionality). I temporarily added the module to both the sphere probe core, and the jumbo 64 fuel tank. When either of those parts was used as the root part, the dialog *did not* show up. When either of those parts was added on to an existing core without Build Engineer, the dialog *did* show up. At this point, I'd probably need to start looking at the code to determine what's going on further, but I don't know if I'll have time to do that.

If we forgo manned landings, and just send a manned "mothership" (to teleoperate robotic landers, maybe?), I wonder if a "Mini-Magnetosphere" could provide the required radiation shielding. And as a bonus, perhaps provide efficient propulsion as well. Edit: Beaten by Fox62, re: magnetic shielding, although I think straight-up electromagnetic shields end up being too massive, unless you inflate them with some type of plasma.

It mostly works fine in 0.21.There was an issue with selecting a target in the Rendezvous tab of the Flight Engineer, that caused to dialog to shrink to almost nothing, though it's reportedly been fixed by a recompiled dll that was posted a page or so back (I haven't tested it myself). There is also an issue if you add the Build Engineer module to a new pod or core part by modifying its cfg file (either directly or via ModuleManager), then that dialog doesn't show up at all. But if you aren't doing that (if you're just using the part, like it was intended), you're probably OK.

Been wondering the same thing here. Just as a test, I tried adding the BuildEngineer module to the cfg for a stock part that *wasn't* a command pod or probe core. In this case, I happened to pick the octoganal strut. When I attached that to new ship, the dialog appeared as expected. So it isn't all stock parts per se that is preventing this. It seems to me that its either the pods/cores that disallow it, OR just root parts in general. It should be pretty easy to test which is the case by modifying and using a non-root core part and a non-core root part, but i haven't had a chance to do that yet. I'll try to look at that tonight: it should at least give an indication of what is causing the problem. EDIT: Actually, I just realized I've already done this... When I first started testing, I still had the old KSPX HECS core installed (in addition to the new 0.21 HECS core), and still had it referenced in my MM cfg. When I placed it as the first root part, the B.E. dialog *DID* show up. So it can't just be root parts causing this. It *must* be something in the new pod/core cfgs. The first thing that comes to mind is the new SAS/RW modules, though I fail to see how that would cause this. MOAR testing needed!

Honestly, I never understood what the purpose for the tape deck was (other than a pretty animation) -- the Flight Engineer chip already contains both modules (check out the cfg file). I used to throw it on everything, but then I created a cfg file that uses ModuleManager to add it to all pods/cores, so I didn't need any parts. I even hid them in the VAB using the filter in the SimplePartOrganizer mod. If fewer parts is better, zero parts is best.

Flight Engineer (which is mostly working, except for the rendezvous feature) is shown during flight. There are helpful stats for orbit, surface, vessel, and rendezvous. Build Engineer (which apparently isn't working when attached as a plugin module for a pod/core) gives ship stats in the VAB/SPH, such as each stage's mass, TWR, Isp, and dV.

OK... tried this again (with 21.1 now), and I'm not able to repeat the problem where the Build Engineer dialog disappears and doesn't come back due to removing and reattaching the chip. But I *am* still seeing the problem where placing BuildEngineer in a part's cfg doesn't make it appear. To eliminate the possibility that ModuleManager isn't working right, I modified a stock part directly with the following lines: MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } The flight engineer appears, but the build engineer doesn't.

Actions on the Fly.

This is listed as compatible with .21 but I'm having issues... I'll ignore the RDV issue mentioned above (disappearing GUI when an RDV target is selected), which I've also seen, but don't really use. More importantly, I'm having trouble with the Build Engineer in the VAB (haven't tried SPH). If I attach the Flight Engineer chip (which is supposed to have Build Engineer capability in it as well) I don't get the Build Engineer GUI at all. If I specifically attach the Build Engineer chip, then I do get the VAB window, but if I remove the chip then re-attach it, it doesn't come back. Finally, if I use ModuleManager with my usual cfg file to automatically add both engineer modules to all pods/cores I get no Build Engineer dialog in the VAB at all; only the Flight Engineer dialog in flight. I haven't seen any problems reported with ModuleManager, so I assume the problem lies with BuildEngineer (but I could be wrong, since other people are reporting BuildEngineer works fine for them). I need to investigate more when I get home tonight. Anyone else see this, or have any other ideas of things I could try?