Jacke

Not quite. Module Manager scripts have operators for Logical AND (',' or '&'), that is, both A and B and only that. They have an operator for Logical OR, or more specifically a Logical Inclusive OR ('|'), that is only A, only B, or both A and B. But as far as I know, MM syntax doesn't yet have a Logical XOR, Exclusive XOR, A XOR B, just one of A or B, not both. Which is what you want, @Rhedd. You can write a script that will act as an XOR operation and in not too much space. This will definitely work. I don't think current Module Manager syntax allows a simpler script that will do the same as this. @PART[*]:HAS[@PLUME[firstthing],!PLUME[secondthing]] { // whatever needs to be done 1st copy } @PART[*]:HAS[!PLUME[firstthing],@PLUME[secondthing]] { // whatever needs to be done 2nd copy } The advantage of the script above is if those two "whatever needs to be done" sections actually have to be a little bit different, it's very easy to make them so. But Rhedd, you said "whatever needs to be done" was the same for both cases. You still need to use this syntax, as I think there is no other more compact way in MM scripting to do so. @sarbianis likely well aware of this, as XOR is a common computer concept, and he'll know how he could introduce it. But it can be very complex to do. And XOR isn't commonly needed for the sort of stuff that MM scripts do. I search this whole topic and haven't found any mention in 2.5 years of Exclusive OR or XOR prior to this. EDIT: From the Modular Manager Syntax wiki entry: Now that I think of it after reading this, there are better ways to do XOR, but it appears @Rhedd only needs standard Inclusive OR....

[ I'm really starting to hate this IPS4 forum software, especially its editor. ] Perhaps @sarbianwould like to know about the MechJeb delta-V miscalculation. I think all 3 engineering mods share some code and part of the delta-V calculations could be part of that. So it could apply to VOID too. @Xcl's post also in the spoiler. Or not. Look up for Xcl's detailed post about delta-V miscalculation. If I tried to include it but cut down space by hiding it in a spoiler, IPS4 managles the Imgur picture widgit.

Try using the old fix for this. Instead of KSP's classical Video Setting Fullscreen (in an alternate video display in the OS from the rest of the desktop), switch to its look-alike, a true borderless window the size of your desktop. Works in Windows (I use it) and perhaps other KSP OS's. 1. Edit the command used to launch KSP to include these options, " -popupwindow -nyan-nyan". " -popupwindows" will change the KSP display when windowed to be borderless: with no title bar or borders or any other widgits on the edges. " -nyan-nyan" will be ignored unless you have the Module Manager mod added (it's often needed as part of other mods which have Module Manager scripts to change things); then you will see a colourful Nyan Cat going across the lower half of your screen as Module Manager is loading. 2. Launch KSP and In the initial menu select Settings and then Graphics, then make sure the Screen Resolution is the same size as your desktop, and then turn off Full Screen, then Accept. KSP will stabilize on the new video settings. Exit KSP, then launch it again. Now you should be able to alt-tab away and back to KSP without any added chance of KSP having issues. While KSP is using a true borderless window, it will run and play it audio even if under other windows. To mute it, you can use the OS volume control or the Master Volume in the KSP Audio Settings.

Right before you launch KSP, what does Windows Process Manager report as your entire memory usage? When you launch KSP_x64.exe, create a new game, and go to the VAB, what does it report. Can you give a few details of how you get KSP to crash? How does it behave? What is the Process Manager reporting for memory usage just before the crash? As @Waxing_Kibbousindicated, with 16GB RAM, you are almost certainly suffering memory leaks and definitely other bugs. With my heavily modded KSP 1.1.1.1250 (EVE with Ultra SVE) running in the VAB, everything on my computer is only taking up under 10.5GB, of which KSP is under 3.5GB. And that's with bloated Firefox with almost 1GB just to itself. And because a 64-bit processor has a much greater max process size, on your computer if that went higher, it would only offload the least used memory into the swap file and then you'd see a slowdown, but you shouldn't crash. Can you PM me your set of mods? I'll compare that to what I have installed and what ones my game has used. Perhaps I can point out the most likely suspects. And if you're having such problems, you may want to make sure you did a very thorough reinstall. Did you remove every possible source of cruftyness, whatever its low likelihood? Did you wipe all of the KSP directory before installing from Steam or the KSP store? After than, did you reconfigure KSP's settings manually? Then did you confirm you had the most recent version of your mods that will work with KSP 1.1.1? And then did you reinstall all your mods from the appropriate install media (usually just extract from .zip files) and reconfigure them by hand? And then did you start a new game and design ships from scratch (and save your older savegames you still want to play until KSP gets over this rocky upgrade series. And saw whether the bug showed up after that massive cleanup? It's a lot of work, but that's what's needed to rule out clashing from KSP/mod version changes that may have left cruftyness behind.

Same as me, except I have 24GB (3-year-old gaming laptop). Even with a mass of mods (I run over 50, but very few parts, but also EVE+SVE at highest resolution), I'm not getting above 4GB for my KSP process. From what others have said, you should be good for KSP once whatever particular bug(s) causing the memory leak for you is fixed, as well as cleaning up your install to remove all sources of cruftyness.

To answer that, need info on your computer. What OS? 64-bit or 32-bit? How much RAM do you have now?

Modelled after the Face on the Bottom of the Ocean?

Probably. Could be reusing a graphics visual line-of-sight function for it. But if it's checking using the CoM height, it's still the same forumlae except X and Y are now the CoM heights off the spherical body's ground.

And there are indications (GOG commented that Squad has asked them to hold off to wait for an updated KSP) 1.1.2 or at least a hotfix for 1.1.1 is imminent.

I just did some quick trig and figured out the general formula and 2 special cases for straight-line visibility range, assuming two vertical antennas on a spherical body. To just have line-of-sight of 500m, two similar antennas would only have to be 0.52m high (Kerbal high ). Two 3m antenna would have 1200m line-of-sight range. Two 10m antenna would have 2190m line-of-sight range. For most antenna designs, you can use their height to the top because the radio waves curve slightly around the horizon.

That's what I found too. However, even in the VAB, you do get something. Besides the slightly exploded view of the pod, if you can explicitly move the camera inside, you don't just see a ghost outline around you like in stock, but the proper IVA INTERNAL. Very cool!

Thanks for all your hard work, Diazo! I've only skimmed some info about the changes going to 1.1.0 (and now 1.1.1) and even that looked brutal.

...with no ads, because *every* ad network has had malware in its rotation. And the chestnut about avoiding porn sites, they (and their ad networks I imagine) have much better security on average. Oh, 99% of the Internet runs on ads now. Something's got to give....

Good good. Went back and editted my questions with strikethrough and added the answer no, so anyone reading won't get the wrong impression. Went and did a quick check of the Mk1 Pod. Here it is on the launchpad. Looking the same as the stock Interior Overlay. And in the VAB, which stock KSP doesn't have. Not surprising that a stock part with just my addition of the JSIATP MODULE isn't showing quite right. The near side of the pod is still solid with only the nearest interior details visible.

I know I don't take my home computer security seriously enough. I've been lucky through a combination of a good hardware firewall, reasonable risk avoidance, and that I still read email as God intended: text and check those headers! But only believe the last "Received from:" header. I think COMODO Firewall and Antivirus are good. But COMODO's opt-out options are slimy! Maybe similar opt-out options cause those problems with Bitdefender. Here's the install window for COMODO Antivirus: See that little "Customize Upgrade" at the lower left. The one that many people will overlook. Click it and you see: You only want the first one, to install the main product. Slimy! Need to deselect those other two. But after that, it's seems okay. Except from time to time mildly encouraging you to upgrade to the paid version. And when it gets an AV positive, asking you if you want a GeekBuddy to help you deal with it (always decline).

I've used web app scanners like MalwareBytes, but I always worry about anything defence or detector that wasn't resident before the infection or isn't running from a read-only alternate boot device. When AVG went downhill, I switch to COMODO Firewall and their Antivirus. Irritatingly, the bloody installers have irritating opt-out features buried in drill-down menus I really really wanted to opt out of (change my browser and browser search). But after that they're fairly well behaved (except for the odd obvious false positive that any of them get). Not as secure as a virtual machine. But I think it's clean...I hope.

I have a bad habit of editing my posts just as someone is replying to them, so my last edit get missed. My bad. So as I mentioned in an edit, JSI Advanced Transparent Pods still depends on RPM and requires RPM to work, correct? So RPM has to be installed with it? Perhaps this should be noted on the original post. Mistaken, RPM not needed for JSIATP. Good good! So this MM script is likely better, setting the mode to OFF initially on modded parts. @PART[*]:HAS[@INTERNAL[*],!MODULE[JSIAdvTransparentPod]]:NEEDS[JSIAdvTransparentPods] { MODULE { name = JSIAdvTransparentPod transparentPodSetting = OFF } } Cool! Looking forward to it!

It's getting away from Indicator Lights, and you should have PM'ed me for it, but briefly.... Don't call yourself stupid or a dummy. You are not. All of have things we just don't know or are not familiar with. When we need to, we can all learn. More in the spoiler....

I also suggested "JSIATP" as an abbreviation for JSI Advanced Transparent Pods (in an edit I was doing as you were replying). And JSI Advanced Transparent Pods still depends on RPM and requires RPM to work, correct? So RPM has to be installed with it? Because a release zip file (or any other archive file format used for installation) should have the version number in its name. If you just see "JSIAdvTransparentPods.zip", what version number is it? If you download or copy the .zip file to the same location, that one file will be overwritten, preventing access to the older versions. It's what's done by most other mods. Take a look at RPM here, or Module Manager here. They have their version numbers in their .zip filenames. Ask @MOARdV how he does it with RPM. I will. I'm aware doing such things can break stuff and will affect performance. It's not my first rodeo.

Looks interesting, @JPLRepo. I suggest using the abbreviation JSIATP. Could you add the version number to the name of the release zip file? Like with the lastest RPM, "RasterPropMonitor.0.26.0.a.zip". That way they'll each have a different name and I won't have to edit them to put in the version number manually. JSI Advanced Transparent Pods still depends on RPM and requires RPM to work, correct? So RPM has to be installed with it? Mistaken, RPM not needed for JSIATP. On the mods's wiki page, I think the path in this quote (bolded) wasn't updated from when it was included with RPM. In the release .zip that file appears to now be at "GameData/JSI/JSIAdvTransparentPods/DisableTransparencyInEditor.cfg.noload". How well do the stock parts meet the criteria you list on the wiki (quoted in the spoiler)? In other words, how well would things work if I followed this: and use a Module Manager script to add it to every part that has an INTERNAL. Like @PART[*]:HAS[@INTERNAL[*],!MODULE[JSIAdvTransparentPod]]:NEEDS[JSIAdvTransparentPods] { MODULE { name = JSIAdvTransparentPod } } (Technically that would add the MODULE to all parts with an INTERNAL that didn't already have it, so it would match non-stock parts too. Not necessarily good.)

You can switch to KSC with the engines on at low power ?!? As in non-zero throttle ?!? Thought that wasn't possible? Part of the bug?

Obviously @Renegrade, you haven't made sufficient sacrifices to the BIg C if you have to 'ware the Kraken. Iä! Iä! Cthulhu fhtagn! Ph'nglui mglw'nfah Cthulhu R'lyeh wgah'nagl fhtagn! Less cultishly, does it act as if the ship is under thrust, not allowing you to switch away from it?

That's to be expected, based on the KAS.version file containing "1.1.0". You have to expect this for point updates of any mod. You could help by testing and seeing if KAS is behaving the same on 1.1.1 as you found it to do so on 1.1.0.

It's frustrating, but it indicates how premature releasing 1.1.0 was, to have even fixes to it break mods that were working with it. On the other hand, without that premature release, I don't think we'd have the features of @sarbian's Make It Small in stock by now. As for RPM, @MOARdV said he'd be on it when he has dealt with real life issues. I think he'll have it fixed right quick.

Well, if it's not showing a status of closed or otherwise indicating a fix has been pushed to the live version of KSP, I'd say its fix isn't included. Although that bug could be affected positively by some of the other changes. But with that high of a level of activity on a bug, I'd say Squad is close to getting a good fix tested and deployed. I'd expect it to come with either a hotfix or 1.1.2.