OHM Extended planetary parameters SDK 0.11

[OrbitHangar]

Author: jedidia

Bugfixes:

-0.11 fixes bugs in GetBodyByIndex and GetBodyByName functions.

Now includes source code!

Extended planetary parameters (EPP) is a sidekick from Orbiter Galaxy developement. Its aim is to provide a standard for more detailed planetary parameters such as atmosphere composition, temperature ranges and lots of other stuff that might be usefull. A description file for extended planetary parameters also includes a description of the parent star, with additional parameters such as age, luminosity and temperature, so that add-on developers can program general solutions for things like for example dynamic heating that would work in all systems that support EPP.

It also allows system creators to add more flesh to their creations and allows any add-on using the EPP sdk to make use of that information. Additionally, EPP will be supported by Orbiter Galaxy 0.6.08 and further versions.

This SDK provides all the functionality you need to make whatever use you like of those parameters in your addons. The major part of the SDK is a parser to read .epp files, as well as several functions for retrieving and evaluating specific information. It is designed to give add-on developers the easiest possible access to extended parameters, and enables their use with only a few lines of code.

Note that extended planetary parameters will be updated in the future. Files written for future versions will still be compatible with earlier versions of EPP, although they will not be able to make use of newly integrated parameters. Add-on developers should stay tuned to update their projects when new versions become available, which will go hand in hand with Orbiter Galaxy developement.

If you have suggestions for parameters or special functions you'd like to see added to this SDK, feel free to make them!

There is a .epp file provided for the sol system, but it is not currently completed. If somebody feels like completing it, I would be very thankfull, since it's rather tedious buisness.

Credits:
This SDK borrows practically all code from the system generator in Orbiter Galaxy, which in turn borrows most of its code from StarGen. So, StarGen plays a major role in this project too, and quite a bit of code from it has been re-used

DOWNLOAD

 

[Wishbone]

Thanks a lot! Will install ASAP!

 

[Urwumpe]

I have quite some add-ons that could use that... will try to include it ASAP.

 

[Wishbone]

A note in the margin: .ncb files aren't really required for the SDK to work (I have just peeked into the partially d/l'ed archive and found that an ncb file is 8 meg large).

 

[jedidia]

ooops, my bad. I copied the whole thing with only the essentials to a different folder and compiled it from there to see if the relative paths really check out and forgott to delete the files created in the process... Will remedy this at once to make further downloads smaller.

Edit: Ha, that reduced the download to a nice 173 kb... I noticed that the file was over two megs on upload, but somehow didn't think anything about it...

 

[Wishbone]

Unfortunately getting LNK1257, meaning (AFAIR) there's something with your .lib file that doesn't want to link. To get around this, could you possibly compile the lib as a DLL? I assume it is a "works on my computer" type bug (been there done that).

 

[jedidia]

Darn. What would be a possible cause of this? What version of visual studio are you using? it was compiled using VS 2008, maybe it could be a problem if you're trying it in 2005?

Also, the Lib is a release build, would a debug build be more apropriate?

There has been an unexpectedly high number of downloads, is the problem universal? anyone else?

---------- Post added at 09:29 AM ---------- Previous post was at 07:47 AM ----------

Yap, just set the project up in 2005, and I'm getting a 1257 too, so I assume that's the problem. I'll build the Lib in VS 2005, then, for wider compatibility. Will upload sometime today.

 

[Wishbone]

I was getting the error in VS 2008 (which is version 9.0 IIRC).

 

[jedidia]

Then there might be another problem... My version is 9.0.30729.1 SP, maybe that is already incompatible. I'll still try to recompile in 2005 and re-upload, just in case.

I presume the problem occurs also when trying to build the example?

is anybody else of the people who downloaded this expieriencing the same trouble?

 

[orb]

I have only VC2005 on my laptop, so I can only say that the error is not LNK1257 that is displayed last, but "C1007: unrecognized flag '-typedil' in 'p2'". LNK1257 only says that code generation failed because of the earlier error(s). And for "-typedil", I found that disabling "whole program optimization" -> "optimize at link time" for library should fix this (source).

 

[Wishbone]

Version mismatch confirmed. I get error C1900. Would advise either compiling as DLL or including source code.

 

[jedidia]

I have only VC2005 on my laptop, so I can only say that the error is not LNK1257 that is displayed last, but "C1007: unrecognized flag '-typedil' in 'p2'". LNK1257 only says that code generation failed because of the earlier error(s). And for "-typedil", I found that disabling "whole program optimization" -> "optimize at link time" for library should fix this (source).

That's exactly what I'm getting in VS 2005, thanks for the proposed fix. I'll try it out.

Version mismatch confirmed. I get error C1900. Would advise either compiling as DLL or including source code.

Since I have VS 2005 around anyways, It won't be a problem to re-compile it. But including the source code might be a good way to save myself some trouble in the future...

---------- Post added at 06:40 PM ---------- Previous post was at 02:32 PM ----------

I feel like Microsoft is making fun of me... release compiled against VS 2005 lib works in VS 2008 in any case, but in 2005 only for release build. In debug build he's spewing LNK2022's and ranting about duplicated data-types. Me and my insuficient knowledge about compilers...

 

[Wishbone]

Microsoft's views on binary incompatibility aren't universally shared... Do not despair, this is going to be a great add-on...

 

[jedidia]

I ended up just packing the source code into the already existing package, the longer I tried the weirder everything got, an I'm starting to have a headache (not coding related, I'd wager... probably going to be sick in the next couple of days), so It seemed the best way to solve this without taking too long. Considering that the source code is only one file anyways, it's no more trouble than including the Lib, really.
Hope this helps everyone to compile that had trouble.

 

