Jump to content

[KSP 1.12.1+] Galileo's Planet Pack [v1.6.6] [23 Sept 2021]


Galileo

Recommended Posts

The GPP team has enough to be concerned with, with contracts that appear too soon for certain places or certain types of contracts that appear at all and should never appear. Ore requests from the barycenter will surely happen and no one's going to like that. :P

 

13 minutes ago, Crimeo said:

you could and probably would (for sake of fun/novelty) want to have some planets orbiting each star near-in, and also some planets orbiting further out around the barycenter, so it would actually realistically be an orbit of both navigational and scientific interest I think.

Sounds legit.

8 minutes ago, Crimeo said:

would anybody ever even reasonably expect such a thing to work in a binary star system mod?

Your question should be "Would anybody ever reasonably expect such a thing not to work in a binary system mod?" Technically solar panels should stop working once they're far enough from any star and should comfortably switch over to the nearer, more productive star given their location. But limitations in Kopernicus (and I suppose KSP too...Evidently Squad never catered for other stars and the possibilities of visiting them when they built KSP) made this problem a thing. And this problem too:

Solar panels work alright around Grannus but function at over 32x normal around Ciro.

Link to comment
Share on other sites

39 minutes ago, Galileo said:

I think it's possible, but a lot of testing would need to be done. Basically we would be making the barycenter the center of the system (that's the only part I am skeptical about) and everything else would just be put basically where you specified earlier. This will require sigma binary obviously and I don't know if a barycenter at the center will work. Have to try. Or maybe @Sigma88 can just give us a yes or no

it isn't currently possible with SB but the changes required to make it possible are trivial

