New Orbiter File Structure Proposal

[Artlav]

Following is a set of proposals of systematic or partial nature about rearrangement of Orbiter's directory structure, sketch #1.
Some of the ideas seem sketchy for now, but it's something to think about, considering that O2009 is far enough for partial drop of backwards compatibility.

Every point and idea is open for discussion, new ideas are welcome, etc.

Here is the boilerplate example for it:
http://orbides.1gb.ru/orbf/orbiter_new_boilerplate_wrap.zip
(Note - the files are empty, and there is a zip inside a zip (the only case when it pays off, btw))

Common:
All the solid-state, unchangeable-with-time things, like planets, vessel config and modules, plugins, Constell.bin, etc should be under \Universe.
All non-solid things like scenarios and flight records should be under \State.
Documentation goes to \Docs.
Other things, like Tools and SDK goes to \Etc, or to \SDK

Point E:
\State\Setup contains all the settings - keymap.cfg, Orbiter.cfg, device.dat, client cfg's, etc.
\State\Scenarios contains scenarios, \State\Quicksaves contains quicksaves, autosaves and current state backups.
\State\Flights contains obviously what.

Point C:
Old \Modules\Server goes to the default system - \Orbiter_ng.exe is actually \modules\server\orbiter.exe, not a link.
Cfg's are put into \ and renamed with _NG.

Point J:
\Universe\Plugin contains sub-system plugins.
All \*.dll goes there (if possible), all non-specific dlls goes there.
\Universe\Plugin\toggle contains Modules-tab activable plugins, \Universe\alltime contains permanent-on plugins.

Point Y:
\Universe\ contains Constell2.bin kind of files, plugin cfg's, etc.
Also contains script directory and multistage and spacecraft3 sub-systems directories (if doable).

Point B:
Vessels.
Every vessel or vessel set have it's own directory under \Universe\Vessels\vessel name
For it:
\ contains cfg's, dll's, images and help files, along with whatever settings add-on need
\model contains msh and dds files, along with whatever other models the vessel should use.

If a vessel needs meshes or textures from another vessel, one must add Share = vessel to the vessel's cfg file (or in-dll call), to let the core know where to look for the files.
Local files have higher priority than the shared ones.

Point A:
Compatibility.
\Universe\legacy should contain add-ons in current format along with all the in-orbiter usable files.
Instead of "unpack over Orbiter tree" old add-ons should be "unpacked over \Universe\legacy tree".
That way, partial backwards compatibility will be preserved - all but complex addons should work.
Also, all very-shared and core-used textures can be put there. Transparently available to all vessels, lowest priority.

