Plug-in running fine on one OS but not another

ferdinand

Thank you for reaching out to us. It is not so easy to answer your question in the current form. I am going to itemize a few things in bullet points to indicate what information is missing and where potential problems could lie. When the bullet points do not help you, you should provide the missing information.

General Information about ABI and Dependencies

For which exact SDK have you built your plugin? 2023.0.0 I assume? Note that our SDK is never downwards compatible. So, when you happen to have beta access, and have built for 2023.1.0, such plugin will not run under 2023.0.0. But since we keep the ABI stable for roughly a year, a plugin compiled for 2023.0.0 will run under 2023.1.0. The ABI version for 2023 is 2022901, you can find out more about ABI versioning on the Plugin Development page.
The "Apps and Features" list should not play any role here, as Cinema 4D does bring all its dependencies on installation, and when Cinema 4D starts, you have everything what is necessary to load plugins. The dependencies of plugins are the SDK, more precisely the frameworks folder in it, against which you compile; it must match the ABI version of the Cinema 4D you want to run the plugin under. But since you likely built for 2023.0.0 and want to run under 2023.0.0, ABI does not play a role here.

About your Project

What kind of plugin hook are you implementing? A CommandData or an ObjectData for example?
Are you sure that in the Cinema 4D where the plugin is not loading, nothing is occupying the plugin ID of that plugin? A plugin ID can only be used once on a running Cinema 4D instance.
Are you sure that you copied over all dependencies for your plugin as for example resource files or custom decencies as third-party binaries? When you are registering an ObjectData plugin and the resource symbol provided in the registration call (const maxon::String& description) does not resolve, the registration will fail.
What is the console output of the Cinema 4D where the registration does fail? Plugin ID collisions are being reported.
Have you checked that indeed the registration does fail? You could do something like this, as all registration functions return a bool:

Bool RegisterMyPlugins()
{
  const maxon::String name = GeLoadString(IDS_MY_PLUGIN_NAME);
  const maxon::String help = GeLoadString(IDS_MY_PLUGIN_HELP);

  if (!RegisterCommandPlugin(
    PID_MY_COMMAND_PLUGIN, name, PLUGINFLAG_SMALLNODE, nullptr, help, NewObjClear(MyPluginCommand)))
  {
    ApplicationOutput("Failed to register: @", name);
    return false;
  }
  // Register other plugins in the same way ...

  return true;
}

If this all does not help, I would have to ask you to share code, either here in the forum or via sdk_support(at)maxon(dot)net.

Cheers,
Ferdinand

Yakuza

@ferdinand

Hi Ferdinand.

Thanks for the quick reply. I'm currently a bit busy and can only answer some questions without investigating further.

First of all I'm using legacy code and it's a commanddata plugin. I downloaded the project tool last week. I compiled it for 2023.0.1 and copied the same folder over to the other Windows running a fresh install of 2023.0.1 with no other plugins present in the plugins folder.

Regarding registration I check this in Main like this

#include "c4d.h"

Bool RegisterSOLO(void);
Bool RegisterSoloPrefs(void);

Bool PluginStart(void)
{
	if (!RegisterSOLO()) {
		ApplicationOutput(maxon::String("Solo could not be registered."));
		return false;
	}
	if(!RegisterSoloPrefs()) {
		ApplicationOutput(maxon::String("SoloPrefs could not be registered."));
		return false;
	}
	ApplicationOutput(maxon::String("solo for Cinema 4D 2023.0.1 (C) 2007-2022 by synesthetic.de"));
	return true;
}

void PluginEnd(void){ }

Bool PluginMessage(Int32 id, void *data)
{
	switch (id)
	{
		case C4DPL_INIT_SYS:
		// Don't start plugin without resources
		if (!g_resource.Init()) return false;
		return true;
		case C4DMSG_PRIORITY:
			return true;
	}
	return false;
}

There is no output in the console at all. I'm going to double check API and C4D versions later this evening and do a rebuild.

Cheers!

Yakuza

