Project Orbiter Galaxy

[rko1963]

Hi Jedidia,

F4,select Camera, than most right Card, Preset selection,
clear all......

regards, rko1963

 

[jedidia]

I have the sad duty to anounce a longer break in developement of Orbiter Galaxy. for details, see my Blog-Post:
http://www.orbiter-forum.com/blog.php?b=726

Linguofreak, if you're interested in the latest version of the standalone exe with halfway working pathfinding, send me a pm with your email, I'll send it to you. Short range (up to 30 to 40 parsec) works very well, above that it's not optimised and even has a few bugs, but you might still be able to make something of it for your "world-building with ill-defined purpouse"

 

[jedidia]

*************************************************************
Developement is officially back on after a longer break. No need to read
anything prior to this post!
************************************************************

The dice have fallen, I'll pick it up again. So this support and discucssion thread is oficially re-opened.

I'm glad I made the poll, as its result were differently than expected, but that's why you make polls... to know what's really going on.

Progress won't skyrocket immediately, though. I left the project with a significant difference in code between the standalone and the plugin, and will have to get them synchronized first. Then I must screw around with the rather rudimentary path-finding AI I wrote for the jumppoints (which are integrated in the standalone, but not in the Plug-in, and certainly not yet in orbiter).
This thread is mostly to make people aware that developement is back up again, and to shove the support thread up the ranks again. So if you download the Add-on now (it is more or less usable, and I'll be glad for any bug reports since getting the thing running stabily is one of the goals of the next version) and run into trouble, here's the place to come to.

The lessons taken from the Poll have already led to a change in the roadmap (see first post in this thread): The people that have no use for Orbiter Galaxy, because they are perfectly content with the solar system, are close to half of the voters. If I take this to be representationally for the community (not exactly statistically sound, but I hope a good enough aproximation) and assume that these are also the people putting the most emphasis on rock-hard realism, it led me to believe that scientific accuracy currently is not the top-most priority, but playability is. I have therefore put off the generator overhaul to produce more accurate systems to version 0.9 (admittedly, it is also the most not-fun to programm), with all the fancy stuff coming before that. Most notably, the next version will support consistency, so you can leave stuff in a system and later return to it (which is not possible in the current version: whatever you leave when you leave, vanishes) and also to give custom system developers the ability to put their orbital bases in along with their systems.

There will be a different thread for the purpose of discussing the GUI, since the poll showed it to be quite a deal breaker. Since I want to keep this thread dedicated to support and fixing bugs, please participate in the other thread and tell me what you don't like about the interface.

 

[edsupagood]

Ok, as I said in the other thread, when the textures finish exporting and I click Jmp, Orbiter exits and restarts. Then I get a CTD, log shows that the configurations are missing:

---------------------------------------------------------------
>>> ERROR: While initialising solar system OGalaxySystems/!359.9h0.1g16.5h/!359.9h0.1g16.5hSystem:
>>> File not found: .\Config\OGalaxySystems/!359.9h0.1g16.5h/!359.9h0.1g16.5hSystem.cfg
>>> [Orbiter::CreateRenderWindow | .\Orbiter.cpp | 727]
---------------------------------------------------------------
>>> TERMINATING <<<

 

[jedidia]

It's a tough nut to crack... config files are exported first, way before textures. In theory, it is impossible to have textures exported but not config files...

So, let's start with the very few things that come to mind from the top of my head. Some of these questions will probably sound a bit silly, but my options here seem very limited...

1. Did you export from inside the Orbiter plugin, or from the standalone exe file?

2. I the second, where is OGalaxy.exe located?

3. Did you just install OG, or did you have it installed before and have merely activated it in the plugins?

4. Does the folder Config/OGalaxySystems actually exist, or is it not there for some reason? (might be possible that it got deleted if an older install, or something went haywire with the installation). If not, the generator is trying to save files to a non-existing directory, which of course don't work. If the folder is missing, create it, and delete the cache.txt file in your OrbiterGalaxy folder. You'll have to export the textures again after that, but such is life...

 

[edsupagood]

I think number 4 is the problem. I just download from OH and OGalxySystems folder in not included in the archive.

 

[jedidia]

I just downloaded it to check, the folder is in the archive... (Config/OgalaxySystems)

I suppose you did download the 0.6 Alpha AND the 0.6.1 patch, otherwise the whole thing shouldn't be working at all, so that question is kind of mute. What program are you using to unpack the archive? is it possible that some unpackers are ignoring empty folders??

Anyways, if you create the folder manually, everything should work just as fine. Make sure to delete your cache.txt file, and delete the textures of the exported systems in your Orbiter/textures folder, or they'll just be lying around eating diskspace. Reminds me that I need to include a function for automated cache removal in a next version...

 

[edsupagood]

Oh that was it, when I unpacked the archive empty folders were just ignored. Now everything is working fine.
Thank for the help!

 

[jedidia]

I just got a new version of the texture generator from Artlav, works a lot better, now the textures actually look what they're supposed to, and it's a tad faster too. Will still be a while to bring my outdated code up to the needed level for a new patch, though.

 

[jedidia]

Just thought I'd give a heads-up for all that are still remotely interested in this project.

I have been hampered in the interface re-design by an irrlicht bug that didn't clip tables properly, and it took me a while until I got around to checking out and building a version of irrlicht where the bug is fixed but that is still compatible with my code so far. That is partly due to reading up on a decade of Schlock Mercenary as well as some scripting work for pioneer, but I'm finally on track again.

Table clipping is fixed, and I'm rewriting the GUI to something that will hopefully be more comfortable. As mentioned previously, the overhauled texture generator is also working quite nicely, although unfortunately not under D3D-client. I hope that can be fixed some time in the future, for now I just hope I can get a new Orbiter Galaxy version out before christmass, with the new GUI and stable generator, but otherwise there won't be any fancy updates yet.

 

[dumbo2007]

great man, keep at it ...iterative improvement, thats the way to go >>>

 

[dumbo2007]

Well, I just tried to download it from here :
[ame="http://www.orbithangar.com/searchid.php?ID=4942"]Orbiter Galaxy 0.6.2 ALPHA[/ame]

and it says The specified file does not exist.

 

[jedidia]

WTF? Confirmed. I tried downloading another add-on, which shows the same message. Looks like O-H is in trouble currently! please be patient, I think they'll have it figured out soon.

 

[dumbo2007]

Nice!, its generating the textures now

I see you also implemented the progress dialog which tells me something is going on and how much is left.

I initially tried with the standalone OrbiterGalaxy.exe to target a system but did not find the "target this system" button. Then I realized it must only appear when orbiter galaxy is started from within Orbiter from a vessel MFD.

So a request , would it be possible to put this button in the standalone exe too. Just so the user has the option of starting off the texture export without starting Orbiter.

---------
ok its done exporting......will report after the jump >>>>

 

[jedidia]

So a request , would it be possible to put this button in the standalone exe too. Just so the user has the option of starting off the texture export without starting Orbiter.

This is already available, it's just called "save to cache" in the standalone. I chose this naming due to the fact that the system has to be targeted again when wanting to fly to it in orbiter, so it's not really targeting. It's merely exporting the system and telling Orbiter Galaxy that it's on the disk. Thus when you target it, Orbiter Galaxy won't export it anymore, until the system gets removed again because the cache is full.

If your export is slow but you have enough diskspace, it's recommended to raise the cache size in OGalaxy.cfg, especialy if you have a few systems you visit frequently.

 

[jedidia]

ok its done exporting......will report after the jump >>>>

So... what happened? did you get eaten by a monster in hyperspace? or get too close to the blind spot? :lol:

 

[dumbo2007]

haha...got lost in sub space

yeah its holiday time, so didn't get much flight time with Orbiter over the last few days


So the systems were generated quite smoothly for the stars I went to, I havent noticed any textures missing as yet.

-------------

Ok so I just double clicked on Sirius and I guess it doesnt have planets, which is fine. So, I entered the star details screen after double clicking and I see no planets in the upper area of this screen, which is still good. Then I tried to click the >>> button and it crashed. So I think the program tries to goto the next planet even if there isnt any and maybe a null pointer access.

Checking out Procyon now...seems to have lots of planets

----------------------

So I tried to jump to Procyon after generating the system from within the DG sitting on a pad at Brighton Beach(the default scenario). And it exported the textures fine and then I pressed Jmp on which I am back in the Launchpad with the !OGSwitch scenario at the top. But when I try to launch it I get :

VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Finished initialising world
Module DeltaGlider.dll ....... [Build 111105, API 111105]
============================ ERROR: ===========================
Scenario parse error for vessel GL-NT: base 'Brighton Beach' not found on body 'Procyon'.
[Vessel::ParseScenarioLine2 | .\Vesselstatus.cpp | 174]
===============================================================
>>> TERMINATING <<<

So is it due to the Brighton Beach base somehow getting written to the !OGSwitch scenario too ?

Maybe I did something wrong. I'll trying jumping to GroomBridge now.

---------------

Ok so with GroomBridge too I had the same issue, so I removed the line :

BASE Brighton Beach:4

from the scenario file and it loaded the GroomBridge system without any issues this time

out with the camera !!! :leaving:

-------------------------

The gas giants look good. Perhaps higher level textures for the moons though. 'cause they look a bit pixelated. Which reminds me, how about some random terrain to match the textures.

So I am trying Rigel Kentaurus B now, since it seems to have a terrestrial planet, and I pressed the Map button by mistake while it was creating the textures, so it crashed , will try to find that star again.

---------------------

Oh wow there is a galaxy sector chooser button

Took a trip to the center of the galaxy and its packed with stars as expected , no black hole though

hmmm, navigating around the galactic core is tough all right, too many stars, my laptop fan just turned on and the map has slowed to a crawl.

Suggestion, perhaps you can reduce the size of the cube(i.e. reduce the range) within which the stars are loaded, the closer to the galactic center the user clicks.

heading back out now >>>>

-----------------------

Ok so my next jump has landed me in a star with the rather mysterious name : 333.8e0.e16323.2e (took 5 alt-tabs to get that down correct )

Well so I saw that the last planet is a ice giant of the type of Neptune(before the jmp, when I was exporting the textures from the map). But when I visit this
planet it seems to have bands across instead of a Neptune like texture. Maybe a Neptune like texture generation can be added to the procedural generator.

Saw some interesting planets like 333.7d-0.1d16342.4c e with neptune like blueness near the poles and 333.7d-0.1d16342.4c g is rather interesting with canal like curving features on a orangish surface.

-----------------

By the way, not directly related to Orbiter Galaxy, but is it possible to slingshot around a star when on you way to another one from Sol ?

...ok time to hit subspace again...will report in later

 

[jedidia]

So the systems were generated quite smoothly for the stars I went to, I havent noticed any textures missing as yet.

Good to hear!

Ok so I just double clicked on Sirius and I guess it doesnt have planets, which is fine. So, I entered the star details screen after double clicking and I see no planets in the upper area of this screen, which is still good. Then I tried to click the >>> button and it crashed. So I think the program tries to goto the next planet even if there isnt any and maybe a null pointer access.

Odd, I can't reproduce that one. the >>> button is for moving to the next system, not the next planet. Is this crash reliable on your machine, or might there be other circumstances involved?

So I tried to jump to Procyon after generating the system from within the DG sitting on a pad at Brighton Beach(the default scenario). And it exported the textures fine and then I pressed Jmp on which I am back in the Launchpad with the !OGSwitch scenario at the top. But when I try to launch it I get :

Ooops, yeah, jumping doesn't work when landed. I should put in a safeguard for that...

The gas giants look good. Perhaps higher level textures for the moons though.

You can adjust texture levels in the OGalaxy.cfg in the OrbiterGalaxy directory. Note however that 8 is maximum. In default configuration, 4 is minimum texture level and 6 is max, which means that the smaller bodies get 4 (which would most likely be the case for most moons), and the biggest get 6. There's additional parameters for Gas Giants, for which you can assign a maximum level (since they're always the largest but you seldomly get close to them) and a minimum level for terrestrials, since they're the most likely you're going to land on.

