Is there an alternative for using the timer 'Every X Seconds'?
Hi there. I'm trying to solve an app crashing problem by reducing the amount of timers I have.
So instead of using the timer rules, I use things like 'If Scene.Time = 6 seconds then do...'. The thing is some of my timers I can't necessarily do that as it says 'Every X seconds do this', or 'After X seconds if X attribute = X then do this'.
How can I convert those using the Scene time, Self time or Game time?
So instead of using the timer rules, I use things like 'If Scene.Time = 6 seconds then do...'. The thing is some of my timers I can't necessarily do that as it says 'Every X seconds do this', or 'After X seconds if X attribute = X then do this'.
How can I convert those using the Scene time, Self time or Game time?
Answers
Hi @1LuVP4nc4k3S you can replace a Timer using Every, with a loop if you like...
Something like:
Rule: When scene.Time => 6 seconds
and Looper is false
Change Attribute RunTime to scene.Time + 4 --- or whatever length of loop you require
----do your thing
Rule: when scene.Time = RunTime
Change Attribute Looper to true
Rule: When Looper is true
Change Attribute Looper to false
For interest, we'll hopefully have a dedicated Loop behaviour in the main GSC beta at some stage in the future, for all different types of loops.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
GSINVENTION FREE TEMPLATES
Hi @CodeMonster There's a sort of myth built up that Timers are baaaad things in GSC.... in the main they're not, providing you don't have too many of them all happening at once, which adds a lot of processing to the app, which could cause it to slow down, or, I guess, in a really extreme situation, crash... (although that scenario is surely once in a blue moon tho').
So even though there are some interesting alternatives to replacing Timers, if these alternative still need constant checking like a timer does, there's no real saving in processing power, I believe...
It could be said that Timers aren't totally accurate either, that they might "drift" but these particular behaviours in GSC are used for games mainly, of course, where we're talking milliseconds out, where it really won't make any difference at all... if it was precise scientific work then that'd be a different matter....
I think there's become a sort of wariness with Timers with some people that they needn't have; to summarise: providing Timers aren't used to a wild excess, and are nested properly, and an absolute scientific precision isn't required, then there really isn't any worry. :-)
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
GSINVENTION FREE TEMPLATES
I have a number of timers on them, so I thought that if maybe I converted them to what's discussed above, that maybe it might solve something - as I really don't want to get rid of the animation.
@CodeMonster and @gyroscope it may even be that this doesn't solve the problem, but I thought I'd try. If you're wanting more info on my problem, here's the post I'm talking it through on:
http://forums.gamesalad.com/discussion/60292/i-ve-reduced-my-project-file-massively-and-it-s-still-crashing-in-gs-viewer#latest
I use Timers are for Chumps where I can and it helps out for sure with performance and accuracy.
I also use the precision formula.
In the timers are for chumps posting, I thought the following statement was interesting: "When you create a timer in GameSalad, you force the engine to disjoint a rule from its true location on a particular actor and encapsulate it within an event that runs outside of its usual scope for a set duration."
Personally I don't like the idea of forcing the engine this way as I would have thought that might impact processing/ram usage. Just my thoughts though - I'm not technically minded enough to know the impact and haven't analysed before and after differences.
Hi again, @1LuVP4nc4k3S I had a quick skim through that thread but didn't take the time to read too carefully, I'm afraid...
But a couple of things that might help you: if you uncheck Load Images for all of your images in all levels other than your intro, menu and first level, then not only will it not take as long but you'll have more chance of the app loading properly as an ad-hoc for testing.
There's a limit of file-size of any app in the iTunes store of 2gb; the servers at GSC when you publish should be capable of 500mb or more now (providing it doesn't time-out); there's a limit for the file size to be able to download directly onto the iDevice (which would have been the warning you got in the bottom right of GSC, but as I say, if this isn't a concern, then ignore it.
Hope that's of some help.
Anyhow your animation, where it's crashing, ome questions please: are you replacing images with a timer, or using the Animate behaviour? How many images are used and for how long, and what is the size of the images, and what is the fps you're using?
Edit: typed before @matarua & @darrelf posted...
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
@gyroscope - as a Moderator, can I ask which would be more acceptable in this forum: if I continue this conversation here, or on that other post? I appreciate some people get flagged for duplicating conversation, and didn't want to screw up the forum policy here
I also saw the 'timers for chumps' post and have changed all my timers to the ones suggested. My original question at the top here was what to do for the timers that say 'Every 6 minutes' or 'After 6 minutes', which @gyroscope provided a suggestion.
I'll try these out and see if it solves my problem, but as I say the bigger issue was that my app was crashing (see other post mentioned). If it doesn't solve the problem, I'll have to find something else - which I'm not all that confident I'll find
For an after call you use a self.Time > 360
or in the middle of the game you must do this to an actor that already exists - well, that gets a bit more complex and you need a timeStamp call as per the Timers for Chumps. It's all in there
@matarua & @darrelf Just to clarify I think the stuff in Timers are for Chumps is excellent advice and makes for precise timings with less ram usage too, I'm sure; respect to the guy who did it... but in quite a few situations, I still think Timers are just fine for the job (which makes me a chump, I guess... ;-) )... I'm just saying "don't throw the baby out with the bathwater".... but then again I'm sure there are lots of people who don't agree with me, and who will never use a Timer behaviour again if they can help it!
Anyhow, back to your problem, @1LuVP4nc4k3S I'm not understanding why you think your animation is causing the crash, etc because of Timers... not seeing why you're using so many timers for an Animate behaviour... but perhaps I've misunderstood something there....
But still with the poss. of helping out, I'll repeat my questions from my prev. post which, if you could answer, could shed some light on a solution:
Your animation, where it's crashing, ome questions please: are you replacing images with a timer, or using the Animate behaviour? How many images are used and for how long, and what is the size of the images, and what is the fps you're using? As you started this thread, I can't see any worries about it being diverted a bit... it all seems to be in the same ballpark anyhow... :-)
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Actor 1 (in the Welcome Screen):
This actor is an animation an is the size of the screen. The only rule it has is to:
a) Animate (at 25fps) - no looping
b) After X seconds destroy the actor
*because the actor underneath will start to animate (because its a continuation of the first animation but a loop). To explain further, animation 1 is a full screen animation of a character falling into the scene and some smoke appears and a colourful pinwheel animates behind it (fading in). The reason I have 2 animations is because animation 1 brings the character into the shot and fades the pinwheel in and brings the smoke in, and in by the time you get to animation 2 the character is still, but I want the pinwheel in the background to keep spinning so I can loop it.
Don't worry, originally I had all these different elements as separate actors so I could control them better but it really whacked my file size up and performance was slow, so I decided to essentially 'flatten' it all into one animation. This actor is what is causing the app to crash at this scene
Actor 2 (in Game Screen):
This actor has a number of rules that tie in with attributes from another actor. But having switched each rule on and off separately, I've discovered that only the rules associated with PNG animations seem to trip up the app. Sorry about this - I thought it was the timers.
This actor is my main character. The main aim of the game is to complete a task before the time runs out (30seconds). You can either win, lose (because time got to 0), or lose (because you didn't complete the task right - but still before time reached 0). Here are the *problem* rules:
a) If timer = false (as in 30 seconds has gone), and the 'you lose' message is at x and y position, then set the image to a dead character. Other wise Animate it as normal.
b) If timer = false, and the 'you lose' message is at x and y position, and the 'WIN/LOSE' attribute is set to 3 (this is when you get the task wrong inside the time), then animate the 'relief' animation for the character.
c) If timer = false, and the 'you win' message is a t x and y position, and the 'WIN/LOSE' attribute is set to 1 (this is when you win), then animate the relief animation for the character and play X sound.
What do you think?
- All animations are always at 25fps.
- Actor 1 is full screen size (320x568) and is 125 frames long and runs to completion (i.e. doesn't loop).
- Actor 2 is 140x235. The main animation which it should default to is 25 frames long and on a loop. The other animations are about 25 frames long too but once finished should return to default animation.
Performance:
Frames per second: 59.89
Memory Usage:
Images: 64MB
Sounds: 801KB
Game Engine: 20.2MB
Other: 24.7MB
Total: 109.7MB
I've tried this for the Welcome Screen and luckily it doesn't make the app crash (yey!!!!) but sadly the animation that plays back looks pretty poor in comparison. Sadly its probably only because I myself am an animator and don't like the difference - I always animate at 25fps
Booohooooo......will try the same concept with the Game Screen now and see if that overall solves the problem...
This is not going very well....
@1LuVP4nc4k3S this might be a silly question but your pinwheel and smoke - are they one actor now animating? You could do both by having one image each and just rotating it using GameSalads rotate behaviour?
The pinwheel is an image which spins - one image rotates in GameSalad - no animation required and slices game size down.
The smoke can be a smoke ball that you pop on the stage a few times and rotate that also in different locations moving it up and down to give you endless changing smoke with 3 or uses of the same image - there is a 'Rolling Mist' demo in the 'Dump your code here' thread.
There is also the issue of you converting from Windows to Mac - this could be causing issues. Only the GameSalad team or other Windows users could answer that perhaps.
All the best and hope you can resolve the issues.
The guys at @DeepBlueApps and @GSHelper might be able to help.
Cheers, M@
In this basic project you can:
- Script your animations in a table
- Adjust animation speed based on target FPS or target time to complete script
- Loop animation or run through once
- Continue or reset animation after run
- Change animation set with the flip of a switch
Extend this project to do these:
- Insert actions aside from changing image (rotate, position, color, blah, blah)
- Start, stop at any frame
- Skip or jump to frames
- Do something based on the current frame
- Loop animation x-amount of times
- A bunch of other stuff I can't think of right now
Note: It may be a good idea to preload images to avoid stuttering on first run of script.
To preload images the quick way:
- Place animation behavior inside a broken rule (will never qualify)
- Place any image you want to preload into the animation behavior
- Preload Art is True in actor
Project:
https://dl.dropboxusercontent.com/u/27937751/gs/modules/animation2.0.gameproj.zip
@matarua Essentially that's kind of the way I had it before. The background actor was a full screen actor of the pinwheel animation (didn't use rotate behaviour - just animate). And the smoke and main character were animated all in one actor as PNG sequence on top. But this added a lot to my project (I had been in the process of trying to decrease file size - its now at 76MB).
Thanks for your suggestion to contact those guys about the Windows/Mac issue. I've messaged GSHelper to see what he might suggest.
@ericzingeler thanks ever so much for your suggestion. I'll give it a bash and see if it helps my situation at all!
Cheers, M@
Went to my Welcome Scene and instead of having the animation in 2 actors I split it up like this:
Foreground actor = animation of main character + smoke + foreground objects
middleground actor = pinwheel which I *didn't* animate, but applied the rotate rule to it.
background actor = animation of background objects
Sadly, this crashes the app at this point. Plus, my project size is now 20MB bigger.
I also went into the Game scene to see if maybe my code had some problems on the other actor which was tripping the app up. I've changed the way I made each rule now so its structured a little differently now. But STILL the same result.
I would love it if all of this was just a case of me going from Windows to Mac.....
During that time, it says my 'Real Memory Usage' is 148.18MB. Is that really bad?
Here's why GS games crash in my experience.
Syntax. Hangs on scene change. In behaviours e.g. 0 was an O instead of a 0 which is bad data. Solution, correct bad syntax.
Table calls. Hangs on scene change or does not fire rule. Where data or table has changed and it's referencing the wrong cells in either columns or rows - bad data. Solution, delete adhoc game and clear viewer and reinstall or re-run everything.
Memory spike. Crashes game, black screen. Images in use may be small on disk but huge in memory. Track memory usage in GS viewer. You can see the errors in X-Code too. It will give you a log.
These are things I have experienced using the Mac version.