Project Orbiter Galaxy

[jedidia]

Never heard of that kind of problem before, and am currently at a total loss to what might be the cause. Obviously it's not an Irrlicht vs. Vista thing, or the standalone wouldn't work either.

Could you define "refresh" a bit closer? As mentioned before, I had occasions crop up where the map would not or very slowly respond to mouse commands. closing the map and opening again usually solves that problem, have you tried that?

 

[Fizyk]

It looks like this: I open the map, a blank dialog opens, just as you wrote in the manual. I wait 10 seconds, nothing happens. I wait a minute, nothing happens. I move the dialog around a bit, and exactly the moment when some part of it is outside the screen, suddenly everything appears. I try some controls (like changing the view using the mouse or the keyboard, after using your trick) and nothing happens. Again moving the dialog a bit off the screen makes it update itself.

I think I tried closing and opening the map again, but I'll try it again to be sure.

EDIT: Closing and opening doesn't help, but I found a way to use it. I have to move the dialog down, so that its bottom is off the screen. It doesn't get reset to its original position then (it does when I try to move it to the left), and because part of it is outside the screen, it updates well.

 

[jedidia]

Probably won't help, that behaviour is completely unknown to me... Anyone using Vista, please tell if you are expieriencing similiar problems. I can't reproduce in 7, 2k or XP. Other than an OS issue there's onlz graphics card comming to mind... Say, do you have the oportunity to test it on another Vista machine, or do you happen to have another OS handy on that laptop?

Apart from that, I just spotted another bugger in the code that wasn't there before... Be warned, if you currently jump to a system and then try to target another one, you'll most likely get a CTD, because your source system is unknown. For some reason, my scenario writing routine has suddenly become very selective and doesn't even take over the Orbiter Galaxy parameters, while it should leave anything in the scenario pretty untouched except for the vessels. No idea when that crept in, but I'll have it fixed pretty soon I should say.

Still no Idea how to solve the more serious issues mentioned here, though...

 

[dumbo2007]

I have a suggestion....to resolve this kind of a problem its useful to have a short video :
Jing is a very easy to use software that allows this and has a free version :
http://www.techsmith.com/jing/

Download here :
http://www.techsmith.com/download/jing/

Its quite easy to setup so I would suggest taking the time to install it and run it to get a small video and then attach it here.

 

[donatelo200]

I have one problem. It's not too mutch of a bug it just has to do with the planets atmospheres. I was in a reall high orbit around an Earth sized ice planet with an atmospheric pressur at 103kpa. When i was lowering my orbit to 400km witch should have ben well above the atmosphere I burnt up at 700km. I looked at the data my ship was collecting and it said the Atm pressure is 48pa with a density of 0 at 700km. The haze itself witch is where the atmospheres pressure should have increased was 250km above the planet. All i'm saying is that the atmospheres of the planets need to be reworked a little. Also here is a screene of an Earth massed venusian planet witch atmospheres pressure was right but not how tall it was supposd to be.

 

[jedidia]

New patch up, will fix all kinds of missbehaviour related to system switch if you had a lot of modules installed. I didn't realise that oapiReadScenario_nextline returns false if it encountered an END statement, not just at file end. That could lead to a premature stop in the export of the switch scenario, so that all kinds of data (including the data of Orbiter Galaxy itself) could get lost in the process. Since I had the bare minimum of modules running in my test installation, I never noticed the bugger!

I have one problem. It's not too mutch of a bug it just has to do with the planets atmospheres. I was in a reall high orbit around an Earth sized ice planet with an atmospheric pressur at 103kpa. When i was lowering my orbit to 400km witch should have ben well above the atmosphere I burnt up at 700km. I looked at the data my ship was collecting and it said the Atm pressure is 48pa with a density of 0 at 700km. The haze itself witch is where the atmospheres pressure should have increased was 250km above the planet. All i'm saying is that the atmospheres of the planets need to be reworked a little. Also here is a screene of an Earth massed venusian planet witch atmospheres pressure was right but not how tall it was supposd to be.

Could you tell me where that planet is? it sounds a bit weird, I'd like to take a look at it.

