Thanks for the response. I figured it would need to be the SceneHook but always best to double check. John Terenece

@m_magalhaes said in Larger BaseMaterial Preview Renders: The function looks like this. As you can see the progressRef and progressIndex are passed arguments. While BASEBITMAP_DATA_PROGRESSHOOK looks like you just need to pass a function (here a lambda), i still don't know what the context is good for. Sorry i don't have enough time to investigate more and give you a better answer. I will try to find more time this week. Be aware that this is marked as Private and "hack". So, it could change in the futur. Thanks. Looks like I was passing in the ProgressHook correctly but still for some reason I do not get any callbacks to it. Perhaps it is because I am not passing in an actual document filename, not sure. But I am still getting the correct renders back even though my ProgressHook does not get called, just would have been nice to see the progress on larger images. The context in this situation would have been great for me to let me set the progress in my progress dialog. So that is what it is useful for. It is fine that it is private and may change, I am only using this for internal tools to generate images, IE not a customer facing tool. Thanks for the help.

Thank you so much!

Wow, thank you both for such detailed and informative replies! First of all, apologies @ferdinand for the tag issues, I was consulting the guidelines whilst typing my question but managed to miss the OS tag. Not sure if it matters too much for python dev, but I am on a Windows machine. I did however notice that the tag list doesn't seem to be updated to include R25 just yet (the version I'm currently working with), so it may need adding by the team. It doesn't look like I'm able to edit my original post past a certain time, but if you have the ability feel free to update Useful to know about the distinction between CommandData.ExecuteOptionID() and CommandData.ExecuteSubID(). The cogwheel icon present on some of the in-built commands was something that I'd noticed previously and been curious as to the implementation of - assumed it was just some complex code magic that added an additional button to the menu UI, ha! I guess that you're probably right in that I shouldn't try to run before I can walk, and if there's no limit to the amount of plugin IDs permitted (makes sense if there are hundreds of thousands of them going spare! ), then the keep-it-simple approach of registering multiple IDs would probably be best at this stage. For future reference though, if it is functionally the same as registering multiple IDs, do you know of any resources showing the implementation of CommandData.ExecuteSubID(), besides the docs; is this something that could be a candidate for an additional example in the SDK plugins repo? @Cairyn thanks for offering a more general insight into the situational decisions behind why something might be the 'best' choice (or not a choice at all!). I'm a designer first and foremost with an interest in coding, rather than the other way around, so considering the UX of a potential plugin and how it could fit into my own workflow is something I'm keen not to ignore To be a little more specific about how the plugin will function: essentially it will be a set of commands allowing the user to rapidly navigate around the viewport in a way that's a bit more custom than the default 'front, back, left, right, etc' views, as well as the ability to toggle between perspective and parallel views, ideally while keeping the same projection matrix (the hard bit!). My intention is to bind these commands to separate shortcuts so that they're a 'function at your fingertips' Actually I do have some additional questions about the ability to set keyboard shortcuts via a plugin, instead of the command manager, and how Cinema then deals with shortcut conflicts, but I think that's one for another thread! Definitely going to refer back to these suggestions as I continue my learning journey. Thank you both again!

Thank you.. It's Solved. @fwilleke80 @ferdinand and @kbar def PluginMessage(_id, data): if _id == c4d.C4DPL_PROGRAM_STARTED:

Hi @ferdinand , Thank you very much for your detailed reply. I think it is very helpful to me. Cheers!

@m_adam OK this is really weird. I tried this over and over yesterday for several hours. this morning it is working fine! It must have been a case of restarting my machine or something. All set on my end! Thanks for testing either way, much appreciated!

DTYPE_LONG can be used with SetGeData if the track category is CTRACK_CATEGORY_DATA, see the third post in this thread. This is the only ambiguous datatype at the moment, and as other datatypes wouldn't make sense with SetValue I think it will remain the only one. But I do claim that the category of the track determines whether you need to use SetValue or SetGeData. (That is almost the same in effect... but in case of DTYPE_LONG not quite.)

Hi Manuel, I didn't think about CopyTo being called on undo. That might be all I need then, thanks. I did a couple tweaks and as of now everything is perfect. Dan

@m_magalhaes Thank you!

Hello @SteveJLV, the example has been fixed and both computations now will reflect the correct result. The fixed example will be included with an upcoming release of the Python SDK documentation. Cheers, Ferdinand

Hi, unless I'm wrong, you already asked the question on this thread Sorry for the delay, i was looking for a workaround solution. Cheers, Manuel

Thank you very much !

Hello @rownn, without any further questions or replies, we will consider this thread as solved by Monday the 20th and flag it accordingly. Thank you for your understanding, Ferdinand

Hello @Expresso-Mechanic, without any further questions or replies, we will consider this thread as solved by Monday the 20th and flag it accordingly. Thank you for your understanding, Ferdinand

Hello @blastframe, I must apologize, I know we took our sweet time with answering this. However, we must move on with that topic, since it has been more than fourteen days since Manuel did provide his last answer. We will consider this thread as solved by Monday the 20th and flag it accordingly. Please feel free to reopen the 'Ask-as-question' status when there are questions left. Thank you for your understanding, Ferdinand

Hello Maxime, first of all, thanks for the quick response. You gave me a great clue with the compiled dll version. C4D R23 is compatible with scipy 1.4.0 so the solution was to downgrade it. Thanks again, Daniel

Oh my god, thank you!!! Now material exchange does work properly again. Without this, it's just a mess to get rid of all .1, .2, .3, before I could execute the mat exchange. What a great helper, should be integrated really... Thank you very much and have a nice day

@ferdinand Thanks to your replay, Some of the features I wanted seemed to be addressed in the R25! Let's rock and roll for R25! Cheers!

Hi Thank you for solving my question, and thank you very much also for the advice.