Jump to content

[1.2] Real Solar System v12.0 Dec 8


NathanKell

Recommended Posts

Just to make it official: I have every major body placed in its appropriate orbit; working on the moons now. Also rescaling those planets that haven't been yet (configurable in cfg).

I have removed 5x and 50x timewarp and replaced them with 1m x and 10m x timewarp.

I have fixed the solar panel issue, although I haven't as yet been able to make my tangents work quite right so the curve is segmented-linear rather than smoothly inverse-square (configurable in cfg).

I have changed the max height and max zoom out distance in VAB and SPH (configurable in cfg).

Link to comment
Share on other sites

Just to make it official: I have every major body placed in its appropriate orbit; working on the moons now. Also rescaling those planets that haven't been yet (configurable in cfg).

I have removed 5x and 50x timewarp and replaced them with 1m x and 10m x timewarp.

I have fixed the solar panel issue, although I haven't as yet been able to make my tangents work quite right so the curve is segmented-linear rather than smoothly inverse-square (configurable in cfg).

I have changed the max height and max zoom out distance in VAB and SPH (configurable in cfg).

Great! Any luck with the terrain? Has the stock Kerbin PQSMod configuration data I sent you helped? Are there any particular things that I've missed out that you want?

Also, is 10m x timewarp too much? A year in just over 3 seconds is very fast, and it's not like anyone is going to be flying Voyager beyond the solar system, right? Maybe 5m x at the most? How about a configurable list of time warp values?

Regarding tangents, could you not use Unity to make the curve in the animation editor, then write a script to dump all of the values to a file? You would need to do something similar for pressure curves as well.

And last but not least, have you tried any of the hacks for axial tilt?

Sorry to bombard you with queries. :D

Link to comment
Share on other sites

You'll have email shortly; just wanted to post this up here. Been a bit busy voting & following elections today.

You're right, won't cost anything to just pull all timewarp values from the CFG. Well, other than time, but.... ^_^

Though given that going to Pluto is taking New Horizons nine and a half years, something more than 1 million is probably in order. 5x sounds fine.

I used CurveEd and it looked right in the window as a curve, but I was getting garbage values in KSP for solar panel power. I'll fix it when I have a minute, I'm obviously just doing the tangents a bit wrong.

No problem. :)

Link to comment
Share on other sites

Just to make it official: I have every major body placed in its appropriate orbit; working on the moons now.

whoa.. wait. Are you talking about all the planets in our whole solar system? or replacement ones for those in kerbal? And for moons, do you mean like... Jupiter will have more than 3? If so, OMG OMG OMG! :)

Link to comment
Share on other sites

whoa.. wait. Are you talking about all the planets in our whole solar system? or replacement ones for those in kerbal? And for moons, do you mean like... Jupiter will have more than 3? If so, OMG OMG OMG! :)

No is the probable answer to that. Just the analogues are in place (e.g. Jool -> Jupiter etc.). I'm the one working on actually making new planets and I haven't had much time to continue my development of my technique yet.

Link to comment
Share on other sites

What about bodies that don't really have a solar system equivalent, like Ike? Maybe rescaled to be one of Jupiter's moons? Gilly could be Phobos or Deimos at almost 1:1 scale, maybe with Bop being the other one. Eeloo looks a lot like Europa, but its orbit is kinda like Pluto's. Laythe is kinda like Titan (if there's a Jool clone as Saturn). Pol could be Io. Vall and Minmus might be outer system icy moons.

Link to comment
Share on other sites

Major = planets. Including dwarfs; Dres is Ceres now. Moons, I'm trying to replicate real moons as best as possible (Gilly->Deimos, for instance).

It might make more sense, actually, to use Eeloo for Europa as you say, rather than Laythe, and Laythe to Saturn. But we don't have a Saturn, so...

Link to comment
Share on other sites

I'm actually not at all having problems with planes or intakes.

In fact, at 1:1 intake ratio, I can reach realistic altitudes at realistic speeds.

SSTO designs are still hard as hell.. planes need to be friggin' huge to carry enough hydrolox or heavy to carry kerolox based orbital engines.