As for the haze, it is a bad indicator of how high the atmosphere reaches, in Orbiter Galaxy as well as in real live. The hight of the haze is pressure related, but chosen a bit arbitrary for looks. You'd better not do a reentry by visuals. If you look at Venus, the Haze doesn't extend as far as the atmosphere too. However, 103 kpa is around one bar, if I'm not mistaken, so clearly that atmosphere shouldn't have reached that high. Tell me where you found that obscurity, I'll find out what's going on.

EDIT: Closing and opening doesn't help, but I found a way to use it. I have to move the dialog down, so that its bottom is off the screen. It doesn't get reset to its original position then (it does when I try to move it to the left), and because part of it is outside the screen, it updates well.

Glad that you can use it! your reports sound very much like an Issue with the OS or the graphics card, I never heard of such weird behaviour and couldn't explain where else it might come from...

 

[Fizyk]

Unfortunately, my computer is the only Vista machine in my house and I don't have any other systems on it

Anyway, I managed to land on Barnard's Star d. It was all white though, but it was probably my fault - it's possible that I didn't wait long enough when textures were being exported. Great work! :thumbup:

EDIT: My guess is that for some reason the map dialog doesn't get the message, which tells it to update. When I move it off the screen, part of it is lost, so the system sends appropriate message to keep it up to date. For some reason it doesn't happen when it's whole on the screen. Probably needs more InvalidateRect()

 

[donatelo200]

That planet was orbiting a G class star on the opposit side of the galaxy (relative to sol) some 3,000 ly away. I didn't record the name of the star sorry. The planet wasn't Earthlike it was an ice planet with an awsome purple atmosphere. I left that system awhile ago but problem with the venusian planets is alot more consistant.

 

[jedidia]

That planet was orbiting a G class star on the opposit side of the galaxy (relative to sol) some 3,000 ly away. I didn't record the name of the star sorry.

Ooookay, then I guess I have pretty bad chances at finding it... :lol:

considering Venusian planets, what would you suggetst? just increasing the haze altitude?

 

[IgnoreThisBarrel]

On my main install and the default 100830 install:
Works pretty well except for two things.
1) Whenever I press jump after selecting a system and waiting for the textures to load, Orbiter gets a CTD and I get that !OGSwitch scenario file. Then, once I open Orbiter again, without even loading any scenario it successfully brings me to my selected system.
2) When in the new star system some planets are completely black, no texture whatsoever. Others work well, but the gas giants always have a low sphere patch level, I tried editing the OrbiterGalaxy.cfg but to no avail.

Also, one more thing. On both installs, once the textures are finished generating (or rather, when the OrbiterGalaxy window un-minimizes) it starts rapidly flashing and I have to close it. This might be a cause for a problem, but I have no idea.

 

[donatelo200]

Hahaha. The venusian't haze altidude is high enough. I thing the density of venusian planets atmospheres needs to be greater. The screene above isn't an ice planet it's what i've come to call as messed up. (it's a venusian planet.) I will hunt for another planet that has the odd atmosphere bug too.

 

[IgnoreThisBarrel]

On the subject of Venusian planets I think there should be a specific "Titanian" class for Titan-like moons, and an "Ionian" class for volcanic moons. But then again that's just me being over-specific

 

[jedidia]

1) Whenever I press jump after selecting a system and waiting for the textures to load, Orbiter gets a CTD and I get that !OGSwitch scenario file. Then, once I open Orbiter again, without even loading any scenario it successfully brings me to my selected system.

That also happens on a clean install, you say? strnge. Have you set your Shutdown options to "respawn orbiter process"?

The symptoms clearly indicate a crash at shutdown, not reload. What might be the cause... I can't really guess anything from the top of my head. Maybe a memory leak that happens to be in a bad place on your machine.

When in the new star system some planets are completely black, no texture whatsoever. Others work well, but the gas giants always have a low sphere patch level, I tried editing the OrbiterGalaxy.cfg but to no avail.

Black... if they'd have no textures they'd be gray. Is there any rule to what type is black? Because of the Gas Giant, I'll see if there's anything wrong in the code so they don't get exported as it should be.

Also, one more thing. On both installs, once the textures are finished generating (or rather, when the OrbiterGalaxy window un-minimizes) it starts rapidly flashing and I have to close it. This might be a cause for a problem, but I have no idea.

That's kind of expected, we needed to verify if it happens on other machines as well. It's an issue between the Orbiter Dialog Window and the TexGen library, Artlav will fix it sooner or later.

