BechMeister

That Tug drone looks like it has fuel for ages. - but it also looks like it's going to be a bit cumbersome to move about? your pc must be a beast! My two small stations makes my framerate tank like hell.. I cant imagine what his crazy monstrosity does x) Man its really aesthetically pleasing Really nice usage of the big part as a engine shroud. what a monster xD Holy cow! You're mad! Im impressed that thing can even lift off! WOW Love your little platform. I only found your project now. Its funny I feel like we have parallel played a lot of the same Ideas... but the scale of your project is a lot more ambitious and more wild x)

nah - no major break through.

Thx a lot @Mikki! I some times "fear" I go too much into detail. But I have had times were, for instance when I was building K.G.02 and had to go back to use the gliders - I forgot how to get them into orbit most efficient. Then it was nice that I could go back and read how I did haha. But yeah.. I did not anticipate It would take this many hours to get the two stations operational. Although A lot of extra time was caused by bugs introduced by v0.1.3. - But i'm glad to hear its not too detailed x)

////////////////////MISSION_UPDATE\\\\\\\\\\\\\\\\\\\\\ H.T.D. back at K.G.01 after a succesful refueling mission: Mission Tasks: A. Test the updated 1st stage for the Methalox Glider. - Success B. Refuel the stranded H.T.D. - Success C. Complete a refuel run with Hydrogen (See Mission Tasks A to D last update) - Success Lessons Learned; Lessons Identified: A. Video showing the launch of the methalox glider, and return of the first stage. Experimenting with video editing: I wanted to experiment with making movies of my missions in KSP2. - I to see what it would look like if I made the hud smaller and cropped it out of the shot to make it look more cinematic. I then wanted to find a way to introduce HUD elements in a more organic way. The only issue as I see it is this: You need to film on very high quality to do this and not have it be pixilated. I am experimenting with this as I contemplate celebrating the finished project by making a cinematic showcase of the two stations as well as all the systems that support them... maybe on my more powerful school pc for enhanced graphics. But I digress. Comment on the design changes of the 1st stage: Swapping the lower two grid fins with wings was a good solution. Thx Bej Kerman for the suggestion. The rocket is more stable on the way out, and I have enough control to aim at the pad. You can actually correct really big errors as it can almost fly horizontally if needed (at least something like ÷ 30-40 °. Right now I have a lot more Δv than I really need.. But I suspect I can reduce the Δv the better I get at landing. B. The H.T.D. returned safely to K.G.01 - After the drone had been refueled and loaded up with another 20t Hydrogen. It was ready to attempt the mission task again, this time with a more conservative Δv consumption in every aspect of the mission. C. Note: This section has a lot of spoiler sections with a detailed walkthrough - as a step-by-step guide for myself to be able to repeat the process. Sorry if the section seems a bit bloated. The refueling went smooth this time - and the H.T.D. returned to K.G.01 with 94 Δv left - a pretty tight margin, Just how I like it. I was originally a bit afraid that the LV-1000 engines were "too" fuel efficient, in the sense that the fact it took them 5 min to do the transfer burn to The Mun - ment that they were burning the craft 30° off the prograde. Here is a reference photo of the 30° difference between being on course and prograde. Maybe it's just because my understanding is flawed? But I imagine that it is not very efficient to burn 30° off prograde to stay on course - a lot of that fuel is spend staying on track rather than pushing the Apoapsis right? For a detailed walkthrough of C(a): See Spoiler section: The craft made it to K.G.02. and the main take away is it arrived at K.G.02, with a meager 78Δv In difference - which translate to a difference of 318 Δv once unloaded with the full tank and loaded with the empty fuel tank. That then means that the Δv budget to get to K.G.02 and complete the rendezvous maneuver. Is only ~1.094 - 1.100 Δv or so. Otherwise the vehicle will be short of the target. Or that if the vehicle has less than 1.200 Δv when leaving K.G.02 - It needs to top off the tanks first. H.T.D. doing hand-over; take-over with the T.T.Ds (yes i settled on that name) The hand over - take over of the fuel tanks went smooth - and I did not have the same issues I had the first time I came back to K.G.02. That being said, I never turned on K.G.02s SAS - as I was afraid to summon the Krakken. See detailed walkthrough of C(b) - see spoiler section bellow: As stated earlier the mission succeeded with 94Δv to spare. The future will tell if a ~100 Δv margin is enough wriggle room for variations in mission parameters. I will know once done transporting all of the 6 missing tanks. To see the detailed walkthrough of C(c): See spoiler section bellow: Final Thoughts: It was nice to see that the theory was possible in practice. I think this will be the last update until K.G.02 has been fully fueled - unless something significant happens. The end of the journey is near. Stay Tuned for More!

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Home | CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz | GPU: NVIDIA GeForce GTX 1660 TI | RAM: 16,0 GB For some reason the SAS set to lock just starts make the station bend and steer uncontrollable. Notice how the SAS actively tries to turn the station. Things I've tried: 1. Just have the station on lock and see it slowly get out of control. 2. Make it point at a target (the sun) 3. Turn of all reaction wheels besides the ones on the core - I was wondering if the bug was made from RCW fighting each other. Included Attachments: SaveGame.zip

