It's like it “cached” or just bypass some attribute value, but when I click inside the compiled block, force it to recook and the attribute value gets back. So weird.
Compiled Block lost some attribute value
1461 4 0
-
- EricSheng
- Member
- 159 posts
- Joined: 2月 2018
- Offline
-
- BabaJ
- Member
- 2048 posts
- Joined: 9月 2015
- Offline
I haven't used compiled blocks so I don't know for sure.
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.
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.
-
- Andr
- Member
- 900 posts
- Joined: 2月 2016
- Offline
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.
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.
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.
Edited by Andr - 2019年9月24日 13:26:19
-
- Andr
- Member
- 900 posts
- Joined: 2月 2016
- Offline
Andr
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.
Don't know if this is the case of the OP, but it's misconception that took me a while to figure out and it's important to know when debugging your compiled for-loop.
I've made an example to show it.
-
- EricSheng
- Member
- 159 posts
- Joined: 2月 2018
- Offline
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:
@pscale *= scale;
The problem will be gone if I replace that line of code to like this:
@pscale *= 100;
——————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.
Edited by EricSheng - 2019年9月24日 23:02:52
-
- Quick Links