Recycled actors acting awful

NobodyX

  • *
  • Posts: 1228
It won't let me upload an example game right now, but:

I made a game that has cannon-things that shoot recycled bullet actors. For some reason some recycled actors get messed up so that they don't get shot out, as if something is making them disappear the moment they get recreated.
Attachment 1 shows the cannon shooting bugs, each time a bullet hits a bug it gets recycled, and the bug also gets recycled. For some reason as the bugs are getting shot at the recycled bullet actors get messed up and don't reappear properly, which leaves gaps (attachment 2) in what is supposed to be a steady stream.
But the bullets don't act funny when they hit the wall.

Earlier today I've had the bullets so that they have a behaviour that recycles them after a short time, in addition to the behaviour that recycles them when they collide. When the bullets had nothing to collide with then it would be a steady stream until they run out of time at the end then disappear (how it's supposed to be). However, when there was an obstruction in the middle of the stream which recycled the actors earlier than the timer, the newly recycled bullet actors would disappear earlier in the stream, as though the countdown variable wasn't being reset properly. Even after the obstruction was removed, some actors would continuously recycle themselves early.

When using recycled actors for big effects I would notice that, when they were recreated, for a frame or so I could see them flash in their old position before appearing in the proper place.

« Last Edit: May 18, 2011, 09:57:26 am by NobodyX »

NobodyX

  • *
  • Posts: 1228
OK, here's an example game of the disappearing bullet problem. After the bullets hit the bugs then the bullets don't respawn properly afterwards. If there are no bugs then it works fine. It's supposed to be a steady stream but some actors go missing.
http://www.stencyl.com/game/play/2162

The behaviours are dead-simple, so I know it's not my fault and that something IS broken.

Alexin

  • *
  • Posts: 3130
Actually, an example game we can open with SW would be better.
"Find the fun"
alexin@stencyl.com

NobodyX

  • *
  • Posts: 1228
Well, I figured someone would say that, but it's part of a larger game that I don't want to share with everyone.

I think I read that if I upload it privately then the important people can still access and download it if they want, is that true? Would uploading it to Forge privately be sufficient?

Alexin

  • *
  • Posts: 3130
Administrators have access to private resources, yes. Alternatively, you can make a smaller game, just for the purpose of testing and debugging.

Don't forget to tell where to start off.
"Find the fun"
alexin@stencyl.com

Epic428

  • Posts: 1118
Earlier today I've had the bullets so that they have a behaviour that recycles them after a short time, in addition to the behaviour that recycles them when they collide. When the bullets had nothing to collide with then it would be a steady stream until they run out of time at the end then disappear (how it's supposed to be). However, when there was an obstruction in the middle of the stream which recycled the actors earlier than the timer, the newly recycled bullet actors would disappear earlier in the stream, as though the countdown variable wasn't being reset properly. Even after the obstruction was removed, some actors would continuously recycle themselves early.

I haven't read beyond this post really, however, I am curious to know, are you using a "Do After" block to kill the bullets when they don't hit something for a period of time?  One thing I am thinking could be possible is that, once the actor gets recycled, the timer created still exists and prematurely kills the recycled actor.

Then again, the very bottom of the post says it still happens even when there is no destruction.

Try putting a print statement in with the logic to kill the actor after a period of time and see if it appears at incorrect times.
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

NobodyX

  • *
  • Posts: 1228
Making it into a smaller game sounds like too much work, so I uploaded it privately to Forge.

Use the scene called PuzzleTest. Everything specific to the top-down part of the game starts with "Puzzle." So ignore all the scenes and actors and whatnot that don't start with "Puzzle." Cannons shoot bullets, arrows redirect bullets, you can push gems and they obstruct bullets, mushrooms obstruct things but disappear when the player touches them, bugs and faces are like walls that get destroyed by bullets. The one called "PuzzleBullet" that looks like a square just sits in one place, it's not really a bullet. Don't place skulls in the level. There are two tilesets with "Puzzle" in the name, use the big one only.

« Last Edit: May 18, 2011, 10:30:29 am by NobodyX »

NobodyX

  • *
  • Posts: 1228
I haven't read beyond this post really, however, I am curious to know, are you using a "Do After" block to kill the bullets when they don't hit something for a period of time?
No. There was a variable that counts down every frame. No "do after"s whatsoever.

Try putting a print statement in with the logic to kill the actor after a period of time and see if it appears at incorrect times.
Print statement? I don't understand what that is, or what you mean.

Epic428

  • Posts: 1118
That's fine, if you aren't using a do after then it wouldn't be that cause. 

Under Flow -> Debug  there is a block called "Print" when you put that in your behaviors and type something in it, it will display the text in the console when it runs that block, it is good for debugging behaviors. You can also put attributes in there to check their values.
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

NobodyX

  • *
  • Posts: 1228
Oh, cool! Thanks, that should be useful!

Alexin

  • *
  • Posts: 3130
Make your PuzzleBullet always simulate (Actor > Properties or search Forge) to fix the problem.

When actors are recycled they're placed somewhere "outside" the scene, making it so they stop simulating when you recreate them. Jon, is that the proper behavior or is it something that we missed?
"Find the fun"
alexin@stencyl.com

NobodyX

  • *
  • Posts: 1228
I just tried using always simulate, it did not fix it.

Winzenheimer

  • Posts: 97
NobodyX are you placing the bugs in the scene using the scene designer or spawning them with a "spawn bug" behavior?

I think I've run into this also while working on my game. When I placed enemy ships in a level with the scene designer and told them to recycle on death, player bullets would start acting up; either being shot irregularly or not at all. The problem was solved when I told enemies to die without being recycled.

I speculate the overall issue is most likely within recycling actors that where not created with the Create Recycled Actor block. If I remember, the previously mentioned block will add to the actor pool if there aren't enough available actors in it. The recycle block must not do this, and only tells an actor to return to the pool, which causes error when the actor was not originally part of the pool.

NobodyX

  • *
  • Posts: 1228
YEAH! You were right, Winzen, I changed the bug behaviour so that they die rather than recycle and it fixed the bullets! You were also correct about that I was placing them using the editor and then recycling them.

Joe

  • *
  • Posts: 2480
I'm really pushing for StencylWorks and the runtime to take care of this automatically (maybe in SW 1.1?). Choosing between recycling and destroying is an implementation detail and, in my opinion, is not something that users should have to worry about, especially since it can lead to problems like this one.