CFTeague2

looks good. also tried this with relatively low tech. my Lil Chonker was a 2100+ ton mass of 2.5m tanks and lots and lots of kickback boosters. Landed on Minmus with final weight of 217t https://steamcommunity.com/sharedfiles/filedetails/?id=3205900428 and https://steamcommunity.com/sharedfiles/filedetails/?id=3205900377 -CFTeague2 - ps started over twice, v1 and v2 were too wobbly and unstable to even launch properly. even v3 had a lot of struts and launched mostly on the power of snacks and miracles....

Yes, sorry, the actual fission reactor one, its like 1t or 1.5t. Like a fuel cell, it has an "activate" / "deactivate" toggle to manually turn it off. I assume that would mean putting in some kind of control rods to damp the reaction, for that to be IRL plausible. So then I guess, if you can manually control the reaction, why not have a way to automatically control the reaction, when power is not needed? but I dont know if they actually DO that like KSP1 fuel cells did

Made a plane with a lot of fuel, using what KSP1 would have called "Wheezlie" engines. Flew on x4 timewarp for about 30 minutes of real time. kind of dull. Landing (with help of some parachutes) ~5km away, and used the jet engines to slowly roll (~5 m/s) until I got close enough for it to count. Along the way, flipped the jet a few times, on the slope-ey terrain, and went too fast at least once, so there were a few reloads Also, didnt remember to put a ladder on the plane, so Bob could not get back in, once i had him outside to plant a flag. had to recover him seperately frmo the plane itself

I havent tried the fuel cells out yet. Guess I should. For comparison -- how does the reactor generator work, in terms of fuel consumption on-demand or always-burning?

Yeah, so while I do like the direction of having some science that takes time to gather, Im not sure if what we have now is the best answer. maybe if it can somehow keep track of progression, simultaneously for each biome as it orbits. so you might put your probe in a polar orbit, let it run for a few orbits and see something like this: (using Tylo biomes for example) - orbital survey / low orbit: ----- highlands -- 100% complete ----- lowlands -- 57% complete (3:23 of 6:00) ---- craters -- 2% complete (0:05 of 6:00) ---- dimple -- 0% complete (0:00 of 6:00) But I dont know if that would be thought of as "too automatic" / "too easy" and maybe defeat the entire idea of making it take time to gather? I dunno. just some thoughts.

Hi all. Im playing a modded EXPLORATION mode, and Im at laythe now with my SSTO to investigate a misssion target down here. But the ground here, in both the "shores" and the special biome area, are giving me a lot of trouble. The plane's tires "sink in" about the height of the tire, sometimes. When this happens, there is a tremendous drag on the craft, resisting motion. Its like its in a tar pit. -- To estimate how strong the drag is, I was able to run the whiplash engines from a stop for several seconds, and get up to about 6 or 9 m/s (then I'd turn off the engines for fear of parts breaking). But in a "normal" situation, I would have expected to be going 50 m/s, or more. easily. An EVA'd kerbal can also "sink in" and when this happens, they seem to become uncontrollable, doing a "floating" or "swimming" animation. I have been able, sometimes, to recover, by using the RCS jetpack. Other times Ive been forced to go back to my most recent save. Since it's a "shores" biome. possibly, there's some interaction with the ground surface, and the water level, which probably is only just below ground level, here. Steam screenshot -- you can see one of the tires is sunken below ground. This is the visible result when it happens. (warning, very minor spoiler with the special biome name displayed in the screenshot, on a mod's popup window) Thanks! -CFTeague2

