Attaching colliders to kickables?

[Robert The Rebuilder]

When I tried using that method, the age crashed.

[Christian Walther]

Hmm, I just thought perhaps it was the parenting that caused your crash. If you also tried it without parenting, then I don't know what the problem is.

[Robert The Rebuilder]

After trying the "collider-for" property again, It turns out the crash was due to the parenting. Without parenting, the age works fine.

Well, I'll posit that this change is not superfluous - in fact, I'll offer it as a replacement to the "collider-for" property. The relationship of arbitrary collider geometry to the visual object is a parent-child relationship, as evidenced by the Cyan ages. The collider-for property completely eliminates the collider scene object and its coordinate interface, which deviates from Cyan's style. Plus, it adds an unnecessary property; why not use the built-in Parent field? Finally, "collider-for" does not set the transform flags present in Cyan's colliders.

[D'Lanor]

Neither method seems logical to me. Robert's way would have been perfectly intuitive if the parent was the collider and the child the visible object. Is it possible to reverse it like that?

[Robert The Rebuilder]

I guess I can see your point, D'Lanor: having an ethereal object (such as the visuals) being the parent of something substantial does seem a bit backwards. However, for Cyan items with a different collision geometry than the visuals, that's how they do it. They are hard to find - some examples are the baskets in Gira and Teledahn's slave caves. But a lot of kickables use a convex hull around their visible geometry (e.g. sticks and stones in Relto, bones and boulders in Teledahn slave caves), which seems like a waste to me.

[Christian Walther]

I have tested this and it appears to work fine. I can see no difference in behavior between kickables created using parenting (the new method) and using collider-for. Unless there are any objections, I will merge this to the trunk when the SVN server comes back up (if it hasn't already been - my latest update is r416). Robert, that means that I would expect you to provide some documentation for the release, is that OK with you?

[diafero]

Perhaps it would be better to make sure we have only one way to do this? Or, in order to prevent confusion (and code duplication), at least let the two possibilities do the same, as in have exactly the same output?

[D'Lanor]

at least let the two possibilities do the same, as in have exactly the same output?

I don't know about that. If Plasma has different methods to achieve something we should be able to use both.

The documentation should mention both methods and explain the difference between them.

[Christian Walther]

I vote for keeping both too. The collider-for property should stay around for backwards compatibility, and I'd rather not change it to do the same thing as Robert's parenting method, because, as far as I understand, it generates simpler PRP output, which may turn out to be an advantage, even if it doesn't match what Cyan does.

[Robert The Rebuilder]

Sounds good to me, too. Now I just gotta figure out where's a good place to document both of these...