How long do your textures usually take to export? If it's over 10 minutes, the process is probably falling backon the CPU because the GPU isn't up to the task. In that case, you can set the generation method to CPU, the flashing won't occur then. Of course, if your GPU can actually handle the generator, the flashing window is a minor nuissance.

 

[IgnoreThisBarrel]

Usually a minute or so at most, here're my texture settings.

//window resolution
1024x768
//current galaxy
MilkyWay
//default hotspots-file
Default
//Max texture level/min texture level (8 is limit!)
6,3
//Min radius for max texture level/max radius for min texture level(km)
5000,500
//always use at least this texture level for earth-like planets (0 to use textures by size) 
5
//don't use higher than this texture level for gas giants (0 to use textures by size)
6
//use this texture level for asteroids
3
//Max/Min number of asteroids in an asteroid belt
10,5
//Number of systems to keep in cache 
2
//Max Distance in lightyears for system Switch and time propagation (use 0 to disable time propagation)
0.1
//Safety margin to estimated time of deceleration burn (days)
30
//Method of Texture Generation (CPU = 0, GPU = 1. GPU has to support fragment shaders)
1
//Simplified textures (0 = full textures, 1 = simplified. Later is strongly recommended if textures are generated on the CPU)
1

I'll try using my CPU.

Also, I just went to the Gl 65 A system. Here are the planets that were NOT just black.
Gl 65 A e
Gl 65 A f
Gl 65 A g
Gl 65 A h
Gl 65 A i
Gl 65 A i IV
Gl 65 A j
Gl 65 A k

A lot were not generated, and this is using default seed settings.

---------- Post added at 12:12 ---------- Previous post was at 12:01 ----------

Neat! I just found out that when you jump to a system any docked vessels are transferred too. I just realized that that is an awesome feature!

 

[jedidia]

A lot were not generated, and this is using default seed settings.

NOT generated at all, you say? hmmm... Please try it with the CPU and tell me if that works better. maybe your graphics card seems up for the job but can't manage as well as it should.

Neat! I just found out that when you jump to a system any docked vessels are transferred too. I just realized that that is an awesome feature!

Why sure, it's an essential feature. How are you going to build your colony without it? :lol:

Same goes for atttachments, as well their attachements aso, so you can get a universal cargo deck and load all the goodies you need to set up your offworld colony. It's a thousand docked together vessels and a thousand attached vessels max, but I think that SHOULD be enough.

Oh, and with the max level for your gas giants set to 6 (and your max level in general), it's no wonder they look a bit polygonial...
Just be prepared for long generation times when you push the levels up. My GPU isn't up for the task either, and I'm currently exporting a system with textures between 6 and 8, and my poor machine's at it for the better part of an hour now Really need to get a new graphics card, if only to play with my own stuff.

And watch your back around Altair d. That place has no good reputation at all...

 

[IgnoreThisBarrel]

Only a thousand? Aww

Anyway, I just tried with CPU, they still aren't generated.

Strangely enough though, terrestrial planet's textures are always generated.

 

[jedidia]

Only a thousand? Aww

I CAN increase the number, if some madman should need it. But I want to see his stack of a thousand with a thousand attachements first, and a plausible reason for what exact purpose he needs more ships!

Anyway, I just tried with CPU, they still aren't generated.

weiiiiird. Could you please go to the directory the system is kept, open the texture log and post its contents here? Let's find out if they are not walked through for some weird reason or if they were *technically* exported.

 

[IgnoreThisBarrel]

Her ya go.

