Collisions use to work what did I do

[wiggy]

Hey CT Community,

So I was working on my missile command type game to learn CT Fusion, and I took a week off. I come back, start adding some stuff, try it, and now I'm chasing bugs that didn't exist. So it must've been the code I added right? Well, I restored a backup from last week to make sure, and it was there too. So now I'm thinking some windows update did this, lol... But seriously even my buddy who played the version from last week was shocked and asked what happened...
Anyway, I uploaded the mfa below. But the 2 new bugs that didn't exist before on the Level 1 frame are:

1- On line 10 of the Event editor, the missile_counter now subtracts 2 every time you fire a missile instead of 1.... why?
2- On line 21 of the Event Editor, the destroy call for the missile upon collision of the aim point no longer occurs....again, why?

Also, let me know if there is a better way to troubleshoot these kinds of issues. I basically deleted the 2 conditions listed above, then re-added it to see if that would fix the problem, but it didn't. So since I don't know how to debug the problem, here I am

Please help me know how to troubleshoot this!

wiggy

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

[Klownzilla]

I'm on my phone right now and can't check but did you add "only one action when event loops" on the condition when the game subtracts from the missiles? :-)

[Sparckman]

Hi there wiggy,

check out this example

missle_command.mfa

[wiggy]

Thanks all for the replies!

@Klownzilla Yes, but even if I take it out, the behavior is a bit worse, 5-6 missiles fire at a time.

@Sparckman - Haha, yeah, I found your posting of that when I was doing a search for something else. I'm trying to learn how to do it without "cheating" by looking at your answers. But thanks, I think I'll have to look anyway if I get stuck on this for a while.

@Snail - Omg... It looks like I somehow copy / pasted lines 10-12 again at the bottom... typing too fast perhaps? So embarrassing, lol. As far as your other suggestion, I'll have to remove the ClickTeam controller and try something else I suppose. What is the best method if the CT controller is not?

Thanks again!

Wiggy

[wiggy]

Thanks Snail,

First, thanks for the example, that REALLY helps me understand. Several red flags come up when I look at your example and your thoughts:

1.) I'm a bit amazed at the amount of code differences. It takes ALOT more of the math / code to get the Active3 to follow the correct path than Active (which was similar to how I did it). This makes me a bit uneasy, worrying that this is my Achilles heal. That unless I can become a trigonometry professor, I may not have a 100% solution and be stuck with a 60% solution like I have now... I'm not sure how to fix that other than just posting questions and hoping someone can answer when this happens in the future to other games I make.

2.) I only used the Click Team Controller because I found highly recommended in another post. But your solution is using another / different extension manager. There seems to be thousands of them, so two questions. One, how do I know if one is gonna work for me, just try each until one works? Second, looking at your code, you have several methods such as VEC_DIR(), AdvDirection(), etc.. Without loading the extension and then right clicking on it to see every available method, is there a help file or some other document that tells you what methods come with the extension so I can know whether or not a method (such as AdvDirection()) exists and will even be worth trying? Hope that makes sense.

Other than that, I'm gonna try some of your solutions tonight and see which one is the easiest that I can still understand. I want to be able to change stuff if needed, and I can't do that if I don't know whats going on, lol.

Thanks!

wiggy

[wiggy]

Almost done reading all your code, and I'm understanding it pretty good. It makes sense, just a few questions.

How did you create baseSpeed, targetAngle, and other new alterable values in your list? I did a quick search, no titles for "How to create new alterable values".
Second, I noticed you have 3 lines with always. Would it not be cleaner / easier to have 3 events listed on one "always" condition, rather than three always conditions for each event separately?

Just trying to learn and understand, thanks!

Wiggy

[wiggy]

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:

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...

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

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.

[wiggy]

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!!

[wiggy]

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

[wiggy]

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:

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