NathanKell

Maxwell Fern: Apologies. I updated the link in the OP but forgot to do so for the readme. Yes, you are correct about what changes. (The correct link is https://raw.githubusercontent.com/NathanKell/RealismOverhaul/master/RealismOverhaul/RO_DRE.cfg ) TheDamDog: Starwaster mostly answered this. To confirm, none of that has anything to do with DRE; DRE merely lowers part temperatures. It uses the same code SQUAD does to destroy a part when it is over max temperature (you can overheat and destroy things in stock KSP, just reentry doesn't add heat). Can you reproduce this using only DRE? technion: pic of the craft?

Noooo you removed the DLLs! I've been getting "nightlies" that way Even inspired me to start including DLLs in *my* repos. Really looking forward to the full flowering of the atmo shader! Also, I do want to second pingopete's point about the normal maps. Even if you just do if(light_facenormaldot > 0) normal = texture_normal it will still look better than no normal map at all. Especially in RSS, we *need* normal maps :\ (But I don't want to give up cities! So...)

Are you using .24 or .23.5? RO is not available for .24 yet.

This is because the "fix" to the "trying to load modules but they're out of order" issue breaks things pretty much as severely.

Indeed it should! Here is where it belongs, and here is where you're most likely to get (more, awesome) contributions!

Thanks! You can do that by reading the OP and/or readme; both very prominently describe how to do that

The real kicker is that in KSP, drag decreases with density, but jet thrust does not. That is the key problem with KSP's jets. Someone should make a counterpart to AJE as NEAR is to FAR: SJE. Simple Jet Engines. It would simply vary jet engine thrust based on density.

Heeey, now we can make the Mercury retro pack have its little prograde thrusters too. Cool!

Taverius: an issue I noticed with some of your MM patches. You do both a FOR and an AFTER. You can only use one pass argument on a patch; if you include multiple ones, then the patch will be executed whenever the first one trips. Indeed, it was considered to count as a malformed patch any line containing multiple pass arguments. Consider this patch: @PART[NP_zmisc_B5_Fin]:FOR[TVPP]:NEEDS[NovaPunch2]:AFTER[FerramAerospaceResearch] { @mass = 0.028 @breakingForce = 90 @breakingTorque= 90 @fuelCrossFeed = True @dragCoeff = 0.63 @deflectionLiftCoeff = 0.56 %MODULE[FARWingAerodynamicModel]:NEEDS[FerramAerospaceResearch] { %name = FARWingAerodynamicModel %MAC = 1.363 %e = 0.7 %MidChordSweep = 12.77 %b_2 = 1.873 %TaperRatio = 0.524 } } If a user has FAR installed, it will be executed long before all your other FOR[TVPP] patches, since those won't be executed until the patcher gets to TVPP, and any AFTER[TVPP] patches will execute long after this did, since it was executed in the FerramAerospaceResearch pass (although the AFTER segment of that pass) If a user doesn't have FAR installed, it will be executed along with the other FOR[TVPP] patches. If this is not intended behavior, you need to use a different method...

Or you could do a bit of a search and find that bac9 and Taverius (the authors) are indeed working on an update.

krenshala: no, you don't know for sure that DRE caused it, since it is a stock x64 bug that appears somewhat randomly. DRE does nothing to decouplers. Please don't go accusing me of breaking things when a 30 second search will prove it's a stock bug, mentioned on the official x64 bugs thread. Oinker: those costs make sense. I will try to remember to move the 2m and 3m over to Realism Overhaul. Although I hasten to point out that many, many people use Procedural Parts (and used StretchyTanks) on non-RO installs, and therefore those parts have a use for them too.

Basically, you can *never* make jets perform correctly with the stock engine code, because the stock engine code is written for rockets, not jets. KSP jets are air-breathing rockets, not actual jets.

I'm trying to get the things I made myself working. I haven't had a chance to do much with this yet, sorry. I will get to it though. However, the only thing asking "are we there yet? are we there yet?" does is make me take time away from coding and invest it in forum posts The only thing the pull request does is add support for compiling on OSX. I have tried this with the latest KAE and it still spews errors to log and behaves oddly at times, and is therefore not ready for release.

frizzank, it *almost* made it into .24. If we do manage to convince them to do .24.1 (since there are some really severe bugs with .24) that fix should get in.

Proc fairings are not so much about decreasing drag as about making your payloads not screw too much with the aerodynamic center and make your rocket unstable.

Check attach erroring is probably something that activates OnPartAttached or something, like RF (via KAE).

You already *have* the deprecated parts. That's what it means. deprecated, not removed. So copying them in will only mess things up because then you will have duplicates. Instead, change category = -1 to category = Aero that will put them back in the partlist. Also change the TechRequired, as you did. Note that KSP loads all cfg files in GameData, no matter where they are (unless they're under a PluginData folder). Same is true for models and textures. Only after loading everything does it (a) process the cfgs and ( hook the models and textures together based on what's in the cfg.

Sandworm: sounds like you have a mod that is not using the dll I just released.

https://github.com/NathanKell/DeadlyReentry/releases And yes DREC v5 is for RC 1.2+

Yes you do. "0.24.1 fast!"

Changelog: v5.0 *Now will cut chutes when they burn up, rather than destroying the part. Max chute temperature defaults to 1/2 part max temperature *Fixed issue with RealChutes compatibility - thanks to stupid_chris! (Also the RealChutes-compatible version of the above feature)

Stock bug that they were going to fix for .24 but didn't. Hopefully there will be a .24.1 and the fix will be in it.

I will just point out that the *meat* of the information is in the anonymous ID and the session data. For example, consider these use cases. 1. RSS uses a ton of memory. I want to know if my user base is mostly running 64bit KSP now. I can find that out with ModStats, and if almost everyone uses x64, I can not worry so much about memory usage. 2. Do people with the RO suite of mods have longer load times than usual? Which mods in that suite cause the longest load times? I can find out with ModStats and then prioritize speeding up the slowest. 3. With all the parts and fiddly bits added in the RO suite, do people spend more time than average in the VAB and less time than average in flight? 4. What is my turnover like? Do people try the RO suite, find it too challenging, and quit, or once they're hooked do they keep playing? With ModStats I can find out, and if necessary make changes. 5. Are people missing some required mods? If people have most but not all of the RO mods, for example, that means the odd mod out needs some work, maybe. ModStats can tell me. Pretty much all these require a persistent (though totally anonymous) ID across sessions, all of these require some metadata (like what version of KSP, and therefore which OS), and none of these reveal anything damaging. Unless that's information that should default to not being available to me? None of my mods include ModStats yet, but these use cases are very appealing, as I hope you will agree.

Not a bug. It's due to how FAR and NEAR handle drag calculation. NEAR detects flat areas by looking for attach nodes that don't have anything attached to them. This is why a nosecone helps: it closes the open node on the top of the rocket. However, the open node on the bottom of the capsule is what stabilizes it. If you close the node by attacing something to it (even an antenna) then NEAR no longer detects it as an open node. Also, welcome to the forums! As for providing other information, you did provide reproduction steps, which is awesome! However, even though the output log did not report anything that seemed off to you, you should still always post it, in case the modder may notice something you did not.

Have you checked the wiki on the git repo?