Hi @Braeburn, thank you for reaching out to us. I'll unpack some stuff in bullet points: Looking into the relevant RFC, you can see that there is very little standardisation, regarding what content/body you can expect for what message code. The 4XX range all indicates an error with receiving the body of a request, so it is somewhat to be expected that you get no content here. Some pages however have custom error pages and/or redirect some responses to 200 which explains the error. When you inspect your url with the google chrome traffic monitor, you can see that there is no redirect happening, but that the 404 will indeed return some text content and the matching content length. When you now shuffle through some http interfaces, google chrome (returns "correct" content and content length of 16), Python's urllib3 (returns no content and content length of 0), the request library (returns the same as chrome) and finally Cinema, you will see that they handle the responses quite differently. Which does not make much sense, since the client should have very little say in this. My suspicion would be that the user-agent of the request plays a role in this, or more specifically not setting up a proper agent, but I cannot confirm this yet. I will reach out to the development team to ask them, what their thoughts are about all that. In the mean time you could just compose yourself the "content" for responses where the body is empty. The status code and message will in your case exactly equate to the "content" (the keys net.maxon.http.httpcode and net.maxon.http.httpmessage in the response header dictionary). This won't help you to catch the content of responses where there are custom error pages without redirects (something like this for example), but will get you pretty close. Cheers, Ferdinand

Hi @lasselauch, thank you for reaching out to us. I'll answer/point out some stuff in bullet points: The error object has no attribute im_function indicates that you are returning an incorrect return value type for an overridden function/method. This rather cryptic message is a bug which will be resolved in the next update (see here and here for details). The method which you did implement incorrectly is TreeViewFunctions.SetDragObject (link) which has no return type (i.e. the return type None). You also misinterpreted the purpose of the method. It is there so that you can distinguish between internal and external drag operations by storing a reference to the object of an internal drag operation. There is also this nice posting made by @m_adam untangling the purposes of the TreeViewFunctions methods. About the core of your question: Your major misconception here is that you can just "replace" the drag object. Which is not what TreeViewFunctions is intended for. It is just a view model / interface layer between the TreeViewCustomGui logic and the data (layer) you want to be represented in that GUI. Cinema solves this internally with a special core message (COREMSG_COMMANDDRAGSIMULATION), but this unfortunately does not translate to Python, since it requires you to access the internal representation of a GeUserArea, which is not possible in Python. So your best bet would be to actually make the data you pass to TreeViewCustomGui.SetRoot() to be the actual PluginData nodes you want to drag. So that you are actually dragging a plugin node and not some stand in. There is however no guarantee that this will work, I would have to try that myself. 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.

Hi @Cairyn, yes, writing snap tolerances to these tool specific containers is not being respected. And after some further investigations I have come to the conclusion, that most things written to document snap settings (even the global settings) will be ignored. A workaround, which oddly is also done by Cinema internally, is to just invoke the respective plugin command for the snap implementations. I will have to ask the modelling team on Monday, why things are implemented this way and subsequently why they did choose to keep the snap settings around in this manner. In the mean time please take a look at the script below, which shows you how to read and write to SNAP_SETTINGS_TOOL with this rather odd approach. Cheers, Ferdinand import c4d def main(): """How to weasel your way around SNAP_SETTINGS_TOOL. The same approach can be applied to other snap tools (basically everything you can turn on or off in the snapping tool bar). """ # Get the command state. state = c4d.IsCommandChecked((c4d.SNAP_SETTINGS_TOOL)) print ("Tool Specific is enabled:", state) # Toggle the command. c4d.CallCommand(c4d.SNAP_SETTINGS_TOOL) # Get the new command state. state = c4d.IsCommandChecked((c4d.SNAP_SETTINGS_TOOL)) print ("Tool Specific is enabled:", state) if __name__ == "__main__": main()

@m_adam Hi Maxime, One additional remark + a question… I’m trying to build a minimum set of rules to avoid the dis/enabling of effectors if not really necessary. I can’t use moFlags to check whether a clone is visible or not, and that’s where the issue might be: 1_ Given the example in the previous post (with offset 2), the moFlags read something like [2,2,2,1,0,1,…..]. Flag 2 being “permanently disabled”. If it means that behind the scenes index 2 is totally ignored, this is where the problem might be… 2A_ So reading moFlags doesn’t give me the info I need. For the moSelections I was able to find the first index of an invisible clone via “baseSelection.GetAll(count)”. So everything fine here… 2B_ I’ve spend many hours trying to find a formula to find the (first) invisible clone with moWeights. Given any weight float value between 0 & 1, a clone gets invisible based on the strength & maximum value sliders (which are not limited and can go way past +/- 100%..). The question: What is the formula (with strength & maximum) to check whether a weighted clone gets invisible? Tia, Jochem (If you want I can start a new thread, but this is so closely related…) One function added in the script below: """ After some code I know which linearCloners have a moSel/Weight tag with the same name as the baseEffector selection string... Per effector - with visibility turned on - I run the func below to check what the minimal offset is (for multiple cloners) & return "update" True if the minOffset is >= the selection index where a clone gets invisible... The passed moSelDict has selection strings as keys & indices of an inexList as values. """ def checkUpd(effector, moSelDict): minOff = 999999 minSelIdx = 999998 for moInd in moSelDict[effector[c4d.ID_MG_BASEEFFECTOR_SELECTION]]: moObj = op[c4d.ID_USERDATA,5].ObjectFromIndex(doc,moInd) # moObj = cloner / index from a linearCloner in-exclusion list.. if moObj[c4d.MG_LINEAR_OFFSET] < minOff: minOff = moObj[c4d.MG_LINEAR_OFFSET] for tag in moObj.GetTags(): if tag.CheckType(1021338) and tag.GetName() == effector[c4d.ID_MG_BASEEFFECTOR_SELECTION]: # selection bs = mograph.GeGetMoDataSelection(tag) count = moObj[c4d.MG_LINEAR_COUNT] + moObj[c4d.MG_LINEAR_OFFSET] try: minSel = bs.GetAll(count).index(1) # << here is where I can find the correct (in)visible selection values for moSelections except ValueError: break # selectionTag with no selection.. if minSel < minSelIdx: minSelIdx = minSel break elif tag.CheckType(440000231) and tag.GetName() == effector[c4d.ID_MG_BASEEFFECTOR_SELECTION]: # weight strength = effector[c4d.ID_MG_BASEEFFECTOR_STRENGTH] maximum = effector[c4d.ID_MG_BASEEFFECTOR_MAXSTRENGTH] # WHAT IS THE FORMULA TO GET (IN)VISIBLE STATE OF A WEIGHTED CLONE, BASED ON THE 2 VALUES ABOVE?.. bs = mograph.GeGetMoDataWeights(tag) minSel = 999999 for w in range(len(bs)): if bs[w] > 0.0: # << this is of course not optimal :) minSel = w break if minSel < minSelIdx: minSelIdx = minSel break if minOff >= minSelIdx: return True return False Edit: It turns out I need a formula for the strength/maximum values for the moSelection version as well. I plotted some values (in excel:) for various combinations of strength/maximum with moSelections/moWeights. All show an exponential growth(/decay) curve... I know you're not supposed to write scripts for others, but if you've got some code lying around - it would be brilliant.

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.