////////////////////MISSION_UPDATE\\\\\\\\\\\\\\\\\\\\ - Fueling K.G.02 with Hydrogen - M.T.D loading the H.T.D. with a hydrogen tank - inbound for K.G.02 Foreword: So I finally got around to experimented with the shielded/inline clamp-o-tron bug, and produce a report with my findings: I may have found a way to avoid the bug - I'll test it by installing the M.L.K.O's to K.G.01 and the escape shuttles. We'll see if it works or not.. if so It will perhaps give me a chance to finish both stations to the state I had planned. And maybe even before For SCIENCE! arrives. That being said, I need to tweak my fueling procedure of K.G.02 - more on that bellow: Mission Tasks: A. Fly the 20t hydrogen tank to K.G.02 - Success B. Swap the full 20t hydrogen tank with a empty tank from K.G.02 - Success C. Rendezvous with K.G.01 - Failure D. Install empty fuel tank, refuel and repeat step A to D. - Failure Lessons Learned; Lessons Identified: A. M.T.D. loading the H.T.D. - steady as she goes. Task A went smooth - The four lv-1000 engines may be efficient - but it takes a good 5min to do the intercept burn from Kerbin to The Mun. I dont trust thrusting in time warp... So there were plenty of time to drink my coffee. I was rather interesting though - The red line, that indicates for how long the burn will take, was on point. But the burn duration was off. So still I dont fully trust the maneuver planner.. its more of a guide line. Image shows the different Δv states of the mission to The Mun, as well as how much the burn timer miscalculated. The Burn Timer said it would require 918 Δv burn to transfer to The Mun. In reality it required 894 Δv - but it burned longer than the timer calculated. I dont fully trust the numbers and I wonder if I should try make the rocket equation to see how much Δv the H.T.D. actually has when it tugs a load of 20t. See spoiler section bellow for a detailed walkthrough of the Mission: B. H.T.D. has performed hand-over;Take-over of the 20t hydrogen tank with the Small Tug Drone that is about to dock the fuel tank to K.G.02 while another Small Tug Drone is preparing to connect the empty 20t fuel tank to the H.T.D. so it can transfer it back to K.G.01 for refueling. The rendezvous with K.G.02 had a lot of issues.. For some reasons the SAS just wanted to send the station spinning. I tried to disable all reaction wheels besides the center ones in the main structure tower... No luck, I tried to set a "control from here" to the top and make it aim at the sun.. no luck. The only thing that worked was to disable SAS and then use timewarp to kill its momentum and hope it was stable going out of time warp. It's something that I've tried with K.G.01 too - as i recall it, it was the first time I loaded the station in again after new patch. This was also the firs time I loaded K.G.02 in as well, so maybe it's just a bug where it does not know whats up and down first time you load the vehicle/station in after the patch? - I dont know... and I dont have enough that I feel like it warrent's a bug report. Any way - the hand over take over went smooth - fortunately the Small Tug Drones had no issues moving the full tank into place... and even with K.G.02 shaking a bit I successfully swapped the full tank for an empty and redocked the S.T.D.s (Damn... thats a bad acronym now that I see it..) Once the H.T.D. was no longer carrying the load of the fuel its Δv counter landed on these figures: I was hoping it would have been enough to bring it back to K.G.01 - but I would find out that it was not soo. More on that in Section C. Detailed walkthrough of the process in spoiler section bellow: C. The H.T.D. final resting place, all depleted of main engine Δv and almost all monopropellant - still about 30m/s too fast. It only took 9 Δv to get out of the Muns SOI - and another 171 Δv to get an intercept path to K.G.01. Which left me with too little Δv to actually complete the rendezvous. I dont know what the most efficient way to return to L.K.O is from The Mun. But maybe I can save Δv by having the correct approach. I will be able to save Δv on the path to The Mun. Normally I have had a path that just takes me into The Muns sphere of influence - but this time I flew a path that went through it instead of gracing it before falling back to L.K.O. I can possible save enough Δv to perform a fuel transfer without spending too much Δv If I do that. The reason I did it in a less efficient way this time was that it lined perfect up with a rendezvous with K.G.02 - where If I had opted for a more economical path. It would have taken a few days and orbits around The Mun before an optimal window would arrive. The Path and fuel stats of the H.T.D. had after the 9 Δv burn to leave The Muns SOI - and the correction burn of 171 Δv to put it on a rendezvous path with K.G.01 I am showing the end state of the Path back to K.G.01 to ask if there is a more optimal way to return that saves fuel? D. H.T.D. flying past K.G.01 with only a 30 m/s difference - all depleted of fuel. Since the H.T.D. failed to rendezvous with K.G.01 I will now have to send up a Methalox Glider to refuel the drone so it can attempt the mission a second time - this time with all the fuel saving mission changes needed to succeed. It is interesting how this was the exact same outcome with the old heavy tug drone - I am planning my vehicles for a level of efficiency I can't provide with my current skills and understanding of the game it seems. Moving Forward: Step 1 will be to save the H.T.D. - I will also attempt to redock the M.L.K.O.s and Emergency gliders with my new understanding of the bug that plagues inline and shielded docking ports. Then Step 2 will be to attempt mission tasks A to D again. I guess its the perfect time to test the suggestion from @Bej Kerman to swap my bottom grid fins to wings for better performance - Now that I will launch a Methalox glider before I had planned. Stay Tuned for More!

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Home | CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz | GPU: NVIDIA GeForce GTX 1660 TI | RAM: 16,0 GB Intro and context: I finaly got myself to pull myself together and make that updated bug report i promised @Anth This is a updated bug report of the bug hunting explored in these two topics: Video of the Bug: Bug Replication description in text: Test A: all inline/shielded port are closed on the open save: 1. Dock craft A, B and C together with a shielded/inline port 2. Quick save / Quick Load - Now all the docking ports will not display the option to undock and are broken. Any manipulation of time or SAS will break the vehicle a part. Test B: The shielded port on Vehicle B starts in the "deployed" - state upon load in from the save. 1. Dock all the vehicles to a shielded/inline port 2. Quick save/quick load - Now all the vehicles docked to a port that was not deployed upon load in will not register as being docked, and will break when manipulating SAS or Time. Test C (Not included) - Check if rendezvous with the vehicle trickers the bug: 1. Dock vehicle B and C with each other and use Vehicle A to burn away. 2. Perform rendezvous maneuver 3. check if ports have "forgotten" their docked state when they are loaded in again. Test D (Not Included) - Check if going into VAB/ KSC screen before rendezvous will tricker bug: 1. Dock vehicle B and C with each other and use Vehicle A to burn away. 2. Perform rendezvous maneuver 3. Go to KSC screen. Then Into the VAB. Then into the tracking station and load the rocket enroute to rendezvous with vehicle B and C 4. Perform Rendezvous and check if ports have "forgotten" their docked state when they are loaded in again. How to fix the issue ingame if you notice it before the vehicle breaks: I have in the past fixed clamp-o-tron shielded/unshielded that did not display the "Undock" option this way: 1. Make an costum action group for the bugged clamp-o-tron with Undock. 2. Press the number you assigned to the undock. This forces the vehicle to undock even if it does not fully register as undocked. Speculation on my part: It seems that when you save - the vehicle "remembers"/saves the state the Clamp-o-Tron Shielded/Inline was in when the vehicle was loaded in the first time and then carry that over to the next time it is loaded in. I at least think it was very interesting that the save where I had the port extended before saving and loading did not break when i quick saved quick loaded. Any way - Happy bug hunting @Anth and team. - Bechmeister signing out Included Attachments: testsaves.zip .ipsImage { width: 900px !important; }

