• Content count

  • Joined

  • Last visited

Community Reputation

175 Excellent


About seanth

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

2,253 profile views
  1. AH! I figured it out after looking closely at your screenshot. You were capitalizing the "A" or "C" at the "(CUSTOM/AUTO)(c/a)" stage What a weird bug, but as the original designer said "please do not use capitalization for anything other than the Galaxy name."
  2. Dearest Cugi, Oooooh, this is going to be a long one. tl;dr: —————————————————— For some time I have been struggling with star brightness. After some updates to Kopernicus star brightness was so overwhelming that the view from KSP or in he map view was just white with glare. I've desperately wanted to focus on planet generation, but the issue of star brightness has been a ongoing problem. Sooooo, I recently decided to lean into it. I realized that several design goals I had could be wrapped into one if I really looked closer at how bright stars appear in KSP: Have only stars with a certain apparent magnitude be visible in Kerbin's night sky. Integrate the ResearchBodies mod with TBG so stars that are too dim need to be discovered. Have star flares scale correctly as you zoom into them in map view. The problem is that, as far as I know, no one knows _exactly_ how the brightnessCurve works. The Kopernicus mod ties into how KSP is written, and KSP uses the Unity game engine and relies on the C# language. The brightnessCurves look like this: brightnessCurve { key = -0.01573471 0.217353 1.706627 1.706627 key = 5.084181 3.997075 -0.001802375 -0.001802375 key = 38.56295 1.82142 0.0001713 0.0001713 } and are technically animation curves used by Unity ( I don't use Unity, but if I understand correctly the first value in each key is a time index, the second is a magnitude, and the last two values are tanget values describing the curve. Values three and four appear to be optional as a backward-compatible feature of Unity. But how does this apply to brightnessCurves for stars? This is the mystery of our faith. There are old IRC transcripts where people that have worked on Kopernicus have tried to puzzle things out, and the concensus is: The first value is "distance" but 0 means far away The second value is "brightness" The brightness is partly modulated by another value for a star: "sunAU" Now "sunAU" is a weird parameter. Reading it, I assumed it stood for "Sun-Astronomical Unit". An astronomical unit(AU) is defined as the distance between Earth and the Sun. In KSP, I assumed it would be the distance between Kerbol and Kerbin (13,599,840,256 m). This was confirmed by seeing that KSP's stock sun had a sunAU set to 13599840256. But how to adjust this for other stars? Technically an AU shouldn't change, but the KSP API documentation implied that the sunAU was related to the brightnessCurve, so it probably should change from star to star. One of the developers that has looked into brightnessCurves the most is @Sigma88. At one point he shared the following: Which seems reasonable to me. If you had a new star 2x the radius of Kerbol, your multipler would be 2.0, so your new star sunAU value would be 13599840256m*2 = 271996805124 m That's the easy part: simple to code into TBG. Next came the tedious bit. In my day job, I do a lot of analysis of data looking for ways to model it. There aren't a lot of brightnessCurves out there that just work for stars that range from tiny red dwarfs to giant blue giants. I needed some way to generate things that would apply for all the stars in the main sequence. To get there, I started hand crafting a brightness curve for a blue giant. I would alternate actual values with zero "brightness values" so I would have visual cues in KSP's map view to tell me when I would transition from one key to another. key = 1 100 key = 2 0 key = 5 100 key = 6 0 key = 10 100 key = 11 0 key = 15 100 key = 16 0 key = 20 100 key = 21 0 key = 26 100 Using a piece of paper for scale on the screen, I adjusted the values so the flare around the stars would be consistent in size at each key, and arrived at a curve like: key = 1 0.8 key = 5 3.5 key = 10 7 key = 15 11 key = 20 15 key = 26 22 The initial plan was to do this for each of the OBAFGKM star types and use each curve type as needed, but as a test I tried the curve I had made with a red dwarf and it Just Worked™. This was great news, but I wanted an equation that would give me the "brightness" part of the key using that first initial "distance" value. Some simple analysis later and I had: "brightness" = 0.74*"distance"^1.01 The values derived from the equation were not exactly the same as what I had manually gotten, but are close enough that I'm happy to use them. key = 1 0.74 key = 5 3.76003099 key = 10 7.57236814 key = 15 11.4047007 key = 20 15.2500763 key = 26 19.8771814 This has worked beautifully in terms of how star flares look as you zoom in and out of them in map view. They scale smoothly and logically in relation to the star body. It doesn't address overall star brightness as seen from Kerbin though. For that, I need a key with a distance of 0, and the brightness would have to be related to the apparent magnitude of the star as seen from Kerbin. That is a whole other in-depth discussion though. Next time I'll talk about the Law of Cosines, star luminosity, apparent magnitude, and seeing stars in Kerbin's night sky. Yours, -me
  3. I'll throw something up on github
  4. I am experiencing an odd bug, but I'm not sure whether it should be reported on Github or not I am working on providing support for ResearchBodies for To Boldly Go (TBG). TBG makes a galaxy file to be loaded by the Kopernicus mod. The problem I am encountering is that I will put a telescope in orbit around Kerbin, go to map view, select a very distant star to observe, use SAS to auto point at the body, and parts instantly overheat and explode. My only thought is that there is some weird bug related to targeting very distant objects. Soooo, should I throw this on the researchbodies github bug reports, consider it a weird KSP bug, or a Kopernicus bug?
  5. That is super strange. I've never encountered that bug before. Could you DM me any details you think might be important to help me figure out what is going on so I can try and help you out?
  6. The exe should be fairly straight forward to use: It first asks you to name your galaxy. This has no impact of the generation of the galaxy, but will result in a meaningful file that will be generated at the end. Next it will ask whether you want a automatic or custom galaxy. A automatic galaxy will choose the settings without your input. A custom galaxy will generate a galaxy using your input as guidance. More on custom galaxies below. The seed is any series of numbers you want. This exists so it will be possible for other people to generate exactly the same galaxy as you if they use the same seed. AUTOMATIC: If you chose "automatic" the application will display the numbers of stars, planets, moons, and astroids generated If you are happy with the results, type "y" and the galaxy.cfg, "Galaxy Gen" txt file, and "wikiEntry.html" files are generated. More on these at the end. CUSTOM: There are additional options if you chose "Custom" You can choose the galaxy age, 0 to 5. 0 is very young and 5 is very old. The age of the galaxy determines the numbers of the different star types: Blue Giants (O), Blue-while Giants (B), White (A), Yellow-white (F), Yellow (G), Orange (K), Red dwarfs (M), and Brown dwarfs (L-Y) You can choose whether you want planets generated or not. This is useful if you are just testing what sort of star types you want. If planets are generated, moons will also be generated. You can choose whether you want astroids generated of not. Astroids, in this case, are not the astroids that appear in the normal KSP game. These are just chunks of rock that orbit stars like planets. Next you can choose what sort of galaxy type you want to have: An ellipse, a disk, or clusters An elliptical galaxy is more spherical in the distribution of stars A disk galaxy has the stars distributed in more of a flattened disc The cluster option creates groups of stars that clump together to sort of make mini galaxies. I admit I always make disk galaxies, so there may be bugs in making the other types. If you find one, be a hero and report it on github. "Advanced settings" will essentially override the "galaxy age" setting. You get to explicitly define how many of each star type you want. If you are happy with the results, type "y" and the galaxy.cfg, "Galaxy Gen" txt file, and "wikiEntry.html" files are generated. OUTPUT FILES: "galaxy.cfg" -- This is the actual galaxy file that the Kopernicus mod will use to place the stars, planets, etc. "Galaxygen_Info-<your galaxy name>.txt" -- This file will record the generation options you used when making the galaxy, including your seed. This file is very useful to help me recreate problems people might encounter. "wikiEntry.html" -- This is a wiki file that lists the star characteristics of all the stars generated. It's modeled after the wiki entry for Kerbol, but upcoming releases will include additional information such as the star's absolute magnitude, apparent magnitude from Kerbol, location of teh frost line, and where the habitable zone is (min/max). "TBG-ResearchBodies.cfg" -- A file that will be generated that will allow players to use the ResearchBodies mod to discover and research distant stars, planets, and moons. This will appear in the next release (which is currently being tested)
  7. Good catch. Not sure how that error crept in. As a side note, you could report code bugs right on github. Issues tab-->New issue Last night I just started getting brightnessCurves working in a way that I think I can use in a procedural way. Thx to the people on the Kopernicus discord server for weighing in on the mystery of brightnessCurves. Once the code base is not in qb64 it will be much easier to generate de novo heightmaps. In python I could do it using PIL or any number of pre-existing tools. But in QB64 I have not even considered it. I'm sure there are similar tools for Java
  8. Another update: I have all the calculations related to the apparent magnitude of stars in TBG working, and a custom cfg is being made for ResearchBodies. What I initially found was that most stars were simply too far away to be seen (having an apparent magnitude of 7 or less). As a consequence I've started experimenting with making the galaxy smaller. Right now the galaxy is 4x smaller than I have had it previously and that is yielding good results. Star brightness in the night sky as seen from Kerbin is (predictably) much higher now, so I am working to adjust that. Once I'm done with that, I'll work on having module manager files automatically generated to adjust how telescopes work. At this point I think I'll actually have things to take pictures of.
  9. Small update: I'm working toward integrating TBG with some cool ResearchBodies stuff. To that end I have been including some code that calculates a star's absolute magnitude, distance from Kerbol, and from that I can calculate the apparent magnitude of any of the generated stars as seen from Kerbin. The average human has a hard time seeing anything with an apparent magnitude of 6.5 or higher (without using a telescope). What this means is that, with ResearchBodies, stars with a apparent magnitude above a certain level won't be seen in map view unless discovered with a telescope first. But, I turn to you: what should that cutoff be? Are Kerbal eyes better able to see stars than ours? Worse? The same? for some info that might help.
  10. Yeah, seems fine. It's GNU General Public License v2.0, so just saying where it came from initially is enough I think. Just a heads up though: Master is many, many updates behind the Janet branch. If you're building off of Master, it's pretty out of date.
  11. Sheesh. Why am I not getting notifications when people post. Make sure you have (at least) KSP 1.4.3 Install the Kopernicus mod Install TBG At that point, you have the option to just use the galaxy file provided. If you want to make your own custom galaxy and are on windows, launch GalaxyGen.exe in the To Boldly Go folder and enter the info you want to make a custom galaxy. If you are on a Mac, I have found that using a Wineskin works fine (on Mac OS 10.13.4).
  12. Absolutely. All the code is up at I'm currently working on the "Janet" branch and am focusing on planet-related stuff (like tidal locking, planets in habitable zones getting atmosphere's with oxygen, etc). The current code is in QBasic, but I have dreams of moving things to python.
  13. An update, and a tutorial on adding planet packs:
  14. seanth

    [1.4.3] Kopernicus (Release 2) - May 6

    A question about line feeds in body descriptions: I looked at the kittopia dumps for examples, and the Dres example shows \n\n, which is what I assumed it would be. The problem is that when I try it with descriptions for bodies I make, the \n are stripped out by KSP, but a new line is not made. I also tested \r and \r\n. Any advice? EDIT WITH EXAMPLES The input I have looks like: description = The Kraken's Lair\n\nthis should be a new paragraph And looking at the resulting file in Logs/Kopernicus/: bodyDescription = The Kraken's Lairthis should be a new paragraph