Sorry for barging in, but as the same Q was asked on two more forums, I stumbled over it. I couldn't find the actual error in the code, but after reducing the whole thing to the crucial lines, I am fairly convinced that it is a bug. I created a completely new scene (R21) to exclude any strangenesses from the original file, and it's still easily reproductible: The script here is very simple: import c4d def main(): obj = op.GetObject() parent = obj.GetUp() parentMat = parent.GetMg() obj.SetMl(~parentMat) It does nothing but assign the child the inverted parent matrix as local matrix. Logically, this should make the child stay constant and in place, regardless of whatever changes you perform to the parent. It works very well as long as you only rotate or translate the parent; as soon as you add some scaling, you get the result above. The child's matrix starts shearing, and the coordinate system is no longer orthogonal (which isn't even supported by C4D natively). I can only conclude that the matrix inversion has a bug and is not handling scaled matrices correctly (as strange as it sounds - such a basic error should show up in every second scene...).

hi, thanks a lot for reaching us out with that issue. i confirm that the code is setting the minimum subdivision to 1 if the command have been migrated (witch it is) I've opened a bug entry and transfert the problem to the devs. I'll come later if I have a more informations. Cheers, Manuel

Oh, man... I thought I hit reply on this days ago! Sorry! So, MoData tag container didn't work, that's not where the MoData is stored. Well, there seems to be MoData there, just always empty... but I think that's because the mograph stuff uses the messaging system so heavily that just grabbing a basecontainer doesn't cut it. @zipit said in MoData.GetData()?: Hi, I was a bit overworked when I wrote this test, which is why I did made a little booboo in the code above with rather dire consequences. I have fixed this now and the timings are now correct (aside from the general diceyness of the whole test). But the general consensus is the same. BaseContainer is not slow and a good choice when we need key, value pairs. One should also keep in mind, that I did employ simplifications for list both in the insert and delete case, if we want to truly delete and insert arbitrary elements from/to a list, this type is terrible, as it has to rebuild all data each time. Cheers, zipit Thanks for revising this. Even if the basecontainer times technically look worse by comparison, in context I can still see it's no slouch! I've moved forward with this approach and so far I'm getting great performance with breaking down and stashing away the array's data into basecontainers. Still wondering if it wouldn't be better to go with a Read/Write/CopyTo implementation, but I honestly don't see a need here. It's plenty fast enough and doesn't even need to be accessed often. @m_magalhaes said in MoData.GetData()?: hi, it's a bit hard to tell as i still don't understood what you were trying to achieve. Do you want to save the mograph data and use them in c4d as a kind of library, or do you want to export them to a 3rd Party software ? Cheers, Manuel I need mograph cache tag functionality without the mograph cache tag. So I need to store MoData and be able to have it persist through file saves/loads, copying to a new document/rendering, duplication, etc. Given the potential size of the data in question (especially once you add animation into the mix) I want to make sure I'm doing this in the most efficient manner possible. Given that all the datatypes that contain the MoData aren't directly supported by the normal storage methods in c4d (basecontainers and hyperfiles), I was concerned that breaking all the data into its individual components to store it away wouldn't be efficient. I'm seeing now that I had little to be concerned about. Performance is great so far! I think I've even cleared my final hurdle, which was creating an array of MoDatas. My problem there was trying to use a BaseArray when what I needed was a PointerArray. Since PointerArray's take ownership of the pointed object, freeing the allocated MoDatas is as clean and simple as calling Reset() on the Pointer Array:) Injecting my MoData into the effector pipeline is equally simple by doing a CopyTo() or MergeData()... currently I'm doing that in ModifyPoints, but maybe I should be doing it in InitPoints? I'll figure that part out, but right now I'm just happy to have it all working! Thank you again zipit and Manuel!

Hi, Correct it was an unknown error. And yes it not only affect Layer but any kind of GeListNode inserted if they are not already in a hierarchy. I marked this topic as solved, and will bump the topic once a fix is included in a public release. Keep in mind this is a Python only issue. Cheers, Maxime.

