Jump to content

Realism Overhaul


NathanKell

Recommended Posts

Yup. Restarted and it got me too. Unbreakable joints helps sometimes, but it's not a traditional wobble problem, it appears to be float errors--at 6317km, one centimeter is much like another. (Pretty sure PhysX, though not KSP internal calcs, uses floats)

Link to comment
Share on other sites

I guess Minmus can stay where it currently is, although maybe a bit harder to get an encounter.

m89e3hF.png

And Kerbol needs to get bigger too, while going to Minmus I think one of my vessels got a gravity assist from the Mun and now it's going out of the Kerbol system :P

Edited by AbeS
Link to comment
Share on other sites

I don't know how to change it, but ferram is right that the physics do silly stuff with realistic rockets. I tried to put realistic stats on the KerbX Falcon 9 and FASA Titan GLV a few versions ago by hacking part .cfg's, and if I didn't strut every single joint on the structure, something would explode on physics load or early in the flight. As for how a plugin would approach it, I don't know. Are the physics properties accessible to plugins?

Titan rocket use to be larger when it was part of NovaPunch. It's actually scaled down some now to fit the 2.5m stock part standard. I also tryed making it more realistic and had dismal results with the physics system and just decided to go with what felt right and did not explode on launch. You may be better off going with what feels correct than having the actual math line up with real life.

Link to comment
Share on other sites

Nathan, you mentioned the possibility of instantiating bodies. Have you looked into the possibility of maybe duplicating Minmus or Gilly and turning them into long term comets? (where long term = I have no idea how long. Short term enough to be interesting but long term enough to be long term)

Link to comment
Share on other sites

I just launched a Titan-alike last night. Worked ok.

Note that in real life the whole thing massed 3.8t, so I think your version, frizzank, is close to 1:1. (but I thought the old NovaPunch version of Titan was 2.18m, not larger-than-2.5?)

If you're doing 1:1 (which you need to do if you're hauling 4t of payload, not 1 ton which is what 64% scale Gemini would be), then you want a 3.05m diameter rocket with 450Kn thrust (160s-316s) on the upper stage and 2200kn (258s-296s) on the lower.

Link to comment
Share on other sites

Starwaster, that's a good idea. I wonder whether you can just pass pqsControllers as pointers. Gah, *&@#^*&@# C#. In C++ it'd be easy to distinguish.

In C# everything is passed by reference except structures.

Link to comment
Share on other sites

Sweet, so we can instance PQS controllers then I think. As long as they are in different SOIs and gauranteed to not be loaded at the same time, that is.

Also, as promised the Gemini-alike mission:

sxJeZp4l.png

1sMSysBl.png

mU3ndURl.png

0CPUCD5l.png

Since this is a rescaled Gemini with smaller SM, I went with a Titan I-like configuration of smaller upper stage, and added an escape tower. Also, it's all 64%, so I couldn't use the 2.5m FASA engines.

It's taking a lot of getting used to, when to end turnover. I had to burn upwards some in spurts well after I was horizontal because I was losing too much vertical velocity.

Link to comment
Share on other sites

Not planned by me, but others are welcome. It would also involve moving KSC to the Cape, presumably, and be a big hit on memory since we can't as yet _unload_ textures.

Hey ferram, after looking more deeply at the DRE code...I think might be good for DRE (right now temp starts at velocity -275; don't think ialdabaoth had a chance to go further) to just depend on FAR, so we can calculate ballistic coefficient (with, perhaps, a scalar based on 64%-real-size?), lift, etc., and then get an actual estimate of the shockwave and the temperature-on-the-vessel.

When I have a chance I'll read (rather than skim) this, which looks helpful:

FAA.gov - Returning From Space.pdf

But that reminds me, Dragon01, my apologies: you were right in part re: scaling. While it's true that if we scale mass by 1/4 when we scale diameter by 64%, then we keep center of mass correct, ballistic coefficient (which is kg/m^2) will _not_ stay correct.

So...how should we handle this?

Final note: Forgot to rescale Kerbin's ocean. Fixed. Also, Mun rescaled and repositioned correctly. Source and DLL updated.

Edited by NathanKell
Link to comment
Share on other sites

This is a difficult problem. There's an obvious solution of scaling everything 1:1. That would require a bigger VAB, but it's been done. On the other hand, without some sort of "batch rescale" plugin, it'd be a pain to support. Another approach would be to use 64% scale for planets, then re-scale the displays to make it seem like it's bigger. Of course, that'd take a lot of rescaling a lot of hardcoded things (including default timewarp scale), not to mention changes to plugins. I don't think it's an optimum solution for keeping it "100% real".

Perhaps a good compromise would be to keep the visuals scaled down to 64%, but the actual values would be scaled 1:1. Pretty much the only "unrealistic" things would be material density and surface area, and even then, it's just be a visual thing, with everything using RL values. Now, this would work fine as long as we could tell KSP what something's surface area is (or at least what to multiply the value by), as opposed to it being calculated directly from the model. I don't think there's any way to reliably compare a rocket to a planet, so as long as models are completely separate from in-game calculations, it should work.

Link to comment
Share on other sites

When I have a chance I'll read (rather than skim) this, which looks helpful:

FAA.gov - Returning From Space.pdf

That is some mighty interesting reading material you got there. Can you indicate where you got them from, as permutating the adress is not getting me anywhere useful. Just the FAA website is a bit too generic :)

