I would try simplifying by cutting out the for each and avoiding UID, two common sources of problems. You probably don't need the array either.
Try using "pick nearest hrrrn to player.x player.y" in place of the "for each hrrnn" underneath the overlap condition. From then on in this event, only that hrrnn will be affected by actions.
It is somewhat complex, but I believe that is because the original tutorial that I was working from was designed to detect collisions as accurately as possible when firing a continuous ray through a series of targets with complex motion. I downgraded it somewhat to fit my simpler needs. It's probably true that I could stand to simplify it, but I'd like to try to get it working first, if for no other reason than just for the practice.
I tried using "pick nearest" in a function that I'd written before, but it never worked well. Using it just on those objects that satisfy the overlap condition, however, would probably work as intended. I'll give that a shot later.
No thoughts other than that looks complex. It probably doesn't need to be.
The idea I presented basically points a sprite in a direction and increases it's width until an object is hit. That gives the hit object and a point of collision.
Yours seems to set the sprite to be full length first and then add all the overlapping objects to an array, then loops over the array in some way while shortening the line by halves. So I'm guessing some kind of binary search? I guess I'd have to look at the tutorial you reference. My guess is the issue may be the order of the sprites, but really there is no way of knowing without something to test.
Yeah, the logic behind it is a simple binary search. That's why I latched on to that tutorial in the first place—it was very familiar to me. In the other game software that I've used in the past, I had written a very similar function for both bullets and beams that determined the exact position of impact by casting a line, checking for collision, halving the distance, and repeating until I got the position of the impact to within two pixels of the object. Then I'd spawn a "collision" object at the end of the ray that actually handled the post-impact processing (incidentally, I'm going to skip that step this time around, as I never did like having to rely on that "third party object" to do the processing). I'm totally unfamiliar with Construct 2, however, and, additionally, its event-based system is something that I haven't yet gotten used to. I was finding it difficult to port the functionality from the old procedural approach to the new event-based one.
I'm gonna give a few more things a try, but if I can't seem to get it to work right, I'll upload the file and ask if folks can take a look at it. If necessary, I'll switch my approach. Really the only reason I haven't uploaded it yet is because I had already added the tons of sounds and music that I already had laying around to the project which, when packaged into the .capx made the file size somewhat ridiculous for what it was. I'll have to yank all that back out so that people won't have to sit there and wait for a zillion megs of sounds to download just so they can test a few lines of game logic. Heh.