Idea Suggestion for a mod loading utility

Blacklight

New member
Joined
Jun 15, 2008
Messages
259
Reaction score
0
Points
0
Location
In space ?
Website
www.myspace.com
I don't know if this exists or not. The only mod loader I ever use for Orbiter is JGME. When working with the game, Oblivion, it really matters what order the addons are loaded and they have a utility called BOSS that can look at the addons you have, put them in the best load order, and notifies you of problems. Then it hit me that it would be cool to have kind of a second generation JGME for Orbiter that does the same thing. I know that JGME will notify you if different addons overwrite other parts of prior loaded addons, but could there be a way of writing something that would check to verify that the files being overwritten were exactly the same or modified versions of files called the same thing and then put the mods in a good load order to minimize conflicts ?
 
Oblivion (or Morrowind, or Fallout 3) mods are somewhat different than Orbiter add-ons.

The former use more packaged approach of modifications (.esp/.esm for game content modification - like configuration files, and optionally .bsa archives for modified files - textures, models, sound). Load order there is arranged by modification time of those files.

Orbiter doesn't use add-on packages, nor checks the file modification date to load files in specified order, but rather loads the dependent files in the order they were referenced in appropriate configuration files, and configuration files are loaded in a similar order (or in order they were found by Orbiter in the bases directory, for surface bases).

I don't think there are any major conflicts of the load order (you don't usually have many, differently named configuration files for the same surface base). The only conflicts are caused by replaced files and not their load order.
 
but wait.. his idea is good.
ModLoader for Orbiter = AddOnLoader(so I'll © it:) OAOL)
Maybe I'll make a program(yes in .Net 4:lol:) which loads *.zip packages of add-ons.

Imagine profiles of selected add-ons:) for example:
I want to fly to the moon today- I'll use a profile with best-looking KSC and landing site on the moon.
I want to train my experience in flying in Mars atmosphere- I'll use a profile with proper ships, bases on Mars and best textures of it :D

That would be cool(in my opinion) so maybe I'll make a proper program for this:thumbup:

P.S. That will help to keep original Orbiter installation almost untouched:)

EDIT: I've a pre-screen of the app:thumbup:
preview.png
 
Last edited:
To be done right it needs core support - a virtual file system or split structure. Then you put the addons in their zips into mod directory, or unpack them into a repository.

Scenario file contains a list of addons it needs, and running it activates them.
Plus some basic cfg file with common stuff like MFDs and hi-res textures.

Would be nice.
Would take effort and thinking.
Would break compatibility big time, or become another [V] feature.
Would require Martin to bother about this, instead of making winds blow across the dunes of Titan or magnetic fields screwing satellite trajectories.
 
I won't need Martin's help:thumbup:
I can't write modules for Orbiter(anybody want to help me?). The application will be running this way:
OAOL.exe <-- main app
OAOLpm <-- profile manager
===
You start OAOLpm.exe and select your profile and then close it.
You start OAOL.exe and it will be running in background.
After loading OAOL.exe you turn on Orbiter and enjoy it.

No any special filesystems. Application will just extract(and make a backup of original ones) files from ZIP packages replacing original ones and when you want to close Orbiter and the app it'll restore original files and everything will be cool.

I'll create a separate thread for it(later).
 
Application will just extract(and make a backup of original ones) files from ZIP packages replacing original ones and when you want to close Orbiter and the app it'll restore original files and everything will be cool.
So, each time i start Orbiter my SSDs would be worn in circles by adding and removing a few Gbs of add-ons?

How long do you expect someone would be willing to wait for Orbiter to load?

Or, do you expect to solve it in such a way as to avoid long waits and hardware wear?
 
may i suggest a more optimal approach by using a special "Addons" folder, which contains sub-folders where each addon is installed in the same folder layout it would take in Orbiter...
then at load time, this tool runs which of those are supposed to be active and hard-links them into their "loaded" positions in the real Orbiter folders respectively


let me try to illustrate the concept:

Code:
orbiter_root_folder
 | - scenarios      <---------------------¬
 | - meshes                               |
 | - modules        <--------------------¬| 
 | - (...)          <-------------------¬||
 | - addons                       [NTFS SYMBOLIC LINK]    
     |                                  |||
     | -  (...)                         |||
     | - SuperRocket3000                ||| 
         | - (...)        --------------'||
         | - modules      ---------------'|
         | - scenarios    ----------------'


this way, no additional storage or copying is required - a symbolic link can be created by shell commands (can be done by a program) and works like a "solid shortcut" of sorts
so when a link is found, it works as if the file existed in that folder, even tho it's somewhere else

this allows one to "forward" any bunch of files into an "enabled" position by linking the files stored separately into their relative paths under the orbiter root :rolleyes:


is there any reason this would not work or blow up ppl's computers?
 
Last edited:
{...} hard-links them into their "loaded" positions in the real Orbiter folders respectively

