[INDEV]-[1.4.3] - To Boldly Go | An external application designed to procedurally generate an entire galaxy for KSP.

[Quontex]

https://imgur.com/a/nsjT9

 

Sorry for the double images, On my phone and no idea how to use the Imgur app. 

 

Another thing is that I usually get ~120 frames, However with that 'overbright' I'm getting 5.

[seanth]

5 hours ago, Quontex said:

https://imgur.com/a/nsjT9

 

Sorry for the double images, On my phone and no idea how to use the Imgur app. 

 

Another thing is that I usually get ~120 frames, However with that 'overbright' I'm getting 5.

What versions TBG, Module Manager, and Kopernicus?

[Not Sure]

7 hours ago, seanth said:

I do all the dev for TBG on a Mac, so yes. What version of module manager are you using?

 

Welp, that must have been the problem, didn't have MM installed. Is that in the OP? All I saw was kopernicus.

[seanth]

On a side note, @daniel l. suggested I make a new thread for TBG since he's not really involved anymore, so we will be moving to a TBG (continued) thread soon.

[Quontex]

5 minutes ago, seanth said:

What versions TBG, Module Manager, and Kopernicus?

Forgot about that.. Sorry

 

TBG - 0.3.0.5f

Kopernicus - 1.3.1-3

Module Manager - 3.0.1

[Not Sure]

Alright I got this working on mac, and i'd consider it playable if the lighting scaled with distance. In the flight scene everything is all white because every star is producing light as if it was 2 km away. Is this not supposed to be a thing or is this an expected bug that is planned to be conquered in the future? Thanks.

[FreeThinker]

On 9/13/2017 at 12:23 AM, seanth said:

Looking for opinions:

Over the weekend I was messing around with the free-for-use warp drive model made by ZZZ to make it work with RoverDude's "Alcubierre Warp Drive (Stand-alone)" mod.

  Reveal hidden contents

In my test using the provided galaxy file, I travelled from the Kerbol system to the nearby Tovsis system (~if my math is correct, it's about 8.08e16 meters, or 8.08 light years) in 3.5 kerbal days. The warp drive is set so high that it's basically unusable inside a star system; you zoom past any target even at the lowest throttle.

The existing warp drives in KSPI and Alcubierre Warp Drive (and maybe others) consume "Exotic Matter" which is made by consuming LOTS of electrical power. What if:

1. TBG provides the ZZZ model and appropriate ModuleManager files so that if the Alcubierre Warp Drive mod (or other similar mod) is installed, this special warp drive part is available
2. The existing warp drives remain unchanged for in-system use
3. The new ZZZ drive is only for interstellar travel, and enforces that by not working if too close to a body. For example, in the Kerbol system, you'd need to be out near Eeloo. 
4. The new drive _also_ uses "exotic matter" but we pretend the interstellar void is full of the stuff. That means we have a special part--like a bussard collector--that only works far away from stars. Sooo...like a reverse solar panel. The further away from a star, the better it works.

Taken all together, the player would be able to continue to use existing warp drives inside a star system, but get access to this new type of drive outside of the system. Once outside the system, the fuel for the new drive would essentially be free. The tradeoff being you need to get outside the system first.

I'm not entirely sure how to achieve #4 yet. Right now I'm imagining a modified solar panel part with an inverted powercurve{} so you get maximal "exotic matter" production far away from stars. 

I'm open to other ideas. 

Notice I have implemented the Bussard Ramjet in KSPIE, it can be used to collect fusion fuel from either interstellar voids, above the atmosphere or directly from stars.

[seanth]

Update: I ran some permutations of what could be going on. It could be ModuleManager. It could be Kopernicus.

Module Manager 2.8.1 + Kopernicus 1.3.1-1: works fine

Module Manager 3.0.1 + Kopernicus 1.3.1-1: works fine

Module Manager 2.8.1 + Kopernicus 1.3.1-3: eye bleeding

Module Manager 3.0.1 + Kopernicus 1.3.1-3: eye bleeding

[Not Sure]

Well, the post above certainly sorted out some things. But now there is kind of the opposite problem.. things are super dim! Maybe thats just how the universe is, but completely dark planets isn't something that is very inviting. However i did find this:

Sunrise lasts half the day... I like it.

(oh and the Kerbol sunflare is somehow visible through the star??? i'll pretend that's a some epic stellar ejection...)

[Galileo]

45 minutes ago, seanth said:

Update: I ran some permutations of what could be going on. It could be ModuleManager. It could be Kopernicus.

Module Manager 2.8.1 + Kopernicus 1.3.1-1: works fine

Module Manager 3.0.1 + Kopernicus 1.3.1-1: works fine

Module Manager 2.8.1 + Kopernicus 1.3.1-3: eye bleeding

Module Manager 3.0.1 + Kopernicus 1.3.1-3: eye bleeding

Kopernicus 1.3.1-3 requires changes to the light curves. 

[seanth]

Ok. I have worked out what the problem is. Good news is that it's a trivial fix; I didn't even need to change any code. I had included an IntensityCurve section in the templates but commented them out because, at the time, they didn't seem to do anything. That's changed with the newer versions of Kopernicus. So all I needed to do was remove the comments on the relevant block in the templates. 

Red hot: https://github.com/kjoenth/To-Boldly-Go/releases/tag/0.3.0.5g

Edited December 11, 2017 by seanth

[seanth]

16 minutes ago, Not Sure said:

Well, the post above certainly sorted out some things. But now there is kind of the opposite problem.. things are super dim! Maybe thats just how the universe is, but completely dark planets isn't something that is very inviting. However i did find this:

Sunrise lasts half the day... I like it.

(oh and the Kerbol sunflare is somehow visible through the star??? i'll pretend that's a some epic stellar ejection...)

If you have some O, B, or A class stars in your galaxy, try visiting those. I think what you might be seeing is just amount of light coming off M or smaller stars (i.e. they are pretty dim). I could be wrong. Maybe things are just too dim.

[Not Sure]

21 minutes ago, seanth said:

If you have some O, B, or A class stars in your galaxy, try visiting those. I think what you might be seeing is just amount of light coming off M or smaller stars (i.e. they are pretty dim). I could be wrong. Maybe things are just too dim.

I just downloaded your hotfix with Kop 1.3.1-3 and MM 3.0.1 and was relieved to see those two working, but somehow the light source got brighter. It got me excited for a second until i realised it was coming from kerbol. restarted and tried again but this was still the case. (oh the glitches... many many more. Now i see why this is in the development thread )

Edited December 11, 2017 by Not Sure

[daniel l.]

44 minutes ago, Not Sure said:

(oh the glitches... many many more. Now i see why this is in the development thread )

I highly doubt it will ever leave the dev thread. TBG is way too finicky and unstable to ever be considered finished.

[seanth]

1 hour ago, Not Sure said:

I just downloaded your hotfix with Kop 1.3.1-3 and MM 3.0.1 and was relieved to see those two working, but somehow the light source got brighter. It got me excited for a second until i realised it was coming from kerbol. restarted and tried again but this was still the case. (oh the glitches... many many more. Now i see why this is in the development thread )

I'm not sure what you are saying. Are you saying Kerbol's light is too bright galaxy wide? If you want, DM me and maybe I can work this out pretty quickly

 

[Jiraiyah]

@seanth

sorry if this question was asked and addressed already, but did you figured something for procedural generating the height maps for bodies? if not, although i don't know how ksp works in that regard but i know how people do it in unity itself, you can use a library called libnoise and generate some noise images and use some simple math to blend them together, using the seed it will almost always give the same result i think, so, you need to randomize the seed a little bit per body, now, I don't know how your programming language would work with this library but it shouldn't be hard to call yet another standalone program to generate those maps for you and in that program call the library?

thanks for everything you are doing

[TastyMango]

On 12/9/2017 at 1:11 PM, seanth said:

This is the first I've heard of a problem with MM 3.0 and TBG. Can others confirm this?

I had thought the over bright stars problem was fixed. Is it back again? @TastyMangocould you post some screenshots and say what version of TBG you are using?

A little clarification may be needed.

TBG (0.3.5f) on my game runs smoothly. No nuclear lightocalypse since I replaced MM 3.0 (see previous posts).

I was trying to assist Nubees with their dilemma thinking it may have been the same as I had back before my MM fix.  From other threads it seems to be mostly a Kopernicus issue. Could be my malfunctioning Module Manager was messing maliciously with Kopernicus?

In any event, that was my fix. Glad to see no one else has had the same issue.

[Not Sure]

So is the "light only coming from kerbol" bug known? I see it every time i load the game, no matter what. 

I don't think light should be coming from that direction...

Thanks for all the work on this amazing mod! i can provide a log if necissary because ive noticed stuff like 
 

[WRN 17:43:13.090] Cannot find preset 'Default' for pqs 'Plunna I'

and

oh my the more i look at this the more i find...

https://drive.google.com/file/d/1tXy2nVIDeAwI1ZNlBbROMtrafZqg97No/view?usp=sharing
anyways, i wish you luck, i see this as pretty close to working great.

Edited December 15, 2017 by Not Sure

[daniel l.]

21 hours ago, Not Sure said:

So is the "light only coming from kerbol" bug known? I see it every time i load the game, no matter what. 

I don't think light should be coming from that direction...

Thanks for all the work on this amazing mod! i can provide a log if necissary because ive noticed stuff like 
 

[WRN 17:43:13.090] Cannot find preset 'Default' for pqs 'Plunna I'

and

oh my the more i look at this the more i find...

https://drive.google.com/file/d/1tXy2nVIDeAwI1ZNlBbROMtrafZqg97No/view?usp=sharing
anyways, i wish you luck, i see this as pretty close to working great.

This is TBG's big problem. Not only is it rather big and clunky to work with. But the moment you think you've gotten it right... the dependency authors update their mods and suddenly TBG is glitching out again.

I do admit, however, it is pretty amazing. And I'm still quite proud of the work I did to create it (Though I'm pretty sure every single line I've written has been changed by now ).

Anyway, @seanth can probably help you with this.

Edited December 15, 2017 by daniel l.

[seanth]

I'm in the process of finishing up obligations related to the end of the semester. By Tuesday, I should have some free time to dedicate to looking into the lighting problem. I also have some new code that will allow TBG to correctly make planets/moons tidally locked depending of their orbital distance from their primary, AND define whether planets are in the habitable zone around a star.

The habitable zone calc isn't useful yet, but it'll hopefully be used to determine where water worlds will show up.

[Not Sure]

On 12/17/2017 at 9:06 PM, seanth said:

I'm in the process of finishing up obligations related to the end of the semester. By Tuesday, I should have some free time to dedicate to looking into the lighting problem. I also have some new code that will allow TBG to correctly make planets/moons tidally locked depending of their orbital distance from their primary, AND define whether planets are in the habitable zone around a star.

The habitable zone calc isn't useful yet, but it'll hopefully be used to determine where water worlds will show up.

Sorry to pressure you, but is there any new progress with this mod recently? I’d be glad to test it. And I can understand the end of semester stuff, I’m actually writing this after completing my biology final. (91%, woohoo!!!)

[Jiraiyah]

umm, not sure if this was asked before or not, if yes, please forgive me and direct me to the answer :

how would your system work side by side with others that specially change the kerbin's internal system like : Alternis Kerbol Rekerjiggered or galileo's planet pack?

thanks for help and your amazing mod. also i hope you didn't miss my comment here :

https://forum.kerbalspaceprogram.com/index.php?/topic/151998-indev-13-to-boldly-go-an-external-application-designed-to-procedurally-generate-an-entire-galaxy-for-ksp/&do=findComment&comment=3241699

[daniel l.]

10 hours ago, Jiraiyah said:

umm, not sure if this was asked before or not, if yes, please forgive me and direct me to the answer :

how would your system work side by side with others that specially change the kerbin's internal system like : Alternis Kerbol Rekerjiggered or galileo's planet pack?

thanks for help and your amazing mod. also i hope you didn't miss my comment here :

https://forum.kerbalspaceprogram.com/index.php?/topic/151998-indev-13-to-boldly-go-an-external-application-designed-to-procedurally-generate-an-entire-galaxy-for-ksp/&do=findComment&comment=3241699

I doubt it would end well, really. At the least, you would have to modify some of the configs to get everything to work properly.

TBG is EXTREMELY unstable, I spent many a day during development simply rage-quitting from the difficulty of getting it to not break.

What I have achieved, I am very proud of. But it wasn't easy. And anyone who uses TBG probably knows by now that TBG doesn't work right by nature, quite the opposite actually. 

[Thomas P.]

I would like to chime it on the topic of generating custom bodies.

Some of you might know that some time ago, I started a project called "Stellarator" (Even before TBG was released IIRC). While TBG started with generating a whole galaxy, Stellarator focused on generating an actual planetary system.

Stellarator solved the problem of generating an actual surface by having a set of PQS configuration templates. Theese templates contain a set of PQSMods that can generate terrain using noise and other methods (VertexPlanet for example). These template configs are special, since their values can contain variables and calculations (unlike regular Kopernicus configs). For example, the seed values of the PQSMods are dynamic and depend on the seed the user entered when running the program. Another feature was, that it generated a random color for the planet, that could be used together with different manipulation methods (For example to generate a brighter or darker color). And you had a way of generating a new random number using the seed, and either calculate with it or just assign it to the respective value. While loading the configs these expressions were evaluated, so every PQS template could produce an infinite amount of actual planets. The intention behind this was, that a human could create a planet that looks good, and then figure out which values could be changed, and which ones were neccessary to produce a result that has the same look and feel - as opposed to just throwing together noise functions and getting planets that might be totally wonky. Also, by using the PQS the program can simply rely on the tools and the API KSP and Kopernicus expose anyway, and not invent something totally new.

The problem with this approach, as with probably any approach, is that you have to generate the ScaledSpace textures. They are always static, and there is no good way to generate them ingame without lagging the users PC to death. In Stellarator I solved this problem by rewriting the PQSMods and the Unity and KSP classes they need independent from KSP. Stellarator then used the Kopernicus Loader to convert the PQS configuration that was generated into a stack of PQSMods, just like they would exist in the game, and used this data to pregenerate the textures. That took a bit of time, but in the end you had a completely procedural solar system.

But since Stellarator never took off, and I am a noob at actualy planet making, I never had the time to write the PQS database. I made three example configs, but thats it. Since TBG took off and got reasonably popular, I would like to propose that the planet generation concepts could be merged into TBG and developed further (I would totally like to help with that as soon as I got the time - I also have some magic for gas planets lying around, lol). I think it's just sad that my old code is lying around with me having no motivation to work on it, while it could help somewhere. And I simply like the idea of procedural generating a solar system that actually works and is not just a proof of concept.

The only problem with that is, that every type of terrain generator would make the current code completely unreadable. The planet generation, and also the difficulty to work with it that daniel mentioned, would really benefit from rewriting it in a different language, probably Python (easy to read and write) or C# (most stuff for the planet generator could be taken from Stellarator).

But of course thats your decision. If you are interested in my proposal, feel free to leave me a message, either on the forums or on the Kopernicus Discord.

[Jiraiyah]

16 minutes ago, Thomas P. said:

I would like to chime it on the topic of generating custom bodies.

Some of you might know that some time ago, I started a project called "Stellarator" (Even before TBG was released IIRC). While TBG started with generating a whole galaxy, Stellarator focused on generating an actual planetary system.

Stellarator solved the problem of generating an actual surface by having a set of PQS configuration templates. Theese templates contain a set of PQSMods that can generate terrain using noise and other methods (VertexPlanet for example). These template configs are special, since their values can contain variables and calculations (unlike regular Kopernicus configs). For example, the seed values of the PQSMods are dynamic and depend on the seed the user entered when running the program. Another feature was, that it generated a random color for the planet, that could be used together with different manipulation methods (For example to generate a brighter or darker color). And you had a way of generating a new random number using the seed, and either calculate with it or just assign it to the respective value. While loading the configs these expressions were evaluated, so every PQS template could produce an infinite amount of actual planets. The intention behind this was, that a human could create a planet that looks good, and then figure out which values could be changed, and which ones were neccessary to produce a result that has the same look and feel - as opposed to just throwing together noise functions and getting planets that might be totally wonky. Also, by using the PQS the program can simply rely on the tools and the API KSP and Kopernicus expose anyway, and not invent something totally new.

The problem with this approach, as with probably any approach, is that you have to generate the ScaledSpace textures. They are always static, and there is no good way to generate them ingame without lagging the users PC to death. In Stellarator I solved this problem by rewriting the PQSMods and the Unity and KSP classes they need independent from KSP. Stellarator then used the Kopernicus Loader to convert the PQS configuration that was generated into a stack of PQSMods, just like they would exist in the game, and used this data to pregenerate the textures. That took a bit of time, but in the end you had a completely procedural solar system.

But since Stellarator never took off, and I am a noob at actualy planet making, I never had the time to write the PQS database. I made three example configs, but thats it. Since TBG took off and got reasonably popular, I would like to propose that the planet generation concepts could be merged into TBG and developed further (I would totally like to help with that as soon as I got the time - I also have some magic for gas planets lying around, lol). I think it's just sad that my old code is lying around with me having no motivation to work on it, while it could help somewhere. And I simply like the idea of procedural generating a solar system that actually works and is not just a proof of concept.

The only problem with that is, that every type of terrain generator would make the current code completely unreadable. The planet generation, and also the difficulty to work with it that daniel mentioned, would really benefit from rewriting it in a different language, probably Python (easy to read and write) or C# (most stuff for the planet generator could be taken from Stellarator).

But of course thats your decision. If you are interested in my proposal, feel free to leave me a message, either on the forums or on the Kopernicus Discord.

ouuuuch, i would really like to see something like this being integrated together. THAT my dear friend WOULD BE a dream come true. specially if you combine the fact that noise lib can provide you with as many different noise textures as you want to put on top of each other for a planet texture production, uuuuf the possibilities of such a system !!!!