Project Orbiter Galaxy

[Linguofreak]

I've also discovered that the innermost planet of Gl 169.1A has a day length that suggests it should be spin locked, but isn't listed as such. The same applies to the innermost planet of Epsilon Eridani (listed in Orbiter Galaxy as 18Eps Eri), and in that case the next planet out actually is spin locked...

---------- Post added at 18:54 ---------- Previous post was at 02:41 ----------

oh... I never noticed that, but when I go through the code in my head it's pretty obvious. Should theoretically not be so for moons around gas giants (i.e. I think there the year indeed is the month), but I'll have to fix that.

Tidal locking between planets and moons isn't implemented at all yet, except for moons around gas giants, since thy are generated with a completely different aproach than moons around common planets. Moons around common planets are currently formed by (probable) collision, while the moons around gas giants are accreted. Tidal effects of all kinds will be a major concern in the developement of 0.7, so you can expect that to get fixed.

There are several errors in the catalogue (for example Sirius has the classification of Sirius B (white dwarf) while having mass and luminosity of Sirius A. I'll probably never spot them all, but those known will get fixed for 0.7, as will the generation of too luminous stars in the solar vicinity. There's only a very arbitrary check currently, and I'll introduce one based on aparent magniutde at sol (just what would be a sensible cut-off for aparent magnitude? you probably got a suggestion for that).

Well, somewhere around 6 or 6.5 is the naked eye cutoff for the average observer.

I believe the telescope cutoff is somewhere around 30. This would be visual magnitude, not bolometric.

The problem is that the cutoff isn't a really fast and hard line. As you approach the cutoff, it takes longer and longer observation times to see a star, which means that even short of the cutoff we haven't seen everything there is to see (also, dim stars are more likely to be discovered if they are near the line of sight to other objects that are observational targets). So a probabilistic cutoff would be best, but I wouldn't know how to advise you on that.

It might be nice to do something like generating normally, then dividing the space going out from the sun into "shells". You then divide the generated and catalog stars into luminosity ranges and delete one generated star in a luminosity range (preferably ones close to catalog stars before ones far away) for each star you find in the catalog in that range, and then apply a check for magnitude that is somewhat brighter than the limit (App Mag 30), but still fairly dim. Determining where to put the magnitude check might take a bit of trial, error, and expert opinion, but it might give the best results.

---------- Post added at 20:46 ---------- Previous post was at 18:54 ----------

Another possible bug: 3rd planet of 359.9h0.1a21.4f. (The star itself is another F class too close to Sol).

The planet is listed as a Venusian, but has a gas mass of ~10% of the rock mass. ISTR that the cutoff for being a gas dwarf is 5% gas mass.

---------- Post added at 20:56 ---------- Previous post was at 20:46 ----------

Should theoretically not be so for moons around gas giants (i.e. I think there the year indeed is the month), but I'll have to fix that.

Thats not what I'm seeing. If you look at the gas giants around 8Del Tri, the listed year lengths for moons are approximately those of their parent planets (though there's a problem even here: The parent planet has a higher mass, so it orbits the sun just a wee bit faster than the moons would if they were on their own. The physics is right, except for the fact that the moons are bound).

---------- Post added at 21:00 ---------- Previous post was at 20:56 ----------

Oh, also, a somewhat more obvious bug, but one I wasn't really paying attention to: Odd things seem to be happening with the scrollbar on the planet list in the System view Window.

EDIT: Though when I took this screenshot I hadn't changed the default resolution for the OG window in the config file yet. Having changed things to 1024 * 700 (Screen resolution is 1280 * 800, and some of the top and bottom is eaten up by OS panels), there's no longer a scrollbar, so no more bug.

Further EDIT: I am still encountering the bug every once in a while, but can't figure out how to reproduce it.

Further Further EDIT: It seems to be related to the number of objects in the system in question.



---------- Post added at 21:25 ---------- Previous post was at 21:00 ----------

Oh: In the Gl 184 system, the moon of the 4th planet has an atmosphere of 99.7% hydrogen and 0.167% oxygen. For one thing, the presence of both free hydrogen and free oxygen in an atmosphere in measurable quantities is unlikely (as the two combine to make water). For another, if hydrogen dominates an atmosphere, it is likely to be in a ~75/25 mix with helium (by mass).

EDIT: Speaking of which, what (in your model) determines the presence of oxygen in a planetary atmosphere? In reality, oxygen is reactive enough that the presence of photosynthesizing life is really the deciding factor, as there is no other known natural process that could occur on a planetary surface that would create large quantities of free oxygen.

Furthermore, a concern in labeling planets as habitable (for humans) or not is that of nitrogen narcosis. In scuba diving, you get about 1 atmosphere of pressure for every 10 meters of water, and nitrogen at pressure causes a narcotic effect often described with "Martini's Law", which I have heard quoted as either "equivalent to one dry martini on an empty stomach for every fifty feet (~= 15 meters ~= 1.5 atmospheres) below the surface" or "one dry martini for every 10 meters (1 atmosphere) below 20 meters depth (2 atmospheres water pressure plus one atmosphere surface pressure = 3 atmospheres)". So beyond 4 atmospheres' pressure or so, impairment becomes significant, meaning that three or four atmospheres would be the limit for colonization, even if the atmosphere was otherwise breathable, unless there was a significant quantity of some gas such as helium in the air to keep the partial pressure of nitrogen down. This wouldn't restrict the potential for native life, though, and you might still get stuff like scientific research stations (using a mix of local air and helium as a breathing gas), though anything less than a colony might not be economically viable (due to orbital lift costs in an Earth-like gravity well, which might not be worth it for a research outpost).

Oxygen toxicity is also a concern, though it would be somewhat mitigated by the fact that an atmosphere with too high a partial pressure of oxygen would tend to result in vegetation fires until the excess oxygen was burned off.

[ame="http://en.wikipedia.org/wiki/Nitrogen_narcosis"]Nitrogen narcosis - Wikipedia, the free encyclopedia[/ame]
[ame="http://en.wikipedia.org/wiki/Breathing_gas"]Breathing gas - Wikipedia, the free encyclopedia[/ame]

---------- Post added at 22:33 ---------- Previous post was at 21:25 ----------

The moon of the innermost planet of 359.8c0.2b93.4b is another oddity. It's listed as Venusian, yet has no greenhouse effect, only 136 millibars of atmosphere, a temperature of 254.9 K, only 64 percent cloud cover, and it has 31 percent ice cover. No hydrosphere though.

---------- Post added at 23:04 ---------- Previous post was at 22:33 ----------

Oh, another semi-error in the star catalog that I've found: ISTR that you were culling multiple stars down to singles. Gl166 C is a (far) companion to 40Omi2Eri (AKA Gl 166 A), and has not been culled out. They're sitting right on top of each other in the starmap view, which makes it difficult to select the one you want. I'd actually just as soon have multiples included (especially in the case of far binaries where the two stars don't place any restrictions on each others planetary systems, but near binaries would be nice too), but if it were done, there would have to be some better way of selecting which star you want when two are very close together.

Also, Van Maanen's star is a white dwarf IRL, but shows up here as a K0V.

---------- Post added at 23:38 ---------- Previous post was at 23:04 ----------

The second planet of Gl 525 has a surface temperature higher than its boiling point of water, yet is listed as having a "Hydrosphere percentage" of 1. (Also, this should be "hydrosphere fraction", since 1 represents complete coverage. As a percentage it would be 100).

---------- Post added at 23:50 ---------- Previous post was at 23:38 ----------

Just had OG CTD on me. Unsure if it was a bug in OG or a Wine problem.

---------- Post added 01-10-11 at 00:50 ---------- Previous post was 01-09-11 at 23:50 ----------

I'm noticing some stars in the catalog with a given class of S0V with unlikely properties, that, when I look them up, seem to be stars for which our data is bad or at least causes astronomers to question what these stars really are. It might be best to omit these stars.

---------- Post added at 02:31 ---------- Previous post was at 00:50 ----------

Against all my expectations the plugin runs under OGLAClient/Wine, though bugilly, with quite a few nasty crashes, and only with Linux GUI settings that I've found can be suboptimal for use with OGLAClient. At first I thought I was running into problems with planet textures, then I realized that OG was exporting to a folder called "textures", while Orbiter was looking for textures in a folder called "Textures". On Windows they're the same, but Linux is case sensitive. The bug was resolved by manually dragging the contents of "textures" into "Textures". Paradoxically, a second saving of a system to cache led to the textures being placed in the "Textures" folder. I had originally installed OG to a separate folder and then moved it into the main Orbiter folder after deciding to try running the plugin. Maybe that had something to do with it. In any case, changing the code to make it save to "Textures" should make things consistent.

