undercoveryankee

Real atmospheres don't have a hard cutoff altitude, so spacecraft in low orbits experience drag that causes gradual orbital decay and have to periodically "reboost" to the desired orbit. Parts of the Trajectories code could be useful to simulate the proper amount of decay.

No. If ModuleManager overwrote the original .cfg files, then you would have to restore them from backups any time you wanted to undo a change (if you removed a mod that contained a patch, or if MM had a bug in it). Currently, MM caches the patched state and runs the full parse process only when something changes, so you get nearly the same performance as permanently overwriting the originals without losing any information about the pre-patched values.

Unlike stock, where the antenna will automatically deploy when you try to transmit something, RT requires you to manually activate the antenna before you can transmit. Is your antenna activated?

The ModuleRCSFX plugin (http://forum.kerbalspaceprogram.com/threads/92290-0-90-ModuleRCSFX-v3-5-19-Jan-15 ) is the most mature way to do RCS configurations that have bugs in stock.

I agree that I'd like engineers to have some advantage over other classes at the KAS stuff, but something less harsh than the other classes having no KAS access at all. For now I'd say wait and see which classes end up most used after the KSP 1.0 balance pass.

Somebody generally posts to the Firespitter thread when a new version of the plugin gets committed, but that can be hard to find if you aren't right there when it's posted. Once you know that the plugin at https://github.com/snjo/Firespitter/tree/master/For%20release/Firespitter/Plugins is newer than what's in the package, the best I know to do from there is to manually look at when Github says the file was last updated.

Fuller explanation of the "&" issue: In ModuleManager 2 before 2.5.7, you could use "&" or "," synonymously to join tests. 2.5.7 removed the special significance of the "&" so MM could address science definitions containing the literal string "R&D". ModuleManager doesn't make changes that break existing patches often, but Squad kind of forced the issue by using "R&D" in places that were otherwise MM-able.

Variables are global to all code running on the same kOS processor, but they aren't shared between ships or even between multiple processors on the same ship. You don't need any kind of ship-specific storage.

I know that was the behavior in 1.4 and 1.5. Didn't it change in 1.6? - - - Updated - - - The current behavior is that MechJeb can control your spacecraft whenever you could manually control it. It's "incompatible" in that you can't arrange for MechJeb to do things while a probe is out of contact. The AR202, which acts as a probe core, gets ModuleSPU added so it doesn't provide local control to ships that are supposed to be unmanned. So you can use both RT and MechJeb in one game; you just don't get as much from the combination as you might imagine should be possible.

Only thing is you can't do math within the value side. Your code would set ResourceAmount to the string "5 * 5". To actually get MM to evaluate the math, you have to do the two-line assign and then *=.

See http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-2-3-5-%28Sept-14%29-Loading-Speed-Fix?p=1416253&viewfull=1#post1416253 for the syntax that's been available since MM 2.3.5. The link in the OP isn't the easiest thing in the world to see, but it's there. I think your use case would look something like @PART { %CrewCapacity = 5 MODULE { ResourceAmount = #$../CrewCapacity$ @ResourceAmount *= 5 } }

Using a MODEL {} node in your part's config to reference a stock model and rescale, weld, or retexture it is fine. Copying Squad's .mu file or stock textures into your package that you're distributing is where it becomes a problem.

Notice that you did get "Impact registered!" once for Seismic Barrage 1 Debris, milliseconds before the two "Ignored" entries. The name filtering is doing exactly what it's supposed to do: filtering out multiple events that are too close together to have any independent value. If you get the on-screen "Impact recorded, data can now be accessed" message, then you have at least one valid impact. I have seen a similar issue where I got a good impact but couldn't collect the data on the seismometer. As far as I can tell, the problem was that the internal ID of the vessel with the seismometer on it had changed between when I started monitoring and when I did the impact. (I put a probe core on the descent stage of each manned lander so I can use it as a seismic station. The original ID goes with the ascent stage.) Solution was to stop and restart monitoring after any configuration change on the lander that might affect its vessel ID.

An omni can communicate with a dish that is within the omni's range and pointed in the right direction. One omni can communicate with as many other antennas as are in range; the only advantage of multiple omnis is extended range in Root range mode. If you have satellites that are connected when active, but don't relay when you switch to another ship, the most likely cause is a dish targeting "active vessel" that's no longer pointing in a useful direction for the intended relay.

The hitchhiker doesn't have ModuleCommand in stock, but some mods add command capability to it. If some mod gave the hitchhiker a built-in probe core (ModuleCommand with minimum crew of zero), that could cause what you've been seeing.

https://ksp.sarbian.com/jenkins/job/ModuleManager/lastSuccessfulBuild/artifact/

I thought it was FixedUpdate() that got called every fixedDeltaTime, and Update() gets called every graphics frame. Most mods that produce or consume resources do it in FixedUpdate. Perhaps this is why.

If you need a smaller casing size than the smallest RealChute allows you to set, you'll need to modify the list of available casing sizes in the appropriate RealChute module. Which I don't remember being that hard, honestly.

One solution for this has been in RT for a while. Select the vessel in the tracking station, hit the rightmost RT button to bring up its antenna list, and you can rename it from that panel without having control.

That looks right to me.

I think those fields are added by Deadly Reentry. I've seen them on stock parts, and it's the kind of thing DRE cares about. "Temperature" is the part temperature, and "Ambient" is the ambient air temperature that DRE is using.

RT hasn't changed. Any part that has ModuleCommand but not ModuleSPU provides local control. Does your station have any third-party parts that act as probe cores? They may not be configured for RT.

Those lines are just a summary. The actual errors should have been logged farther back in the Unity log. What version of MM are you using?

That patch as a whole is converting Interstellar's methane tanks to RealFuels modular cryogenic tanks. It takes the tank's original methane capacity, multiplies by 4.412 to convert from stock-like units to liters, then does the same for Oxidizer at 5 liters per unit, and sets the modular tank's available volume to a number of liters that represents its original capacity. I don't see anything wrong with the patch. Can you look in the log and post the exact text of the errors it's generating?

The best I've been able to tell, ModuleSPU wants to be on a part that also has an active ModuleCommand. If you want a small radial part that gives you access to the RT flight computer, I think the best way with the current code is to add ModuleCommand and make it into a mini probe core. See the OKTO2 or MechJeb's AR202 for config examples.