ialdabaoth

Hrm. Why would this not be working: @PART[RAPIER]:Final { @MODULE[ModuleEnginesFX]:HAS[#engineID=AirBreathing] { @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 2.5 } } @MODULE[ModuleEnginesFX]:HAS[#engineID=ClosedCycle] { @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 0.73 } @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 0.27 } } } Or, given that apparently searching doesn't work at the Module-level, why this doesn't work: @PART[RAPIER]:Final { @MODULE[ModuleEnginesFX,0] { @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 2.5 } } @MODULE[ModuleEnginesFX,1] { @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 0.73 } @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 0.27 } } } Or this: @PART[RAPIER]:Final { !MODULE[ModuleEnginesFX] {} !MODULE[ModuleEnginesFX] {} MODULE { name = ModuleEnginesFX engineID = AirBreathing directThrottleEffectName = power_open runningEffectName = running_open thrustVectorTransformName = thrustPoint exhaustDamage = True ignitionThreshold = 0.33 minThrust = 0 maxThrust = 190 heatProduction = 400 useEngineResponseTime = True engineAccelerationSpeed = 0.2 engineDecelerationSpeed = 0.35 useVelocityCurve = True PROPELLANT { name = LiquidH2 ratio = 2.5 DrawGauge = True } PROPELLANT { name = IntakeAir ratio = 15 } atmosphereCurve { key = 0 1200 key = 0.3 2500 key = 1 800 } velocityCurve { key = 0 0.5 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2200 0 0 0 } } MODULE { name = ModuleEnginesFX engineID = ClosedCycle runningEffectName = running_closed thrustVectorTransformName = thrustPoint exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 175 heatProduction = 650 fxOffset = 0, 0, 0.25 PROPELLANT { name = LiquidH2 ratio = 0.73 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 0.37 } atmosphereCurve { key = 0 465 key = 1 375 } } } Or this: @PART[RAPIER]:Final { !MODULE[ModuleEnginesFX] {} @MODULE[ModuleEnginesFX] { @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 0.73 } @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 0.37 } @atmosphereCurve { @key,0 = 0 465 @key,1 = 1 375 } } MODULE { name = ModuleEnginesFX engineID = AirBreathing directThrottleEffectName = power_open runningEffectName = running_open thrustVectorTransformName = thrustPoint exhaustDamage = True ignitionThreshold = 0.33 minThrust = 0 maxThrust = 190 heatProduction = 400 useEngineResponseTime = True engineAccelerationSpeed = 0.2 engineDecelerationSpeed = 0.35 useVelocityCurve = True PROPELLANT { name = LiquidH2 ratio = 2.5 DrawGauge = True } PROPELLANT { name = IntakeAir ratio = 15 } atmosphereCurve { key = 0 1200 key = 0.3 2500 key = 1 800 } velocityCurve { key = 0 0.5 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2200 0 0 0 } } } Note: Those are literally ALL the possible ways to do this. Since none of these work, I don't know how to proceed. EDIT: Holy crap, THIS doesn't even work: !PART[RAPIER] {} PART { // this is a sample config file, for determining a good file format for defining part parameters // comment line - ignored by cfg parser // empty lines, or lines without a '=' sign are also ignored // all other lines are split at the '=' sign, and the left operand is used to know what parameter we are setting // diferent parameters require data in different formats (see docs), and each module has it's own parameters (again, see docs) // each assignment must be in a single line. Lines without assignments will be ignored. (You CAN turn on word wrap, though) // each keyword here relates to an existing variable in the assigned module. If the keyword isn't found, it is ignored. // conversely, if a keyword is left unassigned (as in not in the file), it will be initialized with it's default value // This is done automatically, so any public variable defined in the loaded module can be accessed this way (provided it's value can be parsed) // --- general parameters --- name = RAPIER module = Part author = C. Jenkins // --- asset parameters --- mesh = rapier.mu scale = 1.0 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0,0.741545,0.0 , 0.0, 1.0, 0.0 node_stack_bottom = 0.0,-0.2048244, 0.0, 0.0, 1.0, 0.0 // --- editor parameters --- mass = 1.75 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 20 maxTemp = 3600 TechRequired = hypersonicFlight entryCost = 65000 cost = 5900 category = Propulsion subcategory = 0 title = R.A.P.I.E.R. Engine manufacturer = C7 Aerospace Division and Rockmax Conglomerate description = The R.A.P.I.E.R. (Reactive Alternate-Propellant Intelligent Engine for Rockets) is a joint venture between C7 Aerospace and the Rockomax Conglomerate. Designed to fill a gap in the design requirements for sustainable single stage to orbit aircraft, this engine combines the best of rocket and air-breathing thrust technology. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 EFFECTS { running_closed { AUDIO { channel = Ship clip = sound_rocket_spurts volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } PREFAB_PARTICLE { prefabName = fx_smokeTrail_aeroSpike transformName = smokePoint emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 1 } MODEL_MULTI_PARTICLE { modelName = Squad/FX/shockExhaust_blue_small transformName = thrustTransform emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.5 speed = 1.0 1.2 } } power_open { AUDIO { channel = Ship clip = sound_rocket_spurts volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } MODEL_MULTI_PARTICLE { modelName = Squad/FX/shockExhaust_red_small transformName = thrustTransform emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.5 speed = 1.0 1.2 } } running_open { AUDIO { channel = Ship clip = sound_jet_deep volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } PREFAB_PARTICLE { prefabName = fx_smokeTrail_aeroSpike transformName = smokePoint emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 1 } } engage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { PREFAB_PARTICLE { prefabName = fx_exhaustSparks_flameout_2 transformName = smokePoint oneShot = true } AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } MODULE { name = MultiModeEngine primaryEngineID = AirBreathing secondaryEngineID = ClosedCycle } MODULE { name = ModuleEnginesFX engineID = AirBreathing directThrottleEffectName = power_open runningEffectName = running_open thrustVectorTransformName = thrustPoint exhaustDamage = True ignitionThreshold = 0.33 minThrust = 0 maxThrust = 190 heatProduction = 400 useEngineResponseTime = True engineAccelerationSpeed = 0.2 engineDecelerationSpeed = 0.35 useVelocityCurve = True PROPELLANT { name = LiquidFuel ratio = 1 DrawGauge = True } PROPELLANT { name = IntakeAir ratio = 15 } atmosphereCurve { key = 0 1200 key = 0.3 2500 key = 1 800 } velocityCurve { key = 0 0.5 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2200 0 0 0 } } MODULE { name = ModuleEnginesFX engineID = ClosedCycle runningEffectName = running_closed thrustVectorTransformName = thrustPoint exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 175 heatProduction = 650 fxOffset = 0, 0, 0.25 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 360 key = 1 320 } } MODULE { name = ModuleAnimateHeat ThermalAnim = HeatAnimationEmissiveRapier } MODULE { name = ModuleGimbal gimbalTransformName = obj_gimbal gimbalRange = 3 } } I'm absolutely using v1.5.6, and other config mods are working fine - any idea what's going on here?

You know, when I was in charge of DRE, I always felt like it was a mod that should really be rolled into FAR and handed off to ferram. It seems like he has most of this stuff taken care of already (and raycasting always did seem like a horribly imprecise hack to me, even when I was using it).

Where is this?

Or a crew cabin version.

Regarding engines / tanks: What would be really nice, would be to actually implement sub-categories, even if only as a sorting system for which parts show up higher in their category lists. If you wanted to get really fancy, you could have a second set of tabs appear under the first set, to filter by. In which case, might I propose: Pods 0.5m Manned 1m Manned 2m Manned 0.5m Unmanned 1m Unmanned 2m Unmanned Propulsion 0.5m Fuel 0.5m Engine 1.0m Fuel 1.0m Engine 2.0m Fuel 2.0m Engine Control 0.5m SAS 1.0m SAS 2.0m SAS 0.5m RCS 1.0m RCS 2.0m RCS Structural 0.5m structural 1.0m structural 2.0m structural small plates and beams medium plates and beams large plates and beams Aerodynamic 0.5m fairings & cones 1.0m fairings & cones 2.0m fairings & cones small fins medium fins large fins Utility Lights Batteries & Generators Docking Ports Wheels & Legs Crew Accomodations Storage Science Sensors Experiment Housings Transmitters

Seriously, the Propulsion tag gets REALLY crowded, and the Control tab is practically empty. Shouldn't RCS tanks go with their thrusters?

Can you describe what's broken?

Really, with the way the UI works in .23, the selection process should probably be taken out of the Action Group menu altogether. What would be ideal would be to hook into the right-click "extra detail" menu from the parts menu, and have a dropdown for "alternate configurations".

Because MJ in the VAB is computing TWR based on vacuum Isp, and on the pad it's computing based on sea level Isp. Remember that changes in Isp are (in the real world) supposed to change thrust, not fuel flow - stock KSP does this wrong, and MJ is following stock KSP's assumptions in the VAB.

Update: We're having trouble recording / streaming video. However, the first player managed to hit the moon with his 3 kerbals, at approximately 400 meters / second.

My local college is having a semi-competitive LAN party this Saturday. I've decided to try to run an event, called the "KSP Noob Build-Off". The event is simple: A group of players who have never played KSP will each be given identical computers, each with a configured 'Sandbox' install of the game. The ONLY mods installed will be Ferram Aerospace and Deadly Reentry. Spectators will be seated behind the competitors. NO INSTRUCTIONS WILL BE GIVEN, other than the following: "Welcome to Kerbal Space Program. The first player to land three or more Kerbals on the Mun, and return them ALL safely to Kerbin, wins. How hard can Rocket Science be, anyway?" If possible, I will compile and post a side-by-side video of the competition.

Aha. So what we really need to do then, is move the engine fuel selector off of its menu and onto the 'tweakable' menu (preferrably as a single line with a '<' and '>' button), and do something similar with the fuel tanks. ... give me a few days, I'll see what I can figure out.

So, any chance of getting it integrated into .23's 'tweakables' system?

Suggestion on syntax: When modifying, @NODE[blah] {...} affects a node, while !NODE[blah] removes a node; likewise, @PROPERTY=... affects a property, while !PROPERTY removes a property. For consistency's sake, when searching, :HAS[@NODE[blah]] should match on having a node, while :HAS[!NODE[blah]] should match on not having a node. Likewise, :HAS[@PROPERTY] should match on having a property, while :HAS[!PROPERTY] should match on not having that property (note the lack of [] if it's a property). So this: @PART[*]:HAS[~TechRequired[]]:Final should really look like this: @PART[*]:HAS[!TechRequired]:Final if we want a tight, consistent language. That said, it's of course your baby right now - but I'd strongly advise considering my recommendation; I know a thing or two about language and script design. One thing you need to be very mindful of, is that eventually Squad will catch up with you - and on that day, you want them to be able to implement their own version of your parser from scratch, without your help, so that mod authors everywhere won't have to redo everything in their cfg files. Every change you make to ModuleManager's CFG syntax is a change that needs to make absolute intuitive sense, AND be easy to write a parser for, or you open the temptation for Squad to just do their own thing and throw your design out the window.

It can, when you start with a procedurally filled tank and then want to edit it further. All those extra digits have to be deleted, which can be tedious. Recommendation: Have a value in the TANK_DEFINITION that determines whether rounding is enabled for that tank type or not, so that stretchy tanks can use a TANK_DEFINITION that disables rounding.

Protip: This is a TERRIBLE idea. THIS is a good idea. There should only be ONE copy of ModuleManager running. EVER. It needs to handle everything from /GameData on down. Putting ModuleManager.dll itself in /GameData is a good reminder of this. Suggestion: Have ModuleManager print "ModuleManager version 1.5 initialized" before all the parsing, and 'ModuleManager version 1.5 finished" after all the parsing. (Obviously, increment version per update). If a user has a problem with a mod, that mod author can demand that the user tell them which version of ModuleManager they're running before they provide any support. That's as far as you can take it, really.

Excellent, this is the next direction I was going to go. Suggestion: Rather than having a damage warning, determine which crew members are "active" and have the entire screen brightness drop as a fraction of their damage_counter, to simulate blackout.

Hello, everyone; it's been awhile. I still don't have a computer capable of running KSP, which means debugging (and hence modding) is currently out of the question for me. However, sarbian's MM extensions looks rather mature and bug-free at this point, other than a few issues that would easily be solved with a minor patch to MM itself. Sarbian has my blessing to take over MM development, with the understanding that every time a new MM version comes out, the community goes into a bit of freak-out mode as people try to figure out whether they have the correct version or not. You'll need to be better at coordination and distribution with other mod-authors than I was (luckily, I set the bar pretty low). Good luck, and fly safe.

Everyone: I want to personally apologize for being so late with updates, and so infrequent with checking in to the site. I'm currently in the midst of navigating the government's bureaucracy for disability, so as to not become homeless. As soon as I can focus attention on KSP again, I *will* give you an update. You have my word.

Actually, I mistyped in my original example; this should probably be @PART[*]:HAS[@MODULE[ModuleEngines]:HAS[@PROPELLANT[Oxidizer]] That way you can just recurse on down as far as you need to go.

Possibly - I'd actually kind of like to pare back specifics, and just concentrate on the codebase; and let other modders like ChestBurster et.al. actually create new fuel types and cross-mod support.

- Isp will affect thrust instead of fuel consumption - RCS thrusters will have configurable fuel types - Radially mounted heat sinks to keep cryogenic tanks cold(er)

Yep! His implementation was beautifully straightforward, so I'm just going to translate it over and make a few simplifications in the places where my mod has already done half the work.

Just FYI, ModuleManager is no longer under development; the latest version is considered "stable", and no new versions should be released unless a future version of KSP horribly breaks something. (This is one of the major reasons why I don't want to add wildcard functionality).