but I need a bit more context on the type of binary we are talking about (haven't read the whole discussion)

Link to comment
Share on other sites

Better image of what I imagine is probably possible with regular old kopernicus? IF issues of "contract for ore from the barycenter" and solar panels are tolerated among the target community. Green X = barycenter, black and red stars have colliding (but still mutually exclusive) SOIs, which would make moving between them sooooomewhat sort of not-so-very-but-sort-of reasonable. And as long as the purple planet's orbit does not overlap the black SOI (is not meant to do so here, isometric 3D view angle taken into account), getting to purple is reasonably straightforward. Same for green and yellow planets far out, if not intersecting with star SOIs

Just guessing that this is how colliding SOIs work though...

Edited by Crimeo
Link to comment
Share on other sites

I think the SOI of each individual star would only extend to maybe halfway to where the actual equipotential surface is - the majority of space would be in the SOI of the Barycenter when the stars are this close in mass.

Link to comment
Share on other sites

I finally "unlocked" Grannus (Research Bodies).

At 6.4x scale, it actually doesn't look that hard to get to:

9RLJ34B.png

...except for the 46-year transit time. and then the intercept would spin the theoretical probe right round like a record baby and shoot it out of the solar system in the opposite direction:0.0:

Plugging in some more numbers, it turns out such a feat would be only slightly more difficult than getting into an orbit of Thalia. :mad:

And Icarus... ha, ha, don't get me started. :confused:

Link to comment
Share on other sites

51 minutes ago, Sigma88 said:

it isn't currently possible with SB but the changes required to make it possible are trivial

but I need a bit more context on the type of binary we are talking about (haven't read the whole discussion)

The aim is to make Ciro (the center of the universe) into a binary system member and to be prepared for the obvious resultant problems of overlapping SOIs...and the reactions from the contract systems.

46 minutes ago, Crimeo said:

Just guessing that this is how colliding SOIs work though...

12 minutes ago, MaxL_1023 said:

I think the SOI of each individual star would only extend to maybe halfway to where the actual equipotential surface is - the majority of space would be in the SOI of the Barycenter when the stars are this close in mass.

Unfortunately that's not how it works. For what I've seen, you will see an orbit line for each intersecting SOI in a binary system. Both of them will be considered concurrently and you'll have to deal with whatever consequences due to Schrodinger's physics. Since planets are on rails and are explicitly made parent-child with another thing I don't expect them to lose their orbits in an overlapping SOI.

Worse than that, your orbital path, as it crosses an SOI's boundary, could bend horribly. You could get gravity-bullied by the 'other' celestial like @CatastrophicFailure has shown. :D 

 

Link to comment
Share on other sites

2 minutes ago, JadeOfMaar said:

The aim is to make Ciro (the center of the universe) into a binary system member and to be prepared for the obvious resultant problems of overlapping SOIs...and the reactions from the contract systems.

yes, that much I've got.

but what kind of binary?

binary as Sun-Jupiter ?

or binary as Alpha Centauri ?

Link to comment
Share on other sites

3 hours ago, New Horizons said:

This made the science behaviour more clear.Thank you. The question still is, which multiplier goes into the reward calculation in a carreer safe game. Too me it seems, that not only the prestige level  applies for the reward calculation. Maybe rewards indirectly go with body index. 

That's a good question and I'm not 100% positive of the answer.  My understanding is that it would work like this...

Contract is generated ->Chooses Body->Chooses Applicable Situation->Generate Parameters->Generate Reward

In that order it would be looking into the config file for the chosen body and situation and generating the contract and ultimately the reward based on those initial parameters.  As suchThis is a bit of an educated guess though and I'm definitely not the expert on this.  To get the real nitty-gritty on it you might ask over in the Contract Configurator thread and see if @nightingale can give you better insight into the mechanics than I can.

 

Link to comment
Share on other sites

6 hours ago, Sigma88 said:

so Grannus is not close to ciro?, where close means in comparison to everything else orbiting Ciro

Grannus and its orbit currently have the following characteristics:

Mass = 0.5 x Ciro
Eccentricity = 0.4
Semimajor axis = 2,000 Gm
Periapsis = 1,200 Gm
Apoapsis = 2,800 Gm
Sphere of influence = 500 Gm

Ciro's farthest planet is Leto, with Pe = 488 Gm and Ap = 597 Gm.  Leto's closest approach to Grannus is about 706 Gm.

 

 

Link to comment
Share on other sites

Personally, I see no added value in making Ciro and Grannus into a binary system.  Grannus' orbital period is over 1700 years.  What exactly does anyone expect to see?  For all practical purposes the movements are imperceptible.

If somebody wants to create their own system, or move planets around, then feel free to do so.  But GPP is a finished product.

Link to comment
Share on other sites

Edit: ninja'd by OhioBob

 

Honestly I don't think it would be worth it to change this system into  binary one.

When you reparent kerbin (it no longer orbits the center of the universe) you get a huge array of bugs

Plus, even if you use SB to make it  binary, you would still have the same experience physics-wise 

Yes, Ciro would orbit  barycenter and when timewarping you could see it and Grannus orbit each other, but it's just an illusion

In practice ciro SOI would still cover all the way out to infinity, and Grannus would still orbit Ciro.

Which means that for  craft going from ciro to granus there would be no difference with or without SB

Edited by Sigma88
Link to comment
Share on other sites

3 minutes ago, Sigma88 said:

Edit: ninja'd by OhioBob

But you added some further good points.  I agree with you that there is really no difference in terms of game play between having them binary or not.

Link to comment
Share on other sites

19 hours ago, CatastrophicFailure said:

I finally "unlocked" Grannus (Research Bodies).

At 6.4x scale, it actually doesn't look that hard to get to:

I've already played with the idea of visiting Grannus. The dV requirements for a kerbaled flyby and return to Gael do not seem insuperable - 3700 dV Ejection burn. But the TransferWindowPlanner tells me a journey time of more than 450 years. This takes to much time for me. How can that be with you only 46 years? Do you fly so much faster with a scale of 6.4?

Greetings

Link to comment
Share on other sites

18 hours ago, Crimeo said:
Better image of what I imagine is probably possible with regular old kopernicus? IF issues of "contract for ore from the barycenter" and solar panels are tolerated among the target community. Green X = barycenter, black and red stars have colliding (but still mutually exclusive) SOIs, which would make moving between them sooooomewhat sort of not-so-very-but-sort-of reasonable. And as long as the purple planet's orbit does not overlap the black SOI (is not meant to do so here, isometric 3D view angle taken into account), getting to purple is reasonably straightforward. Same for green and yellow planets far out, if not intersecting with star SOIs

Just guessing that this is how colliding SOIs work though...

We're never going to be able to make the SOIs work in a realistic way.  The formula KSP uses to compute SOI is just a mathematical approximation.  There are several things wrong with it.  We can get a better approximation of a body's real SOI by computing the location of the equigravisphere.  The equigravisphere is the spherical surface on which the gravitational attraction of both bodies is equal.  Below is an illustration showing both Grannus' equigravisphere and its SOI as computed using the formula in KSP:

equigravisphere.png

One of the first things you notice is that the equigravisphere is not centered on Grannus.  The computed SOI, on the other hand, is centered on Grannus.  Even though the computed SOI is smaller, by centering it on Grannus you can see that it extends much closer to Ciro, causing Grannus to dominate most of the space between the stars.  When the bodies are this close to each other in mass, the computed SOI just doesn't work.

Another problem is that the SOI is computed using the semimajor axis of the secondary.  The radius of the SOI should be a dynamic thing that changes with the actual distance between the bodies.  If we compute Grannus' SOI based on its semimajor axis, then the computed radius is way too big for when Grannus is at periapsis, causing the SOI to engulf Ciro.

Fortunately KSP allows the developer to override the calculation and enter an actual value for the SOI.  But this still centers the SOI on the body.  There is no way to simulate an equigravisphere the way it is in real life.

 

19 hours ago, MaxL_1023 said:

I think the SOI of each individual star would only extend to maybe halfway to where the actual equipotential surface is - the majority of space would be in the SOI of the Barycenter when the stars are this close in mass.

This seems to me to be the most logical way of doing it.  FYI, on a straight line between the stars, the distance of the equipotential surface from Ciro is 0.58579 times distance between the stars.

Link to comment
Share on other sites

6 minutes ago, astroheiko said:

I've already played with the idea of visiting Grannus. The dV requirements for a kerbaled flyby and return to Gael do not seem insuperable - 3700 dV Ejection burn. But the TransferWindowPlanner tells me a journey time of more than 450 years. This takes to much time for me. How can that be with you only 46 years? Do you fly so much faster with a scale of 6.4?

I think there might be something messed up in the Transfer Window Planner's flight times.  Without getting real complicated, I just figured an orbit with a periapsis at Gael and an apoapsis at Grannus and computed the flight time.  I get about 150 years to go from periapsis to apoapsis.  I think that should be about the worst case.

Link to comment
Share on other sites

16 minutes ago, astroheiko said:

I've already played with the idea of visiting Grannus. The dV requirements for a kerbaled flyby and return to Gael do not seem insuperable - 3700 dV Ejection burn. But the TransferWindowPlanner tells me a journey time of more than 450 years. This takes to much time for me. How can that be with you only 46 years? Do you fly so much faster with a scale of 6.4?

Greetings

What @OhioBob said. It would be, in my case, catching Grannus @ periapse, with an ejection burn of around 7km/s. Have you tried computing it with MechJeb or another plotter?

Link to comment
Share on other sites

18 minutes ago, astroheiko said:

I've already played with the idea of visiting Grannus. The dV requirements for a kerbaled flyby and return to Gael do not seem insuperable - 3700 dV Ejection burn. But the TransferWindowPlanner tells me a journey time of more than 450 years. This takes to much time for me. How can that be with you only 46 years? Do you fly so much faster with a scale of 6.4?

Have a look in the orbital maneuvers section for a "one-tangent burn". Compared to a Hohmann transfer, a little extra dV in the ejection and capture burns saves a whole lot of travel time; if you use a life support mod, this is a very useful technique even for nearby destinations.

Link to comment
Share on other sites

Something else that might be happening with the Transfer Window Planner it that it could be computing a type 2 trajectory.  A type 1 trajectory is one in which the angle the spacecraft sweeps out between the departure point and the intercept point is less than 180 degrees.  A type 2 trajectory is one where the angle is greater than 180 degrees.  In a type 2 the spacecraft travels out to an apoapsis beyond the target, and then intercepts the target on the way back in.  Type 2 trajectories are common for trips to Mars because they often result in better intercept conditions and reduce the amount of delta-v required for orbit insertion.  Whether a type 1 or a type 2 is better really depends on where the target is in its orbit at the time of launch.  Although a type 2 may require less delta-v, the travel time for a type 2 will be significantly longer.

If you are simply selecting the transfer that has the lowest delta-v, then you may be unwittingly selecting a type 2 transfer.  At a distance out beyond Grannus, a spacecraft is traveling very slowly.  I can see how using a type 2 trajectory could add a hundred years to the travel time.

The Transfer Window Planner might be computing other transfers that have shorter travel times but higher delta-v.  You might just have to poke around on the porkchop plot until you find something that provides both acceptable delta-v and acceptable travel time.  You'll probably have to compromise by sacrificing a little bit of the one for the other.

 

Edited by OhioBob
Link to comment
Share on other sites

@OhioBob and @CatastrophicFailure,

You are right. I played a little bit and just put a maneuver by eye. Now I am only 22 years to the PE of Grannus indicated, that sounds much better.
What do you think of the idea of a retrograde FlyBy maneuver to save dV? Have done something like the Apollo missions. What was the name of it? Free return trajectory? Looks like an 8.

I just have to try it out!

8nBc7GT.jpg

@CSE

Holy mother:o. So much effort I will not make. Trial and error must suffice.:confused:

Damn it. I just went out of likes.

Edited by astroheiko
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...