OrbitalManeuvers

There's like 12 parts to the Galileo probe, so obviously I'd need to edit all of them equally. This still might be the simplest solution if it works. Will give this a try today. Thank you for the unassuming instructions, too Very familiar with editing cfgs so no probs with your idea. I left out a bunch of info that I didn't know you'd need. The results of asking a question when you don't even fully understand the question Sooooo .... in essence, I already know that the balance of these parts won't work or be "correct" for anything I'm doing. RN was clear on their thread that their parts aren't supported for stock, and I'm on a 2.5x system, so yeah, the balance part can be ignored. I wanted this mostly just for historical recreation and potentially video, so I don't really need the perfect math/balance, since even if TS scaled all that perfectly, it still wouldn't be usable. Tbh and to put things into perspective, I got the shuttle to try to build the ISS, and that's not gonna happen, so I thought - what else did they use this brick for? And that's how I got here ... there's basically nothing riding on this You've given me lots to go on and experiment with - thank you to all! This is an area of KSP I've never looked at, so I appreciate the input!

@Friznit mini tiny baby nit issue for next release, that you definitely probably already most assuredly know about:

Hiya. In several years of KSP I've never needed or tried TS, but apparently I've arrived at the need! Is the below image the kind of thing I'd be able to easily "fix" with TS? Scaling down the probe would also scale down its dV, is that correct? Is that optional? Also is there any specific info about these parts I should know ahead of time? This is RN_US_Probes, and I'd like to use it with SOCK. Surely I can't be the first person to try this ... Thank you for any help/advice!

Here's my log and a few screenshots from a minimal JNSQ install. Eve, Lindor, and Jool are all black in flight and map view. Is this just a case of configs needing to be updated? https://drive.google.com/drive/folders/1B0Lj1t8ukVlmknyqNuppxIMy2H5KVeRt?usp=sharing

thank you, this turns out to be a great solution. somehow I had in my head that BCA was waaaay more involved. We like tiny and silent!

Right, I had looked at that one, it's just way more involved than I wanted. meh, don't worry about it - just knowing that it's a messy module is enough to dissuade me Thanks for the reply!

Would it be possible to prevent KSP from ever assigning crew members to seats? I wouldn't want options or settings or anything, I just don't want KSP to automatically put a Kerbal into a seat, ever. edit: forgot to mention I am aware of other crew assignment mods.

I'm not sure exactly which of the change notes affects this behavior, but I came to say a specific thank you to whoever/however this changed: previously when using the StationaryCamera, right click would allow you to rotate the camera but would also weirdly integrate vertical mouse movement and you'd end up with roll in your rotate. Was that just me? It was difficult to use. Now, the camera remains level which is what I've wanted 100% of times I've used right-click to rotate the stationary camera. Thank you!

I completely spaced out on the fact that you guys had been talking about SLAM drag issues while we were also talking about PVG. My working 1B that gets to orbit with PVG was using the hinged SLAM. I swapped it out for the jettisonable version, and all hell broke loose. I've tried 4 times and I can't even get the J2 ignited because there's not enough ullage with 4 SRMs and the 1B APS units. So yeah the jettisonable version of the slam changes everything.

Good questions. Picture shows the results, here are the changes I made from the previous video/flight: added S-IVB IU, SIVB SRMs down to 2 from 4, heatshield ablator reduced to 200, target alt 130km. Oh, and looks like I'm still using the wrong APS? oops.

hmm you have a GameData folder in your GameData folder? In nitpicking land, I think BoulderCo is a conflict when you also have AVP installed, but that's obviously unrelated . So basically, you have every mod in existence installed. I think if I were in your shoes, I'd create a second test installation that had just my solar system stuff, and KK and its requirements. Then try the editor interface just to confirm it does work on your system. Obviously "adding mods back in one by one" is out of the question for an install that size, but if you can determine that it is a mod conflict, then that should narrow down the list a lot. Sorry I can't be of more help. Hopefully someone here will see something more specific.

