Forum Replies Created
-
Posts
-
It can also be the rights on the output folder or file, or more simply on a temp folder. Another reason could be that the output folder does not exist (some functions misattribute this error sometime, dunno why).
In any case, you can to rexec with sudo, this should tell us if it really is a permission problem, or if it is something else.
Same problem on 0057a0cfd3d3fb6b9b3cdb00ca22eae4c17ae384 (so before attachConstraint split with
rootNode.createObject('AttachConstraint', object1="@M1", object2="@M2", twoWay="true", indices1="144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159", indices2=" 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15", constraintFactor="1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1")Result is not physically plausible. Points of junction seem to be “heavier” than the others. They then gain speed, and the whole thing turn into a windmill. No crash.
You can compare the results using the commented section in the scenario of the initial post (section # This does not work / # Works)Log does not provide any useful information other than INFO messages (loaded plugins, etc).
However, we just realized that a 3 months old master (I don’t have commit id, i’ll try to provide one) can run this scene with the correct result, so this does look like a bug now.
Can you explain what you meant with
you have to specify indices1=”@../M1/np1.indices1″? I’m actually specifying the indexes that way, the values in the inspector are correct.