I'm encountering black textures wherever the planet is of the "rock" type, and Martian worlds have textures that are filled with R=0, G=0, B=51 (in hex that's #000033).

I also ran into a few bugs in OGLAClient that I hadn't encountered before.

Not a bug per-se, but I found a habitable one-face world (I'm finding they tend to be really rare). Its texture is more what one would expect of a general terrestrial planet, whereas a habitable one-face would probably show signs of being such a world in its appearance. (Lot's of cloud cover around the "point of eternal noon" if there's ocean nearby, cloud patterns shaped by special wind patterns, possibly some massive glaciers coming across the terminator in places, etc).

 

[jedidia]

Thats not what I'm seeing. If you look at the gas giants around 8Del Tri, the listed year lengths for moons are approximately those of their parent planets (though there's a problem even here: The parent planet has a higher mass, so it orbits the sun just a wee bit faster than the moons would if they were on their own. The physics is right, except for the fact that the moons are bound).

Thanks, that means that their orbital periods are still calculated in reference to the star instead of their parent bodies. I don't know the code of stargen by heart yet, so that's one thing I probably misread in the code. Will be fixed!

Oh, also, a somewhat more obvious bug, but one I wasn't really paying attention to: Odd things seem to be happening with the scrollbar on the planet list in the System view Window.

Known issue, happens if there are too many bodies in a system. Although the table is dynamic in size, the height of the fields seem to have some weirdnesses (I guess their height is not a natural number, for whatever crazy reason), leading to the table height being slightly too small if there are too much bodies, which prompts irrlicht to display the scrollbars. I'll probably give the table a fixed size and have the scrollbars display by default, but in the right place, to avoid the issue, allthough that might have its problems too. If the table's too small, the horizontal scrollbar apears on the bottom of the screen instead of on the bottom of the table, i.e. somewhere right in the table.

Oxygen toxicity is also a concern, though it would be somewhat mitigated by the fact that an atmosphere with too high a partial pressure of oxygen would tend to result in vegetation fires until the excess oxygen was burned off.

Oxygen toxicity based on pressure is actually implemented, so should be that of nitrogen... Maybe the value is wrong, I'll have to check on that.

Speaking of which, what (in your model) determines the presence of oxygen in a planetary atmosphere? In reality, oxygen is reactive enough that the presence of photosynthesizing life is really the deciding factor, as there is no other known natural process that could occur on a planetary surface that would create large quantities of free oxygen.

The atmosphere model of Stargen is pretty crude, and the hydrosphere model even more so. The oceans on that planet you reported might be in a critical state, I can't even remember wheather I'm showing the flag for that...
The whole composition model is about to undergo a major rework, based on a periodic table and a compound table (the later of which I still have to write up, which is tedious, boring work so it might take a while). Currently not even temperatures are checked, only wheather or not a gass is retained by the planets gravity, the rest of the composition is made up completely random.

