TranceaddicT

Absolutely. I'm away for the weekend (first time in 6mo), so I'll validate everything on Monday.

Right, got it. The important takeaway being that the :NEEDS validation process (and discarding those not met) happens before any pass processing.

This is EXACTLY how MM functions. (And, I might add, proper.) As @Lisias has demonstrated (in his modA, modB, modC example) and I pointed out. Any config with an unmet :NEEDS is thrown out BEFORE MM's :FOR declaration functionality comes into play. This is because MM loads every config it finds indiscriminately and only then performs :NEEDS checking to discard those configs as superfluous. (Why process that which you already know will fail.) So, any config which contains a :FOR[modA] that also contains a :NEEDS[modA] will rightly and PROPERLY be discarded before pass parsing begins. I don't think this behavior can (much less should) be changed in any way without a serious and in-depth code overhaul. I'll also add, that this helps with proper temporal placement of :FOR between :BEFORE & :AFTER.

I don't believe this functionality happens when you think it happens. 1. ALL configs are loaded regardless. 2. Configs are parsed for unmet :NEEDS 3. Those configs are discarded. 4. MM begins processing configs and the :FOR conditional now starts declaring. So, as described, a config with :NEEDS[modA]:FOR[modA] will only be processed if modA is present. If not, it will be discarded BEFORE being parsed by MM and the :FOR declaring a non-existent mod present. That said, if anyone else uses :FOR[modA], modA WILL be recognized ... but it won't be you're doing.

Slayed.

Sorry, I'm crossing thread streams. Just the KSP.log

Those are the logs (and their directory location) needed.

<KSProot>/KSP.log <KSProot>/Logs/Kopernicus/Kopernicus.log <KSProot>/Logs/Kopernicus/Kopernicus.Runtime.log

You skipped a step.

@Alcentar Since you are as allied as you are and I'm equally not, try this ... https://lab.github.com/ There are short, 1-2h exercises available suck that even I was able to become fairly well versed.

Please give consideration to small parts, such as sounding rocket engines, to include a "micro" size. https://www.nasa.gov/content/nasa-prepares-new-sounding-rocket-motor-for-first-test-firing

That's just a mis-configured localization field. Nothing to stress about. @Alcentar are you going to put it on GitHub for issue reporting and help with instances like this?

Suggestion: take the time to remove KER completely. If you use CKAN, uninstall it there AND manually check your install for strays - searchibg for KER specific files. Then, start a new game (new name) in sandbox. (I keep one of these for the "what am I doing wrong cases.) Make a VERY simple purpose-built craft - achieve orbit - and validate the numbers. A modified Acapella could be a good test subject. Then, install KER again. Rinse and repeat. Change nothing. See what KER reports number-wise.

Oh, okay, my bad. Just pulling numbers from wiki and headmath on that one

Well, all the orbital parameters have not changed and the CelestialBodies.pdf included is accurate. I've verified this using KSPTOT. Kerbin's Escape velocity is 5,602 m/s. So, anything approaching 6K is hitting that mark. (leaving the SOI.) I shouldn't have used ballistic; I meant hyperbolic. So, here's what you do. 1. remove everything but the payload and save the payload as a new craft. 2. put the payload on the launch pad 3. RALT + RSHFT + F12 (windows) 4. set SMA to >=127125 (minimum safe orbit) +1600000 = 1727125 5. check NavBall orbital speed (Make sure it says 'Orb', if not click once to change.) That is your orbital dV & add ~1200-1300 for launch (ideal.) I see a SIGNIFICANT different between what KER and KSP are reporting for dV. dV KER KSP s1 2472 1931 s2 3246 2532 Total 5718 4463 It looks as though KER is reporting vacuum for the entire rocket when you should be (at least) using atmospheric values for the first stage and 1/2 of the second. I'd trust the KSP values more. Then there is the issue of aerodynamic losses. That bulk in the middle is causing is going to decrease your efficiency significantly. I'd generously grant you 3900-4000dV out of that based on KSP numbers. TWR is not your worry. That's fine. I think Saturn was closer to 2.

That depends on the LaunchVehicle parameters ... payload mass, LV mass/stage ... Are you sure you not trying to lift too large a payload? Upload a .craft file to a fileservice and share it. If you are close to 6000, you should be going ballistic.

Not the binaries, it just has source code.

Ah, okay. This is my first time with JNSQ (about a month now.) So, it's a big new bag of WFT. I take it you're looking for the next-level ... WTAF!?!

Are those RGB at the top planets? or artifacts?

Setup an Imgur account. I'm assuming that is descent lighting, yeah? You are referring to the ghost lines, yeah? I think, that's just shading and reflection making it appear that way. IOW, it's not a bug, it's a feature.

<whisper type=backalley tone=hush> Psst, JNSQ. </whisper>

Something like this? https://commons.wikimedia.org/wiki/File:PIA20513_-_Basking_in_Light.jpg (Really stupid that won't insert.)

I'm trying to sort out something for Sounding Rockets to make them interesting and worthwhile (and not too grindy.) It's slow , but progressing.

Ping a moderator to close this thread and direct to new.

I've also seen this used as a patch-the-patch or cleanup-my-mess methodology.