0.2i0.5i268.1j a.tex
0.2i0.5i268.1j a_cloud.tex
0.2i0.5i268.1j aM.bmp
0.2i0.5i268.1j b.tex
0.2i0.5i268.1j b_cloud.tex
0.2i0.5i268.1j bM.bmp
0.2i0.5i268.1j c.tex
0.2i0.5i268.1j c_cloud.tex
0.2i0.5i268.1j cM.bmp
0.2i0.5i268.1j c I.tex
0.2i0.5i268.1j c I_cloud.tex
0.2i0.5i268.1j c IM.bmp
0.2i0.5i268.1j d.tex
0.2i0.5i268.1j d_cloud.tex
0.2i0.5i268.1j dM.bmp
0.2i0.5i268.1j e.tex
0.2i0.5i268.1j e_cloud.tex
0.2i0.5i268.1j eM.bmp
0.2i0.5i268.1j f.tex
0.2i0.5i268.1j f_cloud.tex
0.2i0.5i268.1j fM.bmp
0.2i0.5i268.1j g.tex
0.2i0.5i268.1j g_cloud.tex
0.2i0.5i268.1j gM.bmp
0.2i0.5i268.1j h.tex
0.2i0.5i268.1j h_cloud.tex
0.2i0.5i268.1j hM.bmp
0.2i0.5i268.1j h I.tex
0.2i0.5i268.1j h I_cloud.tex
0.2i0.5i268.1j h IM.bmp
0.2i0.5i268.1j i.tex
0.2i0.5i268.1j i_cloud.tex
0.2i0.5i268.1j iM.bmp
0.2i0.5i268.1j i I.tex
0.2i0.5i268.1j i I_cloud.tex
0.2i0.5i268.1j i IM.bmp
0.2i0.5i268.1j i II.tex
0.2i0.5i268.1j i II_cloud.tex
0.2i0.5i268.1j i IIM.bmp
0.2i0.5i268.1j i III.tex
0.2i0.5i268.1j i III_cloud.tex
0.2i0.5i268.1j i IIIM.bmp
0.2i0.5i268.1j i IV.tex
0.2i0.5i268.1j i IV_cloud.tex
0.2i0.5i268.1j i IVM.bmp
0.2i0.5i268.1j i V.tex
0.2i0.5i268.1j i V_cloud.tex
0.2i0.5i268.1j i VM.bmp
0.2i0.5i268.1j i VI.tex
0.2i0.5i268.1j i VI_cloud.tex
0.2i0.5i268.1j i VIM.bmp
0.2i0.5i268.1j i VII.tex
0.2i0.5i268.1j i VII_cloud.tex
0.2i0.5i268.1j i VIIM.bmp
0.2i0.5i268.1j i VIII.tex
0.2i0.5i268.1j i VIII_cloud.tex
0.2i0.5i268.1j i VIIIM.bmp
0.2i0.5i268.1j j.tex
0.2i0.5i268.1j j_cloud.tex
0.2i0.5i268.1j jM.bmp
0.2i0.5i268.1j j I.tex
0.2i0.5i268.1j j I_cloud.tex
0.2i0.5i268.1j j IM.bmp
0.2i0.5i268.1j k.tex
0.2i0.5i268.1j k_cloud.tex
0.2i0.5i268.1j kM.bmp
0.2i0.5i268.1j k I.tex
0.2i0.5i268.1j k I_cloud.tex
0.2i0.5i268.1j k IM.bmp
0.2i0.5i268.1j k II.tex
0.2i0.5i268.1j k II_cloud.tex
0.2i0.5i268.1j k IIM.bmp
0.2i0.5i268.1j k III.tex
0.2i0.5i268.1j k III_cloud.tex
0.2i0.5i268.1j k IIIM.bmp
0.2i0.5i268.1j l.tex
0.2i0.5i268.1j l_cloud.tex
0.2i0.5i268.1j lM.bmp
0.2i0.5i268.1j l I.tex
0.2i0.5i268.1j l I_cloud.tex
0.2i0.5i268.1j l IM.bmp
0.2i0.5i268.1j l II.tex
0.2i0.5i268.1j l II_cloud.tex
0.2i0.5i268.1j l IIM.bmp
0.2i0.5i268.1j l III.tex
0.2i0.5i268.1j l III_cloud.tex
0.2i0.5i268.1j l IIIM.bmp
0.2i0.5i268.1j m.tex
0.2i0.5i268.1j m_cloud.tex
0.2i0.5i268.1j mM.bmp

 

[IgnoreThisBarrel]

Aha! I just looked in my textures folder, and a lot of the texture files were just plain black, like this one.

(This file was originally a BMP file)

 

[jedidia]

In other words,Textures for rocky planets without atmospheres get exported as a black mess.

Are you absolutely positive that you tried exporting in CPU mode? I can see how the GPU can produce such a result, but the CPU is slightly disturbing. It's a case for Artlav, anyways, since the trouble clearly lies with the generation. Not much I can do.