seanth

Maybe not.

I decided to do a sort of roleplay on career-hard starting with the idea of what would a space program be like if it started with ideas like the German V1 and Messerschmitt, but never made a V2. That means planes that primarily land in the ocean (since the retractable wheels are mid-tech tree I have reached a weird point in the tech tree where none of the available nodes are very useful. I could unlock Aerodynamics, but it doesn't really help me. Gives me the J-33 engines, but honestly the J-20s are fine for my spaceplanes and boosterplanes. The LF-800 and external fuel duct are very attractive, but it gives me Oscar-sized tanks without any Oscar sized engines. And why would the player want or need a Rockomax decoupler or adapter before they have the 2.5m parts? Even the description of some of the parts is off. For example: The problem is the Rockomax Brand Adapter is offered in a node before any other Rockomax parts, so what are you adapting to your 1.25m parts to, exactly? At least now that I have unlocked the Fuel Systems node I have a use for the Rockmax Adapter. I might actually but access to it now. The tech tree is pretty much made to force players to follow the sort of rocket-development path we saw on Earth. I'm finding it fascinating just how much changes when you focus on planes vs rockets with capsules. Some images of the jet-plane based program I'm running: Oh, and why is fuel pumping something you can start doing once you upgrade the RnD building? Fuel transfers feels like it should be something researched in the tech tree. Playing on hard has given me a _much_ better idea of what feels broken. 900,000 credits to upgrade the R&D building so I can transfer fuel to something I docked with in orbit? That is _a_lot_ of credits on hard, and super difficult to get without grinding through endless tourist transports.

Dearest Koogie, With 0.3 out, I thought you might be interested in a sort of time line where things are going. @daniel l., @bunjatec, and I exchanged messages a bit about what a timeline of what is coming might look like: 0.3.0.5: Planet and "astroid" generation streamlining. We're well into this, now. @bunjatec moved all the existing planet generation code out of the main file and put them into subroutines in imported files. Moving things into external files will (hopefully) make the code easier to grok, maintain, and will definitely cut down on redundant, repeated, redundant code. What needs to be done now is use a template system like what we did with stars instead of relying on lots of print statements. This is my job, so I'm the bottleneck at this point, but this should probably be done this week. 0.3.1: Planetary discs. Each star has a plane, and the planets orbiting it will be in that plane (with some variation). There can be a few planets with oddball orbits (rogue planets that were captured), but they will be rare. This will cut down on the crazytime looking systems. Placing the planets in their semimajor axes will still be using the existing methods, but we have plans for improvement further along. 0.3.2: Unique Planets from other planet packs. This will be the first release with unique planets being placed. Some of the code is already in place, but needs work. The idea is that the user can just add a single line to an existing csv file, and the planet they list will appear in the generated galaxy only once. If they want it to appear more frequently like the stock planets, they can add it to the csv file in the Data_Folder. Hopefully we'll have a video tutorial up for people explaining how to use other planet packs with TBG at this point. 0.3.3: Better placement of planets. This is a big step. We used real-world scaling relationships for main sequence stars and implemented them into TBG so that you start with just a mass and get all the star's attributes (radius, colour, temp, etc) from there. We'll be doing something similar with planets, but in this case we'll be placing planets in orbits that reflect their characteristics (habitable worlds in the habitable zone of their parent star for example). This will be complicated, but pretty exciting and cool when done. 0.3.4: Better placement of moons. Take the work done on planet placement and apply it to moons. Make sure there is some smarter calculation of relative mass of moon:parent so the moon isn't so big that you have a binary planet system. 0.3.5: True procedural planets. @daniel l. has previewed some of his procedural planet work and we definitely need to roll it in. There are some minor concerns about KSP crashing when there are a _lot_ of procedural worlds being made, but maybe it's enough to just warn the user. That's all. Just wanted to give you an idea of what's going on.

In general, I encourage people to list issues on github since it'll be easier to track. Listing them here is cool, too, since it lets others see what some bugs are. With that said, on to the issues These are related issues. I agree that seeing the other stars during the day is not so cool, and the galactic glow is overwhelming. It's on our mental list of "things to look into" but I'm honestly not sure how to fix it yet. I think someone more familiar with Kopernicus would be able to advise/fork-and-fix this, though. Not sure there is much that can be done in this. If you click on "Core", mousing over the other stars should give you info. That's by design. We were facing a pretty annoying bug that @daniel l.solved by making Kerbol the furthest star from Core. We laid out a rough roadmap for what we'd like to see leading up to the 0.4 release, and it's pretty much all about planets. Fixing the crazy-time orbits is very high on the list. Glad people are enjoying it. \o/

I've been sick. It's all good. I'll try and update github with all your changes tomorrow

Cool! I was hoping to get Kethane working with To Boldly Go at some point

Yup. I second this. If you watch the file count in GameData/Kopernicus/Cache and the file count keeps increasing while your load screen seems stuck, just be patient. Grab a book or something. Think about the Old Days when it could take 15min for a computer to boot up.

How big of a galaxy did you make? If you send me info on the seed you used and your settings, I can replicate what you made and test.

The very first language I learned was basic on a C64, but these days I'm more of a python and fortran guy. It didn't take me long to catch on to qb64, though I am sure I am doing some things "wrong". I agree that having subroutines be grouped in separate files would make the code easier to read, but I couldn't figure out how to do it in qb64. I spent maybe 15min looking, and then decided my time was better spent writing code. When I first started, I wrote a python version of what daniel had done, and I used it as the basis for the first round of code optimization. I had optimized the creation of planets, but haven't moved that code over because of the nebulous "roadmap" in my head about what should be focused on. If you look at https://github.com/kjoenth/To-Boldly-Go/blob/967752d955c311224d0a9e900b9f75d2bdbb25a7/python version/GalMake.py you'll see the functions "makeABody" and "PENABLEISYES" are the functions for making planets. It just hasn't moved back to qbasic. I'd still like to provide a headless python version, but I'd like to see the qbasic version function complete first. If you look at the code, my comment style has been '#. That's with the expectation that I'll move the code over to python. Qbasic uses ' to mark comments, and python uses #. This is @daniel l.'s baby, and he knows qb64, so I'm inclined to keep the main thing as qb64 for now.

Yeah, there is a github: https://github.com/kjoenth/To-Boldly-Go The 0.3 candidate is the McMahon branch. After 0.3 will make a switch in focus. When I started helping @daniel l., I began by economizing code into functions and subroutines (0.2.5) and then redid star generation so it's all procedural (0.3). Next up is revamping planet-related code by moving the planet code to use subroutines (like you suggest), make sure moons are below a threshold mass compared to their parent body, etc. So, your short list is pretty similar to things I'm interested in going next . I'd say fork away. Maybe PM me and we can divide up tasks so we aren't stepping on each other's work? I think @daniel l. has specifically said he wants to maintain planets being able to have the erratic orbits, but I was thinking having an option where the user could use disc vs erratic orbits.

I was actually thinking about this exact thing this morning. It'd be pretty sweet to be able to drop a sub through the surface of an iceworld to explore the oceans

long story short: make-believe person.

Dearest Koogie, One of the unreported bugs has been that there are rare instances where two different stars have the same name. Based on the name generation code I explained in a previous letter, it's bound to happen. I was working on fixing that problem today and have a working solution that also avoids the bug where a generated star name matches an existing template name (like 'Jool' or 'Sun' or 'Mun'). This method will also avoid the wasteful reading of files every time a star name needs to be generated QB64 apparently doesn't have lists, so I've been using arrays. But I also can't do a sort of boolean query and say "is X in array Y" without looping over the array. What I have done is made a blank array that has as many elements as star names the app will need. Next, it uses the Prefix and Suffix files to make a random star name. Now we loop over the names of template planets that are in TBG_Planet_Templates.csv. If the star name happens to match a planet template name, "o'" (as in "of" or "of the") is added to the end and another suffix is chosen. This method results in names like "Joolo'turus". Next we do a similar loop where we see if the proposed star name has already been added to the array of star names. Instead of "o'", "a'" is used...just to provide some variety. This way we get extended star names like "Kerurya'in". There is the possibility that the extended star name has been used. When that happens, another "a'"+suffix is added. So we might see star names like "Rananta'unea'daa" or even "Joolo'turusa'lou". You get the idea. I'm too lazy to do the probability of star names repeating--and the probability will change if the player ad/removes prefix/suffix/template names--but I generated 900 stars and 146 of them had to have their names modified as I explained. Until next time. -seanth

YAY! We still have some tweaks that need to be made regarding star colour and how far from stars planets are spawning, so we might try and enlist you for testing again. Glad it's working now.

@The_Right_Arm: fixed the Mun/Kerbin orbit problem, and launch pad/runway launches work again. To explain, it's time for another letter to Koogie ----------- Dearest Koogie, The bug where the Mun was stationary was an odd one. I ultimately traced the problem to how we make star names. As you know, in To_Boldy_Go/Data_folder/ there are two files used to make names: TBG_Prefixes.txt and TBG_Suffixes.txt. The process is probably obvious in that there are a series of short letter combinations in Prefixes and short letter combinations in Suffixes. You concatenate them and get combinations of names. The good thing to this approach is that, since they are text files and not hard coded, the player can add or remove to the lists and customize their potential names to their heart's content. What happened in this case was that a generated name just happened to be the name of a stock planet: Mun. The prefix was "Mu" and the suffix was "n". The resulting cfg tried to make a star called "Mun" and make it orbit the Core. What we ended up with was the stock Mun orbiting the Core, and since it was supposed to be a sun, there was no orbit line shown. This explains a whole slew of reported bugs regarding the orbits of stock planets. For example, the bug where Jool doesn't seem to be orbiting anything and has moons named in TBG style. Turns out there is a "Jo" prefix and a "ol" suffix. Put them together and you get the attempt to make the star "Jool". There are several other potential naming problems. Ker/bin, Su/n. There could be others, but I stopped looking once I understood the source of the problem. The solution is to add a bit of code that looks at the generated name and makes sure it doesn't match a template name, or any previously used name in the galaxy. It has to be at the code level because there's no guarantee that players won't accidentally(intentionally?) put in prefix/suffix combos that might be galaxy breaking. As a fix for testing purposes, the "Mun" star was renamed "Munn" and the new tester galaxy is at https://www.dropbox.com/s/p93pg5atzh8hvv6/galaxy.cfg?dl=0 Yours, seanth

Heh. That is a _galactic_ corona. It's not coming from "Core". It's the sum of all the stars present. I agree it is pretty overwhelming, though. I am not 100% sure how to dial that down, but it's on my list. Confirmed the Mun isn't orbiting anything. Funnily enough, Kerbin is orbiting the Mun (wat?). I will look at that right after I finish typing this. Confirmed launching problems. I suspect the launch problems are somehow related to Kerbin orbiting the Mun...which I can't easily explain. Looking into it right now, though.

Skip to 6:01 and 9:36 to skip my blablabla and see the lack of terrain glitching and the galaxies. Watch the whole thing for a peak at some things that will be in 0.3

When I get a chance this morning I'll make a "lite" version of that galaxy; maybe it's too processor melting for your computer? I'll also provide some images and videos of the large galaxy on my dev computer

A forum isn't really a real-time chat. An IRC channel or a free slack channel would be a better fit for real-time debugging and help

Nope. No changes in asset location relative to 0.2.6.5 We need a slack channel for this lol

<Rocks back and forth with fingers crossed>

Just to clarify, like @daniel l. said, that galaxy.cfg on dropbox isn't a update to TBG: it's just a test galaxy I made using unreleased code changes and hand edits to try and fix the missing KSC/terrain glitches/physics wat. If the test galaxy works for people, the changes I made by hand will be worked into the code of TBG <eagerly awaits an update from @The_Right_Arm> :nervous: ...

Oh, I get it. Don't make a fresh galaxy. Just download the galaxy.cfg from dropbox, put it into the TBG dir in the KSP GameData dir and launch KSP. When you make a new galaxy, you overwrite the galaxy.cfg you just downloaded. The first three lines of the galaxy.cfg should read: Yes. Version is spelled incorrectly

The file I posed should not need any patching. It does not move the sun, or reparent any of the stock planets or moons. It should just work All my work is done on Mac OS, but that shouldn't matter.

This can't be the test galaxy I posted. There are too few stars and their colours are all wrong. I you using the galaxy.cfg I put on dropbox, or did you mean you made a new galaxy with 0.2.6.5 or 0.2.6.6? EDIT: Doh. Helps if I read more. That last image is a galaxy you generated. I'm still confused by the Jool I and Jool II though: I looked in the dropbox galaxy file I posted and there's no occurrence of "Jool I" or "Jool II" in the file. Could there be an older TBG galaxy file in you folder messing things up?