so id like to make it so my pistols are shot when you press the button, not a press and hold kinda deal, but i did what seemed logical and it didnt work.
heres what the code looks like...
Object(Guninhand) Is faceing ->
Limit Condition for 0.30secs
+Upon Pressing D key
= Fire bullet
logically that would mean you can only shoot every 0.30 seconds, but what happens is you shoot once, and than it wont let you shoot in that direction again. also, there are each of those events for the other directions as well. the only reason i dont have hte bullet fireing in the direction the guninhand is pointing is because in order to have an arm pointed upward on the left side and on the right side, i had to use the 2 spots on the animation thing to the left and right of the UP slot, if that makes any sense. anyone know what i did incorrectly?
[Game design makes my brain feel like its gonna explode.]
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
26th January, 2011 at 13:10:09 -
Repeat while is pressed "Space"
+ Active.AltA = 0
Then
> Active.AltA = 10
> Fire Bullet
If Active.AltA > 0
Then
> Active.AltA = Active.AltA - 1
I remember reading somewhere that using the Timer to have a set time for events isn't as effective as using an alterable value, as one machine may be able to keep up with the timer, but others might not. As I am not the best at coding, I tend to stick with using Alterable Values in all cases where a timer might do, simply because if there's a sequence of events based upon timers and/or regular intervals, they'll always keep pace with the way the rest of the game is running.
But most of y'all know this already. My point is that I just shy away from using the Timer object unless there are very, very few Active Objects and/or functions/events.
Originally Posted by s-m-r (for all the noobs and fellow novices out there)
I remember reading somewhere that using the Timer to have a set time for events isn't as effective as using an alterable value, as one machine may be able to keep up with the timer, but others might not. As I am not the best at coding, I tend to stick with using Alterable Values in all cases where a timer might do, simply because if there's a sequence of events based upon timers and/or regular intervals, they'll always keep pace with the way the rest of the game is running.
But most of y'all know this already. My point is that I just shy away from using the Timer object unless there are very, very few Active Objects and/or functions/events.
For the perfectionist its also less accurate as you cannot reset the timer.
If you have an event that says
Z is pressed
+ Every 00.05
- Shoot
and you start pressing Z at 0.02 then the object shoots 00.02 seconds earlier
if that makes sense.
Negligible? Probably, but it bothers me. You can reset the alterable value if the player lets go of shoot.
I still have a nasty habit of using timer events. I also have a nasty habit of stopping at a McDonalds and suddenly getting hungry. I know it's horrible for me, and when I think about it long enough, I go for the much better alternative. I think this is a pretty good analogy.
Well, just so you guys can see, this is what i did.
+Object(Guninhand) Is faceing ->
+Alterable value A of Guninhand is lower or = to 0
+Upon Pressing D key
= Fire bullet
= add 20 to alterable value A of guninhand
and then...
+Every 0.1 seconds
+alterable value a of guninhand greater than 0
=subtract 0.1 from alterable value A
it works just fine too.
[Game design makes my brain feel like its gonna explode.]
what would be the point in making it an always event? using the 0.1 secs makes it easier to moderate the amount of time between shots fired.
and i read something somewhere that said the fastest mmf2 can process events is 0.2 secs, is that true?
[Game design makes my brain feel like its gonna explode.]
No, MMF will process as fast as your computer can handle and within the frame rate limit.
OMC is right, the timer event may work fine on your computer, heck it may even run fine on every computer, but it's a bad habit to get into because once you start using larger amounts of time you'll start to have inconsistencies if the game runs at an inconsistent frame rate.
The Timer is based on real time, and not in-game time. That's the only real problem.
Siven, once we've learned that the timer is evil, we use no timer at all!
and i read something somewhere that said the fastest mmf2 can process events is 0.2 secs, is that true?
Before MMF2 introduced framerate settings, all klik games ran at 50FPS. I.e., if the game was running at maximum speed (which it rarely would be), the events would run and the screen would be redrawn every 0.02 seconds (protip: this is completely different from every 0.2 seconds). The 'Always' event means 'every frame'.
Unless you use 'machine-independent speed', which I remember typically being gamebreaking, the game speed is going to fluctuate with framerate. The timer isn't, so it's a one-way ticket to inconsistency land.
This is is how your conditions and events should go:
+ Upon pressing "Fire button"
+ If guninhand is faceing direction 0
+ Active.altval = 0
- Fire bullet
- Set Active.altval to (time before you can shoot again, maybe 10)
Originally Posted by The Chris Street I thought "Always" equated to "0.02" seconds.
That's only when the framerate is 50. "Always" equates to FrameRate/100.0. The default framerate is 50, so by default, "Always" is "Every 0.02 seconds".
Yeah, I was gonna say. In-game loops are completely independent of time. This is precisely why timer events are a bad idea to use, because when the game slows down, timer events still fire on time. "Always" is based on in-game loops, so if you increased the framerate, naturally "always" would be a faster than 0.02 seconds. Likewise, if you slowed the framerate down, "always" would be slower than 0.02 seconds. Slow it down to 30fps and Always will literally fire 30x a second.
Personally, I think you should do what you can to make sure the game will run at full speed on as low a spec computer as possible (include options to disable special effects, etc if need be) - and then if the player's computer isn't fast enough, that's their problem.
There's no point trying to make a game run normally but at slow speed.
There's no point trying to make a game run normally but at slow speed.
But that's what MMF does for everything else by default. Can you really account for everything that might trigger the tinest dip in performance? The inconsistency is just going to lurk in the shadows until it gets an opportunity to break the game.
If a game's perfectly playable with those special effects enabled, but for some reason I can't make a particular jump while something's exploding (edit: or because the midi file playing changes or whatever), I'm going to be inclined to think it's the developer's fault.
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
24th April, 2011 at 15:04:21 -
I still wouldn't use timers, since they don't let you access real time anyway (see rest of thread). I'm pretty sure TimeX can get time independent of framerate.
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
25th April, 2011 at 03:12:17 -
Chris - that looks good but remove the "Every 00-01"" from everywhere. Your code will run exactly the same, except it will be consistent on slow machines
I've run games I've made on so many pieces of shit and they still run the same.
But yeah I need to get in that habit of using always instead. Thanks! happy easter
n/a
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
25th April, 2011 at 15:12:25 -
Anything that runs below the target FPS will run differently. It's not likely that someone is using a computer that slow, but it's not just that. If you freeze the app (such as with grabbing the title bar - I think), or your computer happens to lag for a second (due to some other process), it will run differently if you use timers. If you use counters/MMF framerate instead then it will run the same on all machines, albeit slower. In your code, there's no point in having the Every 00-01 in there.
Advertisement
Post Reply
Edited by an Administrator
My point is that I just shy away from using the Timer object unless there are very, very few Active Objects and/or functions/events.
jenswa.neocities.org
*Random(23)! 