dtrauma

So for anyone wondering, there seems to be an active community still around this mod. AFAICT the current effort is best accessed here: https://github.com/nullprofile/krpc In the releases you can find krpc recompiles for current versions of KSP, and under actions you can grab the CI builds of the current development which will also include new features found in stock, including those added by @artwhaley and mentioned by them in the post above. I'm a bit allergic to hanging out on discord and apparently this is where people are so I don't know why no one officially adopted krpc or at least posts here from time to time, and I hope I don't step on anyone's toes by posting, but I'm very happy that krpc lives on and thought I'd share.

Is anyone able to run this on Linux? Maybe something internal to sound on Unity in Linux doesn't like this mod? Erroring out that far down in the stack would also explain why there's nothing in the Player.log. Edit: If it is indeed everyone on Linux, maybe if you can't/won't debug this mention it in the first post so at least people are aware?

Still no joy on 1.11.2. Any ideas about how I would begin to debug this?

I don't know if this is something that is known, but when you are in an eclipse (for example around the Mun and Kerbin blocks the sun), all light sources are blocked and you can't see anything anymore. Even the space station I was docking with in full light cones of four spotlights turned pitch black and I could only see the outlines against the milkyway skybox. Even window lights on my vessel got much darker. I use Scatterer, PlanetShine and DistantObjects.

I think there's a bug in the waterfall-restock config for single bell poodles. That, or my engine is leaking. (I don't know of that image URL is stable, if not go here: https://drive.google.com/file/d/1POmxHceRdTC4bu6eyQDZN5qVhLuDPpq3/view

I'm trying to use this on 1.11.1, but even if this is the only mod (besides MM, of course, and both DLC) it either hangs or crashes on launching a vessel like the stock butterfly (which is when the plugin would presumably start doing something). I tried it on an completely empty new save, too. There's nothing in the logs, either. Only thing unusual about my setup is that I'm on Linux. Help? Edit: Here's the log.

I cobbled what I know together from the forum post / MM release thread. MM syntax is byzantine and unusual at first, because it builds on top of KSP's equally NIH cfg syntax, but once you get going it's not that bad, particularly with "modern" extensions like nested operators and variables.

No, final should be reserved for user overrides IIRC. There is :AFTER and :BEFORE to make sure a patch applies before or after a mod loads, and for this to work correctly the mod has to use FOR. You'd use BEFORE for configs you don't want EL to touch (after the change mentioned to ignore parts already configured) or AFTER if you just want to patch a few values from the default config. Also IIRC you can combine NEEDS and BEFORE/AFTER to make sure it only runs when EL is actually there. A NEEDS check from inside the EL folder doesn't really make sense as of course the folder is there if Module Manager sees the config file. That's my understanding of Module Manager at least, feel free to check the docs to make sure. I hope that the next release includes the changes discussed here, and it will probably only happen when KSP 1.3 hits. You could do everything from your own MM patch file and leave the EL one alone, but it would be more involved. The ! and @ operators (delete/edit) are your friends in that case.

This is the incorrect form, without the nesting needed. The problem is that engines with multiple modes all share just the one EngineLightEffect. So you either get no light in both modes or incorrect light in air breathing mode if the other mode doesn't use air. The comment inside the config file is wrong actually, RAPIERS are not excluded because they have one mode of operation that doesn't use IntakeAir. This results in them getting two EngineLightEffect nodes. One fix is to put the rapier config at the top, and change the general config to: @PART[*]:HAS[!MODULE[EngineLightEffect],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir],!PROPELLANT[IntakeAtm],!PROPELLANT[FanIntakeAir]]]:FOR[EngineLight] { The !MODULE[EngineLightEffect] prevents it from applying to nodes that already have a config, so engine mod authors and third parties can include their own configs without getting duplicate nodes. I guess it would be a feature request to make per-mode configuration possible. In the first example, you are testing for engines that don't use resource a OR don't use resource b OR don't use resource c. In other words, every engine that doesn't simultaneously use all three. You want AND, which you can specify using "," in module manager. The second isn't valid syntax according to the module manager docs.

Just how many mods have you adopted now!? And I have to say, you show some good taste! Major props!

Didn't it, in a way, already happen when struts and fuel lines where introduced? As discussed here, they and multiple docking ports connecting at the same time all already break the model of a tree of parts. This is why this mod works (if it does, waiting on the docking fix to test it), as all the code is already there, there simply isn't a GUI to make the nodes connect in the VAB. So code wise I imagine (got no clue really besides reading the dev blog posts) we have a spanning tree of parts built as they are clicked together in the VAB, and it is used for all kinds of things like proposing staging (and getting it wrong ), re-rooting and just generally making editing easier for the user: it's easy to understand that you have a tree of parts that you influence directly, and stuff like struts and docking ports facing each other are second class citizens, so parts strutted together just break the struts if you move one of them around, and if you copy a part tree, the struts won't necessarily work as expected if you aren't doing something symmetric. If you exposed the full multigraph of parts to the user they'd likely just be confused if not already at expert ship builder level. And then we have the real multigraph mess where parts are connected in all kinds of ways for physics (struts, autostruts) and fuel flow (fuel line) and aerodynamics (cargo bays sheltering other parts), with docking ports affecting all three. It would be really nice (and sufficient, I think), to be able to say "these two aligned and very close together attachment nodes shall be pseudo-connected!" in the VAB - it would require manual fixing of multicouplers when building as opposed to this mod, but you'd always be aware where the connections were and there was no potential for unwanted links in cramped situations. You can get the same effect when using docking ports right now, but that has it's own kind of problems.

I use that, and it nicely illuminates vessels in the dark as much as I want, but the terrain stays black (except for city lights, for example).

Hey, I'm new to scatterer (pretty!!) and have a potentially stupid question: is there a way to use it and not have absolutely pitch black 0x000000 pixels everywhere nothing visible at all night sides of planets and moons? I get that it's probably realistic, but planing things in map view and the tracking station isn't particularly fun if half of the body is just black. From the screen shots visible here it seems it's like that for everyone, am I the only one who minds?

Hehe, Me3 - I thought I was original for reporting that... While you're at it, can you make it HAS[!PROPELLANT[IntakeAir],!PROPELLANT[FanIntakeAir]]? That way it skips all the props and turbopros and fans I have installed.

CKAN thinks 1.8.1 is for KSP 1.1.3, which is bad for both people with 1.2 and 1.1.3 :).