Randazzo

I highly suspect that if humans ran into real kerbals, the meeting would be something like this:

R.A.P.I.E.R. engines are easy and convenient, that's all. Even a blockhead like myself can eventually brute force an SSTO using them with a little practice.

Was somebody doing science?

This is demonstrative of the many varying play styles we have in this game. Personally, I would never consider the time required to complete a mission as a variable thing. It is set in stone. It takes Y amount of time to get to Z and back again. That is how long it takes, period. From this (my) point of view, most life support mods function in such a way that it really is just adding mass, because you must add X amount of mass to last Y amount of time, and time is set in stone. That has been my past position. Since I've been playing around with USI life support, I'm coming around to the idea of a stock system that works in a similar fashion. It's not just adding blocks of life support to last a certain amount of time (though you can use that method if you want), but it offers lots of options like recyclers and habitats that can also act as recyclers, greenhouses, etc. With the new(ish) upgrade system we have available in the stock mechanics, this would allow tech upgrades to existing parts (such as capsules or the hitchhiker and other crew parts) to extend the life support without just being "X mass for Y amount of time". Coupled with being a difficulty option that can be switched off, stock life support isn't such a big bad monster after all.

There are 28 patches that run after zRealPlume. That's why I put the final on there, thinking it will run last, after zRealPlume. Since it didn't work for Nnimrod anyway, it's irrelevant, but (naturally) you are correct and it runs fine with the final tag removed.

Edit: Nevermind, I'm done with this.

As long as you're getting the desired end result, run with it. Is there a correct way to specify that it needs to be applied after all other patches that apply themselves after zRealPlume? Just FINAL? I mostly fumble my way through these things and if something works I just go with it.

It seemed horribly complicated late last night, but it isn't really. The problem is simply getting the patches to execute in the correct order. The short of it is that 000_zRealPlume runs after the effects remover runs, so running your patch after zRealPlume prevents your effects from getting removed. Running AFTER[zRealPlume]:Final allows you to change the audio after applying a RealPlume plume to the engine. You could write a new plume definition, but that's just manually doing what the sound patch is correcting when run in the correct order. Edit: I think it is pertinent to some participants to point out that the issue here revolved entirely around trying to mod around another mod. There is no direct issue with using custom sounds.

OK. It's 1am and I don't have the brainpower to test anymore, but I do have a working solution. I used two configs. Yours, slightly modified: And mine, again, slightly modified: This gets the sound on the engine but there's some issue with the loop. If you throttle the engine down, the sound keeps playing. I'm too tired to figure it out. The key things here are: Don't run your config :FINAL. Let it run like a standard RealPlume config. Mine has to run AFTER zRealPlume (which is another cfg file..yeesh) and it must be final. I don't know if you can successfully combine these into a single patch or not. I'm going to bed. Good luck. Edit: I suppose it would help if I tagged you first.. @Nnimrod

@Nnimrod There's no need to add sound_ in front of the filename. When you see that, it's referring to the stock sounds in the squad folder, and the files are named in that fashion. What's foiling you (and me) is RealPlume. It has a config set up to run after RealPlume itself (look in the 000_ Generic_Plumes folder) that is deleting all extraneous effects from any part with a plume. So regardless of what you add, it's getting wiped. I might have a way around it, still testing.

Since you're using realplume, you won't want to use the effects I posted. Realplume overwrites all of that once you add a plume. Good luck with this. Maybe Sarbian can help you better. Edit: Now I have an idea. Testing.

@Nnimrod There's so much going on there I really don't know where to begin. You definitely aren't getting the correct result from this. There is some stuff I'm guessing you just copy and pasted in there (like the effects I posted) but you really can't do that and get a working result. My honest advice is to scrap that frankenstein config and start over with something simple, then build on it as you get it working. Try starting here: @PART[rn_aerobee150_eng]:AFTER[RealPlume]:Final { @EFFECTS { @Hypergolic-OMS-Red { @AUDIO { clip = RealPlume/Felger_FX/RS25loop } } } } I am making some assumptions here, based on your config: that you use realplume, that this engine has an existing realplume config, and that in this existing realplume config this engine is assigned the Hypergolic-OMS-Red plume. Since RealPlume is going to overwrite any changes made to the engine with it's own config data, you need to let it do it's thing then change the sound for that engine.

Do you have the sound set as the running effect in the engine itself? MODULE { name = ModuleEnginesFX thrustVectorTransformName = thrustTransform engineID = VAD125A runningEffectName = running_closed <--- This line exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 350 heatProduction = 250 EngineType = LiquidFuel PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 295 key = 1 280 key = 9 0.001 } } Perhaps it bears mentioning that you must use a complete effects setup and use ModuleEnginesFX to use custom sounds, meaning you cannot use a vanilla particle effect setup and ModuleEngines alongside custom sounds. So you need something like: EFFECTS { running_closed { AUDIO { channel = Ship clip = sound_rocket_spurts volume = 0.0 0.0 volume = 1.0 1.5 pitch = 0.0 0.2 pitch = 1.0 0.7 loop = true } PREFAB_PARTICLE { prefabName = fx_smokeTrail_light 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 localPosition = 0, 0, 5 } MODEL_MULTI_PARTICLE { modelName = Squad/FX/ks1_Exhaust transformName = thrustTransform emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 0.5 speed = 0.0 0.5 speed = 1.0 1.2 localPosition = 0, 0, 0.2 } } 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 = thrustTransform oneShot = true } AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } coupled with a ModuleEnginesFX node as above.

If we're referring to SSTO fully recoverable space planes, the only difference is that you get the space plane back at the end of the mission. This does reduce funds costs. However, you will discover that saving funds costs you time, since you have to fly the plane back to the runway. Simple orbital missions will now take twice as long at a minimum versus disposable rockets. So if the trade-off is worth it to you, then SSTO Space planes are worth doing. I always end up getting tired of constantly flying them back, personally.

I'm sure you mean well, but Module Manager in fact belongs at the top of every list, because as you said, virtually every mod uses it in one way or another and it is arguably the single most important piece of software that exists in relation to modding KSP.

"Oops."

I've always gone to the Mun first. It's just the most obvious target. Plus it has the allure of going to the "Moon", arguably the most well-known missions of human space flight.

Scathing reply at the ready, but uncertain of intent. Possible sarcasm. Am confused. This thread is a delight of exploding rails.

it is my understanding that using mesh simply takes the first .mu it encounters in the directory regardless of the name you enter in the cfg.

@Esquire42, first let me put this disclaimer up here: I haven't actively developed anything heat related in a long time now, so some of my information may be out of date. The definitive man to ask is @NathanKell if he's lurking about and feeling generous. A couple of issues you're going to face: Heat tiles - radially mounted (which is anything not stack mounted) parts do not (or did not) occlude their parent part from airflow. I believe (possibly incorrectly) that using electric charge as your sole ablative resource will result in no heat being lost as the EC "ablates", because EC has an undefined specific heat, or it is 0. Heat Control uses a plugin written by Nertea, which is certainly an avenue you could look at if you have the chops for it. I didn't. Active Heat Management is a hatchet job on stock modules, but by all means use anything you find useful. The comment I made was just about the name and that particular sentence I quoted.

It could if you used it like a heatshield, but that's neither here nor there. P.S.- I wasn't complaining.

http://forum.kerbalspaceprogram.com/index.php?/topic/142505-12-active-heat-management-system-031/ Sounds familiar.

Looking forward to seeing these parts!

If you're on PC and have a scrolling mouse button (I think that's fairly standard these days), you can hold down ctrl and scroll the mouse wheel to resize your browser text on the fly. Dunno if this is necessarily your problem, but it might help to make it a little bigger. And to be clear, it actually makes everything a little bigger/smaller, not just the text.