Another Purge Problem in Storyboard

Hi,

I have a game which is close to being completed, but I have run into a strange purge related problem. I am following this tutorialand doing everything as it tells me. 

When I run the game, everything works fine, but the only problem comes with mouse AI. If you see the video here, you will find that the mice are behaving properly. They have “dynamic” physics, they move and when they touch a static marker (invisible) I just change the xScale to -1 and reverse the speed.

So, when the level ends, I go to restart screen and click on restart. 

This time when they touch the marker, they do not change the scale or speed (I debugged the code and in the code, the mice do change the speed and scale, but it does not show that it did the change. It keeps colliding with the marker repeatedly.

now when the game ends and I restart once again, the mice start to behave as they should. Can anyone tell me what is the problem here? I also remove all event listeners when the scene exits.


– CODE –


restart.lua

– Purges the prior scene

function scene:enterScene(event)         local prior\_scene = storyboard.getPrevious()         storyboard.purgeScene( prior\_scene )         retryButton:addEventListener ("touch", pressRetry)         levelsButton:addEventListener ("touch", pressLevels)         nextButton:addEventListener ("touch", pressNext)      end  

level.lua


– DIDEXIT SCENE –


function scene:didExitScene( event )     storyboard.purgeScene( "level" ) end  

– EXIT SCENE –


function scene:exitScene(event)     Runtime:removeEventListener("enterFrame", owl)     Runtime:removeEventListener("touch", TouchScreen)     for i = 1, #gameObject do         --print(gameObject[i].x)         if (gameObject[i] ~= nil) then                          if gameObject[i].Name == "mouse" or gameObject[i].Name == "cloud" then                 print(gameObject[i].Name)                 Runtime:removeEventListener("enterFrame", gameObject[i])             end         end     end end  

– ON COLLISION –


local function onPostCollision( event )         if ( event.object1.Name == "mouse" and event.object2.Name == "marker" ) then         event.object1.speed = 0 - event.object1.speed                event.object1.xScale = event.object1.xScale \* -1     end end  

When you purge a scene it gets rid of any display.* object that you have created and inserted into the scene group.  Anything else that got created isn’t touched.  Also if you have declared any variables in the scene’s main chunk, .i.e. at the top of the module, those values do not get reset as part of a scene purge.

You could do a storyboard.removeScene(“level”) in your restart.lua module to completely dump and reload the module from scratch.  This is the “programmer” simple way to fix it.  I wouldn’t mess with the purge in the didExitScene() event.  

However, this doesn’t feel like a scene purging problem.  If not it would happen every time.  Since the 3rd iteration worked as expected, I feel something else is off.  What happens on a 4th time? 5th?  Is there a pattern that odd times it’s good and even times it sticks?

Rob

You are right, I rechecked and found out that I am actually doing storyboard.removeScene(“level”) in restart.lua as purge was doing exactly what you explained. (I am sorry for the mistake, I was trying many things and forgot what I was actually doing :unsure: )

Yes, it is a continuous loop. When I load the first time through restart.lua, the mouse acts irrationally, then rationally, then irrationally and the loop continues. so at odd times it is good and even times it sticks and so on.

If it’s happening when you remove the scene, then it’s something in your logic.

OK, thank you for the input. So I take it that the removing scene part is done right. I will change the logic of mouse AI and see if that works.

I did the logic again and even though i have a different problem, one thing is for sure and that being that the remove scene is working properly, and the problem lies somewhere else within my logic. What is frustrating is that the code is so simple that it is making my mind hurt in figuring out where the problem is! Should work on it when i have had some sleep.

thank you very much for your input, it means a lot!

I tried one more test and now I sort of know what is happening.

I added another mouse to the level and changed the mouse move logic to this

---------------- -- MOUSE MOVE -- ---------------- distance = 0 speed = 1 function MouseMove(self, event)     distance = distance +1     if distance == 250 then         speed = speed \* -1         self.xScale = self.xScale \* -1         distance = 0     end     self.x = self.x + speed     --self.x = self.x + self.speed end  

What happens now is that, as the distance approaches 250, the xScale of one of the mice changes but the rest of the mice maintain the same direction and start walking backwards (mouse moonwalk).

What I gather from this is that, the same function is shared by all the mice, so when 250 limit is reached, one of the mice changes direction and the work is done as the distance is now 0, so the rest of the mice do not change direction.

now the function jumps to the next mouse and the next time 250 distance is reached, that mouse changes direction while the others do moonwalk.

So, sharing the same function for all the mice is causing the problem. Do you have some suggestion to fix this thing? 

One way that I thought of (since I am not going to have more than 5 mice) is to create 5 separate functions for 5 separate mice and run the code that way (I know it is a bad solution but it will work I think)

Can you tell me a work around?

 

how about adding the distance and speed to the mouse object itself.

When you spawn your mouse, you can add attributes to it.  Then in your function:

function MouseMove(self, event)     self.distance = self.distance +1     if self.distance == 250 then         self.speed = self.speed \* -1         self.xScale = self.xScale \* -1         self.distance = 0     end     self.x = self.x + self.speed     --self.x = self.x + self.speed end

And of course I had to make such an apparently obvious silly mistake. Everything is working fine now, but I still cannot figure out why the changing of directions with collisions method was causing problems. Will revisit that some day and check

When you purge a scene it gets rid of any display.* object that you have created and inserted into the scene group.  Anything else that got created isn’t touched.  Also if you have declared any variables in the scene’s main chunk, .i.e. at the top of the module, those values do not get reset as part of a scene purge.

You could do a storyboard.removeScene(“level”) in your restart.lua module to completely dump and reload the module from scratch.  This is the “programmer” simple way to fix it.  I wouldn’t mess with the purge in the didExitScene() event.  

However, this doesn’t feel like a scene purging problem.  If not it would happen every time.  Since the 3rd iteration worked as expected, I feel something else is off.  What happens on a 4th time? 5th?  Is there a pattern that odd times it’s good and even times it sticks?

Rob

You are right, I rechecked and found out that I am actually doing storyboard.removeScene(“level”) in restart.lua as purge was doing exactly what you explained. (I am sorry for the mistake, I was trying many things and forgot what I was actually doing :unsure: )

Yes, it is a continuous loop. When I load the first time through restart.lua, the mouse acts irrationally, then rationally, then irrationally and the loop continues. so at odd times it is good and even times it sticks and so on.

If it’s happening when you remove the scene, then it’s something in your logic.

OK, thank you for the input. So I take it that the removing scene part is done right. I will change the logic of mouse AI and see if that works.

I did the logic again and even though i have a different problem, one thing is for sure and that being that the remove scene is working properly, and the problem lies somewhere else within my logic. What is frustrating is that the code is so simple that it is making my mind hurt in figuring out where the problem is! Should work on it when i have had some sleep.

thank you very much for your input, it means a lot!

I tried one more test and now I sort of know what is happening.

I added another mouse to the level and changed the mouse move logic to this

---------------- -- MOUSE MOVE -- ---------------- distance = 0 speed = 1 function MouseMove(self, event)     distance = distance +1     if distance == 250 then         speed = speed \* -1         self.xScale = self.xScale \* -1         distance = 0     end     self.x = self.x + speed     --self.x = self.x + self.speed end  

What happens now is that, as the distance approaches 250, the xScale of one of the mice changes but the rest of the mice maintain the same direction and start walking backwards (mouse moonwalk).

What I gather from this is that, the same function is shared by all the mice, so when 250 limit is reached, one of the mice changes direction and the work is done as the distance is now 0, so the rest of the mice do not change direction.

now the function jumps to the next mouse and the next time 250 distance is reached, that mouse changes direction while the others do moonwalk.

So, sharing the same function for all the mice is causing the problem. Do you have some suggestion to fix this thing? 

One way that I thought of (since I am not going to have more than 5 mice) is to create 5 separate functions for 5 separate mice and run the code that way (I know it is a bad solution but it will work I think)

Can you tell me a work around?

 

how about adding the distance and speed to the mouse object itself.

When you spawn your mouse, you can add attributes to it.  Then in your function:

function MouseMove(self, event)     self.distance = self.distance +1     if self.distance == 250 then         self.speed = self.speed \* -1         self.xScale = self.xScale \* -1         self.distance = 0     end     self.x = self.x + self.speed     --self.x = self.x + self.speed end

And of course I had to make such an apparently obvious silly mistake. Everything is working fine now, but I still cannot figure out why the changing of directions with collisions method was causing problems. Will revisit that some day and check