maddog59

K9CS Beagle – first of her class, largest ship I’ve ever built in KSP; Mission: Exploration of the planets and moons as far as Eeloo Nickname: The Busch Wagon - because it takes so many Clydesdale SRB's to get it moving! Crew: 14; Capacity: 36, plus auxiliary vehicles Mass (Fueled): 2,323.64t (not including Clydesdale boosters); deltaV (Vacuum): 5,168 m/s; Part Count: 189 (100% stock) Stowable MPL & Science Lab, including experiment packages and communications tower, plus two on-board ISRU units for on-orbit/in-transit self-refueling (3000 Unit Ore capacity total) Dorsal View, left to right - Calvin (deployable Resource Probe); Butch (VTOL Shuttle); Bialystok (Ore Mining Craft); Hobbs (deployable Resource Probe): Ventral View, left to right - Hobbs (deployable Resource Probe); Sundance (VTOL Shuttle); Bloom (Ore Mining Craft); Calvin (deployable Resource Probe); In the center bay, top down - Vladimir ( Captain's Gig); Estragon (Utility Vehicle): Up close and personal with Vladimir (left) and Estragon (right):

In addition to all of the tips above for positioning the decouplers and using struts (auto and otherwise), I always set the first boosters to be dropped along the North/Side alignment, especially with heavy vehicles with low TWR. Since the whole mess is often moving relatively slowly by the time the boosters run out of gas, I've found that if they're aligned East/West they can fall into the vehicle. Of course I'm not above using Sepratrons to counter this as well, but why use more parts when you can let gravity do the work for you?

I'm feeling lazy today so I present for your entertainment: Stations in search of a name: let the suggestions begin! In Kerbin Orbit at 300km: In Duna orbit, with enough dV to get back home, as well as host to a cute little lander that's been to Ike and the surface: And finally (yes, I know it's not a station, but a base, but I wanted to share it anyhow):

Thank you both so much for taking a look at this and your suggestions. I'll have to give them a try in a separate game session. In the meantime, I eyeballed things and took it slow and was able to get the beast into orbit and down on the ground within 2km of my Duna base, so I'm taking the win. It was way over-fueled, so I knew I had plenty of dV to play with. @Scarecrow71 I don't think this had anything to do with an MJ setting. None of my other ships in the same game had this problem. And I've heard of the 'infinite propellant' cheat, but don't know where it is. Is it possible it would be on for a single ship? Or does it apply game-wide? Regardless, I don't think it was on, as I definitely saw the fuel resources dropping as I did each burn. Unless that happens with the IP cheat active? Thanks again!

A few more data points (or observations) of the problem: I put a copy of the vehicle ("Duna Lab") into Kerbin orbit and sent it on to Duna, and everything looked normal. I was able to perform a couple of course corrections on it and the other vehicles. I used the KSP alarm function to create several alarms for the various vehicles at each point, but only used the "Warp to Next Maneuver" in the Staging widget (sorry, I don't know the name of each of the widgets). I didn't use the KSP alarm function for anything other than to keep track of which vehicle to work with next. I switched between vehicles using the Map view. Then the problem recurred with Duna Lab - the next maneuver node is in more than 157 days, for 985 m/s dV, but the NavBall is showing "10000.0 m/s" and "Node in T+1 hr 95m 20s". Even though the mission clock is continuing to tick, the Node clock and the Start Burn clocks aren't counting down. All stages show "0 m/s", even though there's plenty of fuel and full probe control.

@Scarecrow71 I've uploaded to Dropbox a zip file with the .log files, along with the .craft file for the beast in question, and images of the problem and the vehicle itself, and my system info (DxDiag.txt). I'm using Windows 10, btw. In addition to the persistent.sfs, I included three quick save game files, in case seeing the progression is helpful. They're dated and in sequence (20220112.01, .02, .03). Please let me know if I need to provide any additional info, or if I need to submit this somewhere else. Thanks for your help!

Sorry, still not sure I'm following ... but I did check to be sure the control point was correct, and nothing else looked out of the ordinary. It launched normally, using MJ2 for ascent guidance (nothing unusual there), and I made some orbital adjustments manually and everything looked right as rain and worked as it should. I'd switched back and forth between it and other vehicles several times in the course of the campaign. I have a feeling something weird happened when using the alarm function. I may have to just load the Kerbal Alarm Clock mod and use that in the future. I'll probably just try to launch a new version of this problem child and see if the same thing happens, without using the alarm function. I'll save off a copy of the game file first though, in case it's of use for trouble-shooting later.

@HebaruSan That thread you pointed me to says I need to upload the player.log file, but I can't find one anywhere in my KSP folder or sub-folders. I have three .log files dated for the time I exited the game, immediately after this problem started: ksp.log, kerbalengineer.log, and modulemanager.log, but no player.log. Is the reference to 'player' an old one? Also, what would I search for in the log file to see if there are any exceptions? @splashboom I'm afraid I'm not sure what you mean by check all of the craft's buttons. Can you clarify? There's plenty of resources available and there's nothing really unusual about the craft. In fact, it's pretty simple, relatively few parts with just one offset. I was able to get it into orbit without any issues or weirdness. One item that MAY have a bearing on the problem ... this was the last of four vehicles that were in orbit, waiting to go to Duna. I used the new KSP alarm function to set alarms for the four departure burns for each of them, then used the 'switch' button in the alarm function to move from one vehicle to the other. The third vehicle was still burning when the alarm for the fourth (the problem vehicle) was triggered, and I deleted that alarm, finished the burn for the third vehicle, then switched to the fourth. That's when the problem appeared.

I'm trying to get a ship out of Kerbin orbit, but the moment I start to create a maneuver node, the widget appears on the orbit as usual, 1) the dV indicator shows "10000 m/s", even with no inputs made, 2) the maneuver point on the nav ball appears under the center point and stays there as the orientation of the ship shifts, and 3) as I add input to the widget, the indicator continues to show "10000 m/s" even though the the conics behave normally in map view, showing a changing orbit. I've restarted the game (v1.12) a couple of times without any change to this behavior on this one ship. I've never seen anything like this so I'm stumped. I have other ships in the game that all behave normally. This game is almost entirely stock - the only mods are things like MJ2 and Astrogator. Any suggestions on how I can resolve this will be appreciated.

So I gave the Extractor a try, and although it appeared to work correctly and gave me a Zip archive with .craft files for all of the vehicles in the persistent.sfs game, when I tried to load the one of interest I got the 'invalid or locked parts' warning in the menu, and the Confirmation window that was supposed to describe the problems with it, but there were no problems listed, and hitting "OK" shifted the screen as though a vehicle had been loaded. Nothing was in the SPH and the 'Confirmation' window wouldn't go away. I've sent a message to the thru the 'contact' section of the Kerbaltek page, and hopefully they'll be able to alleviate my pain. Further bulletins as events warrant!

Thanks ... you're talking about the Extractor in 'craftkitchen'? I'll give it a try and post back whether or not it was successful. It looks like it was updated last July, so hopefully it does the trick.

I loaded a vehicle into the SPH that I'd built earlier, and was messing around with the configuration when I accidently hit 'Save' instead of 'Launch'. Fortunately I have a version of it landed on the Mun. Is there some way for me to extract that vehicle data and restore it to the SPH/VAB folders?

@magnemoe Yes, those problems are what made it an interesting exercise. I was able to de-orbit this beast from 15Km to the Mun and it's performed fairly nicely once landed. Once landed I'm able to use the spiders (which are on servos) to lift off and land, then switching to the rear facing engine (not visible in the picture) I can get it across canyons and craters. The rear facing engine was also used for de-orbiting, but once I got within a couple hundred meters of the ground I switched to the spiders, leveled out, and landed it horizontally. I use action groups to switch between sets of engines, and between pitch control and the servos I can get fairly good forward and backward motion for shorter hops. Once landed I empty the upper tanks into the lower ones manually, but that's because I forgot about setting fuel priorities. Thanks for the reminder, I'll have to give that try. The front facing engines are used for additional braking assist if I end up going to fast either on the surface or in flight.

So of course, after stepping away from the problem for a while I seem to have figured it out. It had something to do with one or more of the parts being rotated. But to answer @Scarecrow71: I'm testing it on the Mun; no other engines are active; control point is forward; thrust on all engines is identical (100%). I re-built the beast from scratch and avoided rotations as much as possible.

I have a rover with several spiders on rotation servos arranged along the sides. The servos are tied to custom axis controls so I can point them forward and back. The entire ship was built using symmetry and every time I check the CoM and CoT everything seems lined up. But when I try to take off it behaves as though there's another engine on the right side, and the thing rolls to the left. I've added 2 large reaction wheels, and with even with SAS I can't keep it from rolling. I've rebuilt it a couple of times, being careful to make sure there isn't a 'hidden' or invisible engine somewhere, and I've checked the CoT from all angles to make sure it's pointing straight down from the center, and is VERY close to the CoM. I'm completely stumped. I've used this configuration on other rovers without any trouble. Any suggestions on what I can check? I can share the ship file if someone wants to take a look at it and see if they can figure out what I've got wrong.