Need to learn how to debug....

ichimitch

  • Posts: 52
I'm just trying to recreate old simple games to learn as I go.

This game has an issue that I seemingly can't figure out no matter how long I try...  Bullets sometimes lose all X and Y speed and stop dead in their tracks.  I've also noted that once this happens enemies can pass over them without collision.

I keep examining the code blocks but I'm at a loss.  Can someone give me some pointers on how to debug such things? And if gracious enough take a quick look under the hood to tell me what bad practices I'm doing?..

------------------------------------------------------------------------------
edit:
Extensions used are:
All in one Booleans - http://community.stencyl.com/index.php/topic,29132.0.html
Workflow Utilities - http://community.stencyl.com/index.php/topic,44968.0.html

« Last Edit: July 06, 2018, 09:18:15 pm by ichimitch »

merrak

  • *
  • Posts: 2234
I wasn't able to import the game. There are a lot of missing extensions. If you could please list them and links to download them then it'd be easier for someone to pick this up and look at it.

While not relevant to the problem you're describing, your "do every (random integer between 2 and 5) seconds" won't have the desired effect. Another way to think of a "do every N second" block is to imagine giving the computer the instruction, "start repeating this every N seconds". Once you give it that initial instruction, whatever value for N is set is permanent. See link if you want a variable delay.

I don't know what the purpose of the 'randomizer' is, but I might be missing blocks because I don't have the extensions you require.

General debugging tip: Use the print block and keep the log viewer open while you run your game. This is useful to test things like collision response code, where you need to figure out if your code isn't working or the collision itself isn't happening. Printing values of variables can also help you figure out what's going wrong.

ichimitch

  • Posts: 52
I disabled two extensions that weren't actually in use and reattached .stencyl the file.  I've edited the original post with links for the two extensions which are in use.

I also fixed the N timer issue that you pointed out to me. Thanks.

I wasn't able to import the game. There are a lot of missing extensions. If you could please list them and links to download them then it'd be easier for someone to pick this up and look at it.

While not relevant to the problem you're describing, your "do every (random integer between 2 and 5) seconds" won't have the desired effect. Another way to think of a "do every N second" block is to imagine giving the computer the instruction, "start repeating this every N seconds". Once you give it that initial instruction, whatever value for N is set is permanent. See link if you want a variable delay.

I don't know what the purpose of the 'randomizer' is, but I might be missing blocks because I don't have the extensions you require.

General debugging tip: Use the print block and keep the log viewer open while you run your game. This is useful to test things like collision response code, where you need to figure out if your code isn't working or the collision itself isn't happening. Printing values of variables can also help you figure out what's going wrong.

« Last Edit: July 06, 2018, 01:10:25 pm by ichimitch »

ichimitch

  • Posts: 52
Oddly, the problem with not shooting at 45 degrees was a problem with the computer I was using.  While testing on another computer there was no issue. The issue with bullets stopping mid-flight is still an issue, though. I'll edit the original post to line up with the facts.

I originally thought the issue with the bullets might be caused by using "last created actor" as periodically the last created actor may be an enemy, not a bullet. So I changed the code blocks for both the enemy and the bullet to no longer use the last created actor function but the problem persisted. I did try to use the 'print' block and view the console but I didn't find what I was looking for... I'll keep trying.

« Last Edit: July 06, 2018, 09:57:00 pm by ichimitch »

merrak

  • *
  • Posts: 2234
I'll re-download it when I get another opportunity (likely tomorrow). If noone else figures it out by then I'll take a look.

ichimitch

  • Posts: 52
I'll re-download it when I get another opportunity (likely tomorrow). If noone else figures it out by then I'll take a look.

Sorry to bug you, I follow you on Twitter and know you're probably very busy working on that Spokane Goat project (which looks very impressive). If you do manage to find a moment are you still able to give this a look? Nobody else has shown any interest...

merrak

  • *
  • Posts: 2234
Sorry to bug you, I follow you on Twitter and know you're probably very busy working on that Spokane Goat project (which looks very impressive). If you do manage to find a moment are you still able to give this a look? Nobody else has shown any interest...

Sorry, I got distracted and this fell off my radar--but I did take a look at your game for you and I have good news and bad news.

The good--I got it working and the solution was simple. In your bullet I made two changes:

1. Added the block "make self always active" in the 'Created' event
2. Added the event "when self exits scene" with the block "kill self", to prevent expired bullets from hanging out outside the margins

Now, the bad--I haven't gotten to the bottom of what was going wrong. It wasn't so much that the bullets were stopping, but rather collecting at some invisible boundary. I attached a screenshot with a lot of bullets so you can see the "wall" they're hitting.

Normally, when an actor leaves the screen, the engine no longer applies updates to it. This includes collision updates, hence why the bullets weren't colliding with the actors anymore. This is done to save CPU work. The block "make self always active" overrides this behavior and tells the engine to keep updating the actors.

Now the weird part is that the engine was considering the bullets as "out of screen" even though they clearly still in play. I'm not sure why--if there is a boundary set up or a bug in the engine. It seems to me that if this was a bug, it would've been found earlier, as fundamental as collision detection is and how many people use it. It'd be interesting to hear if anyone else has ran into this kind of problem.

In any case, whenever an actor is totally nonresponsive to anything, it means the engine isn't updating it--and adding the block "make self always active" will usually solve your problem. Just be sure to kill the actor when it's no longer needed so you don't have a bunch of actors clogging up your update loop.

ichimitch

  • Posts: 52
Thanks for taking the time to look at it.

I set the off screen bounds for the enemy character.  I wanted them to be able to slightly exit the screen before bouncing off the edge and changing direction. Do you think that may somehow be effecting the bullet?  Perhaps it has effected the entire scene rather than just the desired actor.
 
I normally do set actors to be killed off screen but somehow missed it this time... Thanks for picking that up.

« Last Edit: July 14, 2018, 01:37:49 am by ichimitch »

merrak

  • *
  • Posts: 2234
Interesting. When I get a chance I'll look at it...on my phone now. I didn't notice it earlier but the width and height of the "invisible wall" do appear to be the same size as your actors.