Discussion Developing Addons for different Orbiter Versions

[n122vu]

Thanks, I'll check that one out next. I did try following computerex's old tutorial just to see what would happen, creating a simple plugin that outputs the sim time to the debug string. I'm getting errors in OrbiterAPI.h of all places.

 

[Urwumpe]

Yeah, many confusing messages, but only the last two are really significant. Not sure why I don't see it when compiling with ORBITER_MODULE.

 

[n122vu]

Here's my main.cpp. About as simple as it can get.

#define STRICT
#define ORBITER_MODULE

#include <Orbitersdk.h>


DLLCLBK void opcPreStep(double simt, double simdt, double mjd) {
    sprintf(oapiDebugString(), "%.2f", oapiGetSimTime());
}

 

[kuddel]

VisualStudio 2017 15.5 started setting the /permissive- flag for all new solutions, which disallows the implicit conversion of string literals to non-const char*.
You can edit the solution's properties to disable that flag while you update your codebase to conform to the C++ standard.
It's listed as "Conformance mode" in the "Language" tab under "C/C++" in the project's properties.

Source: https://stackoverflow.com/a/48554786

 

[n122vu]

Source: https://stackoverflow.com/a/48554786

Thanks. I checked, that flag is already disabled across the board on the project. I also added the property sheets (had forgotten about those, thanks @n72.75 ). Still seeing the same errors. Will have more time to look at it later this evening.

 

[kuddel]

So here's what I would do:

1. check that your projects configuration type is set to "Dynamic Library (.dll)"
2. check that your project has added "OrbiterSDK/include" to the "Additional Include Directories" (@ C/C++ -> General)
3. check that your project has added "OrbiterSDK/lib" to the "Additional Library Directories" (@ Linker -> General)

The rest I would check is not really necessary, but most of the time correct:
- "Preprocessor Definitions" should have "WIN32" and "_WINDOWS" defined (@ C/C++ -> Preprocessor).

...AAANNND... Do a RE-build sometimes, as the cache(s) can make non-buildable solutions stay un-buildable :/
So a "Clean Solution" now and than does not hurt.

 

[n122vu]

So here's what I would do:

1. check that your projects configuration type is set to "Dynamic Library (.dll)"
2. check that your project has added "OrbiterSDK/include" to the "Additional Include Directories" (@ C/C++ -> General)
3. check that your project has added "OrbiterSDK/lib" to the "Additional Library Directories" (@ Linker -> General)

The rest I would check is not really necessary, but most of the time correct:
- "Preprocessor Definitions" should have "WIN32" and "_WINDOWS" defined (@ C/C++ -> Preprocessor).

...AAANNND... Do a RE-build sometimes, as the cache(s) can make non-buildable solutions stay un-buildable :/
So a "Clean Solution" now and than does not hurt.

Thanks, will verify those. In the meantime, this morning I was able to, after some reconfig steps, compile the default Deltaglider solution, which is both the DG and the DG Config tool, in VS2019. That tells me it's definitely something in the config of my test project, which is an attempt to start a new project from scratch and get it compiled, the ultimate goal being documenting the steps and then either updating the Wiki accordingly or releasing an updated compiler setup video. Or both.

 

[Urwumpe]

You should make sure, that the compiler is explicitely set to x86 as target, the way how to configure this had changed between older versions and VC++ 2019.

I also needed a moment to find out in my CMake build scripts, that the "Ninja" tool for integrating CMake into VC++ does not support the old commandline options at all and requires an explicit JSON configuration file to support x86.

 

[n122vu]

I had all of the above suggestions already configured, but it appears when I imported the property sheets, it wiped all of those settings. I'm going to delete the entire solution and start again.

Should I continue discussing in this thread, or start another?

 

[Urwumpe]

I had all of the above suggestions already configured, but it appears when I imported the property sheets, it wiped all of those settings. I'm going to delete the entire solution and start again.

Should I continue discussing in this thread, or start another?

I am fine with this thread, since it does contribute to the topic.

 

[kuddel]

Hi there,
this thread reminded me of a tool that I developed some time ago but got forgotten as other things came along.
I've always found it crazy how hard it is to start a new Orbiter development when a new Visual Studio came along or I had to switch between Orbiter 2016 & Orbiter BETA or even Orbiter 2010...

The tool's called 'slngen' (Orbiter SOlutioN GENerator)
It creates (template-)solutions for Orbiter addons, so that you can easily start developing (at least that's what it should do)

I've re-visited that tool and developed it so far that it now can be used not only by myself ? .

Here's the usage (help information):

Orbiter SOLution GENerator tool v0.9    (c) 2020 Peter Schneider
        ¯¯¯      ¯¯
slngen [/T <type>][/VS <version>][/N <name>][/O <version>][/S][/C] <name> [/?]

  <name>        (required) Name of the addon.
                Enclosed in double-quotes (") if it contains spaces.
  /T <type>     AddonType (MFD|Dialog|LaunchpadParam|Vessel).
                The Addon type to be created.
  /VS <version> VisualStudioVersion (2017|2019|all|auto).
                The Visual Studio Version to create the solution for.
  /N <name>     Name of the addon (if parameter-value pair is preferred).
                Same rules for name with spaces applies here.
  /O <version>  OrbiterVersion (2016|2010|BETA|auto).
                The Orbiter Version to create the solution for.
                'auto' will automatically detect the version by the current working path.
  /S            WithSubDirs.
                Creates sub-directories in the addon-directory, containing the project-,
                resource- and source-files.
  /C            Compact.
                Generate project-file with fewer 'Debug|Release' 'Condition's.
  /?            Displays this usage information and exits.

It is meant to be located in the Orbitersdk\utils\ folder (so it's in a known place), but can also be invoked directly from within your newly created "addon folder" in the Orbitersdk\samples\ (Orbiter 2010 & 2016) rsp. Orbitersdk\samples\Modules or Orbitersdk\samples\Vessel (Orbiter BETA).

Here's an example of how to use it:

1. Go to your samples directory and create a new folder to contain your new addon
   and change into that new directory:
   C:\Wherever\Orbiter\Orbitersdk\samples> mkdir DemoAddon
C:\Wherever\Orbiter\Orbitersdk\samples> cd DemoAddon
2. Now issue the slngen command with the appropriate switches. Like for example:
   C:\Wherever\Orbiter\Orbitersdk\samples\DemoAddon> ..\..\utils\slngen /T MFD /VS 2017 "Demo Addon MFD"

This will create all the needed solution & project files (MFD - for Visual Studio 2017 in this case) to start developing.


Note, that not all features have been implemented yet. Hence the 0.9 Version!
Currently missing are:

• 'Vessel' for the AddonType parameter
• 'auto' for the VisualStudioVersion parameter
• 'all' for the VisualStudioVersion parameter

I would like to hear from you whether this works for you and what else is needed (apart from the missing features I've listed above).

The attached ZIP has the tool located in the preferred directory.

Have fun,
Kuddel

 

[n122vu]

Sorry, just now seeing this. Life has been a whirlwind since Thanksgiving. I'll give this a try when able and report back here.