There was a bug with collision and scaling in the 1.6.x line, and it was even mentioned in the manual. Is this fixed in 1.7, or is there a plan to do so? It’s really hard to make a map work with this getting in the way.
What bug are you referring to, exactly?
I don’t know of any bugs with scaling, but I do know of a design limitation: non-uniform scales are not supported by the collision system in general, because they change the shape, and therefore the math, of collision surfaces. There is no plan to “fix” this, because it’s not really a bug.
Uniform scales should generally work, though it is usually more reliable to flatten scales down onto the vertices whenever possible.
I think there are probably some bugs with the CollisionBox type solid. This solid was implemented by an student over a summer and wasn’t very robustly designed, so it has more bugs than the other solids. If you’d like to address some of these bugs, we’d be happy to accept your patches. 
David
Yes, I meant collisionboxes. I have an example of the bug in the following thread:
panda3d.org/forums/viewtopic … highlight=
(Blendfile included as well.)
It seemed to me that it was very sensitive for the scaling.
I don’t know however what you mean by non-uniform scaling? (actor and barrier being of different scales? I definitely would need that.)
Anyway what do you recommend in the current state of Panda to use instead of collisionboxes? (e.g. for walls)
UPDATE: in the linked example I was using collision Polygons, not boxes.
By non-uniform scale, I mean a different scale in the X, Y, or Z axes, as opposed to a uniform scale, which is the same scale in all three axes.
CollisionPolygons should be perfectly workable.
Note that collisions in general are a complex problem, and no collision system is 100% robust. I personally think the Ralph code is not a very good example of using collisions; its strategy of checking under your feet for a ray collision, and repositioning back to the last known floor position when no floor is detected, really only works for very simple environments.
For more general environments you might need a more robust approach. The CollisionHandlerPusher works pretty well in general; and the CollisionHandlerFluidPusher is even better. Neither works in all environments, though.
Some things to avoid in particular are (1) acute angles, or especially tight corners, and (2) back-to-back polygons that are very close together (closer than a few feet or so, depending on the speed at which your avatars can move).
I’m not aware of any particular problem with scales, though. Even if there were a problem with scales, it probably wouldn’t apply to scales applied within Blender, since those will usually be flattened out automatically during conversion.
David
"For more general environments you might need a more robust approach. The CollisionHandlerPusher works pretty well in general; and the CollisionHandlerFluidPusher is even better. Neither works in all environments, though. "
The problem was that 3 walls worked perfectly (same size), a one none at all. It was not some kind of floating point instability.
OK. I don’t know the specifics of your situation, though this is the sort of behavior you can get with the Ralph sample code. It’s not related to floating point instability; it’s mainly a question of how well the handler code deals with multiple collision events coming simultaneously from different directions. This is why I advise against acute angles and back-to-back polygons, because both of these can cause this sort of conflicting collision problem.
The pushers, in general, do a better job (but not a perfect job) of handling this sort of problem, which is why they are better for arbitrary geometry.
I don’t know what kind of geometry you’re creating, or why in particular it’s not working. I’m just reporting my own experiences. The Panda collision code is generally robust and reliable within its parameters.
David