Kobymaru

Um, I think those changes didn't... "stick". Building the DEVELOP branch from your repo from source works fine, but the KolonyTools.dll fresh out of the MKS_0.50.13.0.zip (or the FOR_RELEASE folder on GitHub) still has the same texture path error and the incorrect resources in KolonizationMonitor. Are you sure you included the right version?

Created a GitHub issue for the jitter-wheels here: https://github.com/BobPalmer/Konstruction/issues/35

That's really strange. I'll try to reproduce this on my other Computer, but if this happens on a fresh install of KSP with only MKS, then I'm out of ideas. So have you been able to reproduce it, with the wheels apart? Do you mean are you using the adjustable Wheels? If you can make it stop and start, what are the conditions so it doesnt jitter? Is there a possible workaround? For me it jitters wether it moves or not. Putting it where? The regular wheels don't have servos. Do you mean the adjustable wheels?

This one does not Jitter: This one Jitters: This one Jitters more: I conclude that it's something about the wheels. Maybe there are some collider issues or something. Can you guys reproduce these Results or am I the only one?

They're only so close together to make the example simpler. This one jitters even worse:

Hey guys, do your PAL cranes jitter as much as mine? Even this little fella is definitely afraid of something : His name is MRE, short for Minimal Reproducible example. I could post a craft file, but that seems rather moot for a craft of 7 parts. Does anybody have a fix for this?

Hey, @RoverDude, two pull requests for you: Missing Icon Texture when Toolbar Mod is installed LocalLogistics vessel selector resource funkiness Would be awesome if you could merge them before the next release

Thanks, I think I finally understand. Warehousing is not the same thing as Scavenging. I have some follow-up questions: If this works in only 1 direction, does this mean that mulch is not picked up? Assume I have Vessel 1 with 1000 supplies, and Vessel 2 with space for 30 Supplies, which has 2 Kerbals. The supplies for 2 Kerbals last approx. 30 days with all recyclers considered. If I leave the vessel and go to the tracking station, timewarp 30 days and come back to vessel 2, they immediately turn into tourists. Then after one second, the scavenging mechanic kicks in and pushes supplies from Vessel 1 to Vessel 2. The 2 Kerbals turn back into fully functioning Kerbals. Is this correct behaviour? Because that's what I'm seeing. That is slightly awkward, because this requires me to constantly set timers so my poor Kerbals don't starve.

Hi! Is it normal that while habitation is shared between all vessels in a radius of 150m, that the Supplies *must* come from the same vessel? So if a Kerbal sits on a vessel without supplies, but there is a big supply container right next to that - he will rather starve to death than leave his vessel?

Alright folks, here's the Bug report for Stock: http://bugs.kerbalspaceprogram.com/issues/13569 If you have more information, please pile it on. Also would be nice if someone could test the quicksave from the bugtracker in pure stock and then set the bug to confirmed

Whoops. Sorry about that.

Well water isn't missing, so that's obviously wrong and a bug. However, Cultivate(D) stands for Cultivate with Dirt - and I don't see any Dirt in your base. Maybe you should try to switch the converter to Cultivate(S) for Substrate? Alternatively, provide some dirt. Edit: Whoops. You got all the things, and your converter should work. I'm afraid I have no explanation. Do you have a save for this base, so I can take a look?