Ive had wierd issues with WHEELS (not legs) auto suspension in some places will spontaneously pop your tires. (It kind of looks like the auto-spring strength and auto-dampener strength might get into some kind of self reinforcing oscellation and eventually the tire is pressed so hard vs the ground it just breaks. but thats somewhat of a guess from the very quick visuals before it happens) On LAYTHE specifically, I've had issues with the "shores" terrain, particularly near the <spoiler> area which the mission sends you too. It seems like, there are 2 surfaces -- the visual surface, and then like 1 foot (not even a full meter) below that is a 2nd surface. If/when the tires of my SSTO were on the ground for very long, they would sink from the top surface, to the subsurface, and then the game would act like the craft was stuck in a tar-pit. Running my whiplash engines could get me moving, somewhat. But in the time it took me to get to 9m/s, I would normally have expected to be going something like 50-70 m/s The tires were also very sensitive to breaking, when transitioning from the "top" surface, to the "sub" surface. And the "drag" would spin the craft around, if only 1 of the tires sunk in, before the others. I think this is also how sometimes it broke my tires, by suddenly pulling on it too hard.

Hi All. In case it matters, I was NOT timewarping (speed 1:1). Also, I do have some mods, perhaps, the stock game auto-resumes, and one of my mods is somehow stopping that --- if so, then perhaps a lot of my above post needs a "nevermind" ?? --------------------------------------------------------- ALSO, a seperate NOTE: I did later notice a trick or exploit or something odd. I started Orbital Survey experiement, TYLO LOW ORBIT, over LOWLANDS. it counted down, some seconds, to like 5:57. and then I was over highlands -- apparently a quite large area of highlands. (side note: at this point I already HAD gathered highlands science, and transmitted it). I was able to click the [Resume] button, even though the biome below, was different (started over LOWLANDS, resumed over HIGHLANDS) And the timer, did not reset, it continued from where I left off. It may be something of a trick or exploit. As it turns out, LOWLANDS were somewhat rare. I was able to gather like 5 minutes of the data under HIGHLANDS. Then it autopaused. and I was able to wait until a patch of lowlands (using mod for biome maps from Orbital Survey mod, i could see it was lowlands for a while), and gather the last bit under lowlands. It counted as science for LOWLANDS. I do not know if thats because it ENDED as LOWLANDS. Or because the original start was LOWLANDS. ------------------------------------------------------------- FINALLY, one more opinion --- Not sure if the Orbital Survey experiment is easier to gather at high warps, or some tricks like the above issue. But, it does seem like gathering some types of data "Craters" biome, "Canyons" biome, etc. While a vessel is in ORBIT and cannot stop, for an experiment that needs to gather 6 minutes of data -- this is going to lead to a lot of auto-pausing. It feels like it makes the Orbital Survey experiment kind of frustrating to gather significant amounts of science with. In the current EXPLORATION MODE, this is perhaps moot -- because there are enough side missions and other science experiments -- you can pretty much max out the tech tree as it stands now (page 1-4), without needing EVERY biome researched with the Orbital Survey experiment. BUT, I do wonder -- if the tech tree gets expanded when the colony content is added, or when the 2nd star system content is added, or really for any reason. IF there is a design expectation that the players MUST gather 2/3 of the science from the Orbital Survey experiment across several planets or moons, in order to get the tech tree unlocked --- Well, then I really wonder if the minor frustrations in the experiment will be magnified. Right now, Im using it for the "cherry on top" science points. But if it becomes really required on a lot of planets, I think its current version may become a hassle and stop being fun. Thats pretty speculative -- its not even a problem yet, but just throwing the thought out there. Thanks!! -CFTeague2