Thx for your replies! I'll test it soon & hopefully the bug will be fixed :)

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 :)

@mp5gosu Whooop! Thanks, Robert! You have to return a tuple so return (c4d.NOTOK, False) does the trick for me. Thank you!!! Cheers, Lasse

Hi @ivodow , thanks for reaching out us. With regard to your issue, I can't reproduce in S22.118 (S22 Service Pack1 HF2). Can you please provide info on your Cinema 4D environment? If your release matches the one above, can you share a simple scene to reproduce? Thanks, Riccardo

Hi Eddy, welcome for the Forum and thanks for reaching out us. With regard to your issue, I think the problem is how you handle your ObjectData cache and when if update it during the scene evaluation. In the code below beside checking for my object cache existence and for my object's parameters changes I also check if the cloner's cache has changed when the ObjectData::GetVirtualObjects is called. class PC_12764 (plugins.ObjectData): _clonerDirty = 0 def Init(self, node): return True def GetVirtualObjects(self, op, hh): cloner = op[1002] res = c4d.BaseObject(c4d.Onull) if cloner is None: return res clonerCache = cloner.GetCache() if clonerCache is None: return res firstClonerItem = clonerCache.GetDown() if firstClonerItem is None: return res # check cloner cache dirty count clonerDirty = False if self._clonerDirty != cloner.GetDirty(c4d.DIRTYFLAGS_CACHE): clonerDirty = True self._clonerDirty = cloner.GetDirty(c4d.DIRTYFLAGS_CACHE) # return object cache taking in account cloner cache dirty = op.CheckCache(hh) or op.IsDirty(c4d.DIRTY_DATA) or clonerDirty if not dirty : return op.GetCache(hh) while firstClonerItem is not None: child = c4d.BaseObject(c4d.Onull) child.SetMg(firstClonerItem.GetMg()) child.InsertUnder(res) firstClonerItem = firstClonerItem.GetNext() return res This approach, without using the ObjectData::Execute() gives ,in the end, consistent results when exporting a .aec file using a External Compositing Tag as in the scene attached. AEC file except ... ... NULL2 "Null" { NULLTYPE 1 SIZEX 200 SIZEY 100 ANCHOR 3 ORIENTATION 1 COLOR 1 0 0 SHOWFROM 1 SHOWTO 10 KEY 1 200 200 200 0 0 0 0 0 0 KEY 2 202.036 195.61 204.755 0 0 0 0 0 0 KEY 3 206.929 185.058 216.184 0 0 0 0 0 0 KEY 4 212.786 172.427 229.866 0 0 0 0 0 0 KEY 5 217.679 161.875 241.295 0 0 0 0 0 0 KEY 6 219.714 157.485 246.051 0 0 0 0 0 0 KEY 7 217.679 161.875 241.295 0 0 0 0 0 0 KEY 8 212.786 172.427 229.866 0 0 0 0 0 0 KEY 9 206.929 185.058 216.184 0 0 0 0 0 0 KEY 10 202.036 195.61 204.755 0 0 0 0 0 0 } NULL2 "Null" { NULLTYPE 1 SIZEX 200 SIZEY 100 ANCHOR 3 ORIENTATION 1 COLOR 1 0 0 SHOWFROM 1 SHOWTO 10 KEY 1 0 200 200 0 0 0 0 0 0 KEY 2 0.427 201.541 196.343 0 0 0 0 0 0 KEY 3 1.453 205.246 187.554 0 0 0 0 0 0 KEY 4 2.681 209.681 177.032 0 0 0 0 0 0 KEY 5 3.707 213.385 168.242 0 0 0 0 0 0 KEY 6 4.134 214.927 164.585 0 0 0 0 0 0 KEY 7 3.707 213.385 168.242 0 0 0 0 0 0 KEY 8 2.681 209.681 177.032 0 0 0 0 0 0 KEY 9 1.453 205.246 187.554 0 0 0 0 0 0 KEY 10 0.427 201.541 196.343 0 0 0 0 0 0 ... ... } Scene file PC_12764.c4d

@m_magalhaes That's okay. Thank you for letting me know!