Has anyone managed SSTO yet? my record so far has been 5km/s at 105km.

Oh one thing that does bug me; re-entry effects at lower-ish altitudes.. I know planes get kind of hot (SR-71) at those altitudes and speeds, but re-entry effects seem overkill. any way to fix this ourselves? maybe via DREC?

I am working on this as well, as SSTO's are my main appeal after getting addicted to the Ravenstar from Orbiter :D

I played around a bit last night and was only able to get up to around 2km/s @ 45km. But that was using only atmospheric aspirated engines (specifically the Ramjets from Taverio's mod).

How were you able to reach 5km/s? Did you need to use SABRES in rocket mode, or can you get up to those speeds breathing air?

I'm going to try and make one myself, so I'll post back if successful.

As far as reentry effects, if you are referring to heat, I believe you can modify the modifier with Alt+D+R if using DR. Sorry if you knew that already.

This is because KSP presents complex stuff in intuitive, visible way. That's one of it's big advantages over Orbiter. Lacking a map besides a low-res MFD and with much worse graphics, it just doesn't let you imagine those things so clearly. It does present much more realistic experience, but it's not as easy to learn from it. Also, KSP's exaggerated scale makes some things much easier to see. For example, rendezvous IRL is a much subtler, more delicate affair than in KSP, and therefore harder to grasp. Combined with KSP's ability to give you a look inside the ships you're flying (an aspect completely nonexistent in Orbiter, maybe besides modding) and you've got a perfect learning tool.

Exactly. The stock node maneuver thing is pretty much exactly what transX does, but in a manner that is much more transparent.

Been a bit busy voting & following elections today.

Good man. :cool:

Edited by Sternface
Link to comment
Share on other sites

I believe this has been discussed before. The downside of a Sol sized Kerbol system is that you lose all available navigational data and have to start from scratch. The main advantage of a proper Sol system is that you are able to use all existing real life navigational aids. Just look at how the big guys are doing it and voila, life is a lot easier.

Serious question, where can I find phase angles and ejection angles for the solar system? I can calculate them with the formulas sites like KSP Olex use, but that would become a pain quickly.

Link to comment
Share on other sites

I registered just to comment on this mod as I think it's a fantastic idea.

I understand the current issues with this mod (and general realism modding in general) have to do with the way the game handles space ship size, the required dV to carry out realistic missions, and the resulting size required of ships. I wonder if instead of scaling the planets up to match in the in-game parts/distance. If it would be better to scale the in game parts/distance to the planets.

For example setting a standard to scale to (easy/obvious one would be Kerbin) and scaling the rest of the game as if Kerbin was an Earth sized planet. This would mean an across the board recalculating of in-game units by a factor of ~10.9. Then modifying the scale/orbit of other bodies in the system would be mostly trivial based on what is currently done with this mod.

This would have the beneficial effect of an across the board reduction of the in-game size of spacecraft as a matter of scale (potentially easier to handle by the engine), increasing the usable size in the VAB/SPH (10.9 times as much space!), and keeping planetary body textures scaled correctly.

Conceivable problems would be obviously figuring out an intelligent way to rescale all in-game measurements, rescaling all GameData parts down, possible compatibility issues with mods taking units at a low level and being incapable of handling the rescale (mechjeb), potential unforeseen physics/collision issues from really small parts, etc.

I realize from a game development standpoint units and scale are arbitrary but from a practical modding standpoint using preexisting assets and rescaling the game around these assets might make more sense. Especially when the realism mod direction will necessitate things like more space to construct spacecraft, potentially massive rescaling of planets/moons, and greatly expanding the solar system to meet realistic astronomical distances.

Essentially rescaling gameplay to fit 'the box' we're given in a realistic way instead of trying to expand everything within 'the box' and potentially ending up with having to cut corners and run into a plethora of issues when things like ships, and orbits get to big for 'the box'. If that makes any sense.

I'd do some experiments to see if this was feasible but it's unfortunately beyond my skillset.

Link to comment
Share on other sites

Camacha: yup, local elections. In my state, no matter the town, at the town level almost everything is up for reelection on the odd years.

AndreyATGB: You can use an actual planetary transfer calculator. I know there's a standalone app for Orbiter (because someone was making a KSP version of it)...note that time = 0 is epoch J2000 (i.e. KSP Year 0 = real-year 2000)

However, given that Mr. Shifty forked alexmoon's planner, I'll fork it for this too when I have a chance.

li7in6: howdy!

Actually, at the moment we seem to have beaten all the rescale problems. Even Apollo-Saturn V is only a _bit_ too big for the VAB, I think*, and KJR should fix big-rocket wobbliness. Besides, adopting a smaller scale requires much more work than you'd think, since gravitic acceleration would (I think) be wrong, since it decreases polynomially not linearly. And so many of _those_ calculations are internal; I would hate to change a body's gravity and all orbits every frame!

(Unless I'm mathing wrong.)

*you can always move it down to edit the top, and move it up when done.

Given that existing assets can either be used as is, or (for manned pods) scaled up by approx 1.563, it's not really that bad.

Link to comment
Share on other sites

Conceivable problems would be obviously figuring out an intelligent way to rescale all in-game measurements, rescaling all GameData parts down, possible compatibility issues with mods taking units at a low level and being incapable of handling the rescale (mechjeb), potential unforeseen physics/collision issues from really small parts, etc.

You see, we considered that approach. It turned out to be infeasible, because we'd need to rescale everything, including time and all physics constants, in a way that quickly becomes way too complicated. Also, 1:1 scaling for rockets does work, as it turns out. Check out the thread in Addon Development, with rescaled Soyuz and Gemini.

Link to comment
Share on other sites

Actually, at the moment we seem to have beaten all the rescale problems. Even Apollo-Saturn V is only a _bit_ too big for the VAB.

Here is a fix for that problem (it greatly increases camera movements and allows to pass through the roof of VAB):


[KSPAddon(KSPAddon.Startup.EditorVAB, false)]
public class VABExpanderModule : MonoBehaviour
{
public void Start()
{
EditorLogic.fetch.editorBounds.extents *= 10.0f;
var vabCam = EditorLogic.fetch.editorCamera.GetComponent<VABCamera>();
vabCam.maxHeight *= 10.0f;
vabCam.maxDistance *= 10.0f;
}
}

Resizing the actual VAB model is quite involved now as it's not a single model anymore, but a whole concert of models, so that part needs additional work.

Please make sure to test it out before releasing as I came up with this code in like 2 minutes and didn't really test it (I mean I did check that it actually expands camera movement limits, but not sure about anything else). Specifically it needs to be checked if editor actually saves that information and as such there is no need to increase it every time player gets into VAB.

Edited by asmi
Link to comment
Share on other sites

Nice to see the new VAB height in the alpha version.

Now to build a 250m rocket.

Edit: There seems to be disturbance in the force :D

h1wuOQW.png

Also the rocket can't be mover upwards even if the camera can.

Though i managed to get it 96 m tall :)

FapXxOQ.png

Edited by p3asant
Link to comment
Share on other sites

Also the rocket can't be mover upwards even if the camera can.

That's because Nathan didn't add a complete fix. Specifically, this part: EditorLogic.fetch.editorBounds.extents *= 10.0f;

Link to comment
Share on other sites

Nice to hear someone is working on the 'wobbly-rockets' problem. I mean yes, in real life they add structural reinforcements, all we can do is add struts which in most cases do not eliminate wobble. It's ok for stock KSP but something as large as Saturn V or even Atlas V is almost impossible with the same rigidity. Looking forward to it!

Link to comment
Share on other sites

Had some time in my hands, nothing else to do, so I recorded this:

The external tank and boosters are mass and delta-v identical to rl. The orbiter is lighter by about 15t, but its aero reentry profile is working so I don't want to mess with its CG position... yet. This perhaps is leading to MECO being 1 minute earlier than RL.

Obviously using RealKerbin, FAR and MFS, besides B9, KW and the 1:1 SRB made by 1096bimu.

(I think at this point anyone has noticed I'm a bit obsessed with the space shuttle :D)

Link to comment
Share on other sites

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