(IGNORE) Millisecond timer

@grazer

At the moment the Timer behavior can time down to 10 milliseconds. I have run into many problems where having an object be deleted in less than 10 milliseconds is vital.

The timer limit at the moment:

image

Example

Say I have an enemy. The enemy is supposed to shoot at the player. The enemy’s ammo should be destroyed as quick as possible after hitting the player without being automatically destroyed. If I wanted the enemy to fire a laser, then the laser sprite would build up on the player for as long as the timer allows before destroying it. This would allow the player to be hit multiple times more than intended.

If the Timer behavior could go into milliseconds, the laser sprite would be destroyed before the player got hit multiple times.

This minor Feature would be very helpful for the ‘De-Bug’ system. Also, if I made the ammo sprite solid then then it would push the player before it got destroyed.

That is all, please add this feature to Flowlab.
Thank you,

-Ember.Y

2 Likes

Try using a floating point value for the delay, like: 0.5

2 Likes

Sorry for not understanding but; what is

?

1 Like

A floating point value is any decimal value

2 Likes

Oh. I’m already using a decimal in the timer. Does

Mean a decimal value outside of the timer (In a deferent behavior)?

2 Likes

every decimal number, whether inside the timer or not, is a floating point value.

2 Likes

Why did Grazer say 0.5 then? 0.5 is 50 milliseconds.

1 Like

to show that you can go smaller than 1/10 a second

2 Likes

Oh. I already knew that though. I posted a picture of how low the current ‘Timer’ behavior could go (0.1).

1 Like

My Feature request is an upgrade to the ‘Timer’ behavior. An upgrade that allows the timer to go into singular milliseconds. (Example: 0.05)

1 Like

Hey @JUSTPLAINOP - there are a couple of issues at play here:

First, I think high-precision timers are not the way to create the game mechanics you are describing in a reliable way. I don’t think I fully understand your explanation, but you might want to consider more direct ways of making sure things happen in the order you want.

Second, Timers can only activate while the logic is executing. Trying to activate timers faster than the frame rate just means the logic will run on the next frame anyway, so higher precision here still won’t help you.

2 Likes

It sounds like you just want this

Collision with player → Destroyer

I don’t see the need for a timer at all. Something that a lot of people do it overuse timers way too much, but with proper frame ordering most all code can be done without them. The only time I use timers is when I what a noticeable delay like 3/10 or if I’m making something purely for testing so I won’t keep the code anyways.

2 Likes

If it gets automatically destroyed, the player won’t get hit at all. I want the ammo to hit the player but not build up and hit the player multiple times.

When the bullet collides with the player, all of the collision behaviors that allow the bullet will be activated on the same frame, so It would still work.

1 Like

I will test this. I still think that a timer that could go into milliseconds would be helpful.

1 Like

Like grazer said a timer any shorter won’t do anything.
If you have a timer between 0.1-0.3 it will technically all activate on the same frame. They will technically go off at different times within the same frame, but that gets into frame ordering.

For what you want a timer is not needed.

2 Likes

Hmm. Yes, it does work. Fine, I will close this topic.

2 Likes