Plugins and portability

[Radiant]

IIRC most plugins have not been ported (e.g. to Linux) yet. Thus any game using those plugins (e.g. for special effects) won't actually run in Linux. Of course it's possible to compile a different version that disables those special effects - but doing so would require a separate release of a 30-meg game, even if nearly everything in there is exactly the same.

So would it be feasible to create some kind of workaround? Maybe have a plugin written in Linux that defines all necessary functions but simply doesn't do anything? Or have a module that has a Windows version and a non-Windows version, and the proper version for the OS is loaded?

Or maybe even simpler - the game does compile under Windows, and there wouldn't be a problem if it didn't crash until those plugin functions were actually called (because then I can simply do "if (OS == windows) { pluginsfx () }".

[Kweepa]

Or maybe even simpler - the game does compile under Windows, and there wouldn't be a problem if it didn't crash until those plugin functions were actually called (because then I can simply do "if (OS == windows) { pluginsfx () }".

That's how the mac version works right now -- it warns you that the plugin is not available, but allows you to continue at your own risk.

(IIRC, the Linux version doesn't have any plugin support.)

[Scorpiorus]

That's a good point, I believe we discussed such a possibility for the engine some time ago.

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=91

[Radiant]

That's how the mac version works right now -- it warns you that the plugin is not available, but allows you to continue at your own risk.

(IIRC, the Linux version doesn't have any plugin support.)

Interesting. Unfortunately I don't have a Mac or a Linux machine to test it on. So what would happen if the plugin function is called from the global script? Would it help if I used a GetGameParameter() call to determine the system type, and only actually call the function if it's in windows? In other words, at what point in the game is the global script parsed for known function names?

(in my experience a local script is parsed when the room is loaded, and at that point the game will crash with an error message if any function names are unknown)

[strazer]

I use Linux. Trying to run a test game with a plugin command in the global on_key_press function, it doesn't even start up and just says:

Script link failed: Runtime error: unresolved import 'ccStopExecution'

[Radiant]

Hm, it seems the #ifver directive added in today's beta should do the trick. Cool!

[SSH]

Except, of course, that neither the Mac nor Linux versions are even updated to 2.71 yet, let alone 2.72 beta 5 

[Scorpiorus]

Yeah, the linkage for imported functions from headers is done at start up, as far as I know. If there is no implementation for a certain function, AGS aborts with a run-time error.

The idea in the relevant tracker entry is to link such "imports" to some default implementation (ie. one that aborts the game), so that AGS would quit(abort) whenever one of them is called.

With IsPluginLoaded() we could check whether the required plugin is loaded or not and then act accordingly:

if (IsPluginLoaded (SomePlugin))
{
Ã,  // someplugin is here so the call is ok
Ã,  SomePlugin_Function(...);
}
else
{
Ã,  // someplugin is not available so go with a workaround
Ã,  // or something...
}

Hm, it seems the #ifver directive added in today's beta should do the trick. Cool!

As I understand #ifver allows us to check AGS version at compile time to do conditional compiling. It's useful for making script modules still work with different versions of AGS. So I doubt it can be of any help with unresolved imports, really.



[edit]

By the way, I just noticed in the manual:

#ifver 2.72
// do stuff for 2.72 and above
#endif
#ifnver 2.72
// do stuff for 2.71 and below
#endif

It's possibly deliberate for the lack of any version (number) newer than 2.72 but the example demonstrates it to check ver for 2.71 and below where at the same time it won't work with anything earlier than 2.72, as the note states.

Oh, and also does #ifver 2.72 actually mean that any version above is acceptable as well (seems ot does, looking at the code)?

[Radiant]

The idea in the relevant tracker entry is to link such "imports" to some default implementation (ie. one that aborts the game), so that AGS would quit(abort) whenever one of them is called.

Excellent idea.

As I understand #ifver allows us to check AGS version at compile time to do conditional compiling.

#ifnver 2.72
// do stuff for 2.71 and below
#endif

I don't see how that could possibly work, since #ifnver didn't exist in 2.71 (hence the older AGS will either throw an error message, or ignore the #directives and use both pieces of code)

[Scorpiorus]

I don't see how that could possibly work, since #ifnver didn't exist in 2.71 (hence the older AGS will either throw an error message, or ignore the #directives and use both pieces of code)

Aha, it is the inconsistency I was refering to. So the example would only work for 2.72 and above, and #ifnver 2.72 wouldn't have any sense in there indeed.

So maybe looking some time in the future:

#ifver 2.73
// do stuff for 2.73 and above
#endif
#ifnver 2.73
// do stuff for 2.72 and below
#endif

?

But then somebody may ask: where the heck can I get that secret 2.73 one from?

[Pumaman]

What I'm going to do for the next beta is add a constant AGS_SUPPORTS_IFVER or something, that is always defined in this and future versions, so that a script can do:

#ifdef AGS_SUPPORTS_IFVER
#ifver 2.73
// must be 2.73 or above
#endif
#endif

without breaking it for old scripts.

[Radiant]

What I'm going to do for the next beta is add a constant AGS_SUPPORTS_IFVER or something

That's useful.

Would you maybe have a workaround for the plugin portability question as well please?

[monkey0506]

Well...it's a bit messier, but perhaps you could use #defines?

Code: ags

// plugin script
#define PLUGINNAME_VERSION 123

// AGS scripts
#ifdef PLUGINNAME_VERSION
// plugin functions
#endif

Assuming that macros defined in plugins can be used in the AGS scripts.  I'm not really sure about all this plugin stuff.

[Pumaman]

Well, Scorpiorus has pointed out that it's already on the tracker to add some sort of feature for conditional plugins.

The problem is that since AGS doesn't know which functions the plugin would have exported, it therefore has to simply link all unresloved exports to an abort function -- so if the game was run with the wrong version of AGS, for example, it wouldn't spot the missing functions and would only exit when one was used, with a possibly confusing message about plugins.

[Radiant]

I suppose that, at compile time from the editor, AGS could create a list of functions from the active plugins, and store that somewhere in the Game.dat file. Then if at runtime a plugin turns out to be missing, AGS already has a list of all functions that should abort the game (and any function not on that list should trigger an "invalid function name" error)

[Pumaman]

That may be possible, but would have various technical complications. Still, I'll have a think about this.