Point S:
Solar systems.
Goes under \Universe\celbody\system name.
In it:
\cfg contain all cfg's, markers, etc.
\modules contains modules.
\model contains tex, maps, dds's and msh's.
\terrain contains terrain info (optionally, or if generalized - into the main cfg's)

All rules apply, as in vessels - sharing, transparency, isolation.

Idea 1: Backup current state on exit, like quicksaves.
Idea 2: Provide a call in the Orbiter core to load a mesh from vessel dll:
The call will get a vessel mesh in Orbiter-compatible format and import it, thus allowing add-ons to use their own mesh formats.

Thank you for reading this.
Double thank you for replying to this.

 

[hypersonic]

Good to see other people thinking along the lines that Orbiter's object structure needs to be modular.
So that when installing & removing addons, whatever they are, they don't interefere with the running of existing addons that are already in place.
Flight Simulator does it quite well for example.

 

[tblaxland]

OK, no huge objections here but a comments on plugin config files:

\Universe\Plugin contains sub-system plugins.
All \*.dll goes there (if possible), all non-specific dlls goes there.
\Universe\Plugin\toggle contains Modules-tab activable plugins, \Universe\alltime contains permanent-on plugins.

I notice transx.cfg under \Universe, which seems not quite the right place. Perhaps under \Universe\Plugin\config?

---------- Post added at 21:38 ---------- Previous post was at 21:37 ----------

Flight Simulator does it quite well for example.

I am not familiar with how Flight Simulator does it. Can you provide more detail?

 

[Kozak]

A fairly rightful idea.

Just some critics:
I think, directory structure must resemble its contents, not some blurry characteristic. Not "red\round\ball", but "sports\billiard\ball6".

So this should be easier:
- Every 2-nd+ levelfolder represents an object. \Universe\Sol\Earth means Earth with all bases, surface points, etc; \Vessels\DeltaGlider - mesh+module+config+textures, etc.

- Universe hosts everything about universe. Planets, stars, etc. So structure should loook like:
\Universe\Sol\Sol.cfg
\Universe\Sol\Earth\Earth.cfg
\Universe\Sol\Earth\Bases\Alcantara.cfg
\Universe\Sol\Earth\Bases\Alcantara_tile00.dds
\Universe\Sol\Earth\Terrain\<....>
\Vessels\XR2_Ravenstar\XR2_Ravenstar.cfg
etc.
Main config file name coincides with folder name.

So, main structure should look like this:
\Config --Orbiter configuration
\Plugins
\Scenarios
\Textures --Only shared textures here!!!
\Shaders --New Orbiter should support shaders. This will give much more possibilities to evolve.
\Vessels
\Universe

Idea 2: Provide a call in the Orbiter core to load a mesh from vessel dll:
The call will get a vessel mesh in Orbiter-compatible format and import it, thus allowing add-ons to use their own mesh formats.

This is currently realizable via clbkSetClassCaps - nothing preserves you from adding your own format conversion to msh there.

Also, I'll add one: Universe\<object>\<object>.cfg should have possibility to spawn objects by default. So, e.g. you can populate the Earth orbit with commercial satellites without having to copy/paste 10Kb+ of text.

 

[mjessick]

If you change the file structure, change it so it FOLLOWS operating system conventions.

Or at least make strict compliance an option, or (wild idea here :lol perhaps even the default. The major one to support Windows is to stop writing files in the installation heirarchy. (For example, allow a setting to determine where output files are written to, and default it using Windows UAC APIs. That is, to the user area.
http://en.wikipedia.org/wiki/User_account_control

Vista has hand holding stuff to allow this for now, but future operating systems may not even allow it. Not doing this has been a restriction since WinXP and routinely ignored because way back when, everybody got used to giving themselves administrator status.

 

[Artlav]

This is currently realizable via clbkSetClassCaps - nothing preserves you from adding your own format conversion to msh there.

Huh?
You can provide a pointer to a set of polygons and textures to some Orbiter api call i missed? Or do you mean something else?

If you change the file structure, change it so it FOLLOWS operating system conventions.

Or at least make strict compliance an option, or (wild idea here :lol perhaps even the default. The major one to support Windows is to stop writing files in the installation heirarchy.

???

What do you mean by "installation heirarchy"? How do you define it in Windows Vista? A place where exe file is? Every folder up from that place? Something else?
What if an exe file is just data then - how Vista would distinguish?

Some more information please.

 

[ThatGuy]

I am not familiar with how Flight Simulator does it. Can you provide more detail?

It's like this:

Flight Simulator
>SimObjects
-->Aircraft
---->Random airplane
------>Airplane's files
-->Rotorcraft
---->Random helicopter
------>Heli's files
-->etc.

Vessels are all in their own folder

I like this idea. It makes it much easier to remove faulty addons. I would like to see it like this:

 

[TSPenguin]

One could even keep it compatible with the old system by parsing the vessel/addon dirs like an old orbiter root.

 

[martins]

Or at least make strict compliance an option, or (wild idea here :lol perhaps even the default. The major one to support Windows is to stop writing files in the installation heirarchy. (For example, allow a setting to determine where output files are written to, and default it using Windows UAC APIs. That is, to the user area.
http://en.wikipedia.org/wiki/User_account_control

Out of interest: If write permissions to system areas are a problem, wouldn't the easiest solution be a local orbiter installation into a user's home directory? Surely in that case no higher privileges would be required to write files. Or does the local installation of applications violate another windows convention?

Having said that, I am happy to discuss changes to the directory structure. In order to make Artlav's and Mjessick's requests compatible, I guess the only requirement would be to ensure that the 'State' folder is not required to be a subdirectory of the Orbiter root directory. In that case, Orbiter itself could be installed in a system directory, and each user would have their states in their own home directories. The downside of this is that installing orbiter would become a bit more complicated than just unzipping a file, and it might not be so easy anymore to keep multiple orbiter installations, if they start overwriting each others' settings.

 

[Kozak]

Or do you mean something else?

I mean a function that parses e.g. 3ds file, writes it to temporary .msh and then loads by AddMesh.

 

[Artlav]

I notice transx.cfg under \Universe, which seems not quite the right place. Perhaps under \Universe\Plugin\config?

Yes, makes sense.
Actually, State\Setup would be better, considering the sudden point about people installing Orbiter under Program Files folder, of all places, and problems associated with it.

- Universe hosts everything about universe. Planets, stars, etc.

So, you think vessels are not a part of the Universe? I tend to disagree.
There are the unchanging Universe, and there are our changing impression of it - two places, two purposes, two folders.

About solar systems - yes, that's one of the sketchiest parts.
I was thinkng about putting bases separately from the planets, or planets+bases separately from solar systems, latter allowing for easy replacement of, say, a Moon with a NASSP-Moon -kind of things.

I mean a function that parses e.g. 3ds file, writes it to temporary .msh and then loads by AddMesh.

Yes, that can be done. But, why not get rid of that crutch?

I guess the only requirement would be to ensure that the 'State' folder is not required to be a subdirectory of the Orbiter root directory. In that case, Orbiter itself could be installed in a system directory, and each user would have their states in their own home directories. The downside of this is that installing orbiter would become a bit more complicated than just unzipping a file, and it might not be so easy anymore to keep multiple orbiter installations, if they start overwriting each others' settings.

And the location defined in a cfg file somewhere in the Orbiter installation, like \Universe?
That way average Joe will be able to install Orbiter without triggering the OS anti-user systems, while average tinker-happy Ivan can still have his Orbiter copies with data locality and where he wants them.

 

[Kozak]

So, you think vessels are not a part of the Universe? I tend to disagree.

World "Universe" also suggests Earth with me and you sitting and discussing this topic, as well as our hard drives. Should we place \Windows\ directory there also?..
Just no reason to have 1, 1\2 and 1\3 where you can have just 2 and 3.

As a software engineer, I have to note: Vista has no problems on UAC. The only problem is that it keeps a "virtual" copy of every file in program files for every user, if it's changed. This is obviuosly avoided by placing Orbiter in a different place (e.g. just E:\Orbiter for me. Vista x64, UAC on, no problems). No changes really needed here.

 

[Hielor]

As a software engineer, I have to confirm: Vista has no problems on UAC. The only problem is that it keeps a "virtual" copy of every file in program files for every user, if it's changed. This is obviuosly avoided by placing Orbiter in a different place (e.g. just E:\Orbiter for me. Vista x64, UAC on, no problems). No changes really needed here.

I put all of my games under C:\Games\ to solve the problem.

Also, turning off UAC (and being an administrator) will get rid of that virtual copy thing. I had to do it for Jedi Outcast, which saves its settings as a file in its local folder, and with UAC on it was never overwriting the original file, so it was never actually picking up the new settings.

 

[martins]

And the location defined in a cfg file somewhere in the Orbiter installation, like \Universe?

I don't think that would work, since \Universe is the shared folder. So it shouldn't contain any user-specific data, otherwise we are back at a single-user installation, except with a slightly more convoluted file structure . So either orbiter looks in a default location for the state folder, like $HOME/orbiter/state (which would be ugly, since it doesn't allow multiple installations), or (to make it really ugly) you put the location in the registry, or (my preferred option) you do it the other way round: the user starts orbiter from within the local directory, e.g. a shell script that contains the location of the public part of the installation. That way, you could have multiple State directories, all pointing to different orbiter installations.

 

[Artlav]

I don't think that would work, since \Universe is the shared folder. So it shouldn't contain any user-specific data, otherwise we are back at a single-user installation

Hm. Missed that.

the user starts orbiter from within the local directory, e.g. a shell script that contains the location of the public part of the installation.

Like Orbiter.exe -state $HOME/somepath, with default being where the exe is?
Then, same logic as in my previous post apply, only replacing "cfg file somewhere" with "use the Orbiter.bat". Unless i missed something else?

Also, turning off UAC (and being an administrator) will get rid of that

Unfortunately, some people thing the User Annoyance Control should be kept active.
And running under administrator may not be the best of ideas.

World "Universe" also suggests Earth with me and you sitting and discussing this topic, as well as our hard drives. Should we place \Windows\ directory there also?..
Just no reason to have 1, 1\2 and 1\3 where you can have just 2 and 3.

Well, "Universe" is just a non-boring name for "Data" folder, basically, having all the files under one folder instead on the with-exe tree.

 

[Hielor]

Unfortunately, some people thing the User Annoyance Control should be kept active.
And running under administrator may not be the best of ideas.

Yeah, I know, just mentioning the full workaround currently available. It's not a very good one, though.

 

[Kaito]

You know, I really, REALLY like this idea. Should make things much easier to deal with. Although, wouldn't this screw up the structure of already existing addons?

 

[TSPenguin]

You know, I really, REALLY like this idea. Should make things much easier to deal with. Although, wouldn't this screw up the structure of already existing addons?

One could even keep it compatible with the old system by parsing the vessel/addon dirs like an old orbiter root.

I rest my case

 

[Linguofreak]

I don't think that would work, since \Universe is the shared folder. So it shouldn't contain any user-specific data, otherwise we are back at a single-user installation, except with a slightly more convoluted file structure . So either orbiter looks in a default location for the state folder, like $HOME/orbiter/state (which would be ugly, since it doesn't allow multiple installations), or (to make it really ugly) you put the location in the registry, or (my preferred option) you do it the other way round: the user starts orbiter from within the local directory, e.g. a shell script that contains the location of the public part of the installation. That way, you could have multiple State directories, all pointing to different orbiter installations.

Why not have a file in the \Universe folder that contains a list of users that use Orbiter and where each keeps their \State directory?

 

[MattNW]

I haven't though as much about any of the other points you are discussing but having a more MSFS style installation of add ons would be a big step forward. Despite the advice to make texture and mesh names unique a lot 0f add ons still try to overwrite others. That's why I don't like just unzipping into Orbiter. I have a number of textures I've had to rename then I have to remember which ones has overwritten which others and rename textures or meshes before loading that add on. It would make it a lot more convenient and safe to have all textures, meshes and other files for each add on in a single folder like MSFS does. That would also make installing add ons much eisier. Just drop the folder "New_Atlantis" into the Spacecraft folder and you are done. No chance of overwriting other add ons.