Here are some questions about orbiter development issues.
1)
Who to reset a log file created by an addon ? Of course, an obvious place to reset an existing log is when the orbiter application is started. But the problem is that the orbiter application is automatically respawn when the user will exit the simulation session into a launch pad. An other possibility is to reset the log when the simulation window is opened but that would reset any information printed after loading a module.
There is probably a workaround for this problem by checking the time when the log was last modified and reset the log only if more than just a few seconds has elapsed since the log was previously used.
2)
What about inter-module communications and callbacks ? It appears that there are more and more issues those requires more extensive information change between a modules like a vessel and MFD. For an example a vessel developper may need to assign a callback function that would be called by a specific MFD or an other module. I was thinking something like this...
HMODULE hModule = oapiGetModuleHandle(char *module_name, int n);
"n" is required because there may exist more than one module with the same name. LoadModule() is not a good option because it doesn't check that the module is activated from launchpad and it might spawn a new instance of the module that would be useless.
hModule could be used by GetProcAddress
GetMFDVersion = GetProcAddress(hModule, "GetVersion");
AssignMFDCallback = GetProcAddress(hModule, "AssignCallback");
if (GetMFDVersion()>1.2) {
AssignMFDCallback(MyCallbackFnc);
}
//
// Called by MFD
//
MyCallbackFnc(double mjd)
{
}
But... Since a MFD is object-oriented "a class" would it be enough just to get a pointer into the class ?
if (MFD->GetVersion()>1.2) {
MFD->AssignCallback("MyCallbackFnc");
}
But that would definately require having a header file of the class.
1)
Who to reset a log file created by an addon ? Of course, an obvious place to reset an existing log is when the orbiter application is started. But the problem is that the orbiter application is automatically respawn when the user will exit the simulation session into a launch pad. An other possibility is to reset the log when the simulation window is opened but that would reset any information printed after loading a module.
There is probably a workaround for this problem by checking the time when the log was last modified and reset the log only if more than just a few seconds has elapsed since the log was previously used.
2)
What about inter-module communications and callbacks ? It appears that there are more and more issues those requires more extensive information change between a modules like a vessel and MFD. For an example a vessel developper may need to assign a callback function that would be called by a specific MFD or an other module. I was thinking something like this...
HMODULE hModule = oapiGetModuleHandle(char *module_name, int n);
"n" is required because there may exist more than one module with the same name. LoadModule() is not a good option because it doesn't check that the module is activated from launchpad and it might spawn a new instance of the module that would be useless.
hModule could be used by GetProcAddress
GetMFDVersion = GetProcAddress(hModule, "GetVersion");
AssignMFDCallback = GetProcAddress(hModule, "AssignCallback");
if (GetMFDVersion()>1.2) {
AssignMFDCallback(MyCallbackFnc);
}
//
// Called by MFD
//
MyCallbackFnc(double mjd)
{
}
But... Since a MFD is object-oriented "a class" would it be enough just to get a pointer into the class ?
if (MFD->GetVersion()>1.2) {
MFD->AssignCallback("MyCallbackFnc");
}
But that would definately require having a header file of the class.
Last edited:
