SDK Question How to import "pure" C++ code into MS Visual Studio Express

[turtle91]

Hi @all,

first of all, I have no experience in C++ development or any other programming language at all.
Just some basic trouble-shooting skills...mainly used in Unix.
So using MS's IDE is a real challenge for me.
However, somehow I got it working and modified Toppers "Baseland" autopilot for Orbiter 2015.
This was not difficult, I have just replaced the "getAltitue()" with new "GetAltitude(VESSEL::ALTMODE_GROUND)" calls.
Now I am finaly able to perform full-automated landings at Brighton Beach, while enjoying the nice new 3D scenery.

So far so good.
I am planningt to try something similar with "PursuitMFD".
Currently it just crashes Orbiter-2015.
So maybe it's just a matter of re-compiling this PursuitMFD "against" the new Orbiter API. (?)

However, PursuitMFD comes with pure C++ stuff, no MS VS config stuff in the sources.
So how can I import this sources to MS IDE ?

Just an idea:
-Using ShutllePB as template
-deleteing all relevant C++ and include-files
-copy+paste the PursuitMFD source files into the ShuttlePB dir
-renaming the ShuttlePB to PursuitMFD
?

Or maybe starting with a new empty project/solution and importing alll the needed source files + includes by hand ?

Again, I am not a developer but the success I made with baselandMFD gives me some motivation to try this with PursuitMFD, which I am using a lot in Orbiter-2010.

 

[Urwumpe]

Or maybe starting with a new empty project/solution and importing alll the needed source files + includes by hand ?

Like that for example.

Also, is there really no Solution or Project file around?

 

[turtle91]

No it just come s with a dir-structure like this

CDK\
CJP\
Main\
Split\

Looks for me like standard for an IDE, which I am not aware of.

---------- Post added at 03:49 PM ---------- Previous post was at 03:25 PM ----------

Just checked the PusruitMFD sources.
Here it looks like, that getAltitude() is not being used here.
As far as I understand it, it uses some kind of X/Y/Z position-coordinates.
If this is true, it should work(=land at correct position) with Orbiter 2015, if it would not crash.
So maybe it's really "just" a recompile-to-new-API issue.

 

[jedidia]

Or maybe starting with a new empty project/solution and importing alll the needed source files + includes by hand ?

A visual studio project is, in concept, no more than a fancy makefile... so yes, if there's none provided, and you want to run it in visual studio, making a new project and putting in the files is the usual way to go (you can even use drag-n-drop from windows explorer, no biggie).
However, most stuff for orbiter was written with visual studio, so most stuff usually comes with a project file.
Also, having a project file or not doesn't make thing pure C++ or not. The only non-pure C++ you can write in visual studio is visual C++ (or managed C++, or CLR C++ as it's sometimes called), but compiling that for orbiter won't work anyways, so just make sure you create the right kind of project file.

 

[turtle91]

"...and you want to run it in visual studio"

No...I don't "want". Is there any alternate to this MS IDE, where I can compile/re-compile sorces for Orbiter ?

This GUI-thing drives me crazy. I have had evem problems to find/edit the C++ source file.
I used then externaly Notepad++ for this. I am using the IDE just for using the "compile/release" button.:facepalm:

But thanks for explanation for this Visual-Studio-Project-thing. I would prefer editing Makefiles using vi. :yes:
I like the old Unix philosopy: One job...one tool.

 

[jedidia]

I like the old Unix philosopy: One job...one tool.

Which is a sweet, sweet dream in todays software development world, but for what it's worth, when developing for orbiter, visual studio is exactly that tool. Code editor, debugger and compiler, all in there. It might be a female dog to get used to it at first (though not nearly as annoying as Eclipse, trust me on that), but while I am not genereally very fond of microsoft products, I still have to admitt that their dev-tools are miles ahead of the competition.

 

[martins]

But thanks for explanation for this Visual-Studio-Project-thing. I would prefer editing Makefiles using vi.
I like the old Unix philosopy: One job...one tool.

But surely even in Linux, maintaining makefiles for a large project manually gets tedious and errorprone, so you end up using build systems like automake or CMake - and IDs like Eclipse. The main advantage of IDEs in my opinion is the integrated debugger. Running gdb with or without a tacked-on graphical front end always seems to be a hit-and-miss affair.

Anyway, there is nothing to prevent you from using your preferred approach in Windows. You can run the compiler toolchain from the command line, you can hand-edit your makefiles if you know the format, and you can edit the source files in notepad if you like (or get a Windows version of vi if you prefer).

 

[n72.75]

...and you can edit the source files in notepad if you like...

I can recommend Notepad++

 

[turtle91]

No, I don't want to break the "standards", if MS Visual Studio is "the" IDE, I need to learn how to use it, at least for Orbiter.
Sorry about my maybe negative comments about the GUI, I was just remembering the good old times, where booting from tape, was the way to install SunOS on a Sparc-Station.

---------- Post added at 10:50 PM ---------- Previous post was at 10:48 PM ----------

>I can recommend Notepad++

Yes, that's the one I am using. It's great, esp the "search in all open files" is quite helpfull.

 

[jedidia]

When looking for a pure code editor without any strings attached, I would actually recommend visual studio code (no, it's got nothing to do with visual studio except for the name... and, more importantly, the intelisense support for a gazillion languages).
Notepad++ gets less useful the more files you have in a project. VS code solves that with a directory view.

 

[turtle91]

Thanks for the hint Jedidia.
This looks promising, and its available on different platforms.:thumbup:
I will have a look into this. Maybe it's a bit easier or more transparent, to a rooky like me.

 

[Face]

The only non-pure C++ you can write in visual studio is visual C++ (or managed C++, or CLR C++ as it's sometimes called), but compiling that for orbiter won't work anyways, so just make sure you create the right kind of project file.

Not true. You can create C++/CLR assemblies for Orbiter. I.e. you can use the .NET library for Orbiter development, if you like.

 

[kamaz]

automake

Apage Satanas!

 

[turtle91]

Ok, I have had some success. (Still using MS VS)
I have used the "MyVessel" template downloaded from OH as a base to compile PursuitMFD.
I removed all MyVessel stuff and inserted all the PursuitMFDs provided headers and source-files.
This didn't work, because the includes (even if included into the project) were not found.
So I used "hard-coded" include-dirs within the project-proberties-thing/sheet(?).

I know, using absolute path-naming is a bad practice, so the SLN will only work on my system...so far.
However, the includes were found and I got plenty of errors regarding:
"GetVesselNameA"

So I checked the Orbiter API reference and only found "GetVesselName" (without the "A").
I then changed all the "GetVesselNameA" to "GetVesselName" (without knowing what I am doing).
This time the compile went through, but later on the linker complained abot an undefined symbol called "GetVesselNameW".

Within all the sources I din't found a "GetVesselW" call. so I commeneted out all the "GetVesselName" calls I found.
It seems to be, that this "GetVesselName" calls were dealing with Vessel-Exception-handling for some special Vessels like the Arrow, the Descartes and the Shuttle (from Shuttle-Fleet). Special RCS-attitude-seetings have been hardcoded here for this kind of special vessel.
I can live without those exceptions for the moment.

The next compile went fine...no errors and I got a nice "MyVessel.dll" :thumbup:
So I have renamed it to PursuitMFD.dll and tested it in Orbiter-2016.

And...it works. At least all the attitude-modes, like docking, station-hold etc.
Even the old "REF" bug is still included (if you hit REF for another major-body selecetion, you will get a CTD).

However, landing is not working correctly.
Like Artlavs' "getOnPad" from UAP, PursuitMFD uses VECTORS to find the base/coordinates to land. There are not GetAltitude-calls invloved.
So the AP ends up, where i.e. surface-mfd shows zero-meters, but I have still more then 2000 meters radar-altitude to the surface.

The question is know, is it possible to force VECTORS to use the new ALTITUDE_GROUND mode ? Are there new VECTOR calls to help here ?

---------- Post added at 03:09 PM ---------- Previous post was at 02:19 PM ----------

It seems to be, that the altitude (+velocity to altitude) has been declared here(EI.cpp):
...

double yf = 2* 0.5*1.25*gravB*(1-cos(20*RAD))*appT*appT;
double vyf = 2* 1.25*-gravB*(1-cos(20*RAD))*appT;
....

double minalt = yf;

The variable "minalt" will the be used for final approach at 30 meters above the (Orbiter2010)surface.
Maybe "just" extending/including the "minalt" with GetAltitude(ALTMODE_GROUND) values ?:idk:

---------- Post added at 04:16 PM ---------- Previous post was at 03:09 PM ----------

A simple "double minalt = yf + _VESSEL->GetAltitude(VESSEL::ALTMODE_GROUND);" crashes Orbiter right after hitting the LND button.
Makes sense, PursuitMFDs calculations are using degrees..not meters...mixing both, whithout conversion is a bad idea...

But how to convert the degrees of the Y-vector back to meters_above_ground ?

 

[jedidia]

Not true. You can create C++/CLR assemblies for Orbiter. I.e. you can use the .NET library for Orbiter development, if you like.

Then let's just say that poor me never got it to compile, but then that attempt was 8 years ago when I didn't even know the difference between managed/unmanaged C++, so no surprises there

 

[Face]

Then let's just say that poor me never got it to compile, but then that attempt was 8 years ago when I didn't even know the difference between managed/unmanaged C++, so no surprises there

I see. Well, in essence it is "just" using the CLR compiler setting. Then you will get a so-called mixed-mode assembly. In this you can use the "#pragma managed" and "#pragma unmanaged" compiler switch to use C++/CLR code right inside Orbiter addon code. That's how Orbiter.Net and OMP was done.

 

[turtle91]

I know, I am a bit off topic now, but just want to give back some of my first-C++-experience, when trying to modifiy PursuitMFDs landing AP.

I got some success, which leads to new problems.

Again, the "problem" is new Orbiters-2016 surface-elevation-model.
Per default PursuitMFD initially relies on GetCOG_elev() .
But this gives the "old" altitude back (0...sealevel altitude...Meanradius-thing).
Which is a problem if i.e. the landing-pad is -2600 meter below "0".

So I tried "VESSEL::GetSurfaceElevation", and had some success.
Now the elevation-modell used by PursuitMFD, uses real-time-real-time-radio-altitudes.

But it uses this altitude-reference for the entire approach, which makes the approach very bumby (it tries to act as a terrain-collision-avoidance-AP).
This might be interesting for other autopilots, but causes to ruin the final approach.

So the next goal should be, to use the new surface-elevation-data just before the landing, not during the entire approach.
Or...more complicated...but would be a perfect solution for all kind of approaches(regardless how bumby the terrain below is), writing a more anticipating RCS thruster-management, to avoid wild oscillations.

But this is far behind my scope.

Maybe even better: Using different planet-surface-resolution modells, depends on altitude, to keep the oscillations at more controlled level. (If we are on i.e 20 km altitude, we are not interested in a hill of 200 meters altitude). (GetAltitude(VESSEL::ALTMODE_GROUND,level_of_resolution)

 

[Hielor]

I know, I am a bit off topic now, but just want to give back some of my first-C++-experience, when trying to modifiy PursuitMFDs landing AP.

I got some success, which leads to new problems.

Again, the "problem" is new Orbiters-2016 surface-elevation-model.
Per default PursuitMFD initially relies on GetCOG_elev() .
But this gives the "old" altitude back (0...sealevel altitude...Meanradius-thing).
Which is a problem if i.e. the landing-pad is -2600 meter below "0".

So I tried "VESSEL::GetSurfaceElevation", and had some success.
Now the elevation-modell used by PursuitMFD, uses real-time-real-time-radio-altitudes.

But it uses this altitude-reference for the entire approach, which makes the approach very bumby (it tries to act as a terrain-collision-avoidance-AP).
This might be interesting for other autopilots, but causes to ruin the final approach.

So the next goal should be, to use the new surface-elevation-data just before the landing, not during the entire approach.
Or...more complicated...but would be a perfect solution for all kind of approaches(regardless how bumby the terrain below is), writing a more anticipating RCS thruster-management, to avoid wild oscillations.

But this is far behind my scope.

Maybe even better: Using different planet-surface-resolution modells, depends on altitude, to keep the oscillations at more controlled level. (If we are on i.e 20 km altitude, we are not interested in a hill of 200 meters altitude). (GetAltitude(VESSEL::ALTMODE_GROUND,level_of_resolution)

Couldn't you just get the altitude above MSL of the target landing pad and subtract that from your own above-MSL altitude to determine the "altitude above landing pad" and use that as the altitude parameter for the MFD?

Wouldn't work if the target is in a steep valley, but probably close enough for most purposes...

 

[turtle91]

Thanks Hielor !
Something like what you have mentiond, I have allready tried.

Somehow, I reached now a point, where the MFD "sees/reacts" to altitude BELOW MSL (Brighton Beach is at about -2600) at very late stage of descent (right before doing final latitude adjustmenets).
But when SurfaceMFD shows "0" (but we have still to go "downstairs for about 2600 meters)., the hover-engine keeps the "wrong" zero.
So the ship will never descent to the -2600 meter touch-down-point.

In the code is "pos.y" the reference for the altitude(during landing), but there is also thrust.y, to deal with the de-accel-rate.
So far, I didnt' found a way to bring both in sync.
The MFD isself "knows" the new negative altidue, as seen in MFDs altitude-ouput and the aproach-graph. But the hover re-acts still the old way.

 

[turtle91]

Some updates.
Thanks to the great help from ADSWINJ, I was able to proceed a bit in a more structured way.
I am starting to like MS VS.
Now, I know how to-do things from scratch, not just copy+paste existing projects into MS VS and renaming plenty of files to match my project.

Regrading PursuitMFDs landing-autopilot, ADSWINJ used the base.lat/lon/surface-altitude as a reference for the AP.
So no more real-time bumpy pitch-oscillations during the approach, because the AP reacts just to the fixed surface-base-altitude.
This works now perfectly (if there is no extreme high mountain right before the landing pad).

So task-done, next task:
Since PursuitMFD has been released, there is one bug (reported by CRAS long time ago..but no feedback from RAWASH regarding this).
When in attitude-mode and pressing the REF button (for manual selecetion of major body-of-reference), this MFD caused a CTD.

So I tried the debug-functionality of MS VS (many thanks again ADSWINJ !), but this didn't help much in this case.
I discovered then the helpfull CLASS-VIEW and walked my way down to the source of the problem:

"oapiCelBodyPopup" (I guess the one like in OrbitMFD)

However this caused the CTD and I replaced it with.

"oapiOpenInputBox"

Now I can finally use the REF-button to select whatever major-reference-body.
Interesting is, that I did'nt found "oapiCelBodyPopup" within the API guide.
Maybe an obsolete call from orbiter <=2006 ?