Tellion

Poor Sigma, so many offtopic comments Coming to the rescue: Is the secondary always at the same distance from the barycenter?

Do you have OPM installed? You need to get the stock, standalone version first or the compatibility configs will not work...

2/3) For starting systems a solution is to move Kerbin to the desired location via MM and leave a copy in place. You can only launch from Kerbin, but apart from that you can modify it to your heart's content, see RSS. That would be irreversible per save game of course. If you want to chose starting systems ingame, you are out of luck until someone writes a plugin which would be quite hard in this case iirc. Although: If you are feeling really hacky, you might be able to patch something together with EPL and KerbinSide Well, a galaxy is more like this thing and less a measly black hole/O Type Star orbited by a bunch of other stuff.

I don't know whether NonWonderDog's configs are for RSS or Kopernicus, but in any case I would be surprised if they still work. You could copy their values over into the up to date config, that should achieve results. If you are feeling adventurous, you can also get Kittopia Tech and play around with it. It allows you to edit terrain on the fly but takes a bit of trial and error to get an idea of. (test that on a clean install though, modifying terrain might wreck anything on the ground)

Well, Barycenters do not have much of a surface area I think so the smashing would take some dedication... But yeah, gravity assists powered by several solar masses are problematic. Your use of galaxy confuses me and I am going to assume you refer to barycenters of multiple star systems :3 Yeah, placing the stars at a large distance from each other is a must, but we don't seem to get rid of the messy transfers in any case. It seems to be either a) completely ignoring the body whose SOI you are not in, which kind of sucks, or Allowing major whackiness by having the mass of the stellar system be a concentrated point even when inside the orbits of both stars, which also kind of sucks. This discussion makes me want to install principia right away... Anyways, it is late here... Good night! True, but distance would mitigate that by making it a huge chore to actually getting close to the barycenter, much like crashing something into the sun isn't all that easy. And thx for the answer regarding SOIs, that might be useful somehow...

Why messy though? The center of the whole system is the barycenter, the stars orbit it. It's like placing a copy of Kerbin at the opposite end of the orbit and multiple small moons around both Kerbins. If at all, I see this conflicting more with reality than with KSP's nested SoIs. No criticism of your mod anyhow, it is an excellent and very creative solution especially for planetary binaries. Edit 2: I just thought of close flybys and gravity assists which could be used to exploit such a barycenter. Bleh, KSP is really quite limited... Still not sure what solution I like better in this case... How do overlapping SoIs of the same order behave, does one of you know? Aww that thread is super interesting, thanks! Regarding the graphic, I am not sure I understand though: Both bodies orbit the barycenter? Because if they follow a simple Kepler orbit they have different angular velocities, which is something rather bad in this case. Sigmas mod solves exactly this, even if it trades that for some other inaccuracies. Edit: Aaand I was ninja'd. Twice ._.

As usual, thanks for the answers

Are you sure? Line 19799, right after EVE is doing it's thing. Also, if he downloaded before yesterday he would have all of that stuff except for distant object enhancement and planetshine....

Ah, I remember, the barycenter's mass is a function of the secondary's orbital period. Definitely the best possible solution for planets, where distances are smaller and preserving the equality of orbital periods for primary and secondary on very different orbits is crucial. When we think about stellar binaries though, I think going the manual route of just choosing stars of equal mass and equal orbital periods orbiting a barycenter twice that mass might be better. You can tweak the SOIs until everything fits, still have your 1:1 resonance and (I think) even believable orbital periods combined with the ability to enter orbits that are not bound to one specific body. Or at least that is the idea, I certainly overlooked *something* *somewhere*

Try without EVE by deleting the Environmental Visual Enhancements and BoulderCo folders from your GameData directory, I am quite sure that that is a memory issue in your output log.

