Project Orbiter Galaxy

[jedidia]

I tried running the standalone map, and it crashed.
So I reinstalled it along with the patch and... it still crashes.
The strange thing is I remember when I first downloaded it the standalone map worked fine. :shrug:

That is weird indeed. Have you tried re-downloading?

Win64 shouldn't be a problem, Barrel is using it too if I'm not mistaken.

Sometimes when I wander too far from our local star group in the map it crashes. Maybe this is just a more severe form of whatever that is.

No, unfortunately no. It's an orbiter "bug", because the doubles are simply not able to keep up with the precision, leading to all kinds of messy stuff. I forgott to mention that in the readme, but I never tried out how far you can actually go, so you might give me a hint here. How far out are you when the crash happens?

 

[IgnoreThisBarrel]

Yeah, I use 64-bit too.

As for the going too far from our local star group, I haven't experienced any bugs with that, but that's probably because I've only "jumped" from one system to another.

 

[jedidia]

@Pyromaniac: another thing that comes to mind is if you messed something up in your config file. Not keeping the structure of the file can lead to a crash. So if you changed anything, it might be helpful to post it here so I can take a look.

As for the going too far from our local star group, I haven't experienced any bugs with that, but that's probably because I've only "jumped" from one system to another.

Farthest out I've been was 10 lightyears, but if you have any attachements or docked ships this looks quite worrying in external view. I also don't know if stying at a great distance over a long time can lead to a crash too. Orbiter simply wasn't designed to do what we try to do with it, so we have to accept some backdraws...

Sometimes when I wander too far from our local star group in the map it crashes. Maybe this is just a more severe form of whatever that is.

Also, re-initializing the HUD can crash orbiter at much earlier distance. From 1.5 lightyears upward, it is dangerous to re-activate the HUD (this is why the HUD is disabled when you switch the scenario. If you try to activate it too far from a star, you'll find yourself on the desktop).

 

[Columbia42]

No, unfortunately no. It's an orbiter "bug", because the doubles are simply not able to keep up with the precision, leading to all kinds of messy stuff. I forgott to mention that in the readme, but I never tried out how far you can actually go, so you might give me a hint here. How far out are you when the crash happens?

Let me clarify. I'm not talking about actually jumping too many systems away from Earth. I'm talking about when I open up the map I double click on a faraway star and the map crashes. Usually this happens when the star is too far away or when I switch the grid of stars being displayed too many times.

 

[jedidia]

Let me clarify. I'm not talking about actually jumping too many systems away from Earth. I'm talking about when I open up the map I double click on a faraway star and the map crashes. Usually this happens when the star is too far away or when I switch the grid of stars being displayed too many times.

Ah, yes, entirely different matter Most probably related to the memory leak I killed two days ago. Haven't heard from Artlav yet, I think I'm going to upload the new patch as is, and delivering a fix for the frozen window in GPU generation later on. But I have to finish those few optimisations first I was talking about.

To make a long stroy short, I am confident that those crashes will be eliminated with the next patch!

I'm talking about when I open up the map I double click on a faraway star and the map crashes.

wait... after reading this line I'm having doubts again. You DOUBLEclick on a far away star? that is, before or after you centered it?
oh dear... Just re-running the code in my head right now, The window-message loops passes on doubleclicks without passing on a single click first. That means, unlike in the standalone, in Orbiter a doubleclick would be sent directly to the window, while in the standalone, it would be interpreted as a single click as long as the star isn't centered. Since Stars outside the centered cube don't have their systems generated yet, that can only lead to a crash. Thanks, you just showed me another one here. Will be fixed. For now, know that you're supposed to simply click on a star first to center it, and THEN double click it to get to the system screen. In the standalone it is impossible to do it otherwise, but not in the plugin...

 

[Pyromaniac605]

I have tried redownloading it, that's what I meant by reinstall and I didn't make changes to any of the files.

Darren

 

[Linguofreak]

:lol:

Yeah, I know that there can be strange occurances with moons... The only limit currently checked is the roche limit, but that won't prevent them from being very close to each other if they are of similiar mass and density.

This will get reworked for 0.7, but let's get 0.6 as stable as I can get it first.

I don't find that that screenie stretches believability too much. To my knowledge, such a planet/moon pair, or double planet, whatever you want to call it, is not physically impossible.

 

[jedidia]

I have tried redownloading it, that's what I meant by reinstall and I didn't make changes to any of the files.

Then I'm at a total loss as for a the possible cause...

Let's summarize: Plugin freezes when opening the map from the MFD, together with Orbiter (you can't play anymore, you have to shut down the simulation). Standalone freezes at startup (not when you save a system) but worked the first time it was run. You didn't make any changes to any configs, and I assume that you didn't change the directory structure while copying. Just to make sure: The OrbiterGalaxy.exe file is in the same directory as your Orbiter.exe file and the OrbiterGalaxy directory.

You're using Win7 64, which has proven to work in other instances, and Orbiter 2010p1, which is what the module was designed for. Is all of that correct?

I don't find that that screenie stretches believability too much. To my knowledge, such a planet/moon pair, or double planet, whatever you want to call it, is not physically impossible.

