SpaceNomad

Ohh, stock trained me to ignore the description texts (They normally pose more questions than they answer.) Sorry to say that (since other than that, I really love your mod(s)), but I'm not that happy about the decision to invent extra situations and extra biomes for single experiments. There's already a lot to remember, about which experiments are possible in which situation and when they are biome-specific, and the altitude limits for different bodies (for the latter at least mods like KER help a lot). Experiments making up their own rules don't really help with that. For the contract you could just let the experiment fulfill the requirement in high or in low orbit (you have to enter the required orbit anyway, so not much room for cheating, or just require the orbit to be entered before enabling the criteria about performing the experiment). At least the Windows version contains the build number. My KSP Linux Version identifies as 1.0.5.0 in-game. That makes the "silent patch" really sneaky (well, at least, the README contains the build number).

@DMagic I just got a contract to perform a long-term orbital reconnaissance survey of the Mun in a 117 by 118 km orbit, which is a high orbit. Is it intentional that it asks for performing the experiments in low munar orbit, though (i.e. below 60km)?

I just updated To CapCom 2.0 via CKAN and it seems this version broke the sorting by remaining time (for both offered and active contracts). They are sorted in no recognizable order. Sorting by other criteria seems to work properly, though.

Well, as I already said, it's probably missing the "PLUME" before the opening braces. This is only an educated guess based on the fact, that the first such block in the file is a PLUME node. I don't know for sure what it actually does (If I had to guess again, based on the name I would say it's responsible for the engine effects) The cited node should probably be electric_qvp { PLUME { name = Hydynelox-A7 transformName = TT localRotation = 0,0,0 localPosition = 0,0,1 fixedScale = 4 energy = 1 speed = 1 } @MODULE[ModuleEngines*] { @name = ModuleEngineFX !runningEffectName = DELETE %powerEffectname = Hydynelox-A7 } } And the remaining nodes in this file are also missing the "PLUME". If there was a github repository, I could have just sent you a pull request.

And another syntax issue: In WarpPlugin/Patches/KSPI_CTT.cfg: // adjust positions of lower tree ============== @RDNode:HAS[#id[actuators]] The "==============" should be in a comment.

When testing a little script that was supposed to parse the ModuleManager cache, I stumbled over a few errors in config files of this mod: In WarpPlugin/RealPlume/Quantum Vacuum.cfg there are a lot of compound nodes without a name. From the context, I assume they are all missing "PLUME" before the opening brace, only the first one has it. Though ModuleManager does not complain, it seems to get confused by this nevertheless, as I see literal "@MODULE[ModuleEngines*]" in its config cache after those erroneous nodes. For example: electric_qvp { { name = Hydynelox-A7 transformName = TT localRotation = 0,0,0 localPosition = 0,0,1 fixedScale = 4 energy = 1 speed = 1 } @MODULE[ModuleEngines*] { @name = ModuleEngineFX !runningEffectName = DELETE %powerEffectname = Hydynelox-A7 } }

Very close: They are brought by the Kraken, of course! The Kraken gives, the Kraken takes.

First of all: Thank you for the great mod. I was just wondering why the docking helpers are not surface attachable. I think they should be attachable wherever docking ports are and those are surface attachable. For the moment, I helped myself with the following MM sniplet: @PART[NBdockingHelper*]:Final { @attachRules = 1,1,1,0,0 } Note, that I also disabled allowSrfAttach instead, because it became kind of fiddly to attach the docking ports to it without.

Not VERY . At least the page on Kerbin states the correct current numbers (it's even mentioned in the "Changes" section). The Wiki is filled with content by users (so you and me ), so if you find a place, where it is still wrong, just fix it! In defense of the Wiki: At some time Squad claimed it was fixed (0.24 apparently), but it wasn't. And this time they weren't very vocal about it. It's hidden deep in the Changelog and I'm not even sure that the sentence really refers to this change, it's really cryptic: On another topic: I've actually looked into the Kerbal Alarm Clock source code a few weeks ago to find out how hard it would be to hack another calendar into it. I had assumed it would be quite easy and I just had to add some code converting the number of seconds into a date string. But the date/time code is overly complex and spread over several classes. So, not that trivial.

Not anymore. It has been that way for a long time. But in 1.0.5 in fact the synodical/solar day was changed to 6 hours. So sunrise is now at the same time every day, at about 4:12 at the KSC (I have repeating Kerbal Alarm Clocks running for sunrise and sunset at KSC). The sidereal day is now a bit shorter (6h 59m 9.4s).

The 64 bit vs. 32 bit version is not about double vs. single precision floating point numbers. It's just a coincidence that they are 64 vs. 32 bits long as well. Both double and single precision floating points exist on 32 bit architectures and 64 bit architecture. So, I don't expect there will be "higher precision numbers" in the 64 bit version.

Funny. I just recently were also pondering a Kerbal calendar. I also came to the conclusion that the lacking axial tilt, and neither an inclined nor eccentric orbit would make the astronomical year quite irrelevant. The Mun on the other hand would cause quite substantial tides (given its closeness and the fact that tidal forces scale with 1/r3 instead of 1/r2). It also causes regular eclipses. So, the calendar I invented was also based on the (Mun-) month. This is the sidereal month. I would expect the synodical month (i.e. full Mun to full Mun) to be more relevant for a calendar. According to my calculation it is 141,115s (6d 3h 11m 55s). The value in the Wiki seems to be slightly off. Based on that I came up with the following calendar: A month is either 6 or 7 (Kerbal) days. It would play the role of the working week. A (Mun-)year or Mun-cycle is a cycle of 15 months: A cycle starts with a 7 day months, just alternates between 7 and 6 days and thus also ends with a 7 day month. This basic pattern gives you an average month of 6d 3h 12m (98 days for 15 months), so just 5s too long. Every 288 cycles, the last month would have only 6 instead of 7 days (and this would be called the Month of the Kraken, due to the Stolen Day). Thus, we get exactly 6d 3h 11m 55s Now, what we need is names for the 6/7 days in a week (month) and for the 15 months.

It's actually not as bad as you might think. I'm playing the Linux 64-bit version of KSP with >100 mods installed and bad interactions between mods are astonishingly rare. There is another problem, though: Performance. The lots of mods I have installed lower my FPS quite substantially. Uninstalling a group of 40 mods raises my FPS in a certain situation from 12 FPS to 26 FPS. I'm now in the process of finding out which mods are the worst offenders to decide if they are worth their cost. It might well be that people find that after installing lots of mods in 1.1 their performance to be worse than in 1.0.5.

@Diazo, I tested your DLL shortly in my heavily modded main-installation with the original savegame and ship. So far, I wasn't able to trigger the bug. So, I would say bug fixed. Thank you! BTW: If you want a little fun after the hard work, try flying the test craft. At least with stock it has a very "interesting" dynamics Now, I understand what "Space Noodle" is referring to.

Then the time was well spent after all. And it's still me to have to thank you for the months of work that went into your great mods.