AerospaceME

You say the new ARM parts are over powered. But what is your payload at Lathe? IRL, the Saturn S-1C (first stage of Saturn V) would SSTO in theory if the 2nd stage, 3rd stage, and Apollo CSM/LM weren't stacked on top. But the point of big boosters isn't to put an empty tank into space. Its to put a big payload into space, or in the case of ARM, bring a big one back. Their overpowered until you want to put a Kerbodyne S3-14400 Tank full of LFO into interplanetary space, grab a class E, and powered soft land it back at KSC.

Science feature requests: 1) Track the mass and speed of impactors while doing the seismic experiment repeats and give bonus science (less fall off for repeats) for using subsequently larger and faster impacts, but only if this would actually be meaningful in real life. I'm not a geologist, so I don't know if smashing 5 tons at 40 m/s vs. 500 and 400 m/s into a massive planetary body would yield data which was different in a meaningful way. No big deal if not, I'll still smash as big and as fast as I easily can just for my own edification. A main sail pile driving a few orange tanks into Kerbin is worth the price of admission just for the fireworks. 2) Now that we have the concepts of interactive science and telescopes, how about coordinated experiments? You get X amount of science for doing an impact with seismic sensors, but you get significantly more if you observe it with a telescope. How much more can depend on the scope distance to the impact and, if we had more telescopes then just the IR, the spectrum detection width of the telescope. IIRC, when the 3rd stages of Saturn V impacted the moon, NASA didn't just watch the needles blip on the seismographs, they pointed cameras and telescopes at the impact point to study the composition of the body based on the ejected debris. While were on the subject of interactive science, how about an alternate version of the experiment based on intentionally detonating a small AM tank on the surface and in the atmosphere (for bodies with an atmosphere) and studying the results not only with the telescope and seismic sensor, but also the temperature and blast wave pressure with thermometers and barometers placed near by? I realize that's a heap of coding which might take a fair while to accomplish. Just some thoughts on what to do next with KSPI science. Actually blasting something into a planet after the work of deploying sensors and engineering craft for both is much more fun then just pulling up my standard lander, flying somewhere, landing, clicking, and repeating ad nauseam.

I disagree with a receiver limit. If you have some 5TW finger of God microwave beam and you fly into it, you better have the equipment to handle all 5TW or its going to be like a moth flying into a bonfire. I understand advanced network could adjust power transmitted to match the demand of a different vessel. Perhaps this could be simulated by limiting all vessels connected to a transmitter / relay to the same power, up to the max available for the network (to keep in line with conservation of energy). That way you couldn't have a craft with 5 DV vistas and a micro probe powered on the same link.

Fractal, any thoughts on this suggested change?

I think the pre-cooler stuff needs some work. It would be nice if they also worked by attaching to the thermal nozzle / turbo-jet / rapier engine instead of intakes. This would allow compatibility with radial intakes, give design flexibility, and still be realistic as the turbo machinery shouldn't care where the intake air is cooled, as long as its cooled before it enters. It would be consistent with the rest of KSP to assume all turbo machinery is contained in the engines / nozzles. The pre-coolers could have a rated amount of intake air they can handle to prevent blatant intake spamming a few nozzles. Make the rating tied both intake air and air speed, so cooling required = airspeed x intake air. Exceeding the cooling capacity provided by the pre-coolers on the vessel would cause nozzles to overheat and explode.

To those setting up relay networks: Make sure you match the semi-major axis / orbital period exactly, not the apogee and perigee. That will keep the phase angles from drifting. If the apo/peri doesn't match, you'll have some radial wobble, but if the orbital periods don't match then your phase angles wont be stable and your satellites will drift toward/away from each other, mucking up the network.

They work when placed anywhere on the ship, but I tend to place mine on the generators as a matter of engineering aesthetics.

It wasn't poorly designed, just poorly named. You should have called it an AM torpedo instead of an AM ferry.

1: Thorium has more power but requires more frequent fuel reprocessing compared to uranium, or without reprocessing, will run out of fuel faster. 2: Science lab to do the reprocessing, fuel hexcan with space for depleted fuel. 3: Specific impulse is a measure of both exhaust velocity and propellant efficiency. A higher Isp (specific impulse) means you get more momentum change per kilogram of propellant. It is different from thrust. Delta V is how much you can change your velocity, but has no information on how long it will take to change your velocity. If you accelerate at 10m/s^2 for 1 second or 1 m/s^2 for 10, in both cases you've used 10 m/s delta V. Higher Isp at the same thrust gives you more delta V. Thermal engines are fairly anemic until you have at least upgraded fission reactors, but really come to life with fusion and anti-matter. 4: I haven't used the methane tank stuff yet, but a few versions back the fission reactor models changed. I updated without problems. The models swapped and the saved ships just loaded the new models and clipped the parts as needed. 5: The documentation is improving all of the time, but with all the new features and constant updates, documentation has lagged. My advice is just spend some time experimenting and figure out what works. KSP is a sandbox game after all.

Wow! Talk about being ahead of an issue. If they do run out of UF6 or DUF6 space, the boys on Duna can sit tight for a bit.

So I've been lurking this thread for a while now as I played through the KSPI tech tree, but I think I've found a bug. Being an engineer and "creatively lazy" I tend to make modular ships from common sub-components and assemble in orbit. One of my design components is a Drive / Service section using a 3.75m thermal nozzle, 3.75m basic nuke reactor, 3.75m generator, 3.75m x 8m NP LFO tank, 3.75-2.5m LFO adapter tank, 2.5m probe core and 2.5m docking port. This has appropriate RCS, monoprop, radiators, etc appended to the side. I dock this to whatever "payload module" I'm using. Typically this has a 1.25m reactor and generator or two to provide "hotel" power when the engine is thrusting to keep my science labs running. Anyway, the problem I'm having is that the 3.75m reactor seems to be pumping some of its DUF6 into the smaller kiwi. The UF6 on the Kiwi still shows as full, but it's DUF6 capacity is half full and the big reactor fuel/waste mass is off by about the amount. I thought the fuel/waste was non-transferable. Does the resource manager balance DUF6 across all available "tanks"? This isn't a problem for my 3 lab orbital stations which are permanently docked to their drive sections, but I fear it might cause problems for my lander modules which take the Kiwi full of UF6 and half full of DUF6 with them.