Well, for an old fashioned distant binary, orbits are stable within ~1/5th of the distance of the closest approach, afaik. Assuming planets orbiting up to 10 AU from their primary that leaves you with 50 AU distance to the secondary, something that might actually be possible to burn for with NFP, certainly with KSPI engines. Warp drives will in any case handle anything thrown at them as long as there are no SOI issues. Regarding binaries: Do you really switch from primary to secondary body without staying in the barycenter's SOI in between? I don't quite remember anymore... I think Cantab is right though, accurately modelling a transfer between two components of a binary system is a problem. Can that even be approximated by pretending that your vessel orbits only one central mass (eg. the barycenter) until it is very close to either primary or secondary? If yes, things can be solved by Star -> SOI ranging only little further than the outermost planet -> Barycenter, huge SOI encompassing both starsystems -> Star, same as first. I am not so sure though... If that does not work, I see no alternatives short of Principia

Yeah, makes sense. And I guess I will have to be surprised by the type of star system

Kerbalized as in: Not overly concerned with realism. Have you decided on the type of star system already?

Aww, I will be looking out for that! You are going to go for a kerbalized version, right?

You merged normal and color, or was there a more complicated process behind that? Are Ete and Oree made with KSP? Those reminded me of a couple noise generators I have been toying with and I am curious to know if KSP is really that close to them. Oh, and what about gas giant textures - I have found that the SE exports would require editing all those different maps together to get something that is usable by KSP and have no idea how to do that. Vanor is very nice imo. And yeah, Landcontrol seems to be totally awesome and is probably a huge help with memory, it is just very time consuming to figure all of those PQSMods out.

Ah, interesting approach. So you went template > KSP's PQSMods > Heightmap export? What did you use for exporting, Kopernicus? And I assume you based the coloration on SE or made it yourself on top of the heightmap...

KillAshely, what tools are you using for generating the maps of your planets? Looking through them I definitely see some SE in there but also some which look more like they were created with some fractal noise generator, apart from the handmade editing. Apologies for all the questions and thanks for answering them btw

Absolutely nothing! The only issue is that there is only one instance of Scatterer per game at the moment, so a pretty Jool comes with a bland Kerbin.

Starwaster worked on a solution for that (implementing some sort of insulation or active cooling mechanic I think) but I forgot it's name and did not save a link. If you really want a means to deal with boiloff, asking in the RF thread will probably get you there.

Some more playing around with scatterer, this time with Jool: Trying to use scatterer with Jool in it's 64K version lead to some very pretty screenshots. It also lead to the atmospheric haze fading in and out based on the perspective the planet was viewed in, but that might have been a misconfiguration too. I saved the logs and configuration files just in case you'd be interested Blackrack

I am placing my hopes in this one here also

Well, maybe I dun goofed too , I am going to check. Alright, I didn't spot anything particularly whacky. The reason NFP lowers the ion drive's thrust is that it wants to create a nice balance progression - if it did not do that, you would have little if any reason to use some of the early thrusters that it provides.

Well, the configs *should* not do anything to nerf the ion engine - it does get a thrust reduction to 1.3kN when NFP is installed however, since it would not fit in with the rest of the NFP engines otherwise (that's one of Nertea's patches set with :FINAL to incorporate our fixes, basically). Apart from that, all Xenon engines have their EC consumption modified to compensate for RF's density change to Xenon - thrust is not reduced for those engines at all, they behave pretty much like they do in stock.

If there is an issue with the ion engine, that is my bad. Did you infer that something is wrong from looking at the configs alone or did you observe any weird behaviour ingame?

I already had spreadsheets laid out for 64k so I decided to make some quick OPM compatibility configs for this mod. I downloaded the EVE_7.4 version for that and noticed a few things going through the download folder: There are two RemoteTech Settings .cfgs (those overwrite each other afaik), there are 3 Module Manager versions (MM is awesome but that might be a little superfluous) and, most importantly, an RSS folder containing not only DDS Loader (not needed anymore, correct me if I am wrong) but also a bunch of textures that seem to be present in the 10xKerbol folder also, as well as all of the old RSS .obj files. I didn't look into the other downloads but removing the obsolete stuff might cut file size considerably. If you want to link to or include the OPM configs (link here), feel absolutely free to do so.