Hello @m_adam, without any further questions or other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022. Thank you for your understanding, Ferdinand

@m_magalhaes Thanks for the response. Might be able to use your idea as potential solution. John Terenece

I would recommend against changing anything in the scene from within GetVirtualObjects(). Rather do it in Execute(). Cheers, Frank

Hi this bug was fixed with release 2023.0 of Cinema 4D. Cheers, Maxime.

Thanks for the response Ferdinand, I thought that that would be the case. John Terenece

Hello @khor, without any further questions and other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022. Thank you for your understanding, Ferdinand

Hello @sol87, without any further questions and other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022. Thank you for your understanding, Ferdinand

@ferdinand wow, awesome. It works! thank you so much.

@mogh I didn't know about this function @ferdinand Thank you a lot for your detailed response. I will chek posts which you recommended

Hello @pyxelrigger, without any further activity before Wednesday, the 16.03.2022, we will consider this topic as solved and remove the "unsolved" state from this topic. Thank you for your understanding, Ferdinand

Hello @ferdinand, thank you again for this very detailed and helpful reply! I tried both methods, allocating beforehand and like the previous setup, just have it after the ParallelFor altogether. Both worked, although allocating beforehand introduced some weird flickering in the particles and was (at least it feels that way) more unstable. Which is why I opted to go for the second solution as with some exstensive testing it didn't seem to cause any issues. For anyone maybe reading this in the future and having the same issues: Do not allocate the particle group inside the plugin but use a link field and have the user handle the particle group creation inside c4d, that solved a lot of weird behaviours and seemed to work better/more stable. (at least in my not so intended usecase) I will mark this thread as solved, as it works now and I can fix the main-thread issue as well without too much trouble. So thank you very much for your quick and very detailed replies! Best Regards, Florian

Hmm thank you!! It's not as difficult as I imagined I just had to make a change in the formula for some case, I used: x = focaldistance*math.tan(h/2)*1 [image: 1644929034240-96f1960e87e92c0bd8b3f677b453172d.gif]

@m_magalhaes said in Copying Take Overrides from an object to another via Python not working properly: adding the backupvalue You are master! thanks my friend, it's working!

Thanks, this is going to be fixed in the next documentation release. Cheers, Maxime.

Thanks Frank, @fwilleke80 said in Getting material 'use' flag: BaseMaterial* const materialPtr = textureTagPtr->GetMaterial(); Yep, that's what I was missing. I was thinking the texture tag was the material, but it wasn't and I needed to get the link to the material from the texture tag. Cheers, WP.

Hey @wen, Thanks for sharing the example scene! Got a new question though, what do you mean with: "In R25 Redshift does not have a "Raw" color profile anymore" I looked at the wrong parameter; I thought your second script was still for REDSHIFT_RENDERER_COLOR_MANAGEMENT_OCIO_RENDERING_COLORSPACE as the previous example, but it is for REDSHIFT_RENDERER_COLOR_MANAGEMENT_OCIO_VIEW. So, you are right, "Raw" is still there Cheers, Ferdinand

hxx files are created by the preprocesssor when you compile.They are created in the Generate subfolder of each project. Frameworks should work out of the box (even if sometimes, we have some bugs_ Cheers, manuel

Hi Manual, This is exactly what I needed. Thank you very much. Best regards, Tomasz

Hello @wuzelwazel, without any further questions or postings, we will consider this thread as solved by Friday the 4th, February 2022. Thank you for your understanding, Ferdinand