Hello, I would like to suggest a minor refinement. The Orbital Survey experiment (part: OSCM-01 "mini lab", or the manned version), takes 6 minutes to scan. Its also biome-specific when in low orbit. Over some bodies, at low orbit velocities, you can cross over a biome somewhat often. When this happens, the experiment will auto-pause. This is fine. (tho in a best-of-all-possible worlds, "it might be nice if", it remembered that it was gathering for "highlands" and auto-resumed if it returns to a "highlands" biome) This experiment also has an associated animation which is several seconds long. (extending antenna booms, I think). Every single time the experiment auto-pauses, the antenna booms retract. And then when I click [Resume] in the part manager window (lets assume the biome beneath changed for just a split second and then changed back to the one I was getting science), the animation happens again. What this means, is that there is several seconds delay, every single time, the experiment autopauses. ** Could there be any way to unlink the auto-pause, from the animation and its delay? Maybe keep the animation tied to the original START of the experiement -- but just dont fire the "close" animation on auto-pause, and then re-fire the "open" animation on resume?? Having to click [Resume] every time the biome flickers is ok I guess. But when it takes several seconds delay for it to happen, I see frustrating cases, where the timer will be like 5:43, pause. I'll click the button to continue. few seconds pass, and the timer is not counting down yet, because its doing the antenna boom animation. Then the clock starts ticking on the experiment again. and then, sometimes it will rapidly change biome again. Because of the delay, 8 seconds of being over my biome, only results in like 1-2 seconds of getting the data. of course, if the biome below is very regular, this is not an issue. And this isnt broken, just a QoL issue. specific example: Low orbit polar orbit over TYLO. The south pole area seems to have a mix of Highland, Lowland and rarely Crater biomes below. Im trying to capture HIGHLAND. if I can micromanage the [Resume] button, I will eventually gather all 6 minutes of data needed for the experiment. Just some thoughts, THANKS! -CFTeague2

@DibzNr Thanks. It does look like its probably the same issue. @Flush Foot I see zeros if its the first craft i have focus on, after loading save, is in kerbol orbit. if I have focus on a craft in, say, Mun orbit. Then goto map view, and click the other vessel (in Kerbol orbit), and select -> Control, then what I see is "odd" values, which look like they are leftover from the Mun orbit craft. so I see numbers like 35km PE, when my probe is probbaly 10s of millions of KM above Kerbol

Hi, I would also like to suggest a change, any kind of change, which allows me to stop kerbals loading into rockets ------------------------ First, my thoughts on WHY:: Autoloading of kerbals into rockets seems like a good idea at first. But really, its a bad idea. Think about this -- if I have a rocket that NEEDS a kerbal, and I forget, it takes about 2 seconds of reverting to the VAB to assign a kerbal. If I INTENTIONALLY make an empty rocket -- which I do a lot of, for crew-return vessels -- and a kerbal jumps into that rocket, I launch it without noticing, and then 2 weeks later when the Duna return craft gets back, I rendevouz with my re-entry capsule, only to realize its already GOT 3 kerbals in it. if a craft is missing a required kerbal, you would notice it instantly. But if you WANT an empty craft, and then a kerbal autoloads, theres no warning about the auto load. Yes, the cute face is up in the corner (probably, if the vessel has enough seats, maybe the seat he loaded into is off screen). But if you dont notice, because the ship is planned to be empty already -- well, then you can get pretty far before realizing your ship is full and you have crew, where you really dont need them. ------------------- Now, people are going to say, "in the VAB, you can control if there are kerbals on the rocket". Yes, But No. See, I have a rocket, with an EMPTY capsule, saved. It's my "quick reentry v2" ship. I used the VAB thing to empty the capsule, and its saved as a workspace, with no kerbals. But, what happens, when I want one? I goto VAB, clear my workspace, load in my "quick reentry v2" ship, and click [Launch]. Then at the launchpad, I click [Go] and the countdown starts. --- BUT THEN, I realize there's a stowaway. Somehow, every time the VAB loads the vessel -- which I intentionally SAVED without NO KERBALS ABOARD -- some kerbal feels the need to jump into the capsule. EDIT: -- 2nd scenario --- Have an empty rocket. Goto launch pad. see something (staging maybe) that you want to fix. Revert to VAB. fix the staging. Again, a kerbal will auto-load into the previously empty capsule. Click the [Launch] button. Then at the launch pad, look quick at your staging, since thats "all you changed", and press [Go] -- without realizing you have a kerbal aboard. * So, I dunno, maybe the VAB can NOT auto load kerbals into a craft when you load a saved workspace? * Or maybe some way for the same tool I use to empty the capsule, could let me mark the space as "locked" so noone can auto-load into it? Or any other idea about controlling kerbals into craft -- im not picky about how it happens, but I am getting tired of having rockets in orbit with unintended kerbals. Thanks!! -CFTeague2