Hi @Eduardo-Oliveira first of all welcome on the PluginCafe community. I think @zipit already provided you some correct answers or at least point you that this workflow is kind of strange for a Cinema 4D user since normally the object by itself doesn't really set its own position, but it's up to a tag (constraint Tag) to define the object position to another one. But in case you really want to do it, doing it in the Execute method of your ObjectData is fine. def AddToExecution(self, op, list): list.Add(op, c4d.EXECUTIONPRIORITY_GENERATOR, c4d.EXECUTIONFLAGS_CACHEBUILDING) return True def Execute(self, op, doc, bt, priority, flags): op.SetMg(doc.GetFirstObject().GetMg()) return c4d.EXECUTIONRESULT_OK You also need to ensure you registered your object with the flag c4d.OBJECT_CALL_ADDEXECUTION so AddToExecution and Execute are called. Cheers, Maxime.

hi, your question is sometimes not obvious :D Even with the scene it's a bit compicated. What i can say about your code is that you should be more defensive in your code. Always check the value before continue. For example what if the object is not found ? You should continue to the next item or stop ? for item in spline_UD: rs_mat = doc.SearchObject ("S" + str (item) + " Gas") if rs_mat is None: # Because we don't have object to continue, we iterate to the next item. continue ... Cheers, Manuel

@m_adam said in First Time calling SetAction does show the Brush tool's AM: And I did test only on R21 so be sure to check again because I wasn't able to reproduce as you said with default layout in R21. Cheers, Maxime. I am using R21.207 and with default layout see the brush tool in the AM (identical to what happens with R20.059). For safety, I have now tested your solution on R21 and works as expected.

@r_gigante Sorry Riccardo, I do not understand your reply. I had tried with empty as well as non-empty dialogs. Both as DLG_TYPE::ASYNC and DLG_TYPE::ASYNC_POPUPEDIT. Still with these 4 combinations I do not get appropriate values for the global position. Bool MyDialog::CreateLayout() { Bool res = GeDialog::CreateLayout(); GroupBegin(0, BFH_SCALEFIT | BFV_SCALEFIT, 2, 0, ""_s, 0); AddButton(ACTION_1, BFH_CENTER | BFV_CENTER, 200, 10, "button A"_s); AddButton(ACTION_2, BFH_CENTER | BFV_CENTER, 300, 10, "button B"_s); AddEditText(ACTION_3, BFH_CENTER | BFV_CENTER, 500, 10); GroupEnd(); return res; } Bool MyCommand::Execute(BaseDocument* doc) { if (mDlg.IsOpen()) { mDlg.Close(); return true; } BaseContainer bc; if (GetInputState(BFM_INPUT_MOUSE, BFM_INPUT_MOUSELEFT, bc)) { const Int32 mx = bc.GetInt32(BFM_INPUT_X); const Int32 my = bc.GetInt32(BFM_INPUT_Y); const Int32 w = 50; const Int32 h = 50; mDlg.Open(DLG_TYPE::ASYNC /*ASYNC_POPUPEDIT*/, TEST_COMMAND_PLUGIN_ID, mx, my, w, h, 0); ApplicationOutput("Mouse cursor at @, @", mx, my); Int32 dlgX = 0; Int32 dlgY = 0; mDlg.Local2Screen(&dlgX, &dlgY); ApplicationOutput("Dialog created at @, @ (screen)", dlgX, dlgY); dlgX = 0; dlgY = 0; mDlg.Local2Global(&dlgX, &dlgY); ApplicationOutput("Dialog created at @, @ (global)", dlgX, dlgY); } return true; } Additionally, when activating the plugin when Cinema4D is fullscreen, the dialog gets positioned at the expected coordinates. But the position of the dialog is nowhere near the expected position if the plugin is activated when the Cinema4D window is not full screen. It seems as if the mouse coordinates relative to the application window are applied relative to the screen origin. Which means that if: 1 Cinema4D is not full screen 2 and offset from the top left corner of the screen by an amount X 3 assuming the mouse position is at coordinate mx from the Cinema4D's main window's top left corner The dialog ends up at mx from the screen's top left corner, instead of the expected X + mx. (All the above was tested with R20 only, since I have refrained from further R21 development) Unfortunately, I have moved on and am currently not focused on this particular plugin anymore. As such, I may have missed some details. I will need to find the time to pick up where I had left.

