Collisions use to work what did I do

Hey Snail,

Considering more options for sure, thanks for that! :)

I think the problem is you don't know what you don't know, haha. I had no idea that Clickteam Movement Controller was using integers. I just assumed since this was my first small game, that the problem was my knowledge and I needed to figure it out. I'm not sure I would have ever put together the "why the missile sometimes misses" with "I'll test the angles to see if they are down to the decimal for improved accuracy". The Clickteam Movement Controller did have a help file that I read through, and for the Vector section it stated:

Quote:

---

Direction: The direction (or angle) the object will initially move in, value is in degrees.

---

It should probably state "...value is in whole integer degrees". Oh well, lessons learned.

Alterable Variables...

Quote:

---

Click your object
In the Properties pane, click the "A-Z" icon (variables)
Under Alterable Values, click "New"
Double-click "Alterable Value A" and then rename it to whatever you like

---

Yeah, I basically right clicked to add an event (under the missile object), went down to Alterable Values, saw "Set", "Add to", "Subtract From", "Spread Value"... and started thinking, umm...how did he create new ones in his list? It never occurred to me they could be added / set on the properties of the item, otherwise, why have A-Z available right? lol. Oh well, another lesson learned.

Thanks for sharing the reasoning on the distance variable. I thought to myself...why do that, isn't that intensive mathematically / cpu wise? I'll have to search around for the Move Safely extension examples to see how to implement that one. I did try your example and changed mine up a bit. It works pretty good, it still misses a couple times (not nearly as often as before), but I think its because the missile comes out always pointing at 3 oclock, not like before where it was in direction of turret. I'll have to see what I'm missing because I assumed (incorrectly obviously) that the targetAngle variable was being used to store the angle at which the missile needed to leave the turret at. Apparently its not, or it is and I just implemented it wrong. Its not visible in your example because both Active and Active3 are just small squares.

As far as methods, I'm in to what is "accurate". So if it takes 10 lines of code / events / conditions to make it hit the X, I'm gonna do it. If its a simple solution, I won't make it harder either though, lol :D

Thanks again for your thoughts! I'm gonna take a look at the Move Safely and also tinker around and see why the missile's angle is still stuck.

Thanks Snail,

I went as far as I could without looking at yours haha. I increased my aim point and set the angle, still misses sometimes. So I'm putting in the objDistance as well.

Thanks again. I think yours is interesting, I had never known how to use loops, but its fairly simple. Looks like a GOTO type of function to keep redundancy down. I like the checking off screen by using negative pixels, never thought of that either. I'm tweaking mine to be a bit more efficient based on some of the things I'm learning, so many thanks.

As far as the speed of the conditions, I would assume they are about the same. If I remember correctly, I think it evaluates all conditions from outside parenthesis towards the center, testing the AND last. However, since the objDistance is a value, it would return faster to simply compare numerically rather than using the Range() condition which it would have to look that function up and read / execute it. In my game, probably a few milliseconds difference, but over time and bigger the game, the more it would differ for sure.

I am a bit confused though on your usage of the ParentId / fixed call... I see what you're doing, but I don't know how those functions / values are being tracked / called / executed. The other value that seems difficult to understand is the alterable one "xPoint" / "yPoint". I kinda get what they are for, but they are being used in the AdvDistance functions where I wasn't expecting them... so seeing how they are initialized and used doesn't exactly follow.

Any help there is appreciated as this all helps me make the collisions more accurate!!

Lol... figures...

After pretty much rewriting a lot of the conditions to implement some of the things I learned I have a bug I can't figure out...
Its because of the parentID / fixed relationship I'm pretty sure. So when the collision, or better yet, when the missile is less than 4 pixels (I rewrote it to detect if its close, then to go to the remove target loop instead of doing the collision detection like it was), now all the missiles go to the destroy instead of just the one that is close to its aimpoint.

This is where my lack of understanding of that parentID / fixed values hurts because I'm not able to troubleshoot it since I don't know how it works :(

I'm assuming the math is working since the explosion animation starts at the right spot and the missile and aimpoint are destroyed. However, fusion must've assigned all the missiles the same parentID, or why else destroy all the missiles and aim points on the screen instead of just the current missile that is close to its aimpoint.

Just not sure how to fix, lol...help :)

https://www.dropbox.com/s/bmgou3okt1...mmand.zip?dl=0

Oops, it was an older version, haha. Apologies. Here it is. Been looking at it for a while, still cant figure it out, pretty strange.

https://www.dropbox.com/s/bmgou3okt1...mmand.zip?dl=0

Thanks for the explanations, especially on the parentID. Still a little confusing only because I haven't used it enough, so it may take some time. Its like describing to someone an automobile who lives in the 1500's... they would eventually understand what your saying but not really get it until they see it more and drive it many times.

This comment was interesting:

Quote:

---

When a missile reaches its target (xPoint, yPoint), you have to loop through all missiles in order to find each one's corresponding target object (on each Missile AND parentID("Target") == fixed("Missile") >> destroy Target).

---

It seems to me that is more difficult / cpu intensive if I have 20-30 missiles, rather than just detecting if a missile collides with a target... I guess what I'm getting at is that I see it more of a unnecessary complexity, and probably will for a while until I use it more. I'll continue to use it so I can understand it more, but for now that's my view :D

Ahhh... I see. I already had the destroy on the loop "remove target", and the condition for going to that loop was met when one of the missiles was within 3 pixels of the aim point... So in essence, I was destroying the aim point on line 30, then it went to remove target function (line 32), where it was removing the aimpoint and missile, causing the unwanted behavior. Sweet, I think I'm understanding the loops better, I'll keep implementing them whenever I see repetitive calls, thanks for the tip.

I see what you are saying on the cpu usage and complexity, so thanks for that additional explanation. Here is why I thought it was about the same, food for thought. So see what you think (for collisions)

--Collision Detection method (my original way)
Frame 1
...
CPU tests for all missile / aim point collisions (i.e. 10 missiles 10 aim points)
...

Frame 2
...
CPU tests for all missile / aim point collisions (i.e. 20 missiles 20 aim points)
...


---Missile Range Detection method (your cooler / cpu saving way)
Frame 1
...
CPU creates objDistance variable, stores initial distance from aim point in variable
CPU re-calculates missile range variable objDistance in pixels as it moves
CPU test all missiles where objDistance <= 3 (i.e. 4 missiles 4 aim points)
...

Frame 2
...
CPU creates objDistance variable, stores initial distance from aim point in variable
CPU re-calculates missile range variable objDistance in pixels as it moves
CPU test all missiles where objDistance <= 3 (i.e. 8 missiles 8 aim points)
...


That's what I thought about in my head when I say its more complex lol. To me the second way IS using less CPU, but more complex in coding / debugging... at least it was to me at first :) I mean, I get it now, and it makes sense, I just never thought of it like that. It seemed simpler to just say "hey if any collisions occur", rather than "create a variable to track distance between the objects", "recalculate that distance every frame", "destroy objects when distance <=3". I like cool stuff like that though, where you basically make your own "collision detection" method and are able to squeeze out more CPU power!! :D

So thanks a bunch bro for the explanations! You've definitely given me ALOT more tools / methods to code my games more efficiently!

Snail i have a crazy question :

Why Set X pos to Xmouse +0.0 and not Xmouse alone ??