.jpg.e35026a1519c55bd0cc499bda7e1ffc8.jpg)
maddog59
-
Posts
319 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by maddog59
-
-
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!
-
44 minutes ago, splashboom said:
When accessing crafts from alarms it happened to me that I ended up in the wrong one - they were also named identically, but should not matter. For the craft buttons I mean all the toggles in the control module of the craft ..
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!
-
13 hours ago, Geonovast said:
You can try the link mentioned in this thread.... but last time I tried it, it did not work for me.
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.
-
2 hours ago, Scarecrow71 said:
This is part of stock functionality, and it should be there. Can you provide an image that shows you have a maneuver node planned?
It's showing now ... maybe it just required a restart of the game.
-
I'm not seeing the 'Time to burn' indicator at the lower right of the NavBall. I'm in a 100% stock (no mods) game and I have Advanced Tweakables active. I've combed the Main Menu Settings for another switch and can't seem to find it. Is the 'Time to Burn' indicator part of a mod?
-
I've rebuilt my KSP folder from scratch, added in all of the mods I wanted, but when I try to run KSP with Tweakscale installed I get a fatal error message along the lines of 'Tweakscale couldn't find the needed DLLs', and that "Type initializer for KSPe.IO.Heirarch'1' threw an exception". I've listed my mods and versions below (per KSP-AVC); note that I have TweakableEverything installed, but although KSP runs correctly, the scaling widget doesn't appear on any of my parts. I tried unloading TweakableEverything and just using Tweakscale, but still got the same error.
Is there anyone who can explain what the problem is?
KSP: 1.12.2 (Win64) - Unity: 2019.4.18f1 - OS: Windows 10 (10.0.0) 64bit
ClickThroughBlocker - 0.1.10.17
Filter Extensions - 3.2.6.1
ToolbarControl - 0.1.9.6
KSP-Recall - 0.2.0.6
Astrogator - 0.10.2
B9 Part Switch - 2.17
Community Category Kit - 5.2
Community Resource Pack - 1.4.2
CommunityTechTree - 3.4.4
DeployableEngines - 1.3.1
FShangarExtender - 3.6.0.1
HideEmptyTechTreeNodes - 1.3
Interstellar Fuel Switch - 3.29.4
JanitorsCloset - 0.3.7.8
RasterPropMonitor - 0.31.5
KAS - 1.10.7963.36977
Kerbal Engineer Redux - 1.1.9
Kerbal Reusability Expansion - 2.9.2
Kerbal Inventory System - 1.28.7685.40880
KSP-AVC Plugin - 1.4.1.7
Module Manager Watch Dog - 0.0.2
NearFutureLaunchVehicles - 2.2
NearFutureProps - 0.7.1
NearFutureSpacecraft - 1.4.3
S.A.V.E - 1.11.0.1
Photon Sailor - 1.7.3
ButtonManager - 1.0.1.1
SpaceTuxLibrary - 0.0.8.2
VesselModuleSave - 1.0.1.2
StationPartsExpansionRedux - 2.0.5
Surface Mounted Lights - 1.19.7854.4854
ToadicusToolsContinued - 0.22.4.4
TrackingLights - 0.0.2
Tracking Station Evolved - 1.0.6
Kerbal Alarm Clock - 3.13
TweakableEverything - 0.2.0.2
VOID - 1.1.11
KSP Interstellar Extended - 1.29.2
Waterfall - 0.6.7
ZeroMiniAVC - 1.1.2.4 -
@AkatsukiMana Thanks, but unfortunately those suggestions haven't worked for me. I've created a new KSP directory and am in the process of re-adding all of my mods, a few a time. Maybe I can figure out how to get around the problem... Much obliged!
-
I've been running 1.12 using CKAN - used it to install as many mods as possible including Tweakscale. Today, when I try to launch KSP I get an error that Interstellar Redist.dll must be in the GameData folder, but when I move it there, I get an error that Tweakscale can't find the required .dlls. Both errors are showing up as show-stopper errors (the dreaded "Houston, we have a problem" message on the splash screen).
I've uninstalled and re-installed using both CKAN and manually, following the directions in the install file. I've downloaded Tweakscale from both CurseForge and Spacedock.
In the interest of full disclosure, when I first opened CKAN today, it prompted me to update one of the installed mods, which I did before launching KSP and starting to get these errors. I'm fairly certain it was ZeroMiniAVC, and I tried uninstalling it but there was no change. Yeah, I know: sucks to be me.
Any possible suggestions will be welcome.
-
On 10/14/2021 at 5:08 PM, king of nowhere said:
three minutes is still not all that large. but if done in kerbin orbit, you still get some inefficiency for cosine losses. 16 extra seconds out of a 3 minutes burn? 8% more deltaV required, could be a reasonable result
Well, I usually plan my missions with a ~10% margin, and in that particular instance it was a major annoyance: it had taken me about an hour of fiddling with the various widgets to set up a single node that would get me to within 5 km of the target, and after all of that effort I ended up with a separation of more than 11,000 km. Plus, using more fuel for the course correction really made for a skin-of-the-teeth completion.
-
1 hour ago, AHHans said:
While what @steuben writes is correct as such, the actual differences that you see are not due to rounding errors but due to the difference between an instantaneous maneuver and a long burn.
The prediction from the maneuver node is done with the assumption that the whole maneuver is applied to the trajectory as a single, instantaneous "kick". But in reality the burn takes some nonzero time, which results in a different orbit than the prediction. If the burn is short (a small fraction of the orbit) then the difference is also short, so that you may not notice it. But on long burns the difference becomes large: you not only wind up on a different trajectory than predicted but you also need more dV.
To deal with this you can split your burn into multiple burns: to save dV you can split your burn over multiple orbits. Do one or more short burns at the PE until you are on an elliptical orbit close to the edge of the SOI (but still inside) and then do the final escape in one (probably longer) burn. Ta actually arrive at the target do what they also do in RL: make one or more correction burns somewhere during the transfer.
Doing course corrections is how I've been doing it ... I hadn't thought of first establishing such a high orbit, then committing to a maneuver that would be so much smaller a fraction of the orbital period. Thanks, I'll have to give that a try.
-
9 minutes ago, steuben said:
Special relativity doesn't really kick in till you are around 1/2c and even then the clocks run at about 85% of normal to the outside viewer. To the inside view they still run at 100% of normal.
Thanks; I was actually being facetious - I like to try to inject some humor or whatever in my titles to generate interest/curiosity. I'm somewhat familiar with Einstein's work, but that's a story for another space/time.
From a gameplay perspective, if what you say is correct than it seems like that amount of error makes it much more difficult to make those planetary transfers than I'd anticipate. I don't have much experience w/ nuke engines, but since they have such low TWR and require exceptionally long burns, I'm not sure how to account for this - shorter burns that result in multiple orbits until one gets to a point where a short burn will finally let the ship escape Kerbin's (or another planet's) SOI and be on it's way?
-
I've noticed something odd and am not sure if it's something I'm doing or if anyone else has seen this: it seems as though during particularly long burns, whether w/ chemical or nuclear engines, that the burn time indicator seems to slow down significantly. For example, last night I set up an asteroid intercept that should've gotten me to within about 5km of my target. It used a single Mainsail engine, and ran for nearly 4 minutes. Once I started the burn, I set a timer for 3 minutes at the 3 min/4 sec mark . When my timer went off there was still more than 20 seconds of burn time to go, rather than the expected 4 seconds. When the burn completed, I was more than 11,000 km off from my target.
I tried it a few more times, using both MJ2 maneuver utility and manually, with the same result. I was able to see that the seconds on the burn time indicator at some point began ticking down much slower than the other timers.
I saw this in earlier attempts to make planetary xfers using nuclear engines and thought it was my imagination, or something I'd set incorrectly, but now I'm not so sure.
Thoughts from the hive mind?
-
On 10/12/2021 at 5:33 AM, Alien21 said:
I see a lot of nice space stations here.....hello guys just a question, I will upload later my station photo's. Is complicated try to build a space station around another planet? I have already achieved the target to build a station around Mun and Kerbin, but if I would instead build something around Duna or something else? All suggestions will be appreciated!
It's pretty much the same concept as putting one up around the Kerbin/Mun/Minmus system, with the added complication of making successful planetary xfers. It depends on how ambitious you are with your station design. I've tried two strategies with mixed success:
1) Build the station in Kerbin orbit while waiting for the Duna xfer window to open - you have to be sure to include a point for a big ol' Xfer stage to push the whole beast to Duna and get it into orbit. You can either incorporate the Xfer stage into the design of the station, or detach and deorbit/delete it after you're done with it.
2) Send the station to Duna in pieces, get the stations' 'core' into the desired orbit and the other pieces at higher orbits, then one at a time perform a rendezvous maneuver and build the station piece-by-piece. I like to use a 'construction bot' vehicle that is way overpowered with fuel and monoprop to move the pieces into place after each rendezvous.
Have fun!
K9CS Beagle
in KSP1 The Spacecraft Exchange
Posted · Edited by maddog59
spelling corrections
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):