Extra info! While I had set this topic as solved, without an actual WORKING solution being provided, I simply wanted to point out for future reference that R16 - R19 has a slight different behaviour. As with R20 and R21 the first time the dialog is opened it gets positioned centered on the current mouse position. On all subsequent opening it gets positioned with its upper left corner at 0,0. Something got "fixed" between R19 and R20, but not "fixed enough".

it's not a stop seller so it will be probably fixed in R23. Oh, I read "the next update" as being "the update right around the corner". Not as if someone saying "the next day" but actually meaning "in a not to near future". But thanks for pointing it out. Well this is the global function, in a GeDialog you should use GeDialog::GetInputState Sorry, I am not in context of a GeDialog, but a CommandData. What other options than the global function do I have here? True, not really the answer I was looking for, but still grateful for the reply. Thank you for that.

@m_magalhaes said in Identify Critical Stop Please?: hello, For your next threads, please help us keeping things organised and clean. I know it's not your priority but it really simplify our work here. Q&A New Functionality. About the error it's related to FileName. But we need more information to help more. Be careful about the other thread, it may happen that we add stuff and the line will not refer to the correct DataType anymore. Cheers, Manuel Dammit! No wonder my code keeps breaking... I can't even follow simple forum instructions lol! But hey, at least I got it down to one link. Haha, progress! Yes, Filename, that actually makes perfect sense, so I'm pretty confident I've conquered this error. You're right that I shouldn't rely too strongly on those line numbers. Hell, the next bug fix could make that info obsolete, let alone a reference from years ago. But sometimes you can glean value from outdated info. Maybe in the future line 277 doesn't refer to Filename, but if that error pops up and all my Filename calls look to be in good order I might be able to make some guesses that increase my luck in identifying the issue faster. For instance, I might look at string or static text parameters first, thinking that like datatypes may have been grouped together in the source code. If 329 doesn't refer to baselink in the future I might start looking at in/exclude boxes or shader links first for the same reason. Maybe the list of datatypes in the description manual in the sdk is ordered how they are in ge_container.h and I can use that to choose my next lead. Shot in the dark type stuff, for sure, but maybe gets me generally in the right direction. You know what, this may have to do with me tracking down a weird behavior where Init() seemed to be the cause of every parameter invoking a MSG_DESCRIPTION_POSTSETPARAMETER message on any parameter change... but I have both debugging AND pandemic fog on my brain, so I don't even know exactly which thing I was doing wrong that may have been the culprit, so there's no point getting into all that... doesn't help that a VS Code update seems to like breaking my local git repo's randomly, so that makes reviewing previous code fun. In any case, the error hasn't popped up at all after ensuring all my base container calls were proper and there were no missing parameter initializations. Not that it was a readily reproduce-able error, just one that would pop up sometimes after a heavy testing session... so I had to do a lot of those to ensure it's really gone. But it does raise a question. Since the Filename object doesn't exist in python, what's the best way to initialize it? Docs say it's a string, but I saw something in a forum post that someone was initializing their filename parameter directly through the base container. I figured this had to do with how the python wrapper is internally converting the path to Filename object or something, so that's what I've been doing, but that WAS from 2013. So which is the proper way to initialize it? self.InitAttr(node, str, c4d.ID_FILENAME_PARAMETER) or data.SetFilename(c4d.ID_FILENAME_PARAMETER, "") And even if it's the former, do I set its default value through the basecontainer or in the normal way like so: node[c4d.ID_FILENAME_PARAMETER] = "" @r_gigante said in Identify Critical Stop Please?: Hi @kvb, with regard to the scope and purpose of the CriticalStop I warmly recommend you to have a look at: FAQ CriticalStop() Debug and Output Functions These pages properly explain how the CriticalStop is used in Cinema 4D, how it can be used in plugins and what to expect when it's hit. In you case, as already pointed out by @m_magalhaes , it's likely you're using a GeData::GetFilename() with a GeData whose type was not a Filename. Please recheck your code and if you don't spot the issue, provide us with an example or snippet to reproduce it. Cheers, R Thanks for the links. They'll come in handy on my next project, which will be in c++ (and I will be abusing the hell out of all the debugging options!). Could it have been caused by the filename returning None? Is that even a thing or just something I noticed while I was missing any initialization on my Filename parameter? I can't see it being anything else... unless an empty string could trigger that error? Thanks all! Kevin