That is not a bad idea! although i dont know if i dont mind that extra drag though - the 2 fins near the engines steer it quite well as of now, and reduce its speed to around 250 m/s. Which in turn makes lt very easy to land. How ever. If i added two control surfaces at the bottom. They can help with stability on the way up, and have the same function as wings on the way down. I guess there is something to experiment further with when the hydrogen tanks, eventually has to be refueled.

////////////////////MISSION_UPDATE\\\\\\\\\\\\\\\\\\\\ - Grid Fins - The refuel glider, parked next to its first stage after returning from a refueling mission at K.G.01 Foreword: So.. After 235 hours, blazing from star to star in the year 2330. Uncovering the meaning of Unity and battling the Starborn - I have completed Starfield, and are ready to return to finishing K.G.01 and 02 with renewed vigor. First pleasant surprise was the addition of grid fins! And boy do they make the aiming easier. Still have a lot to improve - I especially have a tendency to have a lot of sideways movement on the last few m/s before touch down. But more on that bellow Without further ado. Mission Tasks: A. Test new grid fins and their drag efficiency. B. Rebalance the 2nd stage glider. C. Refuel K.G.01 with Methalox Lessons Learned; Lessons Identified. A. I experimented with a few setup of fins. In the beginning I made a setup with 4 at the bottom and 4 at the top. Mimicking the version of the rocket with the airbrakes - the button ones would be open all the way through the thick part of the atmosphere to ensure the drag was behind the center of mass, and then retract them once the rocket - with my rather unconventional design.. wouldnt flip on it self. I would deploy the top pair when going down. I Found that the control was still a bit frail. I remembered that SpaceXs superheavy flies with the grid fins deployed to compensate for the draggy starship. Figured if its fins could control the rocket placed center mass - then maybe I could to. I tried to fly the rocket with the top pair deployed and I had more control - although its still like balancing a stick on your hand. If the rocket moves much beyond the circle of the prograde marker it will flip. On the way down I flew it with the top pair. At one time on the way down I found I had trouble steering it towards the pad. I remembered seeing youtube movie with Matt Lowne where he talked about them functioning as wings. I deployed all 8 grid fins and it almost flew as a plane. After a few refuel runs were I experimented more with the gliders wings (See section B) I got rid of the buttom half of the fins as I didnt feel I needed them. But missing the pad made me add 2 to the bottom part. Working as front wings to steer it into the pad: Refuel rocket deploying the 2nd stage, revised glider, showing the 4 top grid finds deployed for stability and the buttom two folded up. When I get more skilled with the grid fins I may remove the bottom two again. - I dont know if its just me. but I feel like the grid fins fight the SAS. In the upper atmosphere I feel like inverting the controls on the way down in the thin atmosphere, and then reverse it in the bottom 3rd part. I'm still playing around with it. Aiming is the hard part. I wish the game somehow could help us take the planets rotation into account. As of now I aim around here. 1st stage on its way down towards the pads. As you can see, I placed a little craft on the center landing pad (which I have set as target) to help get the general direction correct - I find extending or shortening the glide is easier than moving left or right. 1st stage safely back on the pad. The best landing I made during the several refuel runs. I find now that I can land on one of the 4 pads. But its always going to be the most convenient pad on the way down - and I land beside it most of the time x) See spoiler section bellow for the full walkthrough: B. Revised Glider making the final approach to K.G.01. With the gridfins now in game - and the ability to test them. I could revise the gliders wings to help with the drag. I reduced the wings over several flights - until the point where I had two gliders that could not be controlled on the way down - They would do the classic flip once they hit the atmosphere. The latest iteration sits at a sweet spot: The smallest wings that can give controlled decent - As long as you maneuver within 45° AoA it will not flip. Even with the wing reduction It is capable of flying at a ÷20° at around 150 m/s - meaning you have plenty of room to extend the glide if needed. I also found it has plenty enough fuel on to start the seperation at 1800 Δv - insted of 1600 - giving that much more Δv for the 1st stage to land. For full walkthrough - see spoiler section: C. During the 5 or 6 refueling missions I successfully iron out the kinks and got the vehicle ready for this patch quirks. K.G.01 is now opperational again after moving Methalox to K.G.02 and fixing all the things that broke - I gotta give the developers credits. My frame rate at the station is a lot better now than before my Starfield break. Moving forward: Now it is time to get the revised Heavy Drone up and proceed with fueling K.G.02's hydrogen tanks. I am also going to check if the Shielded/Inline clamp-o-tron is still bugged and make that propper bug report I promised Anth. Stay Tuned for More!