Id like to support changes to this. Gilly is the worst. I break orbit from 20km up, I can timewarp fast at first, but soon I still have something like 12km to fall, and I cannot go faster than 4x warp. I made dinner, then ate dinner, basically, before it landed (tho, to be fair, it was just reheating leftovers) I do understand, we dont want someone to timewarp straight thru a planet. but theres got to be some middle ground where low speeds are allowed to warp a little faster... Thanks! -CFTeague2 ps. the original 20km or higher orbit was actually BECAUSE of this limit. I didnt want to not be allowed to timewarp when in orbit. if I could have timewarped faster at lower altitudes, I would have used a lower orbit, and then I wouldnt even had so far to "fall" down to gilly...

Reported Version: v0.2.1 (latest) | Mods: Alarm Clock; Community Fixes; Manuver Node Controller; Micro Engineer; Orbital Survey; Science Arkive; + stuff CKAN auto-installed when adding those. | Can replicate without mods? No OS: windows 10 pro | CPU: intel i7-9700KF CPU @ 3.6ghz | GPU: Nvidia GEFORCE RTX 2070 SUPER | RAM: 32gb Has anyone seen this issue before? I have a modded exploration save with many hours into it. (steam says over 150hours). I was correcting course on some craft on route to Jool, and then the next craft that needed attention was a "long range relay". As a habit from KSP1, I send out relays into an orbit range between dres + jool, with my best antennas. Anyways, when switching to the relay, I did my burn, and then while it was going, I noticed that the in flight readings for AP and PE both said "0m". I finished my burn, and switched away from the vessel, and then switched back, and it STILL said 0m. I saved the game, and exited out to windows. Then restarted KSP2. And the craft still display 0. After some tinkering, and testing. If i goto a craft around any other body --- Mun, Duna, then when it switches to the craft, as the craft "snaps in", the AP and PE readout under the navball, updates. BUT, if I then goto any craft in Kerbol (sun) orbit, as the craft "snaps in", nothing happens to the numbers. The AP and PE show the numbers from the previous craft. Like my Mun craft will be like 200km up, and the AP will still show 200km. even thought Im like 53milliom km from the sun. I have a mod, Micro Engineer, and it also has flight info display section. IT displays the proper numbers, just fine. So, I believe, interally, everything is actually OK. Somehow, it seems to be a display issue. Here's a steam screenshot with the Navball, the flight AP/PE display, and then i also have the Micro Engineer window showing its Flight Info data. https://steamcommunity.com/sharedfiles/filedetails/?id=3198535323 As far as I know, there are no down-range issues caused by this. Its strange that its not working, and it worries me. Also, because it seems to affect only vessels in Kerbol orbit, and I dont always pay careful atten to the AP and PE for my really-far-out relays (the distance, kind of doesnt matter much at that point). But, because of that, I really have no idea when this issue started happening. In my current save file, when i reload the game, even after coldbooting the computer, the sitation remains. It starts vessels in Kerbol orbit with 0m. Then if I goto a vessel orbiting something else, and go back to the vessel in Kerbol orbit, it just continues to show the old number. So, I dunno, it looks like maybe theres some kind of optimization code that maybe tries not to recalcuate the AP/PE if it doesnt "need to", but somehow its not working right? wild guess. Oh, also, I tried timewarping, (click on trajectory "timewarp to point"). It timewarped correctly, but the numbers for AP/PE did not update once the timewarp was done. I was sort of hoping that might force it to reupdate. sadly no. I can upload the savefile (note to self: "quicksave_833.json" ). BUT, the upload on the web page below, wont let me because the save file is 27,261 Kb. which is 27Mb, larger than the limit of 20Mb. so, I dont know how to send you the save file. sorry/thanks. If the save is needed, let me know and i'll try to send it somewhere else? Included Attachments: .ipsImage { width: 900px !important; }

