seanth

Members
  • Content Count

    832
  • Joined

  • Last visited

Everything posted by seanth

  1. About: To Boldly Go (TBG) is a stand-alone application that allows users to create a procedural galaxy. It leaves the stock game's planets untouched, but adds new stars, planets, and moons--all using real-world calculations (adjusted for the oddities of the in-game physics). The original author, @daniel l., has asked me to take the lead on development, and after a long time of inaction I have finally made a new thread. Current release: For KSP 1.4.5-4 (requires Kopernicus 1.4.3.2): https://github.com/kjoenth/To-Boldly-Go/releases/tag/0.3.1.2 Instructions: Install Kopernicus Copy the contents of the GameData/ folder to KSP's GameData/ folder An example galaxy is included with TBG, but if you want to make your own custom galaxy, launch the GalaxyGen.exe application and follow the instructions. Maximum recommended galaxy size: 200 stars. (KSP 64-Bit) Launch KSP Depending on your computer and the number of stars+planets+moons in your galaxy, it might take a while for KSP to start up. If you think KSP might have frozen, look in the Logs/Kopernicus/ folder to see if files are being generated Eeek! A bug!: By all means mention things here, but another good place to report things is at https://github.com/kjoenth/To-Boldly-Go/issues Current features: Automatic of customizable galaxy generation Use of a seed so you can share more easily share your galaxies with friends. An output txt file detailing the details of your galaxy Star types (O, B, A, F, G, K, M) with procedurally determined colours based on their mass. A wikiEntry html file that is generated for each galaxy that provides details for stars in the generated universe Different galaxy types: ellipse, disc, or cluster Galaxy age (impacts the numbers of star types automatically generated) Ability to have no planets, or no moons. Ability to determine exact numbers of each star type. Add in planets/moons from any start pack. Instructions here. Whether stars are visible from Kerbin depends on their luminosity and distance Optional integration with ResearchBodies Pictures or it didn't happen: @daniel l.'s imgur album: KottabosGames review of an earlier version: Short video showing the "milky way" as seen from Kerbin:
  2. Dearest Cugi, I spent the last several days converting existing QBasic TBG code to python. There's no plan to abandon the existing version of TBG, but the python version is "working" in that it is generating galaxy, wiki, and info files. Are the calculations actually doing what they should? That remains to be seen. I will say this, though: being able to delete hundreds of lines of ghetto code I wrote in QBasic to approximate pythons string formatting calls felt great. Survey results are in! Planets in habitable zones narrowly won, with procedural planets close behind. I think, though, that there is enough overlap between those two ideas that I'm going to investigate some procedural planet mods. For example, making sure rocky planets outside the habitable zone lack atmospheres and oceans. "BUT WAIT!" I hear you cry. "Titan is outside the traditional habitable zone and it has an atmosphere and liquid on its surface." True news. As I'm working on the planets (and moons?) in the habitable zone of stars, I'm going to give some thought about how to handle more exotic planets/moons with atmospheres and liquid _outside_ habitable zones. Until next time. -me
  3. Yeah. Snakes-on-a-plane is the in-process python port. I feel like before I start farming out tasks I should get the bare core of TBG working in python: read star templates, generate basic galaxy cfgs with only stars, and write the info text file and star wiki page. Once that is done, I think it will be easier to start breaking things into tasks. Your idea of using projects is a good one, and I'll set something up tonight or tomorrow. I'm not sure, to be honest. I do most of my dev and testing of TBG on a laptop with 16gig and 2.8 GHz Intel Core i7. You can probably run Kopernicus and TBG on your computer, but you might need to generate a smaller galaxy
  4. You would have to upload the images to some site and the past the url to the image your message. If I have time this evening, I will make a galaxy with your seed and see if I can replicate your problems. Can you explain in more detail the problems you experience with ships being thrown out of systems? @Dryo: could you also post the text of the GalaxyGen_info file? That will help me recreate your galaxy for testing.
  5. Could you post some images of the lighting problem and the seed for your universe? I tested lighting on the dark sides of Kerbin and the Mun and didn't see any problems. I want to make sure I can replicate the errors you are experiencing
  6. I am. In fact, I started doing some very basic porting of things to python. I can make a branch of Janet if people are interested in helping with a python version.
  7. Can you post what version of Kopernicus and TBG you are using? And can you elaborate on where you experience weird gravitational things happening?
  8. Minor update that hopefully improves star colour, and maybe gas giant textures. If anyone is running TBG with ResearchBodies, I'd love to hear about how they integrate with the new patch.
  9. Cool. What's your thought on what a python UI might be like? I keep thinking about using something like cherryPy so a python version of TBG would use a web browser as the UI
  10. I might have some time tomorrow to make a video showing step-by-step how to install and use To Boldly Go, but what @The_Right_Armsaid is correct. Now, this image might be slightly different than what you find when you download the most recent release from github, but that's because there are some minor changes that will be appearing in the next release (will be uploaded tomorrow or Friday): The exe makes the galaxy.cfg file, which is the important bit. That's the file that the Kopernicus mod uses to know how and where to place all the stars, planets, and moons.
  11. Dearest Cugi, In my last missive, I talked about generating brightness curves for stars in TBG, but I left out a critical component. Mainly, what value to use when the first key value is 0 (i.e. very far away from the star). I thought I would very briefly talk about how I dealt with that, and what it means in terms what stars can be seen from Kerbin. KSP defines the locations of objects (stars, planets, moons, ships, etc.) using polar coordinates. This means that an object's location relative to the body it orbits is described by an angle(argumentOfPeriapsis) and the distance from the body (semiMajorAxis). As an example, when you being a new game in KSP, Kerbin's location is defined as: When generating stars in TBG, each star, including Kerbol, has a location relative to a galactic core object ("Core"). We have the distance of each star (semiMajorAxis) to the Core, and their angle. What we lack is the distance from Kerbol to each star. We can solve this relatively easily if we convert the star's polar coordinates into cartesian coordinates that will give us X and Y values. Once we have cartesian coordinates for all the stars, it is simply a matter of using the distance formula to solve for the distance between Kerbol and the other stars. What, you ask, does this have to do with what stars can be seen from Kerbin? The human--and presumably the Kerbal--eye has a minimum brightness level it is able to detect without the aid of telescopes. Dating all the way back to at least Ptolemy astronomers have grouped stars by their apparent magnitude as seen from Earth. You can figure out the apparent magnitude of any star if you have its distance from the observer and the star's luminosity. There is a pretty good relationship between star mass, temperature, and luminosity, so TBG already calculates the luminosity of each star starting from mass. As explained above we now have the distances between other stars and Kerbol, so we can solve for the apparent magnitude. This matters because, the best human eyes can't see objects with an apparent magnitude greater than around 6.5. I decided to give the Kerbals better eyesight, so their cutoff is 7.0. I may make this a user editable value in case people want to have more stars appear in the night sky. Boring so far, right? Here's where it gets sort of cool. In the apparent magnitude scale, the lower the value is, the brighter it appears. Kerbol, as seen from Kerbin, has an apparent magnitude of -26.83. For those interested in playing around with some values, or seeing how things are calculated, I put together a spreadsheet that does many of the calculations that TBG does. Through trial and error, I found that the smallest setting that the lowest value in the brightnessCurve that can be seen from the surface of Kerbin is 0.005. Note that this is not the apparent magnitude of the star. How to correlate apparent magnitude to a value that can be used with with the brightnessCurve? Long story short I settled on the equation where e is 2.718282. As a test, if you set the first key set of the brightnessCurve for all stars to: All the stars will appear to be the same size as Kerbol when seen from Kerbin. So now I had a way to link apparent magnitidue to apparent size of a star in the sky. Any star with an apparent magnitude of greater than 7.0 gets a value less than 0.005, making it unseen. The end result of this is that unless small stars--like red dwarfs--are very close to Kerbin, they won't be seen in the night sky. This also allows TBG to automatically generate files that work with ResearchBodies, allowing players to discover distant and/or dim stars.
  12. Updated release. 0.3.1 changes: better coronae scaling as you zoom in on them whether you see a star from Kerbin depends on the star's luminosity and distance from Kerbin optional integration with ResearchBodies Another letter to Cugi and a video showing stars in Kerbin's night sky soon.
  13. 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."
  14. 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 (https://kerbalspaceprogram.com/api/class_sun_flare.html). 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
  15. I'll throw something up on github
  16. 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?
  17. 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?
  18. 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)
  19. 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
  20. 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.
  21. 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? https://en.wikipedia.org/wiki/Apparent_magnitude#Table_of_notable_celestial_objects for some info that might help.
  22. 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.
  23. 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).
  24. Absolutely. All the code is up at https://github.com/kjoenth/To-Boldly-Go 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.