It's actually due to a lower number of bits used to store the floating value.

@r_gigante Well ... this is embarrassing. I came up with the R21 code using notes I had collected over the years, and was rather confused seeing this didn't port over to R20. Actually the correct code should look like following: Bool MyUserArea::InputEvent(const BaseContainer& msg) { const Int32 dev = msg.GetInt32(BFM_INPUT_DEVICE); const Int32 chn = msg.GetInt32(BFM_INPUT_CHANNEL); if (dev == BFM_INPUT_MOUSE) { if (chn == BFM_INPUT_MOUSEWHEEL) { const Float wheel = msg.GetFloat(BFM_INPUT_VSCROLL) / 120.0; Int32 mx = msg.GetInt32(BFM_INPUT_X); Int32 my = msg.GetInt32(BFM_INPUT_Y); Global2Local(&mx, &my); ApplicationOutput("Mousewheel value @ at x=@, y=@", wheel, mx, my); return true; } } return false; } No need at all to perform a GetInputState to obtain the the x and y coordinates from, as the BaseContainer to get it from is already provided as "msg". And this works both for R21 and R20. Man ... sometimes you think you know what you're doing, and then it seems you just know squad. Embarrassing! Riccardo, terribly sorry for wasting your time!

Thanks @m_adam for the insights! Works like a charm!! Cheers, Lasse

@m_magalhaes Hi Manuel, Thank you for giving me some time to check this out. So after a bit of testing and changing the code to work with Cinema I cannot replicate the issue. As you mention it seems to be related to Pyblish. I did find interesting that when running the code in Cinema without Pyblish you can't see the active frame running through the timeline, while you do see it when running through Pyblish. Perhaps that's the correlation with the crash. I will close this as solve, for the fact that it does not crash in the Cinema context. Thanks again! Andre

I need to spend some further consideration since it looks like I was unprecise. When the BaseArray::Append() and the capacity of a BaseArray is reached - BaseArray default size is 16 elements - the internal BaseArray::IncreaseCapacity()is called and it sequentially allocates a new memory block, copies the values of the previous block to the new one, and then the old one is released. Being the values passed to the BaseArray::Append() a reference to myArray[0], it references the first element of the old block and because the code in Append() accesses the reference after the old block has been released, that access is illegal. @r_gigante said in Fun with maxon::BaseArray: To temporarily mitigate it you have to cast the value returned from the [] operator before appending it to the proper type. Actually by writing Int32(myArray[0]) - and here I was indeed unprecise because it is NOT casting but temporary local creating of a copy - a local Int32 copy of myArray[0] is made on the stack at first by the compiler (before calling Append) and then Append(Int32(myArray[0])) references that local copy which is legal. This behavior is NOT a bug - another initial overlook of mine - but rather a behavior by design which for example is also part of std::vector::push_back(). So, as a rule of thumb, cases where references to array elements are used while the array gets resized must be avoided. This note will be added to the BaseArray Manual in our documentation. Sorry for the confusion I initially generated and, if further clarification are needed, feel free to come back. R.

hello, I will consider this thread as solved without new information from you :) Cheers, Manuel

You're welcome, Manuel. Actually, I usually prepare all the textures and mapping to be in UVW mapping, when texturing is required. But, mainly, what I need is exporting geometry that is animated.