ISTR that you were culling multiple stars down to singles. Gl166 C is a (far) companion to 40Omi2Eri (AKA Gl 166 A), and has not been culled out. They're sitting right on top of each other in the starmap view, which makes it difficult to select the one you want. I'd actually just as soon have multiples included (especially in the case of far binaries where the two stars don't place any restrictions on each others planetary systems, but near binaries would be nice too), but if it were done, there would have to be some better way of selecting which star you want when two are very close together.

Far binaries are generally left in (the cut-off limit is too high, I still have to correct that). The problem that two stars are sometimes sitting on top of each other is the dynamic size of the star meshes. They get displayed bigger if there's fewer stars in the region (up to a limit, of course), to improve oversight, so it can happen that two are actually in each other. In my expierience it's still not too difficult to select them by clicking on the label, but it can be a bit irritating. Maybe I have to display the meshes smaller, but then they're also harder to make out... It's a balancing act.

Just had OG CTD on me. Unsure if it was a bug in OG or a Wine problem.

It was a long time ago since anyone reported a CTD (especially in the standalone), but of course it's not impossible that there's still the odd thing that can cause one. I did away with about 3 major memory leaks that where responsible for most CTDs in the Demo, but wouldn't be surprised at all if there are still some left.

I'm noticing some stars in the catalog with a given class of S0V with unlikely properties, that, when I look them up, seem to be stars for which our data is bad or at least causes astronomers to question what these stars really are. It might be best to omit these stars.

That's good advice, thanks. I'll remove them from the catalogue.

 

[Linguofreak]

Oxygen toxicity based on pressure is actually implemented, so should be that of nitrogen... Maybe the value is wrong, I'll have to check on that.

Then it's probably fine, or I'll assume so until I find something really out of whack.

The atmosphere model of Stargen is pretty crude, and the hydrosphere model even more so. The oceans on that planet you reported might be in a critical state, I can't even remember wheather I'm showing the flag for that...
The whole composition model is about to undergo a major rework, based on a periodic table and a compound table (the later of which I still have to write up, which is tedious, boring work so it might take a while). Currently not even temperatures are checked, only wheather or not a gass is retained by the planets gravity, the rest of the composition is made up completely random.



Far binaries are generally left in (the cut-off limit is too high, I still have to correct that). The problem that two stars are sometimes sitting on top of each other is the dynamic size of the star meshes. They get displayed bigger if there's fewer stars in the region (up to a limit, of course), to improve oversight, so it can happen that two are actually in each other. In my expierience it's still not too difficult to select them by clicking on the label, but it can be a bit irritating. Maybe I have to display the meshes smaller, but then they're also harder to make out... It's a balancing act.

Well, if there are multiple stars in a really small space, it would be nice to have something where you click on the general area and it gives you a menu with all the stars near the pointer in it.

It was a long time ago since anyone reported a CTD (especially in the standalone), but of course it's not impossible that there's still the odd thing that can cause one. I did away with about 3 major memory leaks that where responsible for most CTDs in the Demo, but wouldn't be surprised at all if there are still some left.

For all I know it could be a Wine bug. Now, Wine did pop up an error message, so it was a violation of Windows/Wine protocols rather than Linux protocols, but that doesn't mean that a mis-implementation in Wine wasn't responsible.

Then again, it could be an actual bug in OGalaxy that rarely or never actually causes visible problems in Windows, but that some different structuring in Wine brings out.

BTW, did you see the last section of my previous post (on me trying out the plugin, and the results)? I think I ninja'ed you with it.

 

[jedidia]

then I realized that OG was exporting to a folder called "textures", while Orbiter was looking for textures in a folder called "Textures".

Duh! I heared about such problems in ancient legends... :lol: Will be fixed!

I'm encountering black textures wherever the planet is of the "rock" type, and Martian worlds have textures that are filled with R=0, G=0, B=51 (in hex that's #000033).

Can you post the shader.log in your orbiter root directory? The trouble with rocky planets on some GPUs is known (and *might* in some cases be fixed by adding these two lines to the end of the config:

//Fix for black textures of planets without atmospheres (set to 1 if you have black textures)
1

You're the first ever to report trouble with martians, congratulations!

Considering that you're using a laptop, you'll probably have to revert to CPU generation... (adjustible in the OGalaxy.cfg file).

Not a bug per-se, but I found a habitable one-face world (I'm finding they tend to be really rare). Its texture is more what one would expect of a general terrestrial planet, whereas a habitable one-face would probably show signs of being such a world in its appearance. (Lot's of cloud cover around the "point of eternal noon" if there's ocean nearby, cloud patterns shaped by special wind patterns, possibly some massive glaciers coming across the terminator in places, etc).

One faced planets aren't supported by the texture generator, and therefore will get the texture of a type that befitts them best. You'll also notice that venusian planets are currently exported without textures. The generator is, as Orbiter Galaxy itself, still a work in progress.

Well, if there are multiple stars in a really small space, it would be nice to have something where you click on the general area and it gives you a menu with all the stars near the pointer in it.

I'll have to take a look at Irrlicht collision detection to see what I can do about it...

 

[Linguofreak]

Duh! I heared about such problems in ancient legends... :lol: Will be fixed!



Can you post the shader.log in your orbiter root directory?

It's filled with 108 lines worth of:

prog[0]:
prog[1]:

Being that the repeated segment is two lines long, that's 54 repetitions.

The trouble with rocky planets on some GPUs is known (and *might* in some cases be fixed by adding these two lines to the end of the config:

//Fix for black textures of planets without atmospheres (set to 1 if you have black textures)
1

Thing is, this is appearing for worlds with atmospheres, or at least atmospheric haze.

You're the first ever to report trouble with martians, congratulations!

Considering that you're using a laptop, you'll probably have to revert to CPU generation... (adjustible in the OGalaxy.cfg file).

It may also be Wine not fully and/or correctly implementing DirectX or something. Could you send me a version with a OpenGL option?

I'll have to take a look at Irrlicht collision detection to see what I can do about it...

Thanks!

Oh, BTW, it would be nice to have arrows in the starmap view showing the positive directions along the X, Y, and Z axes.

And since the Galaxy map is 2D, it would be nice to have an option to specify a Z coordinate to jump to when selecting a location in the galaxy map. A "Sol is here" marker would also be nice, for finding ones way back home.

 

[jedidia]

prog[0]:
prog[1]:

Yap, that looks familiar. Those two lines are written to the log for every texture you generate. The problem most certainly is incompatibility of the GPU (do you happen to know what shader models are supported by your card?). There are no errors, because the error handling doesn't quite work on NVidia cards, because Artlav can only test it on an ATI card. Although, as I heared in other instances, some other NVidia cards that *should* support the generator (SM 4.1 and above) show the same behaviour, so all hope is not lost that it'll be fixed. For now, you'll have to use CPU generation.

It may also be Wine not fully and/or correctly implementing DirectX or something. Could you send me a version with a OpenGL option?

Won't help in this case, since the texture generator ALWAYS runs in OpenGL (the sole purpose of moving the galaxy map to directX was to avoid collision of the OpenGL contexts of the map and the texture generator).

And since the Galaxy map is 2D, it would be nice to have an option to specify a Z coordinate to jump to when selecting a location in the galaxy map. A "Sol is here" marker would also be nice, for finding ones way back home.

Both are already provided (the manual is your friend! :lol.

keep the left mouse button pressed and move the mouse up and down to adjust the Z-coordinate. Also, there is a GUI when you move the mousecursor to the right screen edge. It contains several default hotspots with famous stars, and provides the ability to add new categories and new spots to it. When you select a HotSpot in the list you will see a red circle in the galaxy map indicating the position of this spot, and when you double-click it you will be taken to the star map at those coordinates (although the hotspots only remember the galactic position of the cube, not the exact position of a star therein). You can set the hotspot file to be loaded at startup in the config.

(when editing hotspots, note that the delete as well as the load buttons have to be double-clicked, to avoid accidental actions as well as an annoying "do you really want to do this" pop-up)

You can also zoom and move around the galaxy map with WASDQE keys, just in case you haven't noticed.

Oh, BTW, it would be nice to have arrows in the starmap view showing the positive directions along the X, Y, and Z axes.

Yeah, I was always planing on adding that, but never got around to it...

 

[Linguofreak]

Yap, that looks familiar. Those two lines are written to the log for every texture you generate. The problem most certainly is incompatibility of the GPU (do you happen to know what shader models are supported by your card?). There are no errors, because the error handling doesn't quite work on NVidia cards, because Artlav can only test it on an ATI card. Although, as I heared in other instances, some other NVidia cards that *should* support the generator (SM 4.1 and above)

Ah, I'm finding DirectX support of "DirectX 10, Shader 4.0" if that's what we're looking for.

The card I have is a GeForce G 105M.

show the same behaviour, so all hope is not lost that it'll be fixed. For now, you'll have to use CPU generation.

Would it be possible to use a standard premade texture (such as the Moon for "rock" planets and Mars for "martian" planets) for the planet types that cause problems while leaving the rest on GPU generation? Maybe an option in the config file to choose between prebaked and procedural textures for each planet type?

EDIT: One reason I suggest Moon and Mars textures is that they come with Orbiter. They wouldn't even need to be provided with OG (though then somebody running it as a standalone might run into trouble, though generating textures is somewhat pointless when running it as a standalone).

---------- Post added at 18:21 ---------- Previous post was at 15:32 ----------

I've tested the texture export on my WinXP machine and it works. Which makes me wonder: Could OG be given a server-client type structure where an OG instance on one computer could have an instance on another machine do texture generation?

---------- Post added at 18:49 ---------- Previous post was at 18:21 ----------

The plugin appears to be working well on WinXP under OGLAClient.

 

[jedidia]

I've tested the texture export on my WinXP machine and it works. Which makes me wonder: Could OG be given a server-client type structure where an OG instance on one computer could have an instance on another machine do texture generation?

Very interesting... You said "XP-machine", which lets me suspect that it's a totally different computer, not a double-boot configuration. That would mean that there's another graphics card at work. Could you give me the model and post the shader log?

The Shader Model of the card in your Linux machine is lightly too old, but that doesn't mean that it won't work in any case. everything NVidia above a G80 should theoretically work, according to Artlav.

Would it be possible to use a standard premade texture (such as the Moon for "rock" planets and Mars for "martian" planets) for the planet types that cause problems while leaving the rest on GPU generation? Maybe an option in the config file to choose between prebaked and procedural textures for each planet type?

Is possible, might get a bit crowded in the config. But I could make a seperate "texture source"-file where that can be specified to keep oversight at a reasonable level.

Which makes me wonder: Could OG be given a server-client type structure where an OG instance on one computer could have an instance on another machine do texture generation?

Pretty much out of the question, I'm afraid, unless someone does it for me. When it comes to coding, I am completely network-illiterate. Learning all the stuff neccessary for something like that and implementing it satisfactorily would throw me months off course, not to mention that my motivation to do it would be very low to start with. Sorry.

 

[Linguofreak]

Very interesting... You said "XP-machine", which lets me suspect that it's a totally different computer, not a double-boot configuration.

Yes. It's actually the first time that I've had a program have trouble with the card in my Linux machine and not the one in my Windows machine. Usually it's the other way around. It's a Radeon HD 2400 Pro, and I've generally found that its OpenGL handling *STINKS*. I actually have used Linux on that machine, but at the moment the external drive I was booting it from isn't attached.

That would mean that there's another graphics card at work. Could you give me the model and post the shader log?

This time it's 468 lines' worth of:

prog[0]:
Vertex shader was successfully compiled to run on hardware.

Fragment shader was successfully compiled to run on hardware.
Fragment shader(s) linked, vertex shader(s) linked. 
 
prog[1]:
Vertex shader was successfully compiled to run on hardware.

Fragment shader was successfully compiled to run on hardware.
Fragment shader(s) linked, vertex shader(s) linked.

 

[jedidia]

According to the shader log (and the textures) it's working nice and clean, on an ATI with shader model 4.0. No surprises there. Everything points to some trouble the texture generator has with the G-Series by NVidia. I'm pretty sure Artlav will manage to fix it eventually, please be patient and use CPU export until then (at least on your Linux machine).

 

[Linguofreak]

Oh, by the way, I'm getting this output in the Wine console on my Linux machine when I run the standalone client. Maybe it will point to something? (Though this is just what I get at startup, it has nothing to do with exporting. It still might show card/driver problems).

Irrlicht Engine version 1.7.1
Microsoft Windows XP Professional Service Pack 2 (Build 2600)
Using renderer: Direct3D 9.0
NVIDIA GeForce 8300 GS nv4_disp.dll 6.15.11.9745
Anti aliasing disabled because hardware/driver lacks necessary caps.
Loaded texture: C:/Program Files/Orbiter/OrbiterGalaxy/Data/ThumbNails.bmp
Loaded texture: C:/Program Files/Orbiter/OrbiterGalaxy/Data/pictograms.bmp
Resizing window (1024 700)
Resetting D3D9 device.

 

[jedidia]

Hmmm... the driver doesn't support anti-aliasing, which is ridiculous for a DX10 card. It's probably Wine vs. DX trouble. That's only for irrlicht though, the texture generator uses OpenGL directly and in all instances. The trouble reported is consistant with what we've heared from the G220 on windows, so any texture problems are unlikely to be connected to Wine or DirectX issues (in contrary to that anti-aliasing. You'll get that back when I make a version with selectable OGL/DX support).

 

[Linguofreak]

Out of curiosity, what are the criteria for a planet to be labeled Venusian? Every once in a while I'll run across a Venusian planet, and, on examining it more closely, I find myself unable to figure out how it possibly got that label.

---------- Post added at 03:07 ---------- Previous post was at 02:50 ----------

Also, might it be possible to have a planet search function of some type, where, given criteria for a planet, the generator starts generating sectors and keeps going until the user tells it to stop (working outwards from the current location), and reports the sector and star identifier for every planet found with the requested parameters?

 

[jedidia]

Out of curiosity, what are the criteria for a planet to be labeled Venusian? Every once in a while I'll run across a Venusian planet, and, on examining it more closely, I find myself unable to figure out how it possibly got that label.

I don't know from the top of my head (let's not forgett that that code wasn't written by me...). I noticed some inconsistencies too, the type assignement is another thing that will get a thourough review for 0.7, since I'm going to add a few more types anyways. Stargen won't be the same afterwards, I hope it'll be for the better...

Also, might it be possible to have a planet search function of some type, where, given criteria for a planet, the generator starts generating sectors and keeps going until the user tells it to stop (working outwards from the current location), and reports the sector and star identifier for every planet found with the requested parameters?

Is possible, but an awfull lot of number crunching. Would probably deserve its own GUI pannel, considering the wide possibilities of atributes you can search for. In any case, it would have to be implemented after the generator rewrite, or I'll just end up writing it two times...

 

[Linguofreak]

I'm noticing that Polaris is another victim of the primary and the secondary getting switched. It's actually a three star system: A F7I or F7II primary, a near F(something)V companion at 18 AU, and a far F3V companion at 2400 AU. OG lists it as a single F7V.

---------- Post added at 16:57 ---------- Previous post was at 16:47 ----------

I'm also finding that O stars, while blue in the system view, are yellow in the star map.

---------- Post added at 17:29 ---------- Previous post was at 16:57 ----------

I'm finding more instances of a bug I'd encountered before: Planets orbiting large, hot stars whose density parameters don't match up to their mass and radius. In this case it's both planets in the 39Lam Ori system.

 

[jedidia]

I'm also finding that O stars, while blue in the system view, are yellow in the star map.

most peculiar, I never noticed that before. Must have crept in at some point...

 

[Linguofreak]

most peculiar, I never noticed that before. Must have crept in at some point...

O stars are rare enough that you'd not be likely to notice it unless you were specifically hunting for a specific O star in the catalog. You'd miss generated O stars by mistaking them for G's, and not many sectors will even contain an O.

 

[jedidia]

It turns out that the probability calculations required for rewriting the generator are somewhat above my head, now I'll have to wait for my father-in-law to come up with a usable equation for me (there's some advantages in being married to a mathematicians daughter...).

Meanwhile I'll be over here working on the chemtables, a task for which you don't need much more inteligence than your average ape, so I'll probably do fine with that... :lol:

Work on the FTL system will resume as soon as I get that bloody equation.

---------- Post added at 11:59 AM ---------- Previous post was at 10:53 AM ----------

@Linguofreak: A thought just crossed my mind... could you download spaceway and give it a go in GPU mode (if you're not already using it anyways). The texture generator for orbiter galaxy is pretty much the same, so you should theoretically expierience the same problems (black rocky planets). If Spaceway works we'll at least know that the bug has to be located somewhere in the slight differences between the two.

 

[Notebook]

To jedidia:

I'm not sure if its helpful, but this has some info that seems close to what you are working on?
http://www.causascientia.org/math_stat/Tutorial.pdf

Example S2—Rolling Dice

page 18.

N.

 

[Linguofreak]

@Linguofreak: A thought just crossed my mind... could you download spaceway and give it a go in GPU mode (if you're not already using it anyways). The texture generator for orbiter galaxy is pretty much the same, so you should theoretically expierience the same problems (black rocky planets). If Spaceway works we'll at least know that the bug has to be located somewhere in the slight differences between the two.

One request for Artlav: The confirmation dialogs in Spaceway are horribly confusing, with their question "Are you unsure?", and the possible responses "Yes, I'm unsure" and "No, I'm sure". Much user friendliness would be added if the question was "Are you sure?" and the answers were "Yes" and "No".