Developing a plugin for several versions



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 24/02/2006 at 05:52, xxxxxxxx wrote:

    Hi,

    Sorry if this question has already been posted.
    I could not find the answer on these forums neither in the SDK docs.

    Is there a way to develop a plugin that can be used on different versions of C4D without recompiling it ? From 6.x to 9.5 for example ? Using COFFEE maybe ?
    Thank you for your help.

    Regards,



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 24/02/2006 at 09:39, xxxxxxxx wrote:

    Hy DL3D,
    I think in most cases COFFEE is at least easier to adapt to new versions.
    But its main advantage is the cross-plattform ability between Mac and Pc I think. COFFEE uses the API of Cinema like c++. So If there are changes made in this API (objects, properties, methods predefined in the Application like the "BaseObject") and there are a lot  from 6 to 9 for sure, I think COFFEE has to have version-dependend code for specific operations too. 
    But were are lucky: There is a possibilty to get the programm-version used in COFFEE. So it should be possible to write plugins that can run under several versions by splitting Version-dependend and version-independend code in the source by this (think about a coffee-framework encapsulating those changed functions and doing the version-control selection the right command to execute for the actual version running).
    To me the most difficult thing about this is:
    I only have one version of cinema. I do not always know abou the changes in more actual versions yet nor about those made from earlier versions. So it will be difficult to test the compatibility without help from others with other versions. (In most cases if you make freeware, the problem is solved  by providing the source and getting corrections/help from others, thats the good thing about it)
    All c++-plugins should better be recompiled to be sure, the binaries match the program-version correctly. Otherwise, in worst case, crashes of the application an loss of data perhaps may occur. (It depends on the plugin of course)
     
    Hope this helps,
    best greetings,
     
    COFFEJUNKIE



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 25/02/2006 at 06:42, xxxxxxxx wrote:

    Thanks COFFEJUNKIE for all these tips ! :-)
    Regards,



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 05/03/2006 at 13:09, xxxxxxxx wrote:

    From the C++ perspective, having done versions for every possibility out there:

    If you are using the C++ SDK, the first thing you need to determine is the minimum version that you want (or can) support. Note that the Windows 64-bit version of Cinema 4D can only be compiled for R9.1 or later and that the MacOSX Universal Binary verson of Cinema 4D can only be compiled for R9.5.2 or later. So, if your base plugin support is R8.0, for instance, you will need to be cognizant of the differences in the APIs (as well as system and compiler/linker differences) for porting purposes.

    As an example, in R9.0, the Polygon class had a name change to CPolygon which brings endless misery if one is not prepared for it. A simple workaround is to create a define in some strategic header like so:

    #ifndef C4D_R9  
    typedef     Polygon     CPolygon;  
    #endif
    

    This redefines Polygon in pre-9.0 compiles so that the same name (CPolygon) can be used in all cases.

    There is definitely no way to compile once and have a plugin run on all systems. The minimum setup for supporting all systems is this:

    Windows: Visual C++ 6.0 or later (.cdl)
    Windows x64: Visual Studio 2005. net or later (.cdl64)
    MacOS: CodeWarrior 8.0 or later w/MacOS Classic Target (.xdl)
    MacOSX UB: XCode 2.2.1 or later (.dylib).

    Luckily, you can get VS2005 and XCode for free, but not the systems on which they run of course (for testing at the least).

    As you see, each results in a different binary library which, unlike say Java, is not portable. Only the source code can be made portable.

    Finally, remember that although COFFEE is a viable alternative, it does not have the feature set and flexibility of C++ plugins. If your plugins are relatively simple, COFFEE may be your 'cup of tea'. ;) Otherwise, skip the cup o' joe and get down to taking your shots. (drum roll please)....

    HTH,



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 13/03/2006 at 16:18, xxxxxxxx wrote:

    I would like to add my question here (if you don't mind)

    Since a lot of command in coffee have changed I end up having two seperate .cof files, one for C4D 9.x and one for the versions below.
    This works fine but one thing stil annoys me... I get an message in the console window telling me about an coffee error in the one of the files (the one for the each other version of C4D).
    Checking the program version doesn't work, since C4D seems to check the files while loading (and before executing).
    Does anybody know a way to suppress these messages without splitting the plugin in two completely different directorys? (so, one download for all versions, without that message that will confuse users)



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 11/04/2006 at 03:49, xxxxxxxx wrote:

    Hello michaelh,
    if cinema would check the files before execution there could be not message, because a .cof-file is a .cof-file without regarding the version of code inside. There must be a kind of execution/regarding the code  for cinema somehow. But perhaps not all of the code is executed. Maybe you just have to find the right position in the code to stop cinema regarding the plugin. (Normally non-compatible .cof-files are not recognized by cinema, but I am not sure how).
    I assume the break must be done somewhere near the super-command.
    I am not quite sure if this works, but its quite easy to try it out:
    Example checks Polygon and CPolygon in your initialization/GetID-sub of your plugins:
    var a=new(Polygon)
    var b=new(Cpolygon)
    if (a) ... Version is lower than 9
    if (b) Version is higher equal 9
    as said,  I am not sure but perhaps in the one or other case you may return NULL as plugin-id/skip the super-command which I assume will stop Cinema loading the plugin without showing an error in the console. I never tried it but it may work perhaps.
    Best regards,
    COFFEJUNKIE
    ps: As said I am not sure, so I say sorry if it is just rubbish :)


Log in to reply