Jump to content

Realism Overhaul

NathanKell

By NathanKell
in KSP1 Mod Development

 Share

Recommended Posts

ferram4

ferram4

Posted
Posted

Playing around with things more, I've discovered some... interesting things.

The orbital period of orbital bodies needs to be set manually. The Mun was at the Moon's orbital distance but was completing an orbit in one day rather than ~27 days.

The Mun's scaled space representation wasn't set. Further, trying to adapt the scaling used for Kerbin didn't work; I settled for multiplying the current scaling by the ratio of Moon radius / Mun radius, which worked out.

The scaled space representation is based on something other than the standard PQS. This means that when coming in close to the Mun you see it fade from a somewhat a-spherical scaled space version to the much more spherical rescaled PQS. We may need to maintain a constant ratio between body radius and the heights on the PQS to make things look proper.

I think the twitchiness on the pad is due to the launch clamps. I'll look into designing rockets that don't need the clamps to launch / building effective clamps using parts and see if that changes things. We might need to recode those to make it work.

In rare occasions, parachutes will open fully within 100m of the ocean. Never seen it happen on land though.

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted

I didn't properly update the bodies after changing their stats. That should be fixed, testing.

I forgot about the Munar scaledspace issue; the thing is, looks like the SS transforms are set often, so we have to keep replacing them, I think? Since the Mun starts at localscale = 0,0,0!

The twitchiness seems to be float precision errors, at least in my experience: you can see the problem with the PQS vertices, if you're coming in for reentry, they slide in and out of the water (now that the waterlevel is fixed).

I've found (some of) the problem with parachutes. It turns out the barometer, and anything that relies on its method of finding pressure and density, reports IN VACUUM. Oddly the chutes do seem to deploy correctly, so _their_ method of determining pressure works. (As obviously does yours!) But it seems like what determines drag uses the same method (or hits the same bug) as the barometer.

Also, I may have found the atmo lighting problem. We'll see.

If worst comes to worst, we can use the new pressureCurve method of setting atmo pressure rather than the function-of-e method.

So, TL;DR check the new source. :)

Link to comment
Share on other sites
ferram4

ferram4

Posted
Posted

Put a link to the source and dll in the first post for everyone's convenience. It'll certainly help anyone interested in getting into it initially since they won't have to search as much.

I don't know what could be messing with the barometer or the chutes, since all FAR does is grab "vessel.atmDensity" for density.

I know that there are AtmosphereFromGround and AtmosphereFromSpace classes that might have something to do with the atmospheric stuff, but trying to get an array of all of them results in an empty array. There might be some use in looking at the ones under "SGT_[...]" which might get used.

Link to comment
Share on other sites
asmi

asmi

Posted
Posted (edited)

Yea issue with chutes isn't FAR-related. It looks like drag is set to zero, trying to find out why...

UPDATE:

What's interesting - is that chute works on my test craft that boost it to about 200 meters and then deploys chute. Looks like there is some issue with transitioning from semi-deployed to deployed state. Still looking...

Edited by asmi
Link to comment
Share on other sites
SFJackBauer

SFJackBauer

Posted
Posted

I had one time being able to splashdown a capsule intact. Even though the chutes opened at their correct altitudes (using one drogue and three radials), the capsule continued to fall at ~150m/s until very close to the sea (50m), then it braked to 7m/s and splashed down. Couldn't reproduce it as in my next attempts the chutes always break off.

Link to comment
Share on other sites
asmi

asmi

Posted
Posted
@ferram, those are the classes that I found and am trying to update. Currently getting some NullReferenceExceptions after I do so though.

Yup, confirming 0 drag, I tried with no FAR too.

Current source code acts kinda weird - after ascent "correct" Kerbin fades away and "small" version of it appears:

o3SteKf.png

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted

Yeah, I tried to switch to replacing the values on every scene transition, in case that was the problem, but it's caused more problems than it's solved. Then I had to break for dinner. :}

Apologies.

I didn't update the DLL yet because I figured it mightn't work.

Link to comment
Share on other sites
asmi

asmi

Posted
Posted

