Sigma88

maybe you didn't read my post here it is again: Exactly EDIT: technically not to all parts, *only* those that have a name (which is usually all of them)

I don't know why this is a problem all I said is that @PART[*] targets all PART nodes with a name, which is correct @PART will target all PART nodes regardless of name being defined or not most of the errors I find in cfgs from mods are caused by the fact that people mix up the MM syntax with the KSP objects defined by the cfgs for example, considering PART nodes "special" when infact they are the same as any other (root) node or misunderstanding the meaning of [*] (which means "with any name" rather than "any of these nodes")

as far as I know you need # to tell MM "title" is a key inside the PART I don't think this would work, I'm actually surprised it doesn't throw an error

@Wagoo I notice you capitalize "Kerbals" is that same thing done in stock as well? I can't remember

so, this is the current HR, in green are marked the current stars, in blue I highlighted the areas where I would like to put new stars to find a star that fits in that diagram, go to wikipedia and find any star that matches the coordinates of the blue stains looking at B-V for the x axis, and luminosity for the y axis for example: Eta Ursae Majoris has B-V -0.19 and luminosity 1350 (I don't think this would fit in the blue regions, I just took a random star) keep in mind that the y axis has a logarithmic scale alternatively, I can look for some stars myself and just give you a list and you can choose one of those also, I will need to rename some of the planets because we can't have more than one planet with the same name here's the list of planet that will need new names: also, I noticed that you don't delete OPM displayName so some of the planets you rename don't get renamed ingame just adding !displayName = DEL in the Property node of the cfgs in the OPM compatibility patches

@Starwaster that's not necessarily true For example: 1- a mod could create a nameless PART to avoid getting targeted by those patches that use @PART[*] and provide a name later in the patching process 2- a mod could just have bad configs (this has actually happened to me) Granted, these are pretty rare occasions, and in fact that's why I said it usually doesn't happen

What about close to the sun and/or in a certain orbit around the sun (like an asteroid field)?

Exactly EDIT: technically not to all parts, *only* those that have a name (which is usually all of them)

mm patches don't target cfgs, they target nodes. depending on how the patch is applied it may or may not apply to the cloned part. first of all the cloning happens at a certain time, so the part is cloned in the state it is at the moment of cloning. after the cloning, if a patch starts with: @PART it will affect all parts (included the clones) if it specifies the name for example: @PART[fuelTank] it will affect only the original "fuelTank" part and not the clone (since it has a different 'name' ) if it uses some different method like: @PART:HAS[#title[fuelTank]] it might still fail (like in this case) if your cloning process messed up the particular value the patch is looking for bottom line, if you want your cloned part to get all the patches of the original, just clone it at the end using :FINAL (for personal use) or :FOR[zzzzzzYourMod] (if you are releasing it with a mod) on the other hand, if you don't want your part to be affected by any other patch, I don't think there is a way to do that ( @sarbian / @blowfish please correct me if I'm wrong on this last point)

1. I would suggest you to write a mm patch to change the descriptions of the bodies rather than editing the cfgs themselves just create a cfg with this inside: @Kopernicus:FINAL { @Body[XXX] { @Properties { @description = YYY } } } where XXX is the name of the body, and YYY is the new description (you can add more than one, so that you can change all planets) also, when you have finished them send them over to me, if I like what I see I might be interested in adding them to GN (unless @Galileo wants to write some custom ones himself) 2. you can remove the renamer to get back the old "Kerman" names if you leave the renamer you have 2 options: preserveOriginals = false you will get 6 starting veterans (Galileo / Jade / Bobert / Poody / Raging / Sigma - Gaelan) and the 4 stock veterans will be simple applicants (Jebediah / Bill / Bob / Valentina - Gaelan) preserveOriginals = true you will get 4 starting veterans (Jebediah / Bill / Bob / Valentina - Gaelan) and 6 custom applicants (Galileo / Jade / Bobert / Poody / Raging / Sigma - Gaelan) 3. just don't install Sigma Replacements: Suits and you won't have any issues on that side

there must be something about the standard linux settings that is not compatible with the plugin I use to extract zips then >_>

@Psycho_zs I tested the cfg and it works, since the rotation is game specific there is still the possibility that your game generates a null rotation. I plan to add the ability to Choose a specific rotation in the future, that might help with this issue

it should rotate the skybox regardless of which texture is applied *should* being the key word here :|

@WillThe84th I am considering adding compatibility for this mod in Galactic Neighborhood usually I ask the planet pack developer to propose a name for the star the pack will get in GN and also to propose a real life star as analogue for this pack I thought it would be nice to name the star "Schedon" or "Skedon" which is greek for "Almost" regarding the star instead, I would like to get a star that fits nicely into the HR diagram of GN stars, so I am looking for specific types of stars. If you are interested I can send you some options when I have an idea of what kind of stars I need now

% is fine let me double check the syntax, I might be remembering it wrong EDIT: the cfg I posted should work, if you are still having troubles I will need you to send me the mm cachefile and output_log.txt file to look at what is happening in your install

the syntax is fine except that you are using @ which is used when editing something, since there are no "SkyBox" nodes that patch will fail what you want to use is: @SigmaReplacements { SkyBox { CubeMap { rotate = true } } }

@MrChumley by any chance did you use some weird setting to compress the archives of Asclepius and Kronkus? I am writing a plugin for GN that installs planet packs from the zip file and it is failing when trying to extract your mods I extracted the files and re-zipped them and it worked fine.

If you install only GN what you get is only the base stars, if you also install some of the supported planet packs, GN will generate an extra star for each planet pack and put the planet pack there. If you want all the stars to be generated regardless of whether the corresponding planet pack is installed or not, you can change LoadAllStars to true

Given that SR does not provide reflection I think it wouldn't make much sense. Unless I am missing the purpose of this mod

I haven't tried those mods so I wouldn't know. Keep in mind that when you load a new planet pack for the first time kopernicus might need to generate cache files and that will increase loading times/ram usage My suggestion when installing a new planet pack is to run the game once, close it when you reach the main menu and run the game again On the second run you should see lower ram usage. Other than that, maybe the planet pack you are using in gn are using ram more efficiently than the planets provided by those other galaxy mods. Stuff like Kopernicus OnDemand or the use of certain PQSMods can greatly improve ram usage. And even the type of texture (png vs dds) can have big impact on loading times

Stars have almost no impact on RAM usage, the worst offenders are planets with a lot of textures. Basically all the ram usage you see using GN comes from the stock game and the planet packs. GN itself adds at most 100mb to the RAM (I have never tested it, but I would be surprised if it was more than 50mb tbh)

I never use EVE or Scatterer and everything loads fine. You will miss out on some features but at least you can have less RAM usage

Sounds like Kerbalism is hardwired to assume the central body of the galaxy is the only sun. This issue needs to be solved by the devs of that mod. There is nothing I can do about that.

@aluc24 The only real bug that I'm aware of is the kopernicus bug where the ksc scene looks bad bacause kerbin is reparented. And the stuff mentioned earlier in the thread about the sentinel parts not working properly. However I haven't put in any effort to make sure the mods you mentioned work on GN. Some should work out of the box (like FAR/MJ/KER/KAS-KIS/Interstellar...) Some mods don't allow multiple stars and so they are not compatible until the devs fix those problems (DOE, CC packs) Some will require custom configs for GN which I don't have time to make and so will work only if someone decides to make those cfgs (EVE/Scatterer) Other than that, I also have not done any work on career stuff because there's little to no reason to make a career game in GN since going interstellar would require finishing the career beforehand

Yes just rescaling is pretty simple (I've already considered adding it to SD) The problem is balancing all the parameters properly, like jump height, ragdoll height and stuff like that