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 :).

Hey! I tried to install your hazard PP textures via ckan, but it claims to not know about them (not even if I look at the incompatibles, too, where your Ven's Revamp textures show up just fine). Confusingly enough, they are on spaceport, which claims they should be on ckan. What happen? By the way, I don't know how/if it works on spaceport, but you could mark texture packs as suitable for all KSP versions, if anything they can break due to PP, but not KSP. That way you don't have to do anything on KSP updates.

I tried that and it doesn't work - try switching a LFOX tank to LF, leaving the editor and returning - you now have an LF tank with large capacity (as you left it), but it also has OX again, too. The same with launching. It seems you really need to delete the original res nodes. Since Firespitter contains parts that have a res node and a FSfuelSwitcher config, I assume it's a Firespitter bug and this shouldn't be necessary. Edit: It works fine with InterstellarFS. I cleaned the config file and fixed the costs so the base cost of a part will stay the same over all loadouts, and the base+res cost will change as it should. It will also clean up its variables after itself, in a somewhat roundabout way, but the PartLoader will be happy. // Code by Badsector, Nertea and veryinky // LF tanks added by Bigglesworth, 24th July 2015 // Keep resource nodes, fix LF changed by SpaceNomad, 23rd August 2015 // moved to InterstellarFS, refactored, cleaned log warnings and made to work with tanks that aren't full by default by TRauMa, 29th August 2015 // we could add :NEEDS[InterstellarFuelSwitch], but as we only touch the InterstellarFuelSwitch node, it's not really necessary // ----------------------- // LFOX tanks // ----------------------- @PART [*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch]]:FOR[InterstellarFuelSwitch] { // temporary variables - if you add one here, add it below in cleanup, too %tempVar = 0 %resCost = 0 %totalCap = 0 %dryCost = 0 %LFCost = 0 %OXCost = 0 // Total tank capacity @totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ @totalCap += #$RESOURCE[Oxidizer]/maxAmount$ // compute cost of fuel fitting in part @tempVar = #$RESOURCE[LiquidFuel]/maxAmount$ @tempVar *= 0.8 @resCost = #$tempVar$ @tempVar = #$RESOURCE[Oxidizer]/maxAmount$ @tempVar *= 0.18 @resCost += #$tempVar$ // and get dry cost as total cost - resource cost @dryCost = #$cost$ @dryCost -= #$resCost$ // we don't really use dryCost yet, but as LF tanks are more expensive in stock than their LFOX counterparts, this may change // Now compute tank costs adaption as new res costs - old res costs // - LF @tempVar = #$totalCap$ @tempVar *= 0.8 @LFCost += #$tempVar$ @LFCost -= #$resCost$ // - OX @tempVar = #$totalCap$ @tempVar *= 0.18 @OXCost += #$tempVar$ @OXCost -= #$resCost$ MODULE { name = InterstellarFuelSwitch # the first option should leave the tank like it is in stock resourceGui = Rocket Fuel;Liquid Fuel;Oxidizer resourceNames = LiquidFuel,Oxidizer;LiquidFuel;Oxidizer resourceAmounts = #$../RESOURCE[LiquidFuel]/maxAmount$,$../RESOURCE[Oxidizer]/maxAmount$;$../totalCap$;$../totalCap$ initialResourceAmounts = #$../RESOURCE[LiquidFuel]/amount$,$../RESOURCE[Oxidizer]/amount$;$../totalCap$;$../totalCap$ tankCost = #0;$../LFCost$;$../OXCost$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = #$../mass$ tankMass = 0;0;0;0;0 } } @PART [*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],@MODULE[InterstellarFuelSwitch]]:AFTER[InterstellarFuelSwitch] { // temporary variables cleanup to supress PartLoader warnings !tempVar = DELETE !resCost = DELETE !totalCap = DELETE !dryCost = DELETE !LFCost = DELETE !OXCost = DELETE } // ----------------------- // LF tanks // ----------------------- @PART [*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch]]:FOR[InterstellarFuelSwitch] { // temporary variables - if you add one here, add it below in cleanup, too %tempVar = 0 %resCost = 0 %dryCost = 0 %mixCost = 0 %OXCost = 0 %LFcap = 0 %OXcap = 0 // compute cost of fuel in part if at capacity @resCost = #$RESOURCE[LiquidFuel]/maxAmount$ @resCost *= 0.8 // and get dry cost as total cost - resource cost @dryCost = #$cost$ @dryCost -= #$resCost$ // Now compute tank costs as dry costs + res costs at capacity // - LFOX (also calculate caps: 45% of full cap for LF) @LFcap = #$RESOURCE[LiquidFuel]/maxAmount$ @LFcap *= 0.45 @tempVar = #$LFcap$ @tempVar *= 0.8 @mixCost += #$tempVar$ @OXcap = #$RESOURCE[LiquidFuel]/maxAmount$ @OXcap *= 0.55 @tempVar = #$OXcap$ @tempVar *= 0.18 @mixCost += #$tempVar$ @mixCost -= #$resCost$ // - OX @tempVar = #$RESOURCE[LiquidFuel]/maxAmount$ @tempVar *= 0.18 @OXCost += #$tempVar$ @OXCost -= #$resCost$ MODULE { name = InterstellarFuelSwitch # the first option should leave the tank like it is in stock resourceGui = Liquid Fuel;Oxidizer;Rocket Fuel resourceNames = LiquidFuel;Oxidizer;LiquidFuel,Oxidizer resourceAmounts = #$../RESOURCE[LiquidFuel]/maxAmount$;$../RESOURCE[LiquidFuel]/maxAmount$;$../LFcap$,$../OXcap$ initialResourceAmounts = #$../RESOURCE[LiquidFuel]/amount$;$../RESOURCE[LiquidFuel]/maxAmount$;$../LFcap$,$../OXcap$ tankCost = #0;$../OXCost$;$../mixCost$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = #$../mass$ tankMass = 0;0;0;0;0 } } @PART [*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],@MODULE[InterstellarFuelSwitch]]:AFTER[InterstellarFuelSwitch] { // temporary variables cleanup to supress PartLoader warnings !tempVar = DELETE !resCost = DELETE !dryCost = DELETE !mixCost = DELETE !OXCost = DELETE !LFcap = DELETE !OXcap = DELETE }

This is very exciting! Forgive me if this is mentioned elsewhere in this thread, but is there a kind of library or eco system of sorts of scripts people did for kRPC? One of the benefits of KOS is that whatever you want to do with it, you'll probably find code that does something similar, and if not, you're probably trying to do something that is just not possible easily. I feel that a place to share works would help a lot when writing new scripts. For example, I recently looked into pyKEP - anyone else thought about using it together with KSP?

Heads up to anyone else just using the SLIM probe core: as linked on the front page, it's missing an SAS module in the part file, so you won't be able to use SAS with a probe with only this core, even if you add reaction wheels and/or RCS. A quick fix is to just add MODULE { name = ModuleSAS } to the part file. Any vessels already launched have to be fixed in the save file.

Hey, good to see the hubs getting some attention. While I have them installed for some time now, I rarely found an opportunity to actually use them as they are very heavy and didn't really fit in with a lot of other textures. Regarding the docking ports (which I tend to use a lot), would you be open to include passable variants (without the jr. docking port), perhaps using firespitters MeshSwitcher? It's not terribly important to me, though, as I've still not decided if I want to use CLS with 0.25 at all, I just thought it would be neat to have at least a passable XL port (I never had to dock a probe to those anyway). By the way, thank you for creating these!

Procedural cost is not implemented yet (the possibility was only introduced with KSP 0.24.1, and no one got around to do it yet). So small PP tanks will be overpriced, large ones on the other hand will be a bargain.

Someone posted this here IIRC and I tinkered with it further, though I don't remember if I changed anything substantial. I also added Goodspeed auto pumping to all proc parts as I can't live without it anymore. Both are things I should probably submit properly eventually...

Hey, I searched this thread and while I found a lot of complaints about the thrust plate overheating with LV-Ns and DREC, there were no real solutions (reducing the heat output of them to 300 as suggested is already done by DREC), but I think I found one. DREC, by default, halves the maxtemp of any part that goes above 2500°C. Not clamps, but halves. That's why the thrust plate ends up with 1800°, which is not enough to sustain multiple LV-Ns even with their reduced output while in flight (DREC seems to leave landed crafts alone, which screwed up my testing quite a bit, and start to burn up the plate while it's still well below the stated 1800°). If you change the plate maxtemp to 2500°, DREC leaves it alone and everything starts to work. I'd suggest this as a quick fix as a lot of people who use fairings will probably also use DREC, and multi-LV-N is one of the obvious applications of the plate.

OK, I'll do that with some of the affected planes. Is there a way to check if wings are configured correctly? I mostly used spaceplane plus. I'd post some crafts, too, if exchanging them wasn't so problematic right now. I guess one thing that worsens the issue is the lack of any meaningful statistics - all the display mods I tried (VOID, NanoGauges) that display info for FAR don't seem to work with NEAR yet - basically, with NEAR's simplified model, wouldn't it be easy to display one drag coefficient for going up (VAB) or forward (SPH)? And perhaps a center of drag marker... If I don't forget something obvious, that's all that's needed to predict vehicle behaviour (you could check angles of attack by turning the whole vehicle in the editor). ninja edit: Question - has the center of lift shown in the editor any relevance with NEAR?

Before I report a bug there, am I the only one who gets update notifications for the version before the current one when Fine print updates on kerbalstuff? Like today, I got a mail with the announcement/changelog for 0.54a right around the time it was posted here (and there, I presume). Edit: NVM, it's in their bugtracker and a fix is in the queue already.