Jump to content


jed

Python not backwards compatible in C4D

Recommended Posts

I'd always assumed that Python code was fairly portable - it's just text, right ? Seems like it's not...

 

I recently got a message 'thanks for the script, but it didn't work'. The guy was on an older version of C4D than me, and my bit of Python failed. I did a test with a file created in R20 that I attempted to open in R16, and got this

 

py_compat.png.f8019b5b8024a7523ad23988581ad7a2.png

 

This can be fixed by copy/paste the text into a new R16 Python window, or just deleting the 1st line 'import c4d' and rewriting it. R16 is Python 2.64, R20 is Python 2.7.14 and the difference is enough to break your scene. Makes me wonder how many 'bad' scenes I've given people in the past.

 

You can get your version here -

 

version.png.c35ecbf527b2e1f26acd7aaa4e7d4edd.png

 

D'OH ! as Homer Simpson would say...

 

 

  • Like 1

Share this post


Link to post
Share on other sites

  • Topic Author
  • Yeah - make new Python window, paste the text. Just deleting the 1st line 'import c4d' and re-typing it seems to work also.

     

    Share this post


    Link to post
    Share on other sites

    I created a simple scene only containing a null, added an xpresso tag and in Xpresso created a python node. Left all default, saved the scene file and opened it in R19, R18, R17, R16.

    All version opened the file without problems. So, I can't really confirm the problem.

     

    From your first screenshot (with the error) it seems the first line looks like "import c4d, math". Shouldn't that read "import c4d.math", with a dot instead of comma?

    Is it maybe a locale thing istead, where decimal point in text is interpreted differently on different OS versions? Just thinking out loud.

     

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • @C4DS I'm wondering if this is what they call PEBKAC - problem exists between keyboard and chair. Anyhow, I managed to reproduce the problem and not reproduce it ie 2 files, 2 different results -

     

     

    probably me doing something stupid...

    Share this post


    Link to post
    Share on other sites
    9 hours ago, jed said:

    probably me doing something stupid...

    Not at all.

    What I noticed: when you import the more complex file into R16 and select the Python node, you can see C4D has trouble interpreting the Python content correctly. The Attribute Manager shows the Python code, but the second line - a comment line - is not correctly color coded. If you then open the Python Editor it does show correct color coding for that second line.

    By the way, I tested on R16.050 not sure what has been fixed since the version you have running, being R16.011

    Checked the MAXON website, but they seem to only go back to R17 for available updates, so cannot really see if any Python interpreter or editor related fixes had been introduced between our two versions of R16.

     

    All I know is that this particular issue doesn't seem to be related to PEBKAC

     

    Wondering if the issue would be fixed without retyping the first line.

    Import the scene file, open Python Editor, press compile ... and check if the yellow title bar disappears. Just wondering.

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • @C4DS Here's the actual R20 file I sent to a Cafe member that started this story - see if you can find out what's going on. The compile error message says 'line 1 position 11' which is the end of the line. This can mean the error is in whatever follows.

     

    mover_R20.c4d

     

    I tried to recreate the problem with this file in R16

     

     

    I still think it's PEBKAC ...

    Share this post


    Link to post
    Share on other sites
    16 hours ago, jed said:

    I still think it's PEBKAC ...

    I understand you might think so, but NO, definitely not.

     

    From the start I assumed it was something related to how R16 did read or interpret the Python text data, triggered by the fact that you resolved the issue by retyping the first line of code.

    I went a little further, and just randomly added an empty line or a comment line anywhere in the Python code. This also - surprisingly - fixed the issue.

    I mean "surprisingly" in the sense that it is not code related.

     

     

    Went even further and saved the working version in R16 and compared both original and resaved text data (using Winmerge utility). This mentioned that both files used different carriage returns ... so I looked at both data in an hex viewer. This shows all characters in the text data, even the non-readable ones.

     

    Apparently, the R16 Python editor does use a different carriage return than R20. I assume that the switch between carriage return types was done at time of R17, since I can load the R20 Python in R19, R18 and R17 without issues. It's only R16 (and probably earlier versions) that show this problem.

     

    Anyway, there's not really something you can do about all this ... unfortunately. The only thing the user with an older version needs to do, is to force the Python editor to modify the carriage return by slightly modifying the content.

     

    668390794_Pythonbackwardscompatible.thumb.png.4356ee9f9fa6326ac680aaa55c0c9e43.png

     

     

     

     

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • So my intuition about error message 'line 1 position 11' was correct ?

     

    I just checked my messages from the original problem, and the guy says

     

    'I watched your video and I tried the file. Alas, it doesn't seem to work for me when I loaded it up and put the two object references into the boxes, I move the slider but nothing happens I'm afraid. 

     

    I'm using R16 at home, I don't know if that's why... I'll try again when I get to work tomorrow, where we have R20 '

     

    It seems it was a R16 problem.

     

    I think we have been very fortunate in the past with C4D backwards compatibility. There's some changes with R20, but MAXON seem to try to keep problems to a minimum eg I recently fixed an old floor generator for a Cafe member to make it work in R20 - the only R20 difference was a couple of cloner ports had changed slightly.

     

    So the big question is - can I assume any Python scenes are OK to share back to R17 ?

     

    BTW, thanks for looking into this - hex editors are a bit beyond me...

    Share this post


    Link to post
    Share on other sites
    2 hours ago, jed said:

    So the big question is - can I assume any Python scenes are OK to share back to R17 ?

     

    BTW, thanks for looking into this - hex editors are a bit beyond me...

    Yes, the Python itself isn't the issue here. So the actual Python code could be shared to version before R17 ... when you copy/paste the entire code. Files containing Python code seem to be problematic when loaded into older versions. Although I haven't checked if Python scripts created in R17+ do have the same issue as the Python nodes in Xpresso or the Python tag.

     

    The hex editor was just a way to visualize the text data.

    Newline and carriage returns (ASCII characters 10 and 13, or 0a and 0d in hex) aren't visible in a regular text editor.

    Share this post


    Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    • Recently Browsing   0 members

      No registered users viewing this page.

    ×