Need help working with bullets [Resolved]

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.

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.

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.

I've completed simplifying and testing the function. Below is the pseudo-final version of my game's shooting code.

This function works exactly as I desired. It's called only once per "shot," it selects only the target that is first "impacted" by the ray, and it properly sizes the visual representation of the bullet to stretch from the muzzle to the point of impact. From here, more post-processing could be added easily, and adding in an "accuracy" variance (as I plan to do later) could be done simply by altering the initial angle of the projectile object (Bullet2 in the example).

The function could be (and probably should be) generalized using Families instead of specific objects (as was done in the original tutorial I scavenged from the Internet).

The base complexity of the function should be minimal. The actual logic itself should have base complexity of log(base 2)(n), however, since the repeat command is used, it degrades to (n) complexity—but, that shouldn't have a very big impact on performance. Even if it did, the number of iterations could be reduced without much consequence, as that part of the function is strictly for aesthetics (since the target of the impact has already been decided at that point, functionality wouldn't be impacted at all).

I left in the additional function parameter from the tutorial I used in case I need to identify specific bullets later as the game progresses. In the example shown above, that parameter is not used.

I'm calling the issue resolved. I'd like to thank everyone who took the time to offer their insight during the thread, and also the author of the raycasting tutorial I found on the site, which, again, regrettably, I cannot directly link to because of my lack of forum reputation (Lightning-fast-raycasting by sqiddster).

I've managed to learn a ton about Construct 2 during this process, and I look forward to pestering you all again when the next issue arises.

I hate bumping a resolved topic, but I wanted to add one thing:

I changed the [Repeat Function.Param(2) times] condition to a [While; Increment > 2] condition, and it seems to have improved the overall complexity of the function as a whole. Rather than executing the sizing loop a flat number of times, it should execute at most ten times (assuming MaxRange is 2,000).

Again, sorry to bump a resolved thread, but I wanted to throw that in there as a theoretical optimization.