Hi @lasselauch, thank you for reaching out to us and I am sorry to hear about your problems regarding targeting multiple localizations. I am struggling however a bit to understand what is exactly going wrong for you. You tell us that the plugin "isn't behaving correctly in R23" which is a bit too broad for us to come up with an reliable answer. I am also sorry for having to point out that your proposed way of getting hold of the implementation of the plugin via aescripts.com - with the proprietary downloader you provide there to distribute your products - is a bit much for us. I would suggest that you share the relevant code more directly here, or, in case you cannot do this, share it via sdk_support(at)maxon.net confidentially with us (please note the Forum Guidelines regarding Support Procedures: Confidential Data, specifically regarding NDAs, in case they would apply here). For your actual problem: It is really hard to give any advice without knowing what exactly is going wrong. I assume you have a Japanese localization in your resource folder and it does not work for the user? I would check: If the folder has the correct ISO 639-1 language code, for Japanese it should be ja-JP, so for the strings folder it should be strings_ja-JP for example. Not providing a matching language code for a running Cinema 4D instance should result in Cinema automatically falling back to en-US. Make sure that the Japanese translation files are all UTF-8. While the manuals do not state that restriction, it could be something that is tripping Cinema up, especially considering that languages with large character sets, like for example Japanese, are not fully represented in UTF-8 due to the limited namespace. I would however had to ask our translators how they handle Japanese if this is the culprit. But in the end these are mostly shots into the dark for me, due to not knowing what is exactly going wrong. So I would also had to ask you to describe more precisely what is going wrong. Cheers, Ferdinand

Hi @blastframe, thank you for reaching out to us and for reporting these errors in the documentation. We will fix both the erroneously attributed short description of AddKey as well as the code example in an upcoming update of the C4D SDK Python docs. Cheers and happy coding, Ferdinand

Glad you found a way and yes I think it's safe now :) I guess there is no more open pint? If so I let you define your topic as solved (see Forum Structure and Features - Ask as Question If you don't know how to do it). Just in case a BaseContainer can also store a BaseContainer. so you could store your own BaseContainer at the ID_PLUGIN And in this BaseContainer at ID 0 stores, the obj counts, and then you can safely iterate over it. Cheers, Maxime.

Hi @delizade, Thanks @a_block for helping out! @delizade you can find the description for the priority options in the Python Tag section of the user manual. Cheers, Ferdinand

Hi, without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

Hi, without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

Hi, I understand that this thread has not yet come to a final conclusion, but without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

@lasselauch said in developers.maxon.net – Offline?: Had one aswell.... a rather old one... ...haha. Slightly outdated. LOL. :D

@m_adam Thanks for that extra info. I had done a search in the documentation regarding DrawTexture but didn't see it listed in the API changes. Hence, I didn't expect its behaviour to have changed so drastically. I haven't worked with S22 nor R23 before, so I didn't look in detail about the DrawTexture documentation, since it wasn't listed as changed. May I encourage this to be added in API Changes ... as it is quite a big deal encountering this issue when all worked fine in R16 upto R21.

@zipit Thanks, I thought so... but you never know whether some functionality has a hidden internal purpose. Deprecating it will probably be the best solution.

Hi @jochemdk, without further questions or feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

Python plugins do not work reliably in R23 on OSX 10.13.6. The C4D minimum spec is for 10.14.6 as Riccardo mentioned. And even if you try to debug a plugin on 10.13.6 what you will notice is that many calls (such as print) don't even work on this OS. So you can't even write anything out to the console to see what the problem might be. No amount of re-installing C4D will help you at all. You just have to let your customers know that the minimum spec for R23 is 10.14.6 and not guarantee any support for anything below that spec.

Thanks for the confirmation. (Follow-up questions moved to a separate post)

@Cairyn said in Matrix and Vector access: But this is happening on the C++ side - we're practically inheriting C++ issues indirectly Correct our Python API is just a layer on top of our C++ API so it of course has its same limitation. But now you actually make me wonder how the Python/C++ interface avoids situations where the C++ side deletes objects that are referenced in a Python wrapper without notifying these, creating invalid pointers. This is exactly the purpose of C4DAton.IsAlive and internally for each type that may be null each call do perform a check to see if the referenced c++ object is still alive. The whole Python interface is, after all, a layer on top, not as deeply integrated as would be necessary to make use of Python abilities like ref counters. Or is it? It depends, because in the case of obj = c4d.BaseObject(c4d.Ocube) then the owner is the Python object, so we have mechanisms to ensure that this obj is held by the PythonObject, and in many cases, we manage python object ref-count properly, so the GC doesn't delete thing people may not expect to be deleted or don't let alive object tool long (aka memory leak). But this is just the Python Object that represents a C++ object, so we have to be careful because if a Python object is deleted, the C++ object is not necessary also cleaned, it depends on who is the owner of the C++ object. Hope this answers your questions. Cheers, Maxime.

Thank you very much, Manuel! This is a working solution for the issue and it helped me a lot! Best regards, Tim

Hi @lasselauch sorry for the late reply, I asked about the developer responsible for it. On Windows we use the WebView control of the last iteration of iexplore MS shipped for 8.1 - Internet Explorer 11 (user-agent ID: "Trident"). It supports >most< things other modern browsers do, but sadly not everything... Especially the JS support has become a problem since IE11 is missing parts of the ECMA 6 standard and needs 'polyfills' to emulate those. Many JS frameworks / libraries don't offer IE11 compatibility and instead rely on the developer to add those polyfills themselves. One of the improvements IE11 received back then was the developer console+tools so the user could use those to track > down the JS issues and resolve them." I also forwarded your request about the ability to disable Javascript, but so far nothing planned atm, so the only workaround I see is either fix your javascript framework (maybe a huge task) or you can disable your javascript based on the user agent and if it's an IE11. Hope this help, Cheers, Maxime.

Hi @jochemdk, okay, I then took the liberty to close the question ;) You can of course still post here. Cheers, Ferdinand

yupyup, BaseSelect has no connection to the original object it actually selects from, not even in the cases where you get a pointer to the BaseSelect returned and change the selection directly through it. That's why we need the max parameter for SelectAll and ToggleAll -- the BaseSelect doesn't know what "all" even is. (Not GetLastElement()!) For GetRange() though, that reasoning does not apply. Now let's see whether I can crash C4D with inconsistent edge selections...

@m_magalhaes Got it, thanks :)