seanth

Isn't the monolith trapezoid, though? so 1 wide, 4 long for the base 9 tall and for the top 1 wide, ? long

Aren't the monoliths isosceles trapezoids? Saying they are 1:4:9 doesn't give what the relationship between base length and the top length

The Monoliths in 2001 have dimensions with ratios of 1:4:9, but KSP monoliths are not strict rectangles. Anyone know the dimensions of KSP monoliths?

It's less a question about TBG updating and more a question about Kopernicus updating. Looks like Kopernicus is updated to 1.6.0. After holidays and a gnarly respiratory illness I'm adding the procedural water-world code and checking to make sure TBG files still work ok with 1.6

@Bej Kerman that's a cool idea. I can definitely see the appeal to the BUT, I feel like that should be a fork in the project. For some situations it's nice to have the older parts remain as stand alone parts.

There is this: https://github.com/StollD/PlanetaryProcessor As of right now I can't figure out how to use it, but maybe it would do what you're suggesting. It's a good idea (though would be slow for that first galaxy generation)

re scaledspace models: no. Seen from the tracking station the planets look like uniform, boring spheres. I'm considering what to do about that. Those are all good ideas. Right now I'm just taking baby steps toward fully procedural planets. It turns out the math for calculating radius from mass and crust composition are tricky. Procedurally generated atmosphere types and KSP curves are another layer of complexity.

Coming soon: 100% procedurally generated water worlds in the habitable zones of stars

Not dead, but real-life has been suuuuuper busy for me the past few months. There's no plans right now to replace the starting system with a new system. It would be relatively easy to do, but I think it makes sense to get other things working before doing that. Having said that, the code is all up on github, and I encourage people to go ham on it.

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

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

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.

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

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.

Can you post what version of Kopernicus and TBG you are using? And can you elaborate on where you experience weird gravitational things happening?

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.

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

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.

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.

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.

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."

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

I'll throw something up on github

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?

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?