Corax

Awesome. This is how it should have been done from the beginning. To this day I'm still wondering how Squad/TT/Unity3D can get away with their borked "opt out" policy.

ARP really should be stock, but it isn't, so a big thank you for keeping it alive! This is my only gripe with Trigger's otherwise awesome mods. I'd much prefer this to be disabled by default, and only optionally check after the user has decided to allow it. I think the GDPR would agree. Any chance you could alter this behaviour to be more privacy conscious? I know "issuing an HTTP GET - and sending no data" sounds inconspicuous, but I don't particularly like giving Google yet another data point of tracking my IP every day.

Seriously? What is the difference between Kourou and Tanegashima?

Chacun à sa façon, but what happened to "concede failure and count your losses"? Am I just too old fashioned?

I'm looking forward to being able to use ETT again, I have fond memories of using it back in... 1.4, I think? Although I also remember it as having been quite the mess back then, with needing tons of custom MM patches to make sense of it ; ) Thank you for taking on this Herculean task of bringing it back up to speed. Just an aside: If you want to distribute a file, replace the ?dl=0 with ?dl=1, this way the download starts immediately, without the need to go through yet another page.

I think the texture in question is EVAVisor, and probably needs to be placed in GameData/TextureReplacer/Default. Looking for EVAVisor in this thread should yield results; failing that, I think GPP (Galileo's Planet Pack) comes with one that might serve as a starting point.

...sounds super exciting! The "small department", and there especially the aircraft section, always feels severely lacking IMO.

That's the indicator for your Reaction Control System, or RCS. If the indicator is green, it means you have activated your RCS; pressing the "R" key on your keyboard toggles it on or off. It doesn't matter whether your vessel actually has RCS thrusters and/or fuel, so it may be misleading at times.

To add to this, it's hard to imagine there being any valid MODULE definition without a name, so regardless of what way you're going to modify it, using "modify" '@name=' should suffice in any case, as opposed to "modify or create" '%'. If it doesn't, I'd take that as an indication of an underlying error. I doubt %MODULE[something]{} is actually going to insert a module that didn't already exist before, so using '%' instead of '@' seems kind of pointless, but I don't think I've ever tried that before, I may be wrong on that count.

You're trying to (modify or insert) the module named TweakScale, regardless of whether it already exists or not, and (change or insert) its name to TweakScale, regardless of whether it exists or not (the '%' operator). If this is going to do anything at all, it's likely not what you intended. If you want to modify an existing module, use '@MODULE', and leave out the %name= part. If you're trying to copy an existing module as a new one, use '+MODULE' and do include the name= part. If you want to add a new module that wasn't part of the config before, just do it as if you were just writing a regular config, not an MM patch, i.e. "MODULE { name = theModuleName }" without any of the @/%/+ operators. Just my two cents.

This. 4 wheels in one part, sadly I can't even remember the author. Was it DYJ? ISA? TDTL? Here's to you, pioneers of KSP modding. Those were the days.

I think I may have misinterpreted your original question; you want to know the maximum possible time for the period of orbit in darkness for a specific orbit, not the general worst case which would always be with the AP opposite the sun. My pedestrian approximation would be to assume an infinitely far away star–that is, parallel light rays–which would give me the distance I'd have to pass through shadow as equivalent to the planet's diameter. Then using trigonometry and Kepler's Second Law, it should be possible to deduce the time it takes to pass through that portion of the orbit.

Agreed, FINAL should in general only be used for "personal" patches, if you will. On the other hand, FOR should only be used by the author of the mod itself (which, granted, Probus would probably be, in the case of ETT), since it defines that identifier as "existing" in terms of ModuleManager, i.e. if ETT is not installed, but a patch uses FOR[ETT], ModuleManager can't know better than to assume ETT is in fact installed, and all other patches depending on that will get applied too.

It's been a while, but ISTR that you could configure them?

Yes you can. RTFM ; ) Something like @TechTree:NEEDS[JNSQ,!OPM,!RSS]:FINAL{ @RDNode:HAS[#id[advancedMotors]]{ @cost *= 1.2 } } @TechTree:NEEDS[RSS,!JNSQ,!OPM]:FINAL{ @RDNode:HAS[#id[advancedMotors]]{ @cost *= 1.3 } } @TechTree:NEEDS[OPM,!JNSQ,!RSS]:FINAL{ @RDNode:HAS[#id[advancedMotors]]{ @cost *= 1.4 } } might work, no guarantees though.

Mind putting that in spoiler tags? Because it kinda is... Thanks.

Never said it isn't, just that for whatever reason some people may not be able to see them, and as such, they are not a reliable means of conveying information. I for one decided a long time ago that it isn't worth wading through knee-deep sewage only to be able to find a scarce few pearls. It may have changed, or it may not, but I'm not in the least inclined to enable signatures again. Also, apparently mobile users are cut out regardless.

Just FYI, signatures are not a reliable way to convey information–they don't necessarily show for everybody; at least they don't for me, so I can only guess others won't see them either.

As you already found out, Posting this here so others with the same question can find the answer, too.

All I can tell you is that messages containing "HighlightingSystem" have started to appear in my KSP logs starting with 1.0.0 in 2015, and have stopped after 1.4.2 in 2018; that may have been around the time I have been using an Nvidia GPU, which I have since switched for an AMD one, or it may be completely unrelated. However I have never seen that specific message you posted. It sounds as though it were related to your graphics cards' capabilities, or its driver settings. Maybe something like the card/driver doesn't support some setting, and a workaround is being enabled in its stead, don't quote me on that though. I wouldn't give it tooo too much currency, if everything is working fine for you... but of course, curiosity is always a good thing! If you find out more, I'd like to hear about it.

By effectively hiding them from the user, the mod author encourages you to use the new parts for newly built vessels, while the old deprecated parts are still available for existing craft files to load correctly.

Public Service Announcement: If you change the ?dl= parameter in Dropbox links to =1, the person wanting to view or download (what "dl" stands for in this case) doesn't have to go through Dropbox's web site, but instead the download happens immediately. https://www.dropbox.com/s/ljmgiurzkyrndna/KSP.log?dl=1 hth

Public Service Announcement: If you change the ?dl= parameter in Dropbox links to =1, the person wanting to view or download (what "dl" stands for in this case) doesn't have to go through Dropbox's web site, but instead the download happens immediately. https://www.dropbox.com/s/cou51gkl41em87y/Screenshot 2020-03-11 13.04.34.jpg?dl=1 hth Also, that way the forum software can embed the image automatically. Didn't know that myself until now, so "thanks", I guess.

No it won't. Worst case is when your AP (the slowest point in your orbit) is directly opposite the sun, viewing through the planet's centre; for that it does not matter whether it's polar or equatorial, you're still occluded by the same planetary disc, which takes exactly the same amount for otherwise identical polar or equatorial orbits (maybe unless you take the planet's precession along its orbit into account too, but that would be minuscule compared to your orbital period). On average (or in total, whichever way you want to look at it), insolation will be better with polar orbits since you'll spend much of the time in a plane along the planet's path above/below the planet's limb, with a clear view of the sun, and much fewer short periods where it is occluded by the planet as opposed to an equatorial orbit, where the occlusion happens on every orbit. TL;DR: The maximally possible time, i.e. worst case, your satellite will be in darkness does not depend on the orbit's inclination for otherwise identical orbits (same AP/PE). You'll need the same battery capacity for either case.