Edited by Camacha
Link to comment
Share on other sites

@Starwaster....That really stinks. :(

Something going around; just lost one myself. Least it was a storage drive.

In other news, I think I have working DRE: I scaled heatmult down to 8 (from 25) and it seemed to work fine for a Mercury-esque reentry (it's from the Gemini pod, but it's scaled to Mercury size, and I did the 168m/s retro kick of Mercury from MA-6's orbit)

I didn't do 35 degree down-angle, though, just straight retrograde.

Still have the parachute bug--any ideas, anyone?

NOTE: DRE debug info shown on screen. Also I was using a 2.0x multiplier to G tolerance (that, configurable, is in the new DRE), which wasn't quite enough to prevent my nose cone blowing at peak G (8.5Gs, for the record)

Javascript is disabled. View full album

@Camacha's ninja:

Right-click the link, copy link (or shortcut, if IE). I just googled https://www.google.com/search?q=formula for heat of reentry

Edited by NathanKell
Link to comment
Share on other sites

@NathanKell: The current source doesn't have any changes to the SOIs, which puts the Mun's SOI within a few kilometers of the surface and the Mun's orbit outside Kerbin's SOI. If we're gonna use real-life values, Kerbin's should be 925,000 km, while the Mun's should be 66,100 km.

For reference, it can be calculated from this:

rSOI = a * (m / M)2/5

rSOI: SOI radius from planet center

a: semi-major axis of body's orbit

m: mass of body

M: mass of the body that is being orbited; for Kerbin this is the Sun, for the Mun it is Kerbin

As for what you were saying, I don't see why we can't do that. I've also been thinking about hijacking the stock aero effects the way that Deadly Reentry does so that things look a bit better. I have to admit that it certainly looks better coming down from a real-life-sized orbit.

@Dragon01: Well, if we're all running FAR with this, there's no reason I can't scale up the surface areas. All that would need is a scalar after I calculate the surface areas from the model.

Link to comment
Share on other sites

Still have the parachute bug--any ideas, anyone?

Not enough drag? Maybe adjust opening pressure and final open pressure/altitude? I forget what the parameters are and can't check them out now.

Edit: You know before my computer died I was noticing actual acceleration even a few kilometers above the surface even with a drogue and four normal chutes. So that's not just no drag that's... I dunno what. Maybe all drag values need to be upped universally? Are there any global parameters that might help?

Edited by Starwaster
Link to comment
Share on other sites

Ferram, regarding SoI, my understanding was that was auto-created based on mass, but it can't hurt to have the line in the source. I'll fix it.

Oh please fix aerodynamics more! Always appreciated. :)

(Actually, how hard would it be to just handle parachutes too?)

And yeah...it looked freakily, awesomely real. :)

I mean, totally obviously simulated, and blurry terrain, but so real compared to KSP!

Re: scaling: actually, I'd suggest then scaling _down_ surface area. Because I don't think PhysX can take three thousand tons of stack. But 750? Yeah. And I'm perfectly happy having FAR required for this. Heck, my original thread title idea was "Realism Total Conversion"--a package deal.

Starwaster: I'll try with higher drag then. Who knows...

DRE Continued v1 is released, btw, so y'all can play with DRE on Earthbin (Kearth?)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...