Suggestion, perhaps you can reduce the size of the cube(i.e. reduce the range) within which the stars are loaded, the closer to the galactic center the user clicks.

That isn't possible without changing the whole architecture, but you can deactivate the surrounding cubes in the drop-out GUI of the star map, that usually helps enough. There's a limit of a thousand stars per cube (which is actually way too few in the core, but I chose to leave this limitation for performance reasons), so in the core you're likely to have about 27,000 stars on display if you don't deactivate displaying the surrounding cubes. Enough to even force a high-end GPU to its limits.

But when I visit this planet it seems to have bands across instead of a Neptune like texture. Maybe a Neptune like texture generation can be added to the procedural generator.

Gas Giants don't have varied texture export yet. It's on the list.

Which reminds me, how about some random terrain to match the textures.

That one is a bit delicate. It would be theoretically possible to adapt ORULEX to provide matching terrain, but Artlav has declared Orulex deprecated, because it's too much of a hack, and there's a random Win7/Vista CTD that he never was able to resolve. I'm not sure of his plans, but if I interpreted various statements of his correctly he's waiting for better support by the core or by a graphics client that would allow to implement the whole thing properly. So, unless Orulex gets an overhaul, there's not that much point in adding it to Orbiter Galaxy, as I couldn't produce matching terrain in its current state, and will crash every few minutes on any Win7 or Vista machine anyways.

 

[dumbo2007]

but you can deactivate the surrounding cubes in the drop-out GUI of the star map

Oh ok, I though there was just 1 cube whose limits were defined by the green grid. Ok I ll try to deactivate some cubes.

 

[jedidia]

The stars in the adjacent cubes are also displayed if you don't deactivate them, although their systems aren't generated yet (to make generation while scrolling "pseudo seemless", although the impression quickly breaks down when you're in more densly populated areas).

Plus, there is a manual, you know. But don't worry, I go through some lengths to accommodate my testers. I've got few enough of them as it is.