You can download the plugin here http://synesthetic.de/plugins/solo2023.zip

ferdinand

Hello @yakuza,

Thank you for your reply. So, I have tested your binaries under 2023.0.0, 2023.0.1, and 2023.1.0. Guessing from your code listing, I assume that you are registering a CommandData and a PrefsDialogObject plugin hook. The plugin loads in all versions for me, see details below

2023.0.0
2023.0.1
I cannot show you a screenshot of 2023.1.0 for obvious reasons, but it loads there too.

You say nothing is being printed to the console, which is odd, as your plugin has multiple ApplicationOutput calls. This is a strong indicator for your plugin not lying on the plugin search paths of the Cinema 4D where it is not loading, please check the plugins include folders in the Preferences dialog of Cinema 4D.
Something is going wrong (buttons are missing) with the Preferences plugin you seem to register in 2023.0.0, but that is not too surprising, since you complied against 2023.0.1 and plugins are not downwards compatible.
In all versions your plugin does not appear in the "Extensions" menu unless I am blind. Since you are not showing the actual registration calls, only wrapper functions for them, I can only speculate here. You could for example be intentionally using PLUGINFLAG_HIDE as you do not want the plugin to show up.
Your copyright remark is printed to the console in all versions.
The plugin loads for me in all versions of 2023, with the detail of the mentioned and to be expected problems in 2023.0.0.

So, bottom line: I would check here if you indeed included the plugin folder. When you are looking for the plugin in the Extensions menu, I would check your actual registration for the flags you are passing. Remove PLUGINFLAG_HIDE when you are passing it.

When all this does not help, we will need a bit more code, especially the defintion of your RegisterSOLO() and RegisterSoloPrefs() would be relevant.

Cheers,
Ferdinand

Yakuza

Hi Ferdinand.

The folder is the default "plugin" folder in the application folder with both OS so no path in the C4D prefs. But even with path it makes no difference. Yes, I'm using pluginflag_hide and access the command via Comand Manager shift+F12. Here the console doesn't even print the copyright remark. On the other OS everything works, console out, prefs dialog in C4D preferences, command in Command Manager.
I'll get back on this later. Thank you so far.

ferdinand

Hey @yakuza,

That is really odd. I will talk tomorrow with my colleagues about this, maybe they can spot a cause for this I am overlooking here.

Cheers,
Ferdinand

Yakuza

Yup, very odd. BTW on the failing OS neither the locally installed 2023.0.1. loads the plugin nor the installation that is installed on the other OS and works there does.

Yakuza

OK, it's working now. I changed two things but probably what did the trick was the latter: I updated Visual Studio and compiled a Release build. The shakey one was Debug config which I totally missed until after the update. FYI I'm using the Community Edition. You can re-download via the above link and test 2023.0.1. and 2023.1.0 again if you are interested. Here it's running just fine in both versions incl. prefs.

Cheers!

kbar

I was reading through this to see if you used a Debug build. Glad you finally found it. I assume what you were doing was compiling on one machine in Debug mode and then just copying the plugin to your second machine to try it out. That second machine wouldn't have had Visual Studio installed so it wouldn't have had the debug runtime dlls, so your plugin wouldn't have loaded. Always compile in Release mode if you are going to test your plugin on another machine, or if you are giving the plugin to someone to test out.

ferdinand

Hey @everyone,

Great to hear that it is working now for you. Can we consider this case solved, or are there any problems left?

Cheers,
Ferdinand

Yakuza

@kbar said in Plug-in running fine on one OS but not another:

I was reading through this to see if you used a Debug build. Glad you finally found it. I assume what you were doing was compiling on one machine in Debug mode and then just copying the plugin to your second machine to try it out. That second machine wouldn't have had Visual Studio installed so it wouldn't have had the debug runtime dlls, so your plugin wouldn't have loaded. Always compile in Release mode if you are going to test your plugin on another machine, or if you are giving the plugin to someone to test out.

That's exactly what happened. Thanks.

Yakuza

@ferdinand

Yes. it's solved. Thank you.