Temeter

Interesting. I wonder if current radiators work too?

That sounds awesome! I've read about ServiceModule tanks being better at protecting cryo fuel, maybe it's included there? Assume it would need special ressources for cooling, too (would be cool too!). Well, off to annoy nathan with questions!

Honestly, I don't find the size to make it harder to use in RSS/RO. Your rockets are bigger anyway, and having a huge Liquid-Hydrogen stage isn't much of an issue in a 10m rocket. Baloon-Cryo-Tanks are afaik even a bit more light in RO, aren't they? That said, the boiloff is imo the true culprit. Makes LH2 almost impossible to use on the long range missions you'd use a nuclear engine for. RO does provide a config to use Ammoniak tho, which has basically no boiloff in a cryo-tank on earth's solar orbit level. 'Only' 1100 ISP, but that's quiet neat, too.

Can I just manually apply the update when using Realism Overhaul? Nvm, just done it and it works. Thanks, I'm warming up to the system, but it's always good to haves settings to just put slight brakes on the realism.

Nice, sounds like Squad really took some good inspiration. I wonder in what direction RealHeat will move. Also yay for jool aerocapture!

Yep, can confirm. I had a problematic capsule that survived a lot longer without timewarp. Btw, out of curiosity: Doesn't this mod kind of overlap with Deadly Reentry?

No, you can save and load during burns just fine, it even reliably works during ascent in low kerbin atmosphere with large rockets and mach effects. Not sure about the way KSP handles this, I think the engine is basically shutdown on reload and then instantly activated to the level it was during saving (it takes the fraction of a second to start burning). Which I could imagine easily conflicts with the Ignitor. Found that feature, as soon as it was implemented, to be very useful when trying risky stuff/different maneuvers in atmosphere, as well as a way to make sure you're not loosing too much time if the last part of a 30 minute burn misses the target. Makes it of course really usefull for RSS/RSS, since they tend have a lot longer burns. Reading the correct part of the Real Fuels Thread would have helped me a lot.^^' In my defense, it's quite easy to overlook for such an incredibly important element. Personally I would have liked a small explanation how much ullage thrust/T-W/acceleration time is needed (in combination), maybe examples. There are too many variables to be intuitive: If I have a 100 Ton interplanetary stage, how much ullage thrust do I need? What if the tanks is half full? A quarter full? How much difference does a service module make, if it makes any outside of pressure-fed hypergolic engines. What about smaller crafts, how does what engine (on what tank?) influence the equation? What goes for multiple tanks? Can I put a small service module at the bottom and a baloon tank above it, would that be an exploit? I'm not sure how the system works, but, outside of the engine ignition indicator, some percentage how 'ready' a tank/engine is to ignite would help alot, so I could follow how much difference my RCS makes, even if i have too little (or is there no too little and it's only a matter of time/acceleration?). The whole thing just doesn't feel that intuitive right now, there are so many question. Which is why some transparency, e.g. in the form of a settling indicator, would already help a lot! Could also tell beginners that there indeed is something like ullage.

On reloading all engines instantly shut down (flameout), which basically left my rockets stranded during experimentation. After that I also had some issue with figuring out RCS tanks, which made testing even harder, until I remembered and checked the service-module tank. Was just a bit frustrating until I figured out the details (especially considering getting into space takes a bit longer anyway). More optimistic now. edit: Jep, now it works. Made a mistake staging my rockets upper stage (120T), and managed to ignite it via RCS. Guess Forward RCS is just more important now. Much better now, I like challenges when I can understand the rules. External Ignitors would be awesome! Just wrong terminology, I ment the fuel pushing against whatever place its needs to be for ignition.^^

Am I right in my assumption that 'service module' tank configs are the ones that actively preserve the pressure? That should solve some problems, might make some nice starter engines... edit: No, doesn't work either. Still learning, but personally can't really say I'm enjoying the Ullage system. How does an Ariane upper stage then deal with multiple ignitions?

I'm a bit at a loss. Do real rockets really work that way? If yes, how does an Aestus 2 restart it's engines, considering it's a full blown, if small, upper stage? That things has 15 ignitions! Or the moon lander, which had seperate burns. Latter two use hypergolic fuels, which afaik are easier to restart (yeah i know they still need some kind of ullage)? Doesn't seem to be simlated, tho... Also, is there some way to restock ignitions for multi-use craft, e.g. with KAS? Or is it just a theoretical design limit (in which case it should be risky, but possible too ignore the limit )? While I'm also a bit skeptical about the whole thing, i'm curious about the challenge. Just hoping it'll be one that's possible to overcome. edit: Seems like the ignition automatically kills engines after reloading?

Awesome! Thanks for fixing it so fast.

Thanks again, this time to Ferram, that's a lot of interesting stuff. Well, stuff that goes wrong, but it does create the picture of a solution that creates more issues than it solves. Guess we'll rather have to put our hope in the upgraded version of Physx! So that's actually one of the versions that were ancient the day it was written? As noted, there were a lot of speculations Ageia just used outdated code so you absolutely need their cards to have any resonable amount of performance using the effects. Compared to the version unity 4 uses? Definitly! It's about time for an upgrade. Luckily the current version turned out to be good enought for most more reasonable projects, but KSP is often enough about getting a step further.

Thx for the answer, so there just isn't enough movement into that direction. I really hope one day devs finally figure out multithreading, it's lack is kind of a serious issue in many CPU-heavy games. Not only physics, but also stuff like pathfinding did cripple some RTS like SupCom. :/

3k D/V really are decivingly little when you're lifting a single capsule. And yeah, i's pretty easy to get to Kerbin orbit. It's a single Kerbal capsule, tho.^^ For bigger parts, take a 2.5m capsule and put a LFB below it. Congrats, you have an orbit capable SSTO!

It's the same. NVidia bought Ageia when the crappy physics-cards didn't get anywhere, put PhysX chips on their cards and tried to use it for marketing purposes. Besides the chip, PhysX is a real physics engine. Pretty crappy at the beginning, apparently also too excacerbate the need for special chips and using very inefficient code. It's supposedly quite fine now and used by a number of games as a more general concurrent to engines like Havok. PhysX-effects are still somewhat of a marketing gag, but games like KSP don't even profit by NVidia GPUs. Long story short, Unity licensed PhysX as it's prime physics engine and integrated it into their engine.

There is one thing I don't understand: Why can't you just e.g. 'cut' a ship in two pieces and then let two threads (or in reality cores) calculate each half? KSP's tree structure means normally parts only have single connections. Shouldn't it be possible to make some process communicate said connection between the two threads? Maybe it would be somewhat more lenient or slightly lagging behind, but, without coding knowledge, it's hard to imagine what could go wrong in this case. I mean, if we can communicate a thousand boxes touching between multiple cores, why not a single connection?

The aerodynamic indicators are sometimes bugged for radial parts. Rather check the debug menu's aero context info/FARs Drag Highliting.

The bigger radial tanks are quite dense and he has an inline tank below the relatively light capsule. You'd get even further if all that weight was used for LFO-engines.

I would love to use them in some way, but they are just worse than any other engine. And still far to large.

Thanks, good to know its in the works! Sounds like there might be general issues with the game itself, tho, even people not using FAR have reported issues. Check Ferrams Post!

Do you use FAR? I've got a similar issue and it just goes away after removing the mod.

Maybe the CoL moves in front of the CoM at high inclinations? Check it in the hangar by tilting the craft and watch how the markers are shifting. Or try moving the wings back further, solved the issue when i encoutered it.

Awesome! Thanks for the update, now I can finally corectly install AJE and try doing a real spaceplane!

Probably even made sense when KSP was smaller and had Kerbin and a single moon. Now you'd need, even without Delta-V, remember/write down lots of numbers, thrust to weight ratios, and make lots of estimations. It's gotten kind of tiring to do so much complicated guess work considering it was originally for the sake of simplicity. The whole 'no dv' thing is something for a very dedicated and special kind of hardcore-player not too interested in realism. I don't think there are many arguments not to include Delta-V, at least after the career's early game.

Fixed posts, checked a bit more: The heat only happens as soon as the launch clamps are decativated, the engines by itself run correct. The few heat radiators that survive after detaching clamps jump down to 23 kelvin. Definitly some kind of bug... Behemoth Mod has been updated and otherwise works fine (large SRBs get hot but never explode, engines stay at reasonable temperatures). Found a lot of other and partly similar issues in the support forum. Seems like an issue of the game. edit: It's possible to fix it by switching all temp(ext) Infinites to reasonable numbers, because then radiation/timewarp can actually kill the heat, no matter how ridiculous the numbers are. Makes me wonder why it switched to infinite in the first place. edit2: Seems like there is also a (connected?) bigger issue with external part temperatures not being found (or not being defined?). It's spammed in the debug menu and, as long as heat convection is enabled, utterly cripples the framerate/simulation. Gonna be a nightmare to find out what is happening.