+slopespotter Posted April 19, 2015 Share Posted April 19, 2015 Hello, I am struggling with a zone mover issue that cancels out any way of dealing with items that are supposed to be taken out of and dropped into the zone: Between zone moves the zone disappears for a second or longer which makes it impossible to interact with any objects within. This is a Urwigo cartridge tested with Android. I am right now looking at a different Wherigo (Play anywhere) that concentrates on moving zones (http://www.Wherigo.com/cartridge/details.aspx?CGUID=478c7843-3c40-4370-aacb-119a60ae4f0e), also on Android, and the movements are silkysmooth here. The move happens instantly without any flickering or disappearing of the zone. I talked to the creator and he confirms that he is basically using the same technique (TranslatePoint() for calculating the border points, and the OriginalPoint and Points properties of the moving zone). What's going on here? I have about 10 active zones with very simple geometrics (no more than five border points), but I cannot believe this is a problem with an Android phone. The moveZone() function is tied to a simple timer. No behavior differences when tested between 1, 2 or 3 seconds for each step. Code fragment, nothing fancy: [Zone waypoints are set globally outside of these functions.] function centerZoneOnPoint(movingZone, centerPoint) local newCenterPoint = Wherigo.TranslatePoint(centerPoint, distanceCenterPoint, 0) local points = { Wherigo.TranslatePoint(newCenterPoint, distanceBorderPoint, 0), Wherigo.TranslatePoint(newCenterPoint, distanceBorderPoint, 72), Wherigo.TranslatePoint(newCenterPoint, distanceBorderPoint, 144), Wherigo.TranslatePoint(newCenterPoint, distanceBorderPoint, 216), Wherigo.TranslatePoint(newCenterPoint, distanceBorderPoint, 288) } movingZone.Active = false movingZone.OriginalPoint.latitude = newCenterPoint.latitude movingZone.OriginalPoint.longitude = newCenterPoint.longitude movingZone.Points = points movingZone.Active = true end function moveZone() if intTornadoPosition > 100 then intTornadoPosition=1 end local centerPoint = zoneRoute1[intTornadoPosition] centerZoneOnPoint(zoneTornado, centerPoint) intTornadoPosition = intTornadoPosition +1 end Does anyone have an idea what my problem could be? Thanks in advance Regards slopespotter Quote Link to comment
+charlenni Posted April 20, 2015 Share Posted April 20, 2015 The function looks good and there shouldn't any problems with it. Do you have tested, if the cartridge is even slow, if you remove the call to moveZone()? Perhaps the problem is in another place. Quote Link to comment
+slopespotter Posted April 20, 2015 Author Share Posted April 20, 2015 Thank you for your reply Charlenni! That is an interesting thought. I have, though, no idea how to benchmark this. How can I measure if the cartridge is slow without involving timers and zone movers? So far we are talking one single timer, one moving zone, and I am going nuts about it being so slow. Is it possible that the number decimal digits play a role? Which brings me to the generalized question: What DOES make a cartridge slow? Besides obvious timers... The number of zones? Even the deactivated ones? The number of medias? Amount of code? Best regards slopespotter Quote Link to comment
+charlenni Posted April 20, 2015 Share Posted April 20, 2015 Nothing of the things you mentioned should slow down a cartridge so much. Do you think it is possible to send me your cartridge? Quote Link to comment
+slopespotter Posted April 21, 2015 Author Share Posted April 21, 2015 Certainly! And thank you for your kind offer to have a look! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.