Ah, I think that I see now.
I think that what is happening is this: when a collision event is called, a collision-entry is passed as a parameter to the method being called by the event–in this case, the “print” function. This collision-entry contains various pieces of information about the collision.
As a result, the “print”-function is getting not only the text that you provide, but also the collision-entry, and is thus printing both.
If you want this to not happen, I suggest creating a new function to be called by the collision-event, one that accepts a collision-entry parameter, but that doesn’t print that collision-entry.
Okay, going back to your original code, I see the problem occurring now.
I think that what’s happening is that, because the ray isn’t being moved out of the target-object, it’s registering as continuing to collide the whole time, even between clicks. So when you click the second time, the ray doesn’t collide anew–it’s merely still colliding. That means that, instead of generating “in” events, the system is generating “again” events–and you’re currently only accepting “in” events.
This, I suspect, is another thing that might be fixed by switching to a CollisionHandlerQueue instead of a CollisionHandlerEvent.
If you really want to use a CollisionHandlerEvent, however, then you can perhaps work around the problem by setting the ray’s “from”-bitmask to be zero at the end of the “click” function, and setting it to be one (or some other value as appropriate) at the start of the function. That way the ray will no longer be detected as colliding between clicks, and thus any collisions found as a result of clicks will be registered as “new”, and thus “into” events.
Fair enough–it seems that I misunderstood the original problem, and I wasn’t aware that you had already implemented the use of your own traverser. My mistake!