{...} a symbolic link can be created by shell commands (can be done by a program) and works like a "solid shortcut" of sorts {...}
It's either hard link or symbolic link, not the both at the same time, as they are different things. Symbolic links aren't supported by Windows XP, but hard links and junctions are, so hard linking would be better - the limitation of hard link is that linked files need to be on the same partition.
 
It's either hard link or symbolic link, not the both at the same time, as they are different things. Symbolic links aren't supported by Windows XP, but hard links and junctions are, so hard linking would be better - the limitation of hard link is that linked files need to be on the same partition.

ah yes - my mistake...
hmm, i think there's a patch or something to enable symbolic links in XP... i say because i think i remember using something of that sort back then.... or maybe i'm just tripping out :P

anyways, i think hard links have a few disadvantages in the big picture, but for this application they do the job just right...


although, i don't think i really get the big deal here... most Orbiter addons are hardly ever conflicting (i've never seen it happen, actually) - and there's very few cases where you'd wanna turn off something that can't be disabled in the modules tab on the launchpad

just a thought... :hmm:
 
I'd love to see this work, and wish I could help. I wish you the best of luck. I know I could use a more practical way to restore the orbiter install, and to organize all the add-ons I have.
 
I know it is some kind of self-advertising, but for the discussion it should be pointed out that there is another type of addon-installer in the works here.

If you start talking about your own filesystem and special folders, I'd recommend you take a look at modern DVCS systems like Git and Mercurial. I bet it'll save you from re-inventing the wheel...

regards,
Face
 
Symlinks?
Actually, that's a grand idea.
No way to add it to XP, since it is a kernel feature.

Problems:
-What if a file is to be replaced?
-What if there are two files of same name?
-What if a file is to be removed?

Only first one is an issue, but a solvable one.

That might even work.
 
Many thanks for telling me about hard linking. I will try to experiment with it.

Symlinks?
Actually, that's a grand idea.
No way to add it to XP, since it is a kernel feature.

Problems:
-What if a file is to be replaced?
-What if there are two files of same name?
-What if a file is to be removed?

Only first one is an issue, but a solvable one.

That might even work.


I'm going to solve these problems in this way:
-leave only those files that are never converted (eg orbiter.exe) is not violated
- All other files (eg earth.tex) move to the folder addons / defalut
- All files in the addons / default will be replaced by files in selected folders from addons
-if the two folders will be on the same files that the program will return an error:)

So, I give an example of:
in my addons folder folders:
-defalut
-amso
-dgiv

I want to fly to the moon Apollo 11 so choose AMSO OAOLpm.exe and fires through the program. The program converts all files in the folder files from a folder defalut AMSO thereby creating backups of original files. Finally, the program uses a hard-linking.
Turn on the simulator and I'm glad your ship.

^
|
|
|
Sorry for translate google:lol:

EDIT:
I've a big problem:( I've found this:
Unfortunately, neither hard links nor soft links are supported by the .NET Framework.

I can write only .NET 4(VB 2010) apps. :(

Therefore, you will need to dig into the Windows API to allow your application to consume this feature.

So, somebody who knows C++(am I right?) should help me. Somebody will have to create a simple console app in C++ which only links the "defalut" folder. I will do the rest.
 
Last edited:
So, somebody who knows C++(am I right?) should help me. Somebody will have to create a simple console app in C++ which only links the "defalut" folder. I will do the rest.
It's for C# I'm writing it in VB 2010
Why ask for C++ if you write in VB?

Then, that example describes all it needs - you need to import functions from kernel32.dll, and use it.
Idea given, DLL name given, function name given - now find the right syntax for your language, and start working.

Also, it's generally a bad idea to start learning programming with .NET languages. The damage it would do can be irrecoverable.
 
It's for C# I'm writing it in VB 2010

Code:
<DllImport("kernel32.dll", EntryPoint:="CreateSymbolicLinkW", CharSet:=CharSet.Unicode)> _
Public Shared Function CreateSymbolicLink(<[In]()> ByVal lpSymlinkFileName As String, <[In]()> ByVal lpTargetFileName As String, <[In]()> ByVal dwFlags As Integer) As Integer
End Function

or:
Code:
Private Declare Auto Function CreateSymbolicLink Lib "kernel32.dll" ( _
    <[In](), MarshalAs(UnmanagedType.LPTStr)> ByVal lpSymlinkFileName As String, _
    <[In](), MarshalAs(UnmanagedType.LPTStr)> ByVal lpTargetFileName As String, _
    <[In]()> ByVal dwFlags As Integer) As Boolean

Source: MSDN: CreateSymbolicLink
 
It's for C# I'm writing it in VB 2010

In the nicest way possible: I'd suggest your starter project would be something that does not have the potential to delete users' files.

If you can't even convert a C# dllimport to VB (in the same framework even!), I'm not sure your input validation will be quite up to par to handle arbitrary file deletions with uncertain input.

Also, you'll find it is much easier to find good examples in C# than VB how to do various stuff in .NET, so learning to at least read that syntax would be a good idea.

Nevertheless, orb nicely provided the syntax conversion already, so hack away. :thumbup:
 
Back
Top