That's just DropBox being silly. I copied it into my folder and got the public link. You could have just "saved the web page" with your browser. Interesting, but runs "fine" (as fine as it gets with a laptop with integrated graphics) on my computer, even with my full mod list. Here is my fully mod list: - AlternateResourcePanel v2.9.1.0 - AtmosphereAutopilot v1.5.9 - B9PartSwitch v1.5.3 - CommunityCategoryKit 1.2.1.0 - CommunityResourcePack 0.6.5.0 - CommunityTechTree 1:3.0.3 - DockingPortAlignmentIndicator 6.5 - EasyVesselSwitch 1.2.0.0 - FirespitterCore v7.5.1 - KAS 0.6.2.0 - KerbalAlarmClock v3.8.3.0 - KerbalEngineerRedux 1.1.2.8 - KerbalInventorySystemNoFun v0.1.2 - KIS 1.4.0.0 - Konstruction 0.1.9.0 - KSPSteamCtrlr autodetected dll - MemGraph Release_1.1.0.3 - ModuleManager 2.7.5 - NearFutureElectrical 0.8.2 - NearFutureElectrical-Core 0.8.2 - PreciseManeuver 2:2.2.2 - Steamworks autodetected dll - Toolbar 1.7.13 - Trajectories v1.6.5 - UKS 1:0.50.11.0 - USI-Core 0.3.6.0 - USI-FTT 0.6.5.0 - USI-LS 0.5.16.0 - USITools 0.8.9.0 - VesselMoverContinued 1.5.1.3 - WaypointManager 2.6.0 Maybe it helps you to narrow down the culprit by subtracting my mods from your mods.

Don't bother, like voicey99 said, it's almost entirely MKS and KIS parts. But thanks for offering Well, this bug I would call rather game breaking . Not a whole lot of point in setting up drilling operations if the drills don't catch up during timewarp. Huh? Which wall of text are you referring to? Also, I'm confused now because I don't have a "dampener" button in my 0.50.11 release which seems to the latest. Do you have a different version? Did I screw up my install? Either way, that's less important than... Thanks for testing and thanks for the Info!! The problem here is the Terrain Detail setting. I had my terrain detail set to "Default" (running on a laptop with integrated graphics) When on "Default", I get errors up to 10m. When the detail setting is on "High", the highest errors are at 0.03m. That means after loading and re-saving my save, the base doesn't jump anymore, and the Drills keep running. Great work with all the info here, guys! Thanks to @dboi88, @jd284 and @voicey99 for help. Sounds like that's definitely a Stock Bug and should be reported. I will try to do a nice write-up and create a Bug report on the public tracker tomorrow (unless you guys want to go first?) and post the link here.

Yes, I do have this.I do have several "ground contact! - error:" errors for each of my vessels. The one in question has an error of -3.739m which is both consistent with the visual height when starting (see pictures) and the heigh difference from 4295m to 4291m. I think it is a stock issue indeed. No RSS or Kopernicus installed. I think a simple fix would be to defer all the Drills processing to *after* the physics loading. This might not be fixable in MKS, but the good news is that @RoverDude is a SQUAD developer as well All we can do is provide nice and simple test cases, create a bug report on the public tracker and politely but firmly ask RoverDudes attention I have worked quite hard to get find a good base spot and set up the base, so I am very reluctant to move the base to a flatter area (especially since 3-biome crossings with water are very rare on Duna). Can you think of a good workaround?

Mind you, it's not a physical hop. The game loads the scene, the vessels are started in the air *before* physics. Then the vessels get set down, and *then* the physics start. By that time, no more hopping. But apparently the drills start doing their thing before physics start doing their thing, which means the drills are fooled into believing that the vessel is flying. Yay, thanks! Minimal mod list: - CommunityCategoryKit 1.2.1.0 - CommunityResourcePack 0.6.5.0 - FirespitterCore v7.5.1 - KAS 0.6.2.0 - KIS 1.4.0.0 - Konstruction 0.1.9.0 - KSPSteamCtrlr autodetected dll - ModuleManager 2.7.5 - Steamworks autodetected dll - UKS 1:0.50.11.0 - USI-Core 0.3.6.0 - USI-LS 0.5.16.0 - USITools 0.8.9.0 Save: https://dl.dropboxusercontent.com/u/1414175/ksp/quicksave-10m-start.sfs Well the 10m jump happens in both the hotfix patch as well as the official release (0.50.11).

Yes, I have the "Toggle Ground Tether" option available. If I press it, I get "Ground tether attached!". If I quicksave, then quickload, I'm still 10m in the air. Here are pictures:

Well yeah, recently, all vessels make a 10m Hop, then get set down to the ground one after another before the physics kicks in. I'm not even sure if that's a mod or stock KSP, but it seems to be on purpose and a workaround for physics insufficiencies. So I don't think mounting it lower will help And it seems indeed that this is the reason for the drills stopping. Thanks for the hint! Now I just need to know what causes this.. Unfortunately, the patch does not solve my problem. While physics easing is in progress, the base is still 10m up in the air and the drills have "No Ground Contact". That is great news however, because my base has been sliding 4 mm/s down a slope. That sounds little, but is not nice considering I have carefully placed all modules around a 3-Biome corner. I used to tie them down with a KIS CB1 Ground base, but hopefully this will be a thing of the past.

On my base, all drills stop working when the vessels are loaded. That is really annoying. Is there a fix or workaround for that?

Hey @Youen, how hard would it be to add the "target" not only from the current impact point, but also the target vessel (if it is landed) or a particular waypoint? That would also be pretty cool.

I did have a situation where I wondered where all my supplies just disappeared. Not enough information though, I need to do some more playing/testing.

It is already on CKAN. If you can't find it under the available mods, you have to go to CKAN Settings -> Compatible KSP Versions -> Select 1.2 & save.

Hi, I have been getting the following exception quite often when moving out of physics range of certain vessels: ActiveJoint.Terminate Exception while setting drive mode: System.NullReferenceException: at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_CALL_InverseTransformDirection (UnityEngine.Transform,UnityEngine.Vector3&,UnityEngine.Vector3&) at UnityEngine.Transform.InverseTransformDirection (Vector3 direction) [0x00000] in <filename unknown>:0 at ActiveJoint.getControlOrt (Vector3 refAxis, PartSpaceMode mode) [0x00000] in <filename unknown>:0 at ActiveJoint.applyCoordsUpdate () [0x00000] in <filename unknown>:0 at ActiveJoint.SetDriveMode (DriveMode m) [0x00000] in <filename unknown>:0 at ActiveJoint.Terminate () [0x00000] in <filename unknown>:0 Has anyone seen this? I have no idea why this occurs, and don't know what mod this belongs to. Here's my mod list: KSP Version: 1.2.2.1622 Installed Modules: - AlternateResourcePanel v2.9.1.0 - AtmosphereAutopilot v1.5.9 - B9PartSwitch v1.5.3 - CommunityCategoryKit 1.2.1.0 - CommunityResourcePack 0.6.5.0 - CommunityTechTree 1:3.0.3 - DockingPortAlignmentIndicator 6.5.2 - EasyVesselSwitch 1.2.0.0 - FirespitterCore v7.5.1 - KAS 0.6.2.0 - KerbalAlarmClock v3.8.3.0 - KerbalEngineerRedux 1.1.2.8 - KerbalInventorySystemNoFun v0.1.2 - KIS 1.4.0.0 - Konstruction 0.1.9.0 - KSPSteamCtrlr autodetected dll - MemGraph Release_1.1.0.3 - ModuleManager 2.7.5 - NearFutureElectrical 0.8.2 - NearFutureElectrical-Core 0.8.2 - PreciseManeuver 2:2.2.2 - Steamworks autodetected dll - Toolbar 1.7.13 - Trajectories v1.6.5 - UKS 1:0.50.10.0 - USI-Core 0.3.6.0 - USI-FTT 0.6.5.0 - USI-LS 0.5.16.0 - USITools 0.8.8.0 - WaypointManager 2.6.0 Legend: -: Up to date. X: Incompatible. ^: Upgradable. ?: Unknown. *: Broken.

Whoops, sorry about that, I missed it. Understandably. If they can't be recovered, that will make a lot of people sad.

Hi! I have noticed that big, old forum threads have disappeared. So far I have seen 3 threads: @RoverDude's MKS/OKS thread here: http://forum.kerbalspaceprogram.com/threads/79588 @politas CKAN thread here: http://forum.kerbalspaceprogram.com/index.php?/topic/143140-ckan-the-comprehensive-kerbal-archive-network-v1220-28-december-2016/ @Nertea's Near future technologies: http://forum.kerbalspaceprogram.com/index.php?/topic/47786-105-near-future-technologies-feb-20-bugfixing I didn't see any other missing threads yet, but chances are, some exist. Does anyone know what's up?