Zelda

The statement terminator for kOS is a period char. So it's complaining that you don't have the terminator. Try "clearscreen." You might find the documentation useful: https://ksp-kos.github.io/KOS/index.html

To go the other direction (i.e., scale in the .cfg only if RO is not installed), you simply need to add '!' before RealismOverhaul in NEEDS. That will allow the changes to only execute if RO isn't present. So taking HebaruSan's example above: @PART[MyPart]:NEEDS[!RealismOverhaul] { // Stock scaling stuff here } You can learn more about ModuleManager dependency checking, patch ordering, etc here: https://github.com/sarbian/ModuleManager/wiki

Near Future Launch Vehicles https://forum.kerbalspaceprogram.com/index.php?/topic/155465-most-112x-near-future-technologies-august-26/#comment-2931918

No idea about the names mod, but fairly certain all of those are from the same mod (Near Future Spacecraft).

Not to answer for @zer0Kerbal on whether this is possible, as I looked and there are a lot of resources defined in BDArmory for different ammunition types, I just wanted to call out that you can do this yourself for your game now. Just add the following code to the DontLeak.cfg file under GameData/OhScrap/Patches, one for each resource defined by BDArmory that you don't want to leak. Replace <BDArmoryAmmoResourceName> with the actual names from the BDArmory resource config files here. OHSCRAP_RESOURCE_BLACKLIST { name = <BDArmoryAmmoResourceName> } Or, better yet, add them to a new .cfg file and put it in a personal patch folder in GameData. That way, if OhScrap doesn't take this change, it will still work even after subsequent OS updates overwrite the DontLeak.cfg file. Hope this helps!

Look at SWE (SRB Waterfall Effects) for inspiration, as that's what they do. Edit: Looking at that thread, they are actually in the process of removing RealPlume to help increase performance, so take that as you will.

Oh, sorry, that wasn't me asking, but that may explain why I couldn't find the setting! Thanks for the quick reply.

I just realized I've never really touched the Parallax config after moving to a 2.5x system some time ago. I can't find a density multiplier in ParallaxGlobal, though, and I don't see one mentioned on the wiki. Is it an undocumented setting, or would that be maxTessellation? Thanks!

A good example would be Contract Configurator or ScanSat, which scale with your rescale patch fine. The waypoints I've been asked to visit all seem to be in the right places, so I think it's mostly fine. An example of a mod that had hardcoded lat/long values was one I can't recall the name of but it provided ILS for the runways at KSC. Because the runway is in a slightly different location, the ILS guides you down on to the grass next to it. That said, the config file is setup explicity to be able to change those values, so that isn't a big deal. I will say I do remember seeing a floating monolith on Kerbin once, but that just sort of fits the universe, ya know?

I don't think so. Most mods and the game contracts know where it is, but I have noticed some weirdness with a mod here and there that seem to have those locations hard-coded to a location on stock kerbin. However, I found there was usually a config file you could tweak if you couldn't live without it.

I use 2.5x and OPM as well, it works fine.

Do you have a mod installed that adds a grid to the VAB? This happened to me a long time ago, and if I remember right, it was caused by a mod interaction with (I think) Hangar Grid.

Awesome, thanks for the quick patch!!

Oh my gosh, THANK YOU! I have been encountering this issue for a few weeks, and it was seriously perplexing. I didn't even make the connection that it started happening after I installed Reviva and MAS since I didn't do crewed missions right away. I wrote a very simple MM patch to remove all MAS Flight Computers from MLP parts, and no more black screens. In case anyone would find it useful: // Removes MOARdv's Avionics Systems from Modular Launch Pads IVA spaces @PART[AM_MLP*]:HAS[@MODULE[MASFlightComputer]]:FINAL { !MODULE[MASFlightComputer] {} }

Hello @NathanKell! Thanks so much to you and the RO community for taking this on. Writing contracts to create my own mission storylines is one of my favorite things in the game, so it's good to see CC get some love! One thing I noticed after updating to the new version - nearly every celestial body and kerbal referenced in existing contracts appear to be showing a Lingoona gender suffix unless the contract explicitly refers to the the object's '.Name()' property (or for kerbals, '.firstName()' and '.lastName()'). So just having a simple string in a contract like this: title = Orbit @targetBody ...will show up in-game as "Orbit Jool^N." I updated a few of my personal contracts to use the name properties to test my theory, and it worked to remove the gender suffix, but most older contract packs currently available would need to be updated too. I don't think it causes any problems with the contracts themselves, so likely not a priority, but I'm wondering if you could update CC to default to returning the object name as a string without the gender marker if it's used in a string like that? Visual example from my game below: https://imgur.com/uhgwmRn Thanks!

Yes, per the change log in the OP of this thread: Luciole 1.6 [2021-01-25] ------------------------- - Add Waterfall Support - Fix for KSP 1.11 - Support new 1.11 inventory system - Include Thumbs picture for inventory - New Subassemblies craft files - New CubeSat Ion Engine

Oh, I wouldn't worry about this change I suggested - it was a guess, and it was later pointed out that it wouldn't fix anything anyway. However, the specific line I was referring to was here in the snacksexperiment.cfg file of BetterScienceLabsContinued: https://github.com/linuxgurugamer/BetterScienceLabsContinued/blob/309bf23232dd7b7802da2f5d893ddcdc4939d1cb/GameData/BetterScienceLabsContinued/Resources/snackexperiment.cfg#L172

This. To confirm, you can edit the profile in the TUFX menu and disable HDR. You'll notice the transparency goes away.

What version of Scatterer are you using? I believe that was a bug from a few versions ago.

It brought a huge smile to my face when I heard it! It's perfect.

I came here to say the startup sound on the Bobcat engine is *chef's kiss* And thank you for the fix for SoundtrackEditor! I just reinstalled it again and am loving it. Excellent work.

Seeing this post get bumped reminded me that I should mention how good these configs are. They are a staple of my TUFX rotation. Thanks for making them.

I know this is delayed and you might have already figured it out, but based on my experience: First, pattern refers to the several color slots at the top of the window that you can edit. Simple parts with no special masking will just use the first color for the entire part, while parts that have masking might use 2 or 3 in different areas of the part. Good examples are Mk2 / Mk3 plane parts, which have the fuselage, stripes, and sometimes doors or other interesting greebles that can be colored differently. You can set the top/bottom of the fuselage to be metallic silver, the stripe black, etc. So together, all of those colors are the pattern. So, with that in mind: Store Color: Stores the current color settings (RGB + Metallic and Specular settings). You can recall this across multiple parts using Load Color. So, find a color you really like that you want to use across the craft, or even on multiple color slots in the same pattern? Easy - use Store Color / Load Color. Store Pattern: This will store all colors used on the current part as a "pattern". Change the colors for the part until you have a scheme you like, then use Store Pattern. Load Pattern lets you then apply all of those colors to another part without needing to select / edit each individually. This is great when you are wanting to quickly apply a consistent paint scheme to a craft that has parts from the same family (i.e., the Mk3). Note that each of these only stores one thing. If you store another color, it overwrites the previous one stored. Same with pattern. Hopefully that helps.

@Feellikeapple, longshot, are you moving the camera around when they happen? The muffling seems to depend on the position of the camera. If you are moving it around a fair bit, like I tend to do, then you'll get lots of sonic booms, one each time you rotate the camera from facing the front of the vessel towards the back.

Upload the log to a file sharing site, like Pastebin, DropBox, Google Drive, OneDrive, etc, and then link it here. Logs are pretty critical to helping you. Without them, it's basically guesswork trying to figure out the problem.