dtrauma

Members
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

11 Good

About dtrauma

  • Rank
    Battle Rocketeer

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. Just how many mods have you adopted now!? And I have to say, you show some good taste! Major props!
  5. 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.
  6. 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).
  7. 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?
  8. 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.
  9. CKAN thinks 1.8.1 is for KSP 1.1.3, which is bad for both people with 1.2 and 1.1.3 :).
  10. 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.
  11. 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 }
  12. 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?
  13. 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.
  14. 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!
  15. 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.