And even with new version of MFSC engines kinda suck. I had to use almost Delta-Heavy-like config to get 15 t to 275km orbit. Couldn't come up with Altas-V like design that would actually have Atlas-V-like performance. And of course Zenit - it's my favourite LV :)

I wanna this baby:

450px-RD-170_rocket_engine.jpg

Link to comment
Share on other sites
asmi

asmi

Posted
Posted (edited)
You...did set it to TL7? If you do it should give you better-than-present-tech Isp (for whatever fuel type), and near-Merlin-level TWR.

Otherwise you'll get bad Isp and TWR.

Ah, <3 dat kerolox too, huh? ^_^

Nope, largest KW engine TL7 has less thrust than RD-170 (5152 kN vs 7550 kN AND real RD-170 doesn't overheat while operating at 100% thrust ;) ), and worse Isp - 295/340, while RD-170 have 309/338, while it's TWR is 89.7 which is far cry from Merlins and NK-33 (RD-170 has TWR of 82). Keeping in mind that sea-level Isp and thrust are all that matters for first stage engines, I'd say that KW engine sucks :(

RD-170 iz ze best!!! :)

P.S. To be honest I disapprove this whole concept of engine overheats in KSP - they just don't do that in RL... Can you add an option to MFSC to eliminate this stupid concept entirely?

Edited by asmi
Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted (edited)

MFSC engines include their thrust plates in their mass; the actual engine TWR was calculated at 108. But you're right that SL Isp isn't as good as those amazing Russian staged-combustion engines.

Interestingly, according to my calcs an engine with that Isp should have a TWR of 84, so sounds like my balance is about right. :)

Here's the sheet I use if you want to roll your own. Just change the stats and go. Set NewName to 0 if you don't want my KATO new engine names.

https://www.dropbox.com/sh/16v210v2vbwv3ov/nmInpsRZ1P

Docs are here: https://docs.google.com/spreadsheet/ccc?key=0AvHneDAy4k99dDZYOHJraGpQc2VuMUxxU0FjSUp6NXc&usp=drive_web#gid=7

Only changes: TWRG column shows goal TWR. Isp SLM and VM are multipliers. So you can customize Isp per engine; TWRG will scale appropriately for balance. Tweak the Isps too if you want. When done, paste Column AC (from AC3 on) into Engines.cfg and remove the quotes, and IspsOut into RealSettings.cfg and remove the quotes.

BTW the largest KW engine is actually the G8D now, rescaled to 5m. The largest in pure thrust is the old NovaPunch 1.0 M50-5x, at 9000 at TL3 (only goes up from there).

EDIT: Also you might have the first alpha of v3, where overheat was broken. Re-export from the calcs.xls I uploaded above, the heat should be good now. Or just change the formula in that column and re-export, and heat will not be an issue. ^_^

Edit 2: Actually, you'll be at near-Vac Isp in about 30 seconds to 1m from launch, I think, and your first stage will probably burn for 2 minutes.+ So even for first stages, SL Isp shouldn't matter that much, although certainly matters more than for upper stages!

Edited by NathanKell
Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted

I AM A MORON. FILM AT ELEVEN.

I was setting max atmosphere height in km instead of meters. That's why stuff worked up to 105/135m.

Oy.

Tested, and that fixed it. We now have parachutes! And, for those folks without FAR (I know, I know) we have drag.

Uploading fixes.

Link to comment
Share on other sites
pina_coladas

pina_coladas

Posted
Posted

Bug report: EVA on mun is slippery and you sink into the ground a little when not moving and you can't plant flags. Hope this helps somehow.

It's going to be REALLY hard to make a realistic Apollo-style landing now... finally a real reason to make a two-stage mun lander! Also, it really threw me off seeing the mun in an inclined orbit, now I have to think a little bit about launch windows.

Getting off RealEve is going to be be pretty ridiculous and going to the outer planets is going to take a very long time on max time acceleration...

Link to comment
Share on other sites
ANWRocketMan

ANWRocketMan

Posted
Posted

Just a note: I haven't landed on the moon yet, but I was wondering what's up with the "moon's" super short orbital period? Is that a problem with KSP's physics or does the gravity not scale correctly as in real life?

It is awesome though!

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...