[Wishbone]

Code up and running, thanks (as time allows will link it up to the reentry code in PrecMFD. A few ideas: array counts should ideally be available without iterating through the array; would it also be beneficial to avoid mem leaks by pushing as much of the stuff to the stack as possible? I find it really helpful to use const modifiers as liberally as possible to catch contract violations; same for references instead of pointers. Since some of your functions return std::strings there could also be used std::vectors (isn't STL wonderful )... Another recommendation would be to add console output to the sample code - it makes one pause and scratch the forehead when the sample code says nothing as if there had been an error.

Again, thank you for the SDK. (Hope Urwumpe is reading this between shovelling snow and keeps on planning a followup to his brilliant Link 11/16 idea which would allow communication between add-ons without too much fuss of recompilation)

 

[jedidia]

A few ideas: array counts should ideally be available without iterating through the array

The boundaries of all arrays are available. For the atmosphere it's zero to EPP_Body.gases, for the planets it's 0 to EPP_System.numPlanets - 1,
and for moons it is 0 to EPP_Planet.moons (not minus one, since the 0 index denotes the planet itself. I know it's a bit awkward, but it was the best solution for what I needed in orbiter galaxy.)

would it also be beneficial to avoid mem leaks by pushing as much of the stuff to the stack as possible?

Pretty much everything apart from the root elements is in the stack. If you call ~EPP_System, every pointer gets freed. All you have to do is create an EPP_System and delete it again when you're done, and you're good. Even every single pointer you got from a function of EPP_System will be freed in the process, I don't see how I could make it much more convienient.

Another recommendation would be to add console output to the sample code - it makes one pause and scratch the forehead when the sample code says nothing as if there had been an error.

I was a bit lazy there, I admit it, but I wrote in the guide that the sample doesn't actually do anything (maybe I should have put a comment into the code, that would have been better). You can put a breakpoint to see what's happening, it's primarily there to show the use of all the functions.

Since some of your functions return std::strings there could also be used std::vectors (isn't STL wonderful )

It might be, but I never worked with it. What's wrong with strings?

 

[Wishbone]

Thanks for clarifications (and I admit I'm lazy too), will try to avoid off-by-one mistakes. Strings are fine, vectors are good for numerical data. Will also wrap stuff in exception handlers, the atmosphere code will be called at most once per DLL lifetime - or per MFD initialization (I have heretofore assumed that users will travel in a single system, will probably reconsider after I get accustomed to warping through space),

 

[Urwumpe]

Code up and running, thanks (as time allows will link it up to the reentry code in PrecMFD. A few ideas: array counts should ideally be available without iterating through the array; would it also be beneficial to avoid mem leaks by pushing as much of the stuff to the stack as possible? I find it really helpful to use const modifiers as liberally as possible to catch contract violations; same for references instead of pointers. Since some of your functions return std::strings there could also be used std::vectors (isn't STL wonderful )...

I agree, this is all some good improvements. I would also think about using Pimpl-es a few times, instead of direct pointers.

Again, thank you for the SDK. (Hope Urwumpe is reading this between shovelling snow and keeps on planning a followup to his brilliant Link 11/16 idea which would allow communication between add-ons without too much fuss of recompilation)

If you are interested in getting the idea to a prototype version, just let me know, it is all just about a small number of message codes, that permit to push data ahead, or permit polling the queues by a MFD. I currently just have a crude version in the Black Dart as feasibility test... (I fear I will never release the Dart as long as I abuse it as experiment platform of choice, it is the first to receive EPP support)

I am not sure, it would really improve this one, since it is very inter-vessel communication specific, but it wouldn't be hard to make the interfaces of EPP flexible enough that it can be used for a few EPP versions without recompilation...just by installing a more recent EPP.DLL,

 

[jedidia]

I would also think about using Pimpl-es a few times,

I'm afraid I have no clue about what that is... let's not forgett that I'm pretty much a novice without any education in the field.

I have heretofore assumed that users will travel in a single system, will probably reconsider after I get accustomed to warping through space

With the current orbiter version that is pretty much the case. You can't load a new system without re-loading orbiter. Orbiter Galaxy merely times and automates that process. If orbiter ever integrates a dynamic scenario load this might change, but for the moment that isn't a "threat".

but it wouldn't be hard to make the interfaces of EPP flexible enough that it can be used for a few EPP versions without recompilation...just by installing a more recent EPP.DLL,

The interface isn't the problem. I am paying attention to full backward compatibility, which means that any version of EPP will be able to work with .epp files that have been created for later versions. But there's a lot of parameters that will get added during the next stage of Orbiter Galaxy developement, and no matter what interface I choose, the developer will still have to update his add-on to make use of those new parameters. If he doesn't want to make any use of them, he won't have to update anyways.

For the atmosphere it's zero to EPP_Body.gases

Sorry, that's EPP_Body.gases -1. For the celestial bodies, it's better to use a function to get a pointer on them, since there you can use orbital numbers (i.e. one-based).

the atmosphere code will be called at most once per DLL lifetime

If by atmosphere code you mean the atmospheric calculations that EPP does to supplement some of the parameters (it seemed pointless to have the user define parameters in the file that could be calculated from other parameters), that only gets called when a file gets loaded.

 

[Wishbone]

The atmosphere code in Precession MFD that uses Sutton-Graves and Tauber-Sutton formulae for heat rate coefficients... I'm discovering more of the EPP API bit by bit.