Sigma88

mass, gravParameter and geeASL define the same property of the planet they are all calculated one from the other, so you just need one of the 3 rules are: if none are defined geeASL from the Template is used to calculate mass and gravParameter if only one is defined the other two will be calculated from the one that is defined if more than one is defined gravParameter takes priority over the other two, mass takes priority over geeASL math used to convert: geeASL = ( gravParameter / radius^2 ) / 9.8065 gravParameter = mass * 6.67408e-11

that's just about the only meaningful thing you can do in the cfg you have name and cap name is required to know which body you want to apply the cap to, and cap is the max total science gained from that body

like Beverly

Sigma ScienceBalance This mod provides a new way to balance science in KSP. How to use This mod will put a hard cap on science gained from specific bodies. You can use a MM patch to edit the settings and add science cap to each planet. Settings Current settings are: SigmaScienceBalance { messageText = <string> messageDuration = <float> Body { name = <string> cap = <float> } } messageText is the error message displayed when science cap has been reached for a certain planet messageDuration is the duration the error message will remain visible on screen Body defines the science cap for a specific body (name) Downloads [Latest Release at GitHub] If you want to contribute to my caffeine addiction: Don't expect anything in return other than my sincere gratitude. Changelog v0.1.0 - First Beta Release Credits @Papa_Joe for suggesting a way to clear screen messages License All Rights Reserved

this might help you understand the math we settled on https://github.com/Kopernicus/Kopernicus/issues/166 Thomas is the one who implemented the code so I'm not 100% sure I can help you with the coding part. but I can try

I'm not sure if what you are seeing is a bug or a result of the new feature. with 1.3.0 kopernicus now can calculate ec/s from multiple stars, which means that if you have 50% exposure from 2 stars you get 50%Ec/s from the first and 50%Ec/s from the second. Ec/s also varies with distance and luminosity of the star, as always.

I think this is a common issue for mac and linux users. I'm not 100% sure but I think the only solution is change textures to png try this patch, maybe it helps: @Kopernicus:FINAL { %useOnDemand = False } put that into a .cfg file, in your GameData folder. if this doesn't help, then you'll need to convert all textures to png EDIT: it's either change dds to png or move textures out of PluginData, not sure wich one

usually I don't give support for older versions of the game, but since 1.3.0 just came out, I guess I can take a look if you click on the nyan cat in my sig you can find a list of files I need to debug your issue.

-

added this

yup, that's the general aim of the mod, I didn't put much effort in managing the career part of the mod (mostly because there's not much career left to do when you can go interstellar) changing the planet setup midgame is not the best idea, if TransKeptunian still works you might find that mod the best solution to add planets on a OPM install

it's not assured that multiple packs breaks the game, but it's a possibility. some planet packs provide a list of compatible planet packs, so that might be a place to start. when adding / changing planets it's always a good idea to backup saves and start a brand new save for the new planet configuration my mod generates multiple stars and loads every planet pack you install in orbit around a different star. GN is more a "interstellar exploration" pack, rather than a career pack. so if you are looking for a career game you are better off getting planet packs. there are some compatible with OPM, TransKeptunian and NewHorizons come to mind, and I think @GregroxMun have one as well but I can't remember if it has been released already

@Gameslinx I don't think it would be a problem for you to keep the stock-alike tag, I was just explaining why you might see somebody say it isn't

it's worth noting that "stock-alike" is mostly used as an indication of visuals rather than size. so I think it's fair to classify your pack as non stock-alike. much like SSRSS is called "Stock-Size" RSS, I would classify your pack as "stock-size" but not stock-alike.

if it's a planet pack and it's written properly, then it will work with SD. if your kerbin has not been changed it means that you either installed it wrong or the mod you are using is somehow breaking SD. since from looking at the forum thread I don't see anywhere mentioned that the mod changes the planets, SD should work. worst case scenario the clouds will load too low and clip through the mountais if you want me to look into your issue, click on the nyan cat in my signature, upload the file requested and I will take a look use the minimum amount of mods required. if you have a gazillion mods I'll just ignore the files

I don't know, I haven't tried. my suggestion would be to backup your game and try

I guess it could be possible to show "current" and "latest", on the right side, where the version numbers are instead of showing yellow version number, you could show 2 version numbers, one green under "current" (to show that the current install is compatible with the current KSP used) and one blue (or other color) under "latest" (to show that the latest version of the mod is compatible with the latest version of ksp) or you could even keep the one version number like now, but change the color coding: - red: current version of the mod is not compatible with the installed version of ksp - yellow: current version of the mod is compatible with the installed version of ksp, but the latest version available is newer and is compatible with the installed version of ksp - green: the current version of the mod is the latest available, and it is compatible with the installed version of ksp - blue: the current version of the mod is compatible with the installed version of ksp, the latest version of the mod is compatible with the latest version of ksp (and the installed version of ksp is not the latest)

I think it's ScaledVersion/Light/luminosity but I never checked if it actually affects heating as well (I usually edit it for Ec/s of solar panels)

I like the idea of relegating miniAVC to it's own folder, it is definitely the option I like the best of all the ones I have read making KSP-AVC notify users only if the newes version available is compatible with their KSP version sounds like a very good idea as well I never noticed if it already does this

this is stock (no mods installed) and this is Stock + Kopernicus + ModularFlightIntegrator + ModuleManager I'd say they look pretty much identical and this is what you want: it's probably a custom sun flare, maybe even with a custom brightness curve

did you report this to the mods that change the sun ? because it's most likely them that can solve the issue since that is not the stock sun but a modified version

I don't think adding that would be a detriment to the mod, but I think that for AVC that wouldn't make much sense, you would never use the feature because you would just not install the mod as for miniAVC, I guess it depends on your playing style... my ksp folder has tons of different GameData folders, because I constantly change the mods setup of my installs. this means that every time I create a new GameData I would be asked to optout if you have only one GameData and don't ever change it, then the opt out is fine I think the problem here is intrinsic in how miniavc works. if you remove the concept of "opt out" then all the discussion becomes moot, because only those who opt in ( = install KSPAVC) will get the notifications

yes I get the point, but still for every 1 of those you will gain 10 that are annoyed by miniAVC

yes, that worked out great for kopernicus people just ignore the popup window and flood the thread with complaints that their game just broke In my experience popups never helped, but maybe I was unlucky

I don't honestly KSP-AVC is there, if anyone wants to use it it's available. no need to force it down their throat. there is really no upside of having it installed other than annoy people who don't want to have it installed. since I feel like KSP-AVC is very useful, I always put a link in the OP of all my mods. and I list it as "supported" I don't think sneaking stuff into people games is a good way of doing mods problem with that is, everytime you restore your gamedata from a backup you will get the notification or if you have different GameData folders, all of them will require the opt out. and after all, what would a dev really gain from forcing miniAVC into his mods? it's not like it gives you important data about the usage of your mods or anything... and to be clear, I don't have anything against miniAVC itself, it's just that I don't understand why anybody would want to put it into their mods maybe someone that uses it can illuminate me