I support changes for the TRIP PLANNER in the VAB. 1) I wonder if the tool should be accessible from more than just the VAB -- maybe you could call it up from KSC or tracker? not sure. IF so, then I think changes to the "FROM" location are especially valuable. If you already have the ship in orbit, and you want to check your remaining dv, maybe you could do as suggested in the mockup, and say "FROM Kerbin -> Low Orbit" and then select the destination? If the tool is ONLY for the VAB, then... im not sure there is as much benefit for changing the FROM location. At least not until we get colonies and you can build ships in other places. For now, the ships are always starting in the VAB on the ground, on kerbin. 2) I still see lots of benefit to changing / refining the TO: location. The difference in dv required for a "High Orbit Flyby" vs "Low Orbit Flyby" vs "High Orbit" vs "Low Orbit" vs "Landing", can be enourmous. Specifically, Im looking at JOOL, which is probably a worst case. But when we send new players to put a comm around jool, they are going to use this tool to estimate what they need. The planner for Jool is going to say "no no no", because right now, it always assumes you are landing. For example, here's what I see now for JOOL: Kerbin Low Orbit: 3400 Kerbin Exit: 900 Jool Intercept: 1250 Jool Entry: 160 Jool Low Orbit: 2780 Jool Surface: 14000 ---------------------------------- Total: 22520 So, OK, first, I will totally acknowledge, that since, the numbers are itemized, someone can work backwards and figure, to ignore 14000 of that number, if they dont want to land. Not everyone is automatically going to take the 22.5k number and build for that. But, IF it is a somewhat simple change, adding a few selections to the popup (no idea if thats all it needs?), and some quick IF logics to control which numbers to include, ---> then it might be nice to allow them to say they want to goto "high orbit" or "low orbit" or maybe "flyby" , as well as "landing" Numbers-wise:: -- "flyby" would require intercept, and maybe "entry" amounts? or maybe just "intercept" gets you a flyby. Not sure how much value there might be in "high flyby" vs "low flyby". But even if some people might like it, Im not sure how to define "low flyby" for the existing tool. (What I would use it for, is a case where I want to send a probe on a flyby, just close enough to get "low orbit" science reading. so it would be based on the Low Orbit science "line" for the planet/moon. But thats a "stretch goal" perhaps, since it needs more thinking and calculating...) -- "high orbit", literally could be just the minimum to capture at all. But I dont think thats really what people mean. They tend to want a less elliptical orbit than "barely captured". So I dont think just "intercept" and "entry" numbers by themselves are enough. If I had to make up a rule of thumb, completely as a guess, maybe we could take something like 1/4 of the "low orbit" number, and maybe that would give us an estimate of capturing, plus rounding the orbit some, but not all the way to low orbit?? That would need a little testing and refining. But this tool is about ballpark numbers, so I im hoping just using a fraction of the "low orbit" amount is good enough, to keep it really simple... So, maybe "intercept" + "entry" + 1/4th of "Low Orbit" might be a quick estimate? -- "low orbit" would add in all the numbers, except surface. -- And then "landing" would add all of the numbers... So, using my suggestions as is, for Jool:: selecting "flyby", you'd get a dv estimate of 3400+900+1250+160, for :: 5710 total selecting "high orbit", you'd get a dv estimate of 3400+900+1250+160+ (1/4 * 2780) , for :: 6405 total selecting "low orbit", you'd get a dv estimate of 3400+900+1250+160 + 2780, for :: 8490 total selecting "landing", you'd get the entire estimate of 22.5k Does that sound nice to anyone? And, hopefully, for implementation, reasonably do-able? THANKS!! -CFTeague2 PS. I'd also support some kind of "subway map style" d-v map, available, in game. The various versions of community generated d-v maps for KSP1 were very helpful. It took a short learning curve to interpret them, but once it "clicked" for you, it was a really good way to provide many layers of the info. Tho you did need to add the numbers up in your head...

Can confirm this issue. While in the VAB, i cannot go directly to the tracker, it is grayed out. I can get there by first going to R+D (or something) and THEN going to tracker. so it seemed odd.