API Question Sol file name

[cristiapi]

Is there any function or method to get the name of the sol file loaded in the simulation? For example, with the default distribution I should get "Sol.cfg".

 

[fred18]

Is there any function or method to get the name of the sol file loaded in the simulation? For example, with the default distribution I should get "Sol.cfg".

only way that comes to my mind is to parse manually the scenario file... if it's a vessel into the clbkLoadStatusEx I'd put something like

char Sol[256];
oapiReadItem_string(scn,"System",Sol);

don't know if it might work

 

[cristiapi]

It should work, but it's not a vessel, it's a Celbody dll and afaik there isn't an equivalent function.

 

[fred18]

It should work, but it's not a vessel, it's a Celbody dll and afaik there isn't an equivalent function.

:hmm: I can only think of building a ghost vessel that has that function in clbkloadstate, create it at the beginning (clbkinit), get the info and then delete it...

 

[jedidia]

oapiReadItem_string(scn,"System",Sol);

This doesn't work, as oapiReadItemX looks for the format param = value, while here the format is param value without the =. Therefore, you'll just end up at the end of the file.

What you can do is oapiReadItemString(scn, "BEGIN_ENVIRONMENT"). Interestingly enough there's a bug in orbiter that will leave the stream at the according line if the item searched for consist of only one term without any space in it.
You can then proceed to read the rest of the file using oapiReadScenario_nextiline().

What you have to consider, though, is that if you do that during clbkLoadState, you have to then continue reading through the scenario file until you're at the same line again where you hijacked it, otherwise there will be hell to pay. The scenarios are meant to be read consequitively line by line, not browsed through like config files!

It should work, but it's not a vessel, it's a Celbody dll and afaik there isn't an equivalent function.

Wait... if it's a cellbody, how do you not know which system it is in by default? Don't you usually code a cellbody for a specific system?

 

[fred18]

I think that apart from the metod to get the item (yep, oapiReadItem_string is wrong, but there are other ways) the issue is that you have to get the handle of the scenario file currently launched to parse it somehow.

And that's difficult outside a vessel, I cheked a bit the oapi but it's not easy at all.

 

[Face]

Is there any function or method to get the name of the sol file loaded in the simulation? For example, with the default distribution I should get "Sol.cfg".

Why do you need that?

 

[cristiapi]

Wait... if it's a cellbody, how do you not know which system it is in by default? Don't you usually code a cellbody for a specific system?

Why do you need that?

It seems that Orbiter doesn't get angry if I append some (commented) lines in the file Sol.cfg (or whatever it's called) and since I wrote a Celbody that moves any generic (multiple star) system, I need to write somewhere the initial state of the bodies; the Sol.cfg file (specially created for the wanted stellar system) would be the perfect place.

If I don't know the sol.cfg file name, I can take two ways: use a configuration file for my dll (my current choice) or use a Sol.cfg with only a given name (like "Generic_sol.cfg").

 

[Face]

It seems that Orbiter doesn't get angry if I append some (commented) lines in the file Sol.cfg (or whatever it's called) and since I wrote a Celbody that moves any generic (multiple star) system, I need to write somewhere the initial state of the bodies; the Sol.cfg file (specially created for the wanted stellar system) would be the perfect place.

If I don't know the sol.cfg file name, I can take two ways: use a configuration file for my dll (my current choice) or use a Sol.cfg with only a given name (like "Generic_sol.cfg").

I understand. While I can see the elegance in the solution of writing the module settings directly into the solar system configuration file, I'd recommend not to do so, because you are effectively exploiting the comment system of a given format to store settings. If Martin chooses to change that in the future, your solution would suddenly stop working.

Also, what about the configuration file of the GBody itself? AFAIK you can use the same module for more than one GBody configuration, so you'd e.g. create a mySol.cfg like so:

Name = mySol
Star1 = Sun
Planet1 = myPlanet
Planet2 = mySecondPlanet

and a myPlanet.cfg like so:

Name = myPlanet
Module = cristiapisGenericModule
<some more parameters for the module>

and finally a mySecondPlanet.cfg like so:

Name = mySecondPlanet
Module = cristiapisGenericModule
<some different parameters for the module>

That would be more along the lines of Orbiter's solar system configuration model IMHO.

 

[cristiapi]

Probably it's the best solution, also because I need to be able to efficiently change (at least) the mass of each body for a new simulation of a new system.

Thank you all! :tiphat: