Skip to content

Conversation

@MeFisto94
Copy link
Member

Actually mind the comment that has been removed.
Earlier versions had the picker init in collideWith(), to bypass this problem partially, but I think this is the best solution (apart from making Picker cloneable, but it doesn't preserve "much" state anyway).

So: This would be a fast fix for 3.3 (cherry picking) and we can think about cloning later.
Actually the code has been written like that to allow for multiple terrain picker algorithms, where currently we only have Bresenham.

What would need cloning, is the field multipleCollisions of BresenhamTerrainPicker, but since most cloning happens when loading, this isn't critical.

Unless you prefer that we'd be doing things right right away and make the Picker Cloneable, for this I'd need guidance, though.

…a terrain from file still works (after cloning, the picker would have the wrong terrain quad instance)
@MeFisto94 MeFisto94 requested a review from pspeed42 January 18, 2020 10:02
@pspeed42 pspeed42 merged commit 81f9b9d into jMonkeyEngine:master Jan 18, 2020
@pspeed42
Copy link
Contributor

We can make it cloneable if anyone ever implements another picker type... I don't see that happening, though. At least now they will figure it out sooner.

@stephengold stephengold added this to the v3.4.0 milestone Mar 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants