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.

When hovering over the part in the editor (VAB/SPH) there is also a small scale in the picture, which in the case of the FL-T200 is 1m. Since the part seems to be a bit shorter than that scale, 0.8884m seems about right. And you're right that the part appears to be higher than wide (I just measured it on the screen when attached, 7cm height by 6.4cm width). But I think, that's just the perspective distortion, as the part already has its full height at the closest point to the camera, but reaches its full width further behind. Edit: When zooming further out the distortion becomes less, as expected (e.g. 1cm by 1.1cm, so already wider than high).

@Probus If I'm not mistaken, the version string format changed between 20160112 and 2016-01-15, note the added dashes. I assume, CKAN considers dashes to be lower than the numerics and thus considers the 20160112 version to be the highest in this year. It seems, CKAN has the epoch field which can be increased to tell it "we have changed the versioning scheme and consider all versions with higher epoch newer than those with lower epoch". There is also the related x-netkan-epoch field, I'm not sure how CKAN and NetKAN interact exactly. In general, it's better to keep the versioning scheme stable to avoid trouble.

The combination of Kerbal Alarm Clock and Transfer Window Planner also has a great visualization of ejection angles since the newest KAC version v3.5.0.0 (see this post for a demonstration).

@DiazoPhew, I finally managed to reproduce the bug with just AGExt and ModuleManager installed. The used craft file is in the following GIST. And here is a log (first load of the craft was successful, second one had the bug). To reproduce, just start a new sandbox game, move the craft file to its Ships/VAB folder and load it from the VAB. Repeat loading until the action groups mess up. The "Big Dish" groups should only have two actions each, the "Dish" groups only one. It seems to be "all or nothing", i.e. it doesn't matter which action group you watch. After one load they suddenly all have their symmetry parts added. If you can't make it work after several loads, try adding more boosters sepatrons. As you said, the number of parts seems to have an influence, and maybe your computer is faster than mine.

I thought so, as well. But my Kerbals were able to climb when my Astronaut's Complex was still at level 2. And now that it's at level 3, I don't see them doing anything differently. So, I suspect the game is just ignoring that flag. Maybe it was planned to restrict climbing with the Astronaut's Complex, but then it occurred to the devs, that climbing is something that Kerbals learn at the playground not in the Astronaut's training

That would somewhat fits to what I'm seeing when trying to reproduce it in my test installation. While I was able to replicate it there with the original vessel (but not with a very small vessel built from scratch), it's also much less reproducible than in my real installation (which has a lot more parts installed and thus might make the editor slower). Also, the more I strip down the test vessel to exclude mods, the rarer the event. I already started spamming stock parts to counter it So, I was already suspecting, there might be some race condition involved. One thing I just noticed: When the issue is happening, I'm seeing a lot of messages after I think, in the cases, where the bug didn't happen, those messages only appeared before the "Ship name loaded!" message. Would the timer firing before the load finished explain what I'm seeing?

Okay, I'll try to find a minimal reproducer. I hoped, it would be easy to reproduce. If it's an interaction with one of my 130 mods, that might take some time Though, only a very small fraction of them should affect the editor, so it's probably not as bad as it sounds. Any hint, what was the reason for this bug the first time (a technical explanation will do, I'm software developer)? Might make the hunt for a reproducer a bit easier.

I suggest installing KerboKatz FPSViewer and KerboKatz PhysicalTimeRatioViewer (see here) for experimenting with this setting. They let you see and edit the parameters ingame. For example with maximumDeltaTime of 0.02s I currently get 24 FPS and a physical time ratio of about 50% (which means, that per second real time only 0.5s of ingame time elapse, so slow-motion ). With maximumDeltaTime of 0.08s I get about 13 FPS but my physical time ratio is about 100% (so I get real-time instead of slow-motion, but the display is more stuttery due to lower FPS).

Haven't really looked at the code, but it might be worthwhile to change it, so it can write MM-compatible configs and read it back (not general MM patches but just the ones it writes). This way, the user has only a dependency on ModuleManager, which you pretty much need for any mod anyway Have you had a look at the TechTree editor included in KSP? I haven't used it, so can't really vouch for it, but might be worth a try. It's accessible when opening the debug screen (Mod+F12) while being in the R&D building.

You are aware that it doesn't seem to be actively maintained? The author of the plugin hasn't posted since last July and not even logged in to the forums in the last 3 months. So, be prepared to have to solve problems with it yourself; if something breaks in future KSP updates, for example. (Well, at least it should be trivial to convert it back to MM patches if all else fails.)