Andr
if u disable or bypass the compile block does the pscale reset to 0?
There's the chance that u are resetting the pscale by mistake and then you are seeing a previously cached version when checking the nodes inside the compile.
My understanding is that with compile blocks it's tricky to see what's going on inside, even when you force compile.
When I need to check the attribs of for-loop iteration inside a compile block I always double check the values by hitting the “reset cached pass” button of the for-loop end node.
BabaJ
Some nodes can't be used in a compile block.
I am wondering if you have a node in one of your sub-nets that has one?
I remember seeing but forget how, there is a way to ‘see’ if a certain node can be used or not.
Maybe someone can show how to check, if this is the creating the issue.
As far as I know it should throw an error if you use a non-compilable node, but maybe not if said node is inside a subnet.
If you press ‘D’ on your network editor, you can select to show the badge for non-compilable nodes.
Thanks for your reply:
It's not because of the non-compilable nodes, I've turned on the non-compilable badge, and the Compiled Block will throw errors if there're non-compilable nodes in it.
Actually I've tracked a line of VEX code cause this problem, like this:
but I just haven't figured it out yet.
The problem will be gone if I replace that line of code to like this:
——————update——————————–
The “scale” variable is coming from a float array in detail attribute, it seems like this will cause the problem.
—————— update final ———————–
Finally, I find the problem is caused by my height is generated by Python:
and it remains in “default state”, and when it be compiled, it won't run the python code, so the value will be 0 I guess, It's really a rare case I think.
Just change the default python code to assigning the value will solve the problem.