Helicopter.dll

[Thunder Chicken]

Did you include the orbiter library files to the project (Orbiter.lib and OrbiterSDK.lib)?

Yes. This project is based on an older project which I have used to compile .dlls for Orbiter - everything seems to be set up correctly.


-----Posted Added-----


OK, think I sorted out the API read utilities. One thing is giving me a problem, the char statement:

char mesh_name;

void Helicopter::clbkSetClassCaps (FILEHANDLE cfg)
{

    oapiReadItem_string (input_file, "MESH_NAME", mesh_name);

}

The variable in the api call is supposed to be char * and the linker isn't liking the above. I'm not familiar completely familiar with C++ and I am wondering if this has something to do with the length of the string.

This is what I get during linking, I can't make heads or tails of it:

Linking...
   Creating library C:OrbiterModulesHelicopter.lib and object C:OrbiterModulesHelicopter.exp
Helicopter.obj : error LNK2019: unresolved external symbol "void * __cdecl operator new[](unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??_U@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z) referenced in function "public: char * __cdecl std::_DebugHeapAllocator<char>::allocate(unsigned int,void const *)" (?allocate@?@D@std@@QAAPADIPBX@Z)
Helicopter.obj : error LNK2019: unresolved external symbol "struct std::_DebugHeapTag_t const & __cdecl std::_DebugHeapTag_func(void)" (?_DebugHeapTag_func@std@@YAABU_DebugHeapTag_t@1@XZ) referenced in function "public: char * __cdecl std::_DebugHeapAllocator<char>::allocate(unsigned int,void const *)" (?allocate@?@D@std@@QAAPADIPBX@Z)
C:OrbiterModulesHelicopter.dll : fatal error LNK1120: 2 unresolved externals

 

[Thunder Chicken]

OK, game is back on. I was attempting to compile and link under debug and not release. See http://orbiter-forum.com/showthread.php?t=3979

It occurs to me that it might be possible to make this dll generalizable to propeller-driven aircraft as well. I need to think about this a little more.


-----Posted Added-----


One question is how I setup a scenario file to get this to work out. I have a generic helicopter.dll in the Modules folder. I need to be able to establish a config file unique to each ship, but somehow tell the module to look for the right config file through the scenario file. I'm not quite clear on how spaceship.dll handles this.

 

[Urwumpe]

Have the line "Module=Helicopter" in the configuration file.

And if you can make general propeller driven craft, we should also be able to make generic tilt rotor craft...

 

[Thunder Chicken]

Have the line "Module=Helicopter" in the configuration file.

I'm still missing something basic. I have a helicopter.dll in my Modules directory. When I open a scenario, I need a means for the scenario to load the proper module, and then have the module read the correct configuration file.

 

[Urwumpe]

I'm still missing something basic. I have a helicopter.dll in my Modules directory. When I open a scenario, I need a means for the scenario to load the proper module, and then have the module read the correct configuration file.

Well, you start in the scenario by specifying the configuration file to use as class name, for example:

MyCopter:AH-64D

Next, you need the module line in the configuration, so orbiter finds the DLL. then you need the function ovcInit to create the special vessel physical model (not the generic orbiter model). and ovcExit to delete it later. The rest is the matter of the callback functions of VESSEL2.

 

[Thunder Chicken]

I need to go through this step-by-step as I have never done this before.

-----------
So, in the scenario, I would enter the ship as:

AH-64:Helicopter/AH-64

which points the scenario to Config\Helicopter\AH-64.cfg

In AH-64.cfg would be the lines:

CLASSNAME    = AH-64
MODULE        = Helicopter

Does Orbiter automatically look for the MODULE tag? Is CLASSNAME a recognized tag as well?

The final bit is how to define the class name from the module. The helicopter.dll needs to establish a class AH-64. How do I get the module to know it needs to do this?

 

[Urwumpe]

CLASSNAME    = AH-64
MODULE        = Helicopter

Does Orbiter automatically look for the MODULE tag? Is CLASSNAME a recognized tag as well?

The final bit is how to define the class name from the module. The helicopter.dll needs to establish a class AH-64. How do I get the module to know it needs to do this?

Yes, the "classname" gets used inside Orbiter, as well as "module".

You then do the following steps inside helicopter.dll ( as I would do it)

You first create a new generic helicopter vessel object, for example "return new HELICOPTER(hVessel, iFlightModel);"

In the constructor of this class, you reset all variables to a defined state. All. Don't forget one.

Then, inside clbkSetClassCaps, you read the configuration file options and create the physical model of the vehicle as the configuration file tells you to.

Then, next, in clbkLoadStateEx, you load the scenario file data. Finally, in clbkPostCreation, you set the initial animation states.

 

[Thunder Chicken]

Then, inside clbkSetClassCaps, you read the configuration file options and create the physical model of the vehicle as the configuration file tells you to.

One question regarding the configuration file: clearly something like the following:

input_file = oapiOpenFile ("/Helicopter/Helicopter.cfg", FILE_IN, CONFIG);
oapiReadItem_string (input_file, "MESH_NAME", mesh_name);

can't be used in helicopter.dll as I don't know a priori which config file to look for. At this point, Orbiter must already know the config file in question, so how do I reference information from that file? Is there some generic path to the known configuration file that replaces 'input_file' in this instance?

 

[Urwumpe]

can't be used in helicopter.dll as I don't know a priori which config file to look for. At this point, Orbiter must already know the config file in question, so how do I reference information from that file? Is there some generic path to the known configuration file that replaces 'input_file' in this instance?

The required file is already opened when you get it's file handle in clbkSetClassCaps. You don't need to open it again.

Otherwise, the name is the same as the class name of the vessel + ".cfg" in the orbiter configuration folder.

 

[Thunder Chicken]

Yes, in the API examples that I used as a template it is filehandle 'cfg'.

The module compiled, and the scenario starts, reads in the proper mesh and other information from the config file. So far, so good. Now I need to work on the physics and how to implement general animations and strobes.

Thanks for your assistance, Urwumpe.