I strongly suspect it to be this bug (which is the same you linked @Spicat - but the "exploration" of it is more explored) - go to p.2 and read the last few posts. Which is related to the Inline and shielded ports bugging out - its like they forget that they have crafts docked to them when the craft is loaded in. They will "break a part" under time warp. - Which if your rendezvousing with the vehicle you will be under. You can test if the port is bugged out by right clicking it and see if it says docked - if it does not say dock you have to make a costume action that undocks the inline port and it will separate the vehicles and register them as separated. I have had a lot of run ins with this bug during my space station project. But I have not played since Starfield came out.. since i am slowly crawling through that game. As a father and student i don't get much time to play unfortunately. It reminds me that i sorta promised @Anth to make a cleaner version of the bug report x) When I get through my first run of Starfield I will get back to my station building.

It satisfy the B option mentioned here: But not A. This is what I am certain about with A: So far I can consistently break the Inline port by doing the steps mentioned here: dock a craft with a clamp-o-tron to a clamp-o-tron shielded/inline Quick Save and then Quick Load Right click on the Clamp-O-Tron Shielded. If it does not show the option to Undock the bug is in effect. Right click on the regular clamp-o-tron and undock Now the clamp-o-tron shielded should be broken. However - It can be fixed by following these steps: Make an costume action group for the clamp-o-tron shielded with undock on hotkey 1 Press Hotkey 1 Now the Clamp-O-Tron Shielded is no longer broken I have also discovered that the part connected with a bugged Clamp-O-Tron Shielded/Inline will drift away from the craft under time warp, and occasionally move independently from the rest of the craft when doing Pitch/Jaw/Roll maneuvers. You can replicate that with these steps: Dock a craft with a clamp-o-tron to a clamp-o-tron shielded/inline Quick Save and then Quick Load Right click on the Clamp-O-Tron Shielded. If it does not show the option to Undock the bug is in effect. If you activate SAS and Pitch/Jaw/Roll You may see the part connected with the Clamp-O-Tron Shielded/Inline start doing maneuvers on its own while "tethered" to the craft it is docked to. (clipping into the other craft) If you Time Warp, The part of the craft with the Clamp-O-Tron Shielded/Inline Will drift off the main craft but still respond to SAS of the part with the regular Clamp-O-Tron on But why and how the regular clamp-o-tron on drone - as shown in the video - broke i can only speculate. It was fixable with the same method used to fix the shielded one This is my speculations: I have a theory though, that I have yet to test. you have a Clamp-O-Tron docked to a Clamp-O-Tron shielded with the the bug active. Then time warp so the two crafts drift a part. then Quick save and Quick Load The game may (this is not something i have tested yet) register the two parts as separate crafts again. But with the docking bug on both the Clamp-o-Tron Shielded and Clamp-o-Tron will be broken. (still fixable with the costume action fix) The reason I suspect this is that I experienced a few times that when i was rendezvousing with the station with a new module and once I could see the station. drones were floating by themselves even If i had not left them undocked. Before finding the station and drone in this state This would happen: - I approach the station and loaded it onto the grid while in time warp until I am close ~10km off ( giving the drone time to drift off) - Then I some times I would Quick Saved and Quick Loaded to fix the Target Velocity which also frequently bugged in v.0.1.3. and found the drone and station undocked from each other and learned the drones docking port was broken. I have not tested this yet. P.S. - I believe this: Is caused by the same bug. These are all my findings on the matter as of now. I tried to be as thorough as possible - Sorry if it became a little long of a post

