Hi,
has this been addressed in R23 SP1 release?
Cheers,
Andreas

I somehow doubt this is an issue that could be solved by changed priority.
The Python tag is executed once during the execution of the scene (lets leave exceptions to this rule aside for now). Regardless of priority or exact execution order, the tag's code gets executed once. With priority you can change the point of time of this one execution or change the order of the execution of all entities contained in a scene.
But in your Python tag you do modify the scene by changing the two links. And then you want to have the result of this change a few lines later. But nothing has changed so far. You have only changed a link parameter of two instances in the middle of C4D evaluating the scene entity by entity. In order for the Loft to change it's size, the Loft needs to be executed. But when you read the size, it's still the Python tag being executed... you get where I am heading?
I don't think, what you are trying to do here is possible with a single Python tag. Instead do it in two. Have one assigning the links. The other places the cube based on Loft size. Then you can use the priorities of the tags to make sure, the execution order is as follows:

1. Tag "Set Links"
2. Loft (actually this implies execution of the instances beforehand)
3. Tag "Position Cube"

Cheers

Good catch, I fixed the post.

No, you didn't upset me. And I may have been a bit short, asking for actual errors.
For me the latter indeed is an important point. You will help yourself a lot, improving the information contained in a question. For example when talking about errors, but not providing any information or details about the actual errors. On your journey into C4D development and Python programming the Console is your friend and more often than not it already contains good information to solve an issue (and even if messages therein seem to make no sense, they may mean something to others). If I have been too harsh, I apologize, but also please try to view it from the other side. The people wanting to help, spend time for this. Having to ask the same questions again and again, just to find out what the actual question or problem is, is just time lost. For the one wanting to help simply lost and for the one asking it only takes longer to get the desired answer. On top assume, there may be multiple people wanting to help, so parts of this equation even multiply... so asking good questions, will help you reaching a solution in shorter amount of time and save time on side of those helping, which in turn will increase chances to get help at all.

I hope, you don't get me wrong. Really in this case it wasn't a big deal and it was probably my fault, to just insist on an error message without further words. Sorry for that. And the above, while addressing you, you should actually rather read as a hint to everybody asking questions on any forum.
In a nutshell, if you are having a problem, try to help other people help you.

And please keep asking questions. It's the best way to improve as a developer. Believe me, I know, what I am talking about. Looking at my code should be evidence enough, I asked way too few questions...

Cheers

@mogh It looks as if my reply this morning somehow got lost. I basically asked, what errors you get exactly?

???
So, what are the errors?
I have none...

Hi,

I only briefly scanned this topic, but I have a few thoughts and questions. Simply ignore me, if I talk rubbish as usual...

Does this problem occur with every shader that supports subshaders or only a few? Does it happen with the layer shader as well, for example?
If I remember correctly BaseLinks work only correctly (especially in AliasTrans context), if the linked object is a valid member of a document (e.g. in a NodeData for example via branch. Now, if my mind doesn't trick me, there are certain shaders, which do not properly hold there subshaders in the shader tree. Which caused me all kinds of issues, when trying to initiate shader updates from a NodeData and I ended up with special code for certain shaders (I think, it were mainly those stemming from good ol' Smells Like Almonds shaders), basically extracting the subshaders from their parameters.

And another thought, maybe you already tried and I overlooked it in this thread: Does using ForceGetLink() change anything for you, when trying to resolve those links? If I'm not mistaken, C4D also resolves links beyond a document's context with this.

Cheers,
Andreas

how would I implement your code in python 3.x (R23)

Not sure, what exactly your problem is. I'm currently using a simpler version of above code in C4D R23 and it works for me. Well, I build the string a bit differently and the print is also written differently in Python 3. But this doesn't seem to be your problem.
I'm aware there are parts of time module deprecated in Python 3, but... I mean, deprecated doesn't mean it's gone, only that it will be gone some time in future. And as I use it as a debugging tool, I don't care too much for the moment. The code is not meant to stay in my projects.

Can you post an error message maybe? I'm too lazy to test that exact version now.

I have been following this topic in all three (!) forums since beginning and I'm really looking forward to the outcome of this topic.

I'd call myself quite a Matrix mutant, so just ignore me, if my question is completely off topic or bogus in this context. My expectation would have been the same as @Cairyn's.
Yet, there has always been this last sentence on the Matrix fundamentals page, which reads pretty suspicious to me.

[Local Matrix] = MatrixMove(op.GetFrozenPos()) * HPBToMatrix(op.GetFrozenRot()) * MatrixMove(op.GetRelPos()) * HPBToMatrix(op.GetRelRot()) * MatrixScale(op.GetFrozenScale) * MatrixScale(op.GetRelScale())

Please note that the both scales are applied at the very beginning, so the local matrix is not the same as [Frozen Matrix] * [Relative Matrix]. This is necessary in order to guarantee that your local matrix always stays a rectangular system; distorted sy

I'm not questioning the correctness of this sentence. I'm just wondering if it may be related to this issue? And if one would maybe need to separate the scale from the equation and calculate it in correct order?

@zipit You are right. Forget my comment. I shouldn't have posted before my first coffee. Indeed I was triggered by the dialog not being closed, but then brain activity obviously went back to power save...

@zipit: Actually I wouldn't consider your code a solution to the problem. This is something, though I'm aware it's done quite often (and at least for quick tests I used such code myself for sure), that's a bit dangerous and most likely not supported by Maxon. The context owning the dialog, which is used to defer the status bar updates, does no longer exist after the execution of the script. It's basically a a zombie dialog performing the status bar updates. In my view, such code shouldn't be recommended, nor be used in anything that's released to the public.

Edit: While it's no good practice to leave a dialog open after script execution ended, my comment was wrong and stupid.