Raycasting Help

I have been using the raycast extension provided here (http://community.stencyl.com/index.php/topic,16734.0.html) to provide coordinates for an instant-traveling projectile. It should be able to detect actors and terrain as well as their current x/y location. However, the coordinates it provides seems to be nonsensical.
It will detect regions correctly, and the debug line I have been drawing to determine where it starts/stops ends in the correct location when it first makes contact with it.

Code: [Select]

Source/scripts/ActorEvents_14.hx:473: [[B2Fixture,[Actor 0,LoadParkourTest],10,896,10,0,0.966777408637874],[B2Fixture,[Actor 0,LoadParkourTest],10,896,10,0,0.966777408637874]]
However, colliding with tiles is a tossup. Sometimes it will travel through several tiles, come out on the other side, and then provide the coordinates it exited the tile from...

Code: [Select]

Source/scripts/ActorEvents_14.hx:473: [[B2Fixture,[Actor 100000000,Terrain],704,639,10,0,0.366336633663366],[B2Fixture,[Actor 100000000,Terrain],0,639,10,0,1]]
...or just ignore all the tiles outright until it hits the edge of the screen, despite being adjacent to the tiles it just collided with and having no difference whatsoever in what type of tile it is.

Code: [Select]

Source/scripts/ActorEvents_14.hx:473: [[B2Fixture,[Actor 100000000,Terrain],620,0,0,10,1],[B2Fixture,[Actor 100000000,Terrain],620,256,0,10,0.666666666666667]]
If the raycast goes offscreen, the game crashes, even though it's set to end at the edge of the screen.
None of this is making any sense to me. This extension is several years old, so is it possible that it's too deprecated to work properly with modern Stencyl?

Tiles can be tricky to work with because the individual collision bounds of tiles are merged into larger polygons. Turn on debug draw to see where these are. There is a parameter you can use to compute the position where the collision occurs along the line segment from the origin to the end. I don't remember off the top of my head what that is. Do you have documentation for the extension?

Tiles can be tricky to work with because the individual collision bounds of tiles are merged into larger polygons. Turn on debug draw to see where these are. There is a parameter you can use to compute the position where the collision occurs along the line segment from the origin to the end. I don't remember off the top of my head what that is. Do you have documentation for the extension?

It's not much but yes. The block I'm using is the last one he describes.

This extension provides three blocks:

1. "first actor on line" returns the first actor hit on the line (the actor nearest to x1, y1). If no actor is hit, it will return null.

2. "all actors on line" returns a list of all actors hit on the line, in order of first hit to last hit.

3. "ray cast" returns a list of raycast results, in order of first hit to last hit. Each result is its own list containing:
   0. The B2Fixture hit.
   1. The actor the fixture belongs to.
   2. The x of the collision.
   3. The y of the collision.
   4. The x normal of the collision.
   5. The y normal of the collision.
   6. The fraction along the line at which the collision occured.

It's been a while, so I'm a little rusty--but I think the x and y of the collision would be the point where the collision was triggered, which may be inside the collision box. To get the point of impact, you need to use the fraction instead.

Let (x1,y1) be the point of origin, and (x2,y2) the second point in your raycast line. t is the fraction returned by the raycast. The point of impact would be at

Code: [Select]

x = x1 + t(x2 - x1)
y = y1 + t(y2 - y1)

You can test this by drawing these points and checking that the (x,y) point is located where you expect it to be.

I believe I'm formatting that equation correctly, but it still isn't doing what it's supposed to. The line still stops at random points (albeit different ones from before) and still travels through the same tiles.

If your camera can move, you have to subtract the camera's X/Y position from all of those XYs in the draw line block.

The camera for the scene in question is static; that shouldn't be affecting anything in this instance.

I could still use some help on this, I'm completely lost.

I'll bump this thread one last time, I'm not finding any solutions and the answers provided by merrak did not solve the issue.

Is this what you're trying to accomplish (image attached--yellow line is raycast from the light to the boiler)

I attached the code that generates the ray. A couple of notes:

First, be sure to check the actor type.

Second, to help debug, you may want to print a list of all of the bodies that the raycast hits. For tiles, if you hit multiple terrain group members (tiles), then you'll need to sort the list of collided bodies and pick the closest one (lowest t value).

The major difference between your code and mine is that your raycast is based off a static entity, whereas mine is being done from a constantly moving one, the player. The static values you have set for x2 and y2 don't work in my case. Trying to run what I believe is the corrected variation of your code crashes instantly.
To elaborate what I am trying to do, I need the game to constantly be checking where the player is pointing and marking the x and y coordinates of the first object in the player's line of sight, be it tiles or actors. As another side note, I am having issues trying to figure out the coordinates that should be entered if the player is looking at a 45 degree angle, as the x and y location of the line would be different from a simple check of the scene's height/width. If that's too much of an issue for this thread I'll make a separate one for it.

My x2 and y2 are only static because I just set that code up as a quick test. It would work if x2,y2 were moving every frame, since it's recomputed in the drawing loop.

Is RailgunCollision ever null? That would be my first thought why it might crash.

It has something to do with checking that item 1 in the list is a member of the tiles group. It runs fine without it, albeit still incorrectly (it's draws a small dot that's completely off on the player's position).