I am under the impression that its the same bug. As i see it the original post was a finding that there was a bug. Then through out the report the bug was narrowed down to be an issue with inline and shielded parts? I can make a new report if you want it more precise and try make a simple craft that I can replacate it with.

of course not Now I just feel a bit embarrassed with how casual I wrote mine

You need to quick save often, so you can revert back to a place were things were in order - thats what I do. Fx: - got burned all the fuel on stage one and stage seperated F5 - got into orbit F5 - i made my burn to the mun F5 etc. This way you will not lose to much process when ever the game bugs out. I am running into them more often now too - but its usually with an active craft. And when ever it launches without trejectory lines it blow up once it reaches space. You welcome - I tried to be as precise as possible

Ugh i know that one - though for me it was medium ports. I also learned the hard way that just because you can out a micro port to a small port in the VAB - does not mean you can in space xD

I decided to test it myself. I booted up the original save file from 14/07 - made an action group for both ports on the drone with undock on hotkey 1 - Pressed hotkey 1 while not docked to anything. - then proceeded to dock with the broken port = no issues - craft docked. So. I believe it has all something to do with a problem with the Inline/Shielded clamp-o-tron - The error occurs when ever you load a save with a Inline/Shielded Clamp-O-Tron docked to another Shielded/Inline Clamp-o-tron or regular Clamp-o-tron. OR! when you load a craft onto your "grid" (I dont know if grid translates - its more an eve online term I guess). - but when a rocket approaches a station and it comes close enough that it is loaded in. If you dock with a clamp-o-tron shielded/inline - move it around and then undock from it before "logging off" and loading back in they work fine. - So the error happens somewhere in the save and load process. At least that is my findings.

Reported Version: v0.1.3.2 | Mods: none | Can replicate without mods? Yes OS: Windows 11 Home | CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz | GPU: NVIDIA GeForce GTX 1660 TI | RAM: 16,0 GB Hello. I wanted to send up 3 of these Mun Landers to dock with my Mun Station: To make sure I could put them all into the faring and them not bounding around like the head of a chicken I decided to put decouplers on them and strut them in place - the reason I use decouplers is its the only way I currently know that will break the strut so the crafts can be separated. How ever I found that the docking ports not only didn't work - the decouplers would stay with the craft and be tethered to it - If you used time warp, they would drift away. But they would still react to the SAS commands of the craft. I tried to use a fix that has worked for other broken ports - setting an action group to undock and then press it even if it isn't docked - but it didn't work. I have left two save files in this folder: https://1drv.ms/f/s!AhGsvJ5Xnc4dsSxTvfRqdU9Cp23R?e=5iMsKT PS. I forgot to crew them.. SO you will have to spacewalk between vehicles if you want to test them. Included Attachments:

Certainly - I may also just have phrased it poorly. I have experienced 2 ways a port can be rendered broken: A. A craft "falls off" a Clamp-O-Tron Inline or a Clamp-O-Tron Shielded - Theory: The port is locked in a docked stage even if it has "undocked" - some times the craft that fell off the inline port will still react to the SAS of the craft said port is on. Other times it will register as its own separate craft. - why this is I have no idea. keep in mind that the craft mostly fall off in the background when you are timewarping because you control another craft that is rendezvous-ing with the station. - So I have never seen it happen "live". I've only ever arrived at the aftermath. It Can be fixed by making a costume action group with the undock set and pressing it. B. If you put a decoupler on a Clamp-O-Tron - No way to fix it. I have now given it its own bug report for you to approve. The question I was asking about was if the "patient zero" docking port mentioned here: It is a regular clamp-o-tron and not a inline or shielded, I was wondering if the "action group fix" had been tested on it and if it starts working again? - because that would indicate that the issue came to be from being docked with an Inline/shielded clamp-o-tron. I guess I could try myself. That savegame just lies pretty far back and call me lazy I'll get around to do the decoupler one asap. So they have each their thread. Doesn't it often go like that?

I have experienced the same - meaning I am launching some vessels upside down, as I can connect the clamp-o-tron st to clamp-o-tron st and its a strong connection x) But then I launch the second stage upside down, and have to do a flip maneuver once launched - of course it's not a solution for all crafts

@gluckezand @Anth12 the inline and shielded ports still have this issue yes. I can only recall having this issue on inlined parts except once. And that was the original drone who's port was broken. That was a regular Clamp-o-Tron. At least i trickered the "docked but not docked" bug pretty easy and resolved it by using forcing the shielded port to undock via action command. @Anth12 was it ever tested if using an action to undock on broken clamp-o-tron on the drone would fix it? That being said, i paused with on every undock, and it did not break the craft into pieces. And i have had multiple crafts around a station without them falling a part. So we may be out of the woods with that?

////////////////////MISSION UPDATE\\\\\\\\\\\\\\\\\\\\ K.G.02 fully assembled and crewed in orbit around the Mun, overlooking Kerbin. Mission Tasks: A. Install the last 4 methalox tanks to K.G.02 - Success B. Burn K.G.02 into a 0° inclination. - Semi-Success C. Develop Escape Vehicle for K.G.02 and a new Heavy Tug Drone. - Success D. Install Escape Vehicles and crew the station. - Success Lessons Learned; Lessons Identified: A. All 8 methalox tanks installed at K.G.02 It was quite the journey to get the last 4 tanks installed. I found out that the inline ports are particularly troubled - I installed 2/4 tanks no problem and logged for the evening. When i opened the game next day the "docked but not docked" issue showed its ugly face. I found out that if you load a save where the inline/shielded ports were docked to the drone, it would register the port not as docked, but the two crafts as one. It was quite a mess... I also had an issue where the Kraken would strike when ever the drone connected the fuel tank to the methalox tank port. I solved that by aiming the tank at the port and then undock from it while coasting. making sure the drone was not docked to the troubled shielded port when the tank docked to the station. It was a bit harrowing as the fuel tanks are "dumb" so orientation, direction and speed was set once disconnected. Any way I got the 4 tanks installed. I don't know if I will be using the shielded part on vehicles anytime soon. The Issues does not seem to have been resolved in v.0.1.4 as per the blog. How ever Anth12 has asked me to check if the issue is still there. So I'll test it when I install the now missing 4 tanks to K.G.01 - and I will do some bug hunting trying to put the Escape Gliders and M.L.K.O.s on K.G.01 All bug reports has ofcourse been updated with my findings.. See detailed walkthrough of the process in spoiler section: B. Heavy Tug Drone pushing K.G.02 into a ~0° inclination to ease future rendezvous from K.G.01 This step turned out to be somewhat more difficult than first anticipated. With K.G.01 I could just set The Mun as target and it would show me where the Ascending and Descending nodes were. How ever I could not get K.G.02 to show me the ascending/descending node when targeting Kerbin. My solution was to fly the prototype of the new heavy tug drone to The Mun - together with the prototype for the Escape Vehicle to The Mun and be very careful not to stray away from the 0° inclination. This would allow me to test both See section C. while not perfect - it proved close enough. Subsequent launches with the fully developed escape vehicles show that its still some 0.2° off - but thats so little so I call it a success. K.G.02 being boosted into a 0° inclination. The station was easy to boost - the center structure stayed on point and having 8 empty hydrogen tanks rather than full meant that the structure did not experience a lot of stress. I was a bit worried that it would veer off course, as the super structure had "warped/bend" because of uncareful saves. I really wish we did not have to be so careful with saving while a craft/structure is under tension/compression!! Later i managed to somewhat straighten out the structure by making strategic quicksaves while the station was orientating towards the sun again and thus flexing... But it is a thing that creates considerable stress to me.. That I need to worry about that when ever I save. Also K.G.02 has some serious resonance issues. I dont know what happens.. but the station will start to resonate and vibrate so violently that it falls a part. So far the only way to fix this is to constantly swap between cargo and station as soon as its loaded onto the grid and use time warp to stop it vibrate out of control. C. Escape Vehicle on approach to the Mun being tested. Escape Vehicle for K.G.02: When developing the escape vehicle I initially tried to make it with 4 engines at the top - like all the cool kids. First try proved that the engines were very inefficient in that position - The craft had 1700 Δv in total, but would spend all of the Δv breaking, and landing because the engines would lose a lot of effect from thrusting into the structure of the vehicle. I think it's very cool the game punish you for not thinking about that... but it would nice if the Δv count and T/W ratio would reflect this. 2nd version I angled the engines out - It would still spend most of the Δv getting down to the surface of The Mun - now because of the inefficient thrust vectors. In the end I decided to scrap the idea of placing the thrusters on top. and put them on the bottom as shown in the image. The craft has enough Δv to break itself to a suborbital path with The Mun from 1790 km above the surface and land. It has enough Δv to get itself back into orbit. But not back to 1790 km orbit. That being said - if a rescue mission has to recover the escape vehicle - I suspect it will be a lot easier to do so in orbit. So there is that. Escape Vehicle Prototype 3 on touch down on The Mun and fully deployed. The escape vehicle has 2 big solar panels to keep it running while on the surface - waiting for rescue. It can hold 3 crew members. I have made it so that the landing legs will be stiff upon landing. but as soon as the craft has landed it can hydraulic lower itself to rest on the ground. Allowing Kerbals to go for a walk without needing latter's. The craft has a big antenna pointing up for transmitting and receiving big data packages - and a smaller VHF antenna for faster communication with LOS to possible rescue missions. Last but not least - it has 4 big spotlights for illuminating the landing zone and is painted red to be easily visible from space. I may have made one error though - the battery power could be an issue if you are forced to land on the dark side of the mun. - I dont think the battery capacity will last you 6 days So I guess you can also spend some of the Δv getting to the north or south pole... otherwise there is room for a future scandal when kerbins suffocated because the escape craft ran out of juice before the rescue... to dark? New Heavy Tug Drone (H.T.D.): New H.T.D. front and back together with M.K.L.O and Medium Tug Drone. I tried to make a full version of K.G.01 inside the VAB with the converter that allowed for 16 methalox tanks being installed. It looked pretty cool but lagged insanely much. The bigger fuel tanks did not look good. But it got me thinking that I could make a new H.T.D. with the new vacuum optimized methalox engines and see if I could lower the fuel amount to something sensible. The new drone carries 18t Methalox - meaning that it will require 2 fuel tanks to refuel instead of 4. With 8 fuel tanks it means it should be able to move the 4 hydrogen tanks without having to refuel K.G.01 in the meantime. Thus synergy has been restored. I liked the 4 engine look of the labradoodle engine and decided to go for 4 LV-1000 "Cornet"s - it turned out that the mass reduction from using 4 engines also meant I had more Δv - if the game can be trusted. I did a bunch of rocket equations to get the most Δv as possible - but I can't remember what engine config gave the best result (LV-1000 vs LV-3000) I tried to make the "4 finger" methalox mount to make sense on the H.T.D. But it was just impossible to get the right amount of Δv squished into the design if it had to move 36t fuel rather than the 20t fuel with the hydrogen tanks, and making a "3 finger" 27t fuel tank configuration was impossible to make "pretty". So I have decided to reduce it to a "2 finger" setup - meaning 18t fuel, which is only 2t shy of the 20t hydrogen tank. Looking like this: H.T.D. with "2 finger" fuel mount and next to a standard 20t hydrogen tank The most important is that the craft is compatible with the M.L.K.O.s and the fuel tanks, and it has synergy with K.G.01 and 02. D. H.T.D.v2 enroute to K.G.02 with an Escape Vehicle. The last step for K.G.02 was to install the newly developed Escape Vehicles and crew it. The journey went without incidents. K.G.02 fully operational and crewed. Here with the 4 escape vehicles installed. I installed the 4 escape vehicles on the lower docking ring as I imagine them only being used in emergency - So you dont want to walk passed them all the time on the "comercial flights" - the upper docking ring will be for M.K.L.O.s and future crew crafts. Since the M.K.L.O.s are only capable of surviving re-entry on Kerbin, and not a landing on The Mun. I decided to install 4 Escape Vehicles - as the M.K.L.O. can't double as a escape craft for interplanetary ship crews, as it can on K.G.01 Moving Forward: I suspect my next post to be the last post on this epic journey. K.G.01 needs to have the 4 new methalox tanks launched to it, to replace the 4 tanks I just installed on K.G.02. Then all tanks that need to be in circulation are in orbit. I will also be installing the Escape Gliders and M.K.L.O.s on K.G.01 to see if the inline/shielded clamp-o-tron bugs persist after v.0.1.4 Stay tuned for more! K.G.02 fully assembled with The Mun as a backdrop