Not theoretically impossible, but a moon that close seems at least practically highly improbable, and wouldn't survive very long. I do have to put in some limit to prevent occurances where moons overlap, in any case.

Nice to see you around here by the way. Did the plugin run under wine?

 

[Pyromaniac605]

OrbiterGalaxy.exe is in the same folder as Orbiter.exe, I did not change the structure, I am using Win7 64-bit, I am using Orbiter 2010 P1.
Phew, that was a lot to type. :lol:

Darren

 

[jedidia]

And the freeze happens right at the start, so you never even get to see the star map, not in the plugin nor in the standalone, right?

 

[Linguofreak]

Not theoretically impossible, but a moon that close seems at least practically highly improbable, and wouldn't survive very long. I do have to put in some limit to prevent occurances where moons overlap, in any case.

Earth's own moon, if it formed as it is theorized to have, had to have started out fairly close (I'm not sure exactly how close), and as long as a moon is outside of the synchronous orbit radius for its planet, it will move outward with time, slowing down the planet's rotation as it goes, until it's in synchronous orbit, so even a fairly close moon shouldn't be too short-lived.

Nice to see you around here by the way. Did the plugin run under wine?

Haven't tried it yet. Probably won't until mid-December, as I'm fairly busy with school at the moment.

 

[jedidia]

Haven't tried it yet. Probably won't until mid-December, as I'm fairly busy with school at the moment.

Tell me how if it works once you find the time



New patch up:
[ame="http://www.orbithangar.com/searchid.php?ID=4943"]Orbiter Galaxy 0.6.03 PATCH[/ame]

Fixes several small problems that could lead to crashes and introduces status display for texture export, although it most probably won't work when exporting on the GPU, because that still makes the window freeze.

 

[donatelo200]

I don't find that that screenie stretches believability too much. To my knowledge, such a planet/moon pair, or double planet, whatever you want to call it, is not physically impossible.

They are slightly eccentric. So they collide. The mass ratio itself is realisstic.

 

[iamwearingpants]

Everything is working perfectly but I have one problem.
All my planet textures are missing!

Is there a solution to this?

 

[Linguofreak]

They are slightly eccentric. So they collide. The mass ratio itself is realisstic.

Ah. Eccentricity is... problematic. Two objects that close would likely be tidally locked, at least the smaller body to the larger one, and that process tends to do away with eccentricity.

 

[jedidia]

Everything is working perfectly but I have one problem.
All my planet textures are missing!

You could start by not jumping to the targeted system if the textures haven't finished exporting yet, which is what I have to assume you are doing with the little information you provided

---------- Post added at 01:50 PM ---------- Previous post was at 10:16 AM ----------

Added a new patch with a quickfix for those who have black textures generated for planets without atmospheres. I hope this fixes it. Wanted to put it into the last, but somehow completely forgott about it:

[ame="http://www.orbithangar.com/searchid.php?ID=4943"]Orbiter Galaxy 0.6.04 PATCH[/ame]

 

[donatelo200]

This is major problem. I am unable to explore any venusian planets or any planets with a thick atmosphere for that matter.

The atmospheric pressure itself is correct but it's dencity is wildy off making the atmophere a very extended. Densitys of these atmospheres should be extremely high on the order of 250g/ml for this planet but the density is only 94 g/ml.

 

[Columbia42]

Just tried the new patch and everything works really well (except for the status of texture exportation not showing up while running on GPU.) I do have one small problem which is that textures are still not being deleted from my hard drive. I have the number of systems to keep in cache set to 2 but I currently have 4 sytems in cache and a corresponding amount of textures in my textures folder. Whenever I export a new system it replaces one of the four so the number of systems in cache is always 4 which is fine excep that I have the number set to 2 in OGalaxy.cfg.

 

[jedidia]

again, the manual does miracles... :lol:

2 Systems is the absolute minimum cache size for Orbiter Galaxy to work, so that is hard coded. What you define in the cfg is ADDITIONAL cache size
Also note that if you reduce the cache size, the remaining systems won't get removed automatically. I have to put that in sooner or later...

The atmospheric pressure itself is correct but it's dencity is wildy off making the atmophere a very extended. Densitys of these atmospheres should be extremely high on the order of 250g/ml for this planet but the density is only 94 g/ml.

Please provide me with system name and the cube it can be found in (coordinates, displayed in the upper left screen of the star map), otherwise I can't take a look at it (unless it's a catlogue star, those I can find). I might have a bug in the calculation of atmospheric density somewhere. Or it might just be that the atmosphere consists of very heavy gases, in which case the the density is actually accurate. Heavy gases would result in a much denser atmosphere at the same pressure than lighter gases.

 

[Columbia42]

Please provide me with system name and the cube it can be found in (coordinates, displayed in the upper left screen of the star map), otherwise I can't take a look at it (unless it's a catlogue star, those I can find). I might have a bug in the calculation of atmospheric density somewhere. Or it might just be that the atmosphere consists of very heavy gases, in which case the the density is actually accurate. Heavy gases would result in a much denser atmosphere at the same pressure than lighter gases.

It's not a specific system. All venusian planets are pretty much like this.