Closed jarllarsson closed 9 years ago
So even if it's always the same params getting fed to controller 0, we always get different results. Unless we never perturb the params after the first run. With no perturbation, the same params are fed as well, but then we get deterministic results. WTF! :poop:
Seems to be a problem with controllers writing to each others torques. Or something like that. More than 1 controller in optimization mode with perturbation off gives a different result compared with only 1 controller.
Happens in normal mode as well.
Getting these results when not running VFs, and only PDs.
Same result when only running VFs and not PDs. However, the applyNetLegFrameTorque exhibits these problems on its own as well. Next I'll try the prev. tests to run without it.
Getting non-det results with that off as well. So I conclude that either all three torque manip-funcs are incorrect or theres is another source for the error.
So I've more or less concluded that the fault is not bullet's. At least not immediately in the sense that spawning more rigidbodies have an effect. I've now isolated the creation of components in further characters when creating more than one, and I have to take this isolation back one step at the time and test for 1 and 2 characters(controllers).
Seems like it is the handling of explicit rigidbody collision checks. If I disable CHECK_FOR_COLLISIONS on the feet it seems to be giving me the correct results. Will try this in optimization next as well.
solved
The first controller which should receive the winner params and get the same score as it achieved last time, does not behave in the same way.