Yeah - but one is very hardcore and the other very arcady - I cant wait to play it though!

Update: I have a strong theory that putting a decoupler on a docking port will break it. I have done this some times in the past to be able to strut the cargo to the faring. As the decoupler always breaks the struts. But this time the docking ports did not work - Also the decouplers were doing funky stuff were they again was docked and not docked. - It would be stuck to the docking port, but when i time warped it driftet off. It was still registered as part of the craft though... I dont know if this is a known issue or if i should make yet another bug report?

just a small joke: So I was buying Starfield after seeing the first spoiler free reviews of the game, and my steam said this: I feel its like comparing games like Escape from Tarkov/Squad/Arma3 to Fortnight It made me giggle to myself at least.

I have had a similar issue, but that was because the NAV ball remained with the previous stage.. but controlled the second stage.. its hard to explain. I resolved it with a quicksave quick load. In my case they always started with working, and then later didnt work. I have a theory for the issue though. It seems to me that when you load a save there is a chance that the inline docking ports "forget" they are docked. At that point you can retract and extend the docking port, and it wont show the option for undocking. If something else undock - or dock with force to the same vehicle/station - The force will "eject" the vehicles connected to the ports that have "forgotten" they are docked - These crafts will still remain part of the vehicle/station. So if you use SAS to move they will move too.. even when they are still drifting away. If you delete these drifting pieces the port will remain broken... because it is docked.. but not docked. - The fix i found is that if you make an action group with undock option and you press it - nothing will obviously happen as nothing is docked to the port. But now you can dock to it. - Its just a theory though... It seems the problem has a higher chance of happening if its inline port to inline port... and less of a chance if its inline to not inline. How ever.. I have not tested it since v0.1.4. - but ill test it some time in the weekend. I'll try bait the weird - parts lose cohesion bug and move individually - bug also. It is weird that I seem to run into these particular bugs more often than others x)