Scialytic

Quick update: it seems like the performance problems scale with the number of emitters not particles, and it doesn't make a noticeable difference whether or not they are active. Most likely, there's something screwy going on in SmokeScreen. I'll try to figure it out and fix it when I get a chance, but I need be clear that I don't expect that to be anytime soon.

I didn't write that config although it is a fairly complex one. perhaps @Scialytic can take a look at some optimizations in the future? I'll put a copy of the old config in the folder for the next update so people who have trouble with it can revert to it (by deleting the current config and renaming the extension of the old config). But the current one will remain the default. I'll take a look the next time I have a decent block of free time. The thing with the RAPIER is there's 4 nozzles per engine, so whatever the threshold for "too many" particles is, you're going to hit it faster than you would with most other engines. Emission can only be reduced so much before the plume visually breaks down into distinct particles. @EdwardB3020 can you give me a sense of how many RAPIERs you're trying to run at once?

Sorry, @Drew Kerman, it was just an oversight on my part due to inexperience. It didn't occur to me that other mods might rename ModuleEnginesFX. For a quick fix, just replace your RealPlume/000_Generic_Plumes/Methalox_AirBreathingMode.cfg with the file from https://github.com/Scialytic/RealPlume/raw/master/GameData/RealPlume/000_Generic_Plumes/Methalox_AirBreathingMode.cfg @Zorg PR submitted.

It's taken longer than I anticipated, but after a couple attempts I scrapped and some lessons learned, I've arrived at a RAPIER plume setup that pleases me. This is a significant departure from the old config, and incorporates some features that (to my knowledge) have not been done before. The ClosedCycle mode plume is standard usage of Methalox_LowerShock, so I'm going to focus on the new AirBreathing mode plume. In the following pictures, I'm using the SmokeScreen GUI to show how the AirBreathing (left) and ClosedCycle (offset right) plumes look under various conditions. One note is that the black background helps the plumes stand out clearly, but it can make them look more opaque than they really are. At the end I'll show how it looks under daylight flight conditions. The first picture is all sea level pressure. The last frame, Mach 3.75, is not a circumstance one would normally encounter, but I wanted to include the most extreme form of the plume just to show that it doesn't break. Stationary: AirBreathing mode thrust is roughly 60% of ClosedCycle mode thrust. Mach 0.7: approximately equal thrust. Mach 1.2: AirBreathing mode is hitting its stride now. The bypass ramjets have come to life. The ramjet plume is more noticeable in game because of the movement. In the picture it's kind of faint, but I didn't want to overdo it. Mach 1.5, 2.0, 2.5: thrust continues to grow. Mach 3.75: maximum thrust. As mentioned earlier, this is at sea level pressure, so far from normal flying. The second picture shows something closer to how a typical spaceplane might fly on its way to orbit. 65% atm: shock cones fading just like in Methalox_LowerShock. 45%, 25% atm: the "fume" component determines the size of the plume now, so that's independent of thrust, but it will be brighter & fuller or dimmer & wispier according to thrust. Mach 5.5, 5.76, 5.86: AirBreathing mode loses power sharply above Mach 5.5. In the beginning, this was actually the primary thing that motivated me to redesign the RAPIER's plume. I wanted to see it losing thrust instead of just watching a number decrease. I'm particularly fond of the fact that I was able to do this algorithmically within the new generic plume cfg. So it should be easy to reuse this plume for RAPIER-clone engines from mods. As long as it follows the same basic format (8-key velCurve; 5-key atmCurve) the plume should automatically adjust itself according to the host part's velCurve and atmCurve. I meant to post something sooner, but I had some false starts and then I fell victim to "just one more tweak." Feedback is very welcome. I can still easily change anything as I have not cleaned up the cfgs yet.

You're entitled to your opinion. I suspect the "argument" you have in mind is beyond the scope of my words and intents. In any case, I don't share you perspective. There are many different possible fuel and oxidizer combinations, and almost all have lower ISP than hydrolox. To me, it would feel arbitrary to single out a specific one without any particular reason. Official art is a very flimsy reason, but it's still better than nothing. I don't really have a plan for which (or how many) engines I will work on, but I like the idea of using hydrolox for more efficient RAPIER-like mod engines. If you are thinking of submitting I'll remember to hold off on those to avoid duplicating work.

But is there any known hydrolox rocket where the result of all such factors is a plume that looks purple (and a pinkish sort of purple at that)? I framed it as "the newest art [...] seems to depict" because of considerations like these. I don't want to be unduly argumentative here, but I feel you're unfairly representing my post. I believe I was quite clear in angle 1 that the real SABRE is a hydrolox design. However, the RAPIER is not identical to the SABRE, so there are other considerations one might want to include. The other two angles are just that: different ways of looking things that lead to other plume options. I never stated, nor did I intend, a positive claim that REL has actually switched to methane. Even in angle 3, I said methalox "could work as a compromise between the theoretical design and the in-game stats" not that REL is really going that route.

Are there any hydrolox rockets with purple plumes? That's an honest question; I'm genuinely interested.

The plume color