Alright my friend, I hope something here proves helpful, somehow. First, I suck at this stuff (this is Rule 1 which I will refer to often). So if it works for me it's gotta work for others. My build looks similar, I actually have lower TWR for some reason. You'll notice due to Rule 1, I forgot the S-IVB IU. Also, notice my numbers are with the (incomplete) launch stand detached, as KER shows quite different numbers when it's attached. Here's a raw screencap video of the ascent to orbit, including the PVG setup. Launch stand unfinished obviously. This is unedited real time so it's long. tl;dr/ihatepvg: PVG nails this flight in a way that would be very difficult to replicate by hand. Watch the Ap/Pe in the last 60 seconds of the video. That said, these are some PVG Truths for me, on my system, almost exclusively based on Friznit-approved BDB builds and variations thereof: - PVG sucks for some rockets - PVG is perfect for some rockets - PVG is extremely sensitive to TWR throughout all stages - too high TWR on upper stages makes PVG less efficient (higher Ap/higher final angle) When PVG does suck for me, I use Classic, and manipulate the Turn end altitude while getting close to Ap and then I drive the Final flight path angle slider to emulate what PVG should have done. I can usually hit my Ap, and have a tiny circularization burn, but it's definitely doing it by hand which is icky.

if you wouldn't mind re-uploading a current log file, that would help others. Basically any time you change anything, previous log files are invalidated, and it needs to be looked at fresh again.

Honestly, I don't think you're going to get anywhere until you show what you're doing. Show the build, show the dV numbers in the VAB, show the staging, the PVG numbers on the pad, etc. One set of pictures and I'll bet someone here will quickly identify the issue. As it is now, we're all just guessing. The build works for me and for others, so I'm sure we can help given a bit more info.

This might or might not be pertinent to your issue, but this seems bad. I would delete the others and leave only the latest. [LOG 20:27:06.152] [ModuleManager] version 4.0.2.0 at /Users/account/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/GameData/ModuleManager.4.0.2.dll won the election against Version 4.0.2.0 /Users/account/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/GameData/ModuleManager.4.1.3.dll Version 4.0.2.0 /Users/account/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/GameData/ModuleManager.4.1.4.dll Version 4.0.2.0 /Users/account/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/GameData/ModuleManager.4.2.1.dll

Sure does, especially when you're not having a senior moment and missing the forest for the trees. Forgot the chute is for the landing, not *only* the return trip.

I think it's your Pe. Try "130"

for display, but not for input. The inputs to constrain your transfer window search are Y/D.

So I have a zip file called Distant_Object_Enhancement_Continued-v2.0.3.1.zip which contains a .version file that says this: { "NAME": "DistantObjectEnhancement", "URL": "https://raw.githubusercontent.com/TheDarkBadger/DistantObject/master/GameData/DistantObject/DistantObject.version", "DOWNLOAD": "https://github.com/TheDarkBadger/DistantObject/releases", "VERSION": { "MAJOR": 2, "MINOR": 3, "PATCH": 1 }, Am I correct that 2.3.1 was just a typo for a hot minute, and your current release is the direct replacement for what I have above?

Weird, I def do not have it installed in this one and I used this to do a bunch of scatterer/TUFX AA testing

While I do have Harmony installed now, I didn't previously, and never had problems loading KSRSS. For me it came as a dependency of ConformalDecals**. Maybe CD is borking on load? Edit: ConformalDecals, not TU. Whoops.

Sorry to be a pain. Can you say something about this mechanism? Is this code detecting that scatterer is installed and then skipping other code? I'm curious because these settings that KSP has, like AA, that are singular and global, are addressed by multiple mods, and figuring out who is king of the hill can be challenging. E.g. TUFX, scatterer and KSP all have an AA setting, and if I'm not mistaken, Unity has one value to set. This begs the question which mod is the last one to make the Unity call to set this value, and what does that do to the other mods who thought the value had been set to something different? Am I thinking about this all wrong, or does Kopernicus have to actively detect and yield to scatterer to accomplish the end result of scatterer settings taking preference? And conversely, if Kopernicus didn't actively detect scatterer, they could be stepping on each other for some Unity settings?

With scatterer having a lot of "shadow" settings too, is there any chance you could give some sort of hint what belongs to Kopernicus and what belongs to scatterer? Do both of these mods draw their own custom shadows, or are they both setting global Unity options?

How many days are in a JNSQ year? I need to convert JNSQ real date to Y/D for TWP, and trying to understand if Jan 1, 2002 falls on Y2D1 or Y1D366.

If the EULA accurately expresses their position, I'd be interested in their justification for showing mods in their loading screens.