Sounds good. I'll post some preliminary pictures when work is further along.

I've started work on updating the RAPIER plumes, but the more I think about it, the less certain I am about how it should be. The current setup uses Turbojet for AirBreathing mode and Hypergolic-Lower for ClosedCycle mode. Those choices were made quite a long time ago, and the available plume options have expanded significantly in the years since then, so perhaps it's time to reconsider the plume. I'm very interested in how Zorg (and anyone else) sees it. Consider this post just me thinking out loud; I'm not married to any of these ideas. Angle 1: It's RealPlume so make it look like the real engine. Okay, SABRE doesn't really exist, but it has been described with enough detail for our purposes. It's a hydrolox rocket with air bypass ramjets. Design the plumes to match that, and don't worry about the engine's in-game behavior. Angle 2: The current setup makes sense for the RAPIER's in-game stats. 305 s vacuum ISP is pathetic for a hydrolox engine, especially one at the end of the (stock) tech tree. Insert tangent debating whether KSP "liquid fuel" and "oxidizer" are best understood as hydrazine and nitrogen tetroxide anyway. Therefore, just update Hypergolic-Lower to one of the newer hypergolic plumes, maybe tweak the Turbojet settings a little, and leave it at that. Angle 3: The newest art from Reaction Engines Limited seems to depict a methalox setup. Perhaps basing the new plumes on that could work as a compromise between the theoretical design and the in-game stats?

If this looks good, I'll clean up my .cfgs and submit a PR.

I originally started tweaking/updating some configs for my own use. I feel like they are turning out better than I expected, which made me consider they might be good enough to submit. Feedback is very welcome, and of course if they're not wanted that's fine. The LV-TX87 "Bobcat" is inspired by the Aerojet LR-87, so I went with Hypergolic_LowerRed(_shock): The KE-1 "Mastodon" is inspired by the mighty Rocketdyne F-1, so Kerolox_LowerFlame seemed appropriate: This last one still needs work, particularly in how it changes with decreasing pressure. The wiki says that the T-1 Toroidal Aerospike "Dart" is inspired by the Cesaroni Technology, Inc.-produced aerospike nozzles used in the Dryden Aerospike Rocket Test, but those were solid-fueled and thus not a good basis for the Dart's plume. So, I grabbed some reference material https://imgur.com/a/CuvYHUb and tried to focus on common features. This is derived from Hypergolic_LowerOrangeShock, but has been significantly modified. It arguably uses way too many particles. Is there an accepted/recommended limit on how complex one plume can be?

The "Deleting all craft files that contain the string "SSTO"..." loading tip naturally got me wondering what a rocket SSTO would be like in JNSQ. Since I'm waiting for the hotfixes and Kopernicus updates to finish their churn before starting my proper campaign anyway, I figured I'd take a stab at it. I normally play with FAR so if I've made any obvious stock aero mistakes, that's why. I understand that FAR tends to slightly reduce the delta-v required for ascent, and it seems like Team Galileo has stock aero in mind when making/balancing JNSQ, so I omitted FAR. Full album: https://imgur.com/a/s1vzblo TLDR version: I must say, I had a blast. I can't thank Team Galileo enough for this mod. It's almost like being a new KSP player again.

My thanks to Team Galileo for this wonderful mod, and congratulations on this impressive achievement. I'm waiting for the BG/Kopernicus situation to settle down before starting a new campaign, but I've played around a bit in the initial JNSQ release and it seems quite awesome. Speaking as a TAC-LS player, the Life Support Monitoring window does not account for recycling, so it's not something to rely on even in an otherwise stock game. For JNSQ, I think the easiest option for short missions is to mentally halve the life support time estimates it gives you when allocating supplies in the VAB/SPH. For longer missions where the mass of recyclers is justified, you'd need to do your own calculations anyway.

Thanks for making this. I noticed a typo/bug in RcsMp4.cfg: line 191 sets the MP4 RCS unit's vacuum ISP to 70 instead of 270 like the other MP# RCS.

That depends on your definition of "better." Adding more LV-Ns, (or replacing them with higher TWR engines) will improve your acceleration at the cost of needing more fuel for the same delta-v. Duna isn't hard to get to; you don't need to maximize efficiency if you don't want to. For munar missions perhaps, but not for interplanetary. Credit to MarcRan17 for this graph:

I use some batch scripts to handle my saves. I'm not sure if they are of interest to anyone else, but I'm posting them just in case somebody finds them useful. I use winrar but they could easily be modified to use 7zip or whatever. "clear-world.bat" and "archive-saves.bat" are stored inside the KSP root directory, so I can run them just by double-clicking. "archive-ksp.bat" is stored in the same directory as the KSP root folder. clear-world.bat ~ Restores everything in the default save (including Kethane) to the brand-new state (as if this were a new KSP install) @ECHO OFF pushd ".\saves\default" del /Q *.sfs "C:\Program Files\WinRAR\RAR.exe" e "..\..\saves [clean].rar" "saves\default\persistent.sfs" popd pushd ".\PluginData\mmi_kethane" del /Q Deposits.dat "C:\Program Files\WinRAR\RAR.exe" e "..\..\saves 2013-04-20 #01.rar" "PluginData\mmi_kethane\Deposits.dat" popd archive-saves.bat ~ Creates a new archive of all the saves, including plugin state files. The file name is dated and numbered automatically. @ECHO OFF SETLOCAL set rarcmd="C:\Program Files\WinRAR\RAR.exe" a -rr3p -k -m5 -md4096 "-ag{ }YYYY-MM-DD{ #}NN" %* :archive ECHO %rarcmd% for /D %%X in (saves) do %rarcmd% "%%X.rar" "%%X" ".\PluginData" :end ENDLOCAL archive-ksp.bat ~ Creates a backup of the entire KSP directory. I use this before major upheavals, such as upgrading to a new version of the game. @ECHO OFF SETLOCAL set rarcmd="C:\Program Files\WinRAR\RAR.exe" a -rr3p -k -m5 -md4096 "-ag{ }YYYY-MM-DD{ #}NN" :archive ECHO %rarcmd% for /D %%X in (KSP_win) do %rarcmd% "PUT_YOUR_BACKUP_DIRECTORY_HERE\%%X.rar" "%%X" :end ENDLOCAL

If you're considering that much effort, you might as well just test it empirically in the game. With an approximate gradient-descent approach, you could figure out the optimum altitude to start pitching over in relatively few launches (depending on how precise an answer you want).

I recommend the "Cubic Octagonal Strut" part. Remember that the intakes just need to be facing the correct direction; it doesn't matter what they are attached to.

This is true in the special case of equatorial orbits. More generally it is the normal or anti-normal vector you want to align with.

It depends on your priorities. For your convenience, a major consideration is that you need to be above 120 km to enable 100x time warp (although that can be circumvented by switching to another vessel). For maximizing efficiency, lower is better. With practice, docking at any altitude is easy so that shouldn't be an issue long term. Back when I was first learning docking I put things over 200 km, but now I put any Kerbin-based refueling craft at 75 to 80 km. That said, I haven't done much LKO refueling since I installed the Kethane mod. I have a Minmus mining & refining operation going, which now serves as my primary orbital refueling point.

If it got all the way up to 250 kN, I think the video must be from an older version of the game. The part.cfg maxThrust is now 225. As EndlessWaves said, the thrust follows a velocity-dependent curve. Also, the Isp changes based on air pressure.

Spaceplanes are particularly tough to give guidelines for, even more so than rockets, because people's subjective preferences about part count, handling, and aesthetics play a bigger role. One person's ideal is another person's rubbish, and big SSTOs will force you to make hard choices. That said, here are some tips based on my experience building interplanetary SSTOs: 1. Iteration is very important. Don't try to get everything right all at once. Test and refine. Test and refine. 2. You want just barely enough turbojet engines + wings to takeoff and ascend using only jet power. In my experience, this typically means 4 turbojets for a Mk1 or Mk2 cockpit-based design and 5 or 6 turbojets for a Mk3 cockpit-based design. So basically, once you have settled on a number of turbojets, add wings and canards as needed until it just barely flies. It's hard to describe, but the handling should start to feel good at around 10 to 15 km altitude. 3. I usually end up with designs that takeoff by running off the end of the runway. This is mainly a symptom of the center of lift being quite a bit behind the center of mass. My reasoning is that takeoff is much easier than landing, so I design such that the handling will improve as fuel burns and the CoM moves rearward. When you think you've got it right, test landing from orbit on empty tanks. 4. Use only ram air intakes. Start with about 5 ram air intakes per turbojet, and add more as needed. I usually end up closer to 10 per engine, but it varies. This is generally the most grueling part of testing for me. You want just enough intakes to get you above 2100 m/s using only turbojets. Given your low TWR, this requires you to be quite high (typically well over 30 km, otherwise your acceleration is too slow and you waste a lot of fuel). Finding the right ascent path can get quite time-consuming, but it can yield really impressive results. 5. In almost all cases, a pair of LV-N engines should serve as your main rocket engines. I like to supplement them with a pair of aerospikes, primarily for takeoff on Duna. Plus it's nice to have the option of some extra kick when you want it. During ascent, I usually run the aerospikes for a few seconds when transitioning from jet to rocket power. Some people really seem to like the Rockomax 24-77s, but for heavy SSTOs I don't (they are great on small vehicles though). Keeping the part count down and maximizing Isp are your top priorities. 6. I've seen people really overdo the landing gear. 3 is all you need on most designs; maybe 4 or 5 if it's really heavy. 7. Make sure you have the right ratio of liquid fuel to oxidizer. You'll be surprised how much fuel 4 turbojets burn though, especially if you're visiting Laythe. Also, a little excess fuel makes landing on the runway at KSC easier when you return; excess oxidizer is completely useless. I hope that helps. Good luck.

Apart from abusing quicksave/load, I have not found a good way to aim precisely enough at non-trivial distances. E.g., if you are 10 km away, 1 degree of aiming error means you'll miss the target point by about 175 meters -- and that's assuming the missiles fly perfectly straight.

Like a tessellation?