Every second function

Hi. Unity 5 made allot of improvements, but there is 1 function i would like to see in the future to speed
up the development process and performance.

Today we have this frame realtime functions:

void Update () // every frame
void LateUpdate() // Every frame after Update frames

Now allot of times i do construct my own logic to have every second events (with Deltatime), because many things does not have to be every frame. It works and thats fine.

But It would speed up the development practice if we had a example void DeltaEvent() function that happen based on time and not frame. This is useful for logic implementation, example distance check, UI event etc.

Discuss?

 

Invoke, InvokeRepeating, Coroutines, your own threading solution. Unity has many ways to do what you want.

 

Yes there are ways to use it like that, but i dont think you get what i am talking about. I am talking about Mono function, not IEnumerator or Deltatime relevance, i already stated that solution. IEnumerators needs to be started from another function.Also when you Invoke.

Let me clarify

Code (CSharp):

1. void Update()
2. {
3.   // Every thing you put here will be handled every frame
4. }
5.  
6. void SomeNewUnity5FunctionTimeBased()
7. {
8.   // Every thing you put here will be handled every second
9. }

 

Everyone understands what you're saying, there's simply no reason to do it. A coroutine can do exactly what you want far more flexibly than a "built-in" function like that. It saves absolutely nothing in development time, it would be slower than coroutines because it's found and stored using reflection, and you wouldn't be able to control the intervals or logic the way that you can with a coroutine either.

And a coroutine is just one of many alternatives, all of them better.

 

Coroutine are not the solution nor the best practice for what i am talking about. The best solution at this point of time, is to use Time relevance intervals (since this what you want to achieve) Corotines are not ment for this task, even you can delay by time.

The solution (this is taken from Unity advice, so trolling is kinda pointless here)

Performance friendly code:

Code (CSharp):

1. float TimeInterval ;
2.  
3.     void LateUpdate()
4.     {
5.         // ones per in seconds
6.         TimeInterval += Time.deltaTime;
7.         if (TimeInterval >= 1)
8.         {
9.                       TimeInterval = 0;
10.                        // Performance friendly code here
11.          }
12.     }
13.  

 

I also agree that unity should NOT have built - in functions that fire at specific time intervals.

As you've proven, you could easily replicate the behaviour yourself.

In your example, you've written something that fires every second. Good. Great!

Are you suggesting that unity should have an OnEverySecond() function?

What if i wanted to fire something every two seconds? Or every five?

You can see that if unity were to add functions for every possible time interval, the api would fill up with quite quickly and it would not make a lot of sense.

You could write your own timer class:

Code (CSharp):

1. public class Timer {
2.  
3.      float seconds;
4.      float timeStamp;
5.  
6.      public Timer(float seconds)
7.      {
8.           Set(seconds);
9.      }
10.  
11.      public void Set(float seconds)
12.      {
13.            this.seconds = seconds;
14.            this.timeStamp = Time.time;
15.       }
16.  
17.      public bool ExpireReset() {
18.           if (Time.time >= timeStamp + seconds) {
19.                 Set(seconds);
20.                 return true;
21.           }
22.           return false;
23.      }
24. }

Which on its own would be fine, but you could also extend MonoBehaviour so that it fires events at intervals you choose:

Code (CSharp):

1. public class IntervalBehaviour : MonoBehaviour {
2.     Timer secondTimer;
3.  
4.     void Awake()
5.     {
6.           secondTimer = new Timer(1f);
7.     }
8.  
9.     void Update() {
10.           if (secondTimer.ExpireReset())
11.                   EverySecond();
12.     }
13.  
14.     public virtual void EverySecond() {}
15. }
16.  

You could extend your behaviours from this and have a EverySecond function on each of them, that way. OR, for double extra try-hard mode, you could do this:

Code (CSharp):

1. public class IntervalMessages : IntervalBehaviour {
2.  
3.          public override EverySecond() {
4.                 gameObject.SendMessage("OnEverySecond", null, SendMessageOptions.DoNotRequireReceiver);
5.          }
6.        
7. }
8.  

And voila. We've now implemented what you wanted in the first place. Place this last component on any gameObject, and any behaviour it contains with a "void OnEverySecond();" will fire every second.

Sometimes, you've got to do the work youself. Unity can't do EVERYTHING for you.

 

This is why we have a discuss right? its great to hear peoples input on this subject, there are solutions (yours good example also) so this is not a issue discussion really. Its just that it would be nice to have some function that works better with time, rather than frame. (Of course we can implement this our self, its just that time is a big factor in any games, why hack basic needs?

Frames and Time are pretty far apart, even they are related.

Lets say Unity made a function that worked kinda similar to IEnumerator Coroutine, just without the start and stop and 100% independed, you can control time just fine with the Coroutine function, wouldn't be a big problem to implent something similar. Would give more control and overview of time relevance. I am not sure if Coroutine are based on COM interoperability, any one?

How can you fill up the API ? Didn't know such a limitation did exist

 

Aaaaaaaaaand... you have the expertise to determine this why?

Coroutines accomplish this perfectly.

You do know that the automatic code actually has another function that calls things like Update and LateUpdate for you. You're just complaining that YOU have to write the code to start the coroutine.

How about you write a class that scans via reflection your components for methods with a name that matches the signature you want, generates the delegate, and calls it on the interval as defined in its name.

Invoke and InvokeRepeating deal with time.

WaitForSeconds deals with time.

A LOT of functions deal with time.


If you're upset that the functions don't actually wait that exact number of seconds, and instead are the frame nearest that duration of time. Well that's not going to change. Unity only lets you update between frame rendering (on Update). With good reason, if you altered the state of the game during frame rendering, it could effect the look of the scene mid draw. You could end up with the top portion looking one way, and the bottom another.

This is the same reason you can't update unity objects from another thread.

 

You clearly dont get it I can see that a allot of people lack the knowledge around Coroutines, i am not going to elaborate on that. Better to go read http://docs.unity3d.com/Manual/Coroutines.html

 

Coroutine already has that, its just that Coroutines has some clear limitations(hence my thread on this). I hope your not against Coroutines. They are pretty good for there uses. But not for what i am talking about in all situations.

 

Yeah... I don't get it.

I honestly don't get what YOU'RE on about.

I do understand coroutines just fine. You linking to the documentation that shows examples about how to write a coroutine does not prove that they "are not the solution nor the best practice" for operating code on some interval of time.

 

Name them. Name what limitations they have that your solution remedies.

I'm not going to understand what you're remedying if you don't tell us what you're remedying. Because they aren't that "clear" to me.

 

Its good that you realized that, its a good start Yield and take a chill pill lordofduct, read the link i gave you (read all of it), and the sense will come to you, no need for me to copy/past basic Unity documentations. Enumerator has limitations in Unity.. Have a good evening.

 

Sure, you have a good evening as well.

I have to go read basic documentation on coroutines, because clearly I don't know how they work.

I'll just leave this right here.

 

I think @lordofduct is frustrated because you are trying to hold an instructional, knowledgable demeanor when it's very obvious that you have no idea what you're talking about.

I'd prefer if we could keep nonsense like this out of the unity forums, so lets just call this thread closed.

 

Did you really post that code if your own post had no meaning? You clearly understood where i was going with this.

 

I'm with @Ironmax on this one.

I also think Unity needs to integrate a "Make MMO" button, since that would save a lot of people so much time in making their games.

And would it kill them to have a couple gun models included and some pre-made levels so I can get my FPS off the ground sooner?!

 

To be fair, this code has some potential pitfalls. If you are quibbling about the few bytes of garbage created by coroutines, it's worth looking closely at this too.

It will suffer from accumulating floating point errors each frame. This is typically not a huge deal, but the accuracy will effect some games. Coroutines and invoke do not suffer from this problem.

A bigger accuracy issue is abandoning the partial deltaTimes where the second mark is crossed mid frame. Coroutines will face this problem, I don't believe invoke will (but it's worth checking).

If you want performant code, but are not overly concerned about accuracy, use a coroutine. If you need more precise time, and performance is not an issue, you are better checking against Time.time instead of using Time.deltaTime.

Either way if you really need this functionality, it's trivial to build into your own functionality.

 

Good luck using Coroutines IEnumerator interface for every situation in your project. Your going to have some problem if you want to return data. Your just looping through generic collection, and there is no way you can check how many and what is running. Floating point errors with the code i posted have no place in reality. The code is taken from Unity expert advice http://docs.unity3d.com/Manual/MobileOptimizationPracticalScriptingOptimizations.html

Also Coroutines does work in relevance to frames, since Yield will wait for next frame
based on your time.

You can of course make allot of messy code and call it your own solution. You don't have to comprehend the meaning of this thread.

 

Return data to what? A custom timer in Update doesn't return data either. In both cases you are limited to manipulating state, rather then returning values. You can do this equally well through any of the methods described. Coroutines actually have the advantage of being able to declare local state that can persist between frames.

There are advantages and disadvantages to every method mentioned in this thread. Insisting one method is superior or inferior is silly. Use the method that best suits your project needs and be done with it.

 

What data? Any data.. You can make some Lambda and CPU costy code, but not very good idea. Thought it would work.

Code (CSharp):

1.  
2.     bool LogicSystem(bool timesinceLastEvent)
3.     {
4.         return timesinceLastEvent;
5.     }
6.  
7.        void Update(){ //<---- bad practice for logic implementation
8.  
9. // Update returns type
10.         LogicSystem(true);
11.  
12.         }

Point is, you cant put all your logic code in 1 coroutine because you are limited from returning values and you need to return time for each sequence, you have to make many. Its messy, and not very controllable. You might wonder why Microsoft made MVC, they made the logic implementation better and removed it from the visual area. Not really direct comparison but still.

Don't get me wrong, i love coroutine and i use them allot for sequence of events, like animation sound or skill duration. I don't want any of the current methods altered or removed.

Example:
Lets say you have 10 coroutine and 20 objects constructed with own Time.time logic.

Then the big question is, how many time dimension do you have? Second question, how are you going to control that..

Actually BenZed class solution is exactly what am talking about. But working with time like this should be a standard. Since I see allot of people put there logic in to Update method. Makes sense doesn't it? For me personally its not a issue since i have my own implementation long time ago.

 

Microsoft made MVC......... LOL!

It's only that MVC predates the company Microsoft by a few years.

I honestly still don't understand what it is this accomplishes precisely. I read that "link" you told me to read, still no clue what you're talking about. It's not as "clear" as you said it would be if I did.

 

The forest, no trees, just forest, i stumble over trees, yet i see no trees, i have no clue about trees yet i am in the deep forest.

 

There's an MVC framework for ASP.NET named... MVC. Because Microsoft.

Since how often the user wants to run a timed event varies, creating a specific one for "every second" isn't really a good option. You could bake the frequency into the method name, and have the engine parse that with reflection to run the method at the right times, but...

Honestly, this is exactly what InvokeRepeating does. It's a shame that InvokeRepeating doesn't take method arguments (boo string based programming!), but implementing that as an extension method is trivial. It's also more flexible than a specific method that does something every second.

Also, @Ironmax, your particular combination of arrogance, linking senior forum members to basic manual pages, and poor spelling is not going to win you any respect or friends.

 

Please, please, honestly. I'm begging you.

Tell me what it is I don't see!?

Is it the garbage collection issues?

Is it the fact that if you 'wait for 1 second' it's actually not going to be exactly one second (though the Update method isn't either)?

Is it that you don't like to have to call 'Invoke' or 'StartCoroutine' in the OnEnable/Start function?

Is it that you don't like that every component has to manage its own ticker/timer to wait some duration, rather than be event driven (like MVC is)?

What is it that 'UpdateOnInterval()' function does that these other options don't do? Please, inform me as to what it is that isn't clear to me, but quite so obviously clear to you.


It's not I can't see the forest through the trees... I see the forest of APIs and frameworks all about me. I just don't see the one specific tree that seems to be calling out to you. So help a developer who has been writing .Net for 10 years on a professional level what it is he doesn't see that you find so damn obvious.

Who knows, maybe I'm missing something here. Maybe you really have tripped over some paradigm I've never even considered thinking about. So educate me... I'd love to learn new things.

But as far as I've seen you have vague quibbles with the effort needed to perform an 'on interval'. That there should just be a 'name function this and it works' method to programming. And you're not willing to accept the rationale for not having the inclusion of a message that is interval based. What if I wanted a 2.3 second interval, and you wanted a 5.4 second interval??? How would one define this!? How with your approach would you write this???

Code (csharp):

1.  
2. void UpdateOnInterval2_3()
3. {
4.  
5. }
6.  
7. void UpdateOnInterval5_4()
8. {
9.  
10. }
11.  

????

What if my interval of 2.3 changes to some other interval depending. What if I have a 'brain' script for my entity that thinks on a 0.1 second interval, but I make another brain that thinks on a 0.2 second interval (which I DO have!)... how do I change between the intervals with out having to write an entirely NEW class? How can I abstract these concrete methods into more generalized interfaces?

 

Stop with this child nonsense please, and get out of my thread. Your not making any sense or being constructive.

I told you that Coroutines IEnumerator have limitations, if you where able to read, you should see that you cant return types or control the collection of running Coroutines.

But you keep nagging with nonsense like a 12 year.

 

OK, will do, I obviously won't get the response I'm requesting.

This conversation is quite obviously going no where.

 

The good thing with ignorance is that you get what you want (obviously). You dont need to reason or comprehend a conversion, you already have your answer. Nobody said any thing about 1 second limitation, gj..i said timebased..Read? Comprehend?
Do you want me to quote my own posts now? I am in kindergarten ?

 

So how is that working for you?

What your asking for should not be built in. There are many ways to do so with the tools provided. Could subclass MonoBehavuour and built the functionality into your new class. Could just make a timer class and instance it in where wanted. If you don't want multiple timer instances you could just make a timer object as a MB, that has some static events other objects to subscribe to.

 

- Limit control
- Limit overview
- Time Dimension
- Workaround home made classes or hacks.
- Mix of design and logic structure (the point with pointing at mvc) If you cant comprehend dont post.
- Performance issue
etc.

 

Ya but your idea of a Interval Message like the Update one, solves no of the issues you bring forward any better than any of the other solutions, which work and perform fine.

 

I never said it would be like Update one. I said the opposite. A new better Method with Time control rather than frame control. Got it? Courtines obviously don't do the job, because of its limitation that i have explained 3 times now.

Let me ask people here, that clearly have some understand of Unity codeing.

Why do you think Unity made LateUpdate in the first place? We can just construct our logic
with Update() to jump to last frame.. right? No need for LateUpdate we can just invoke. Sure i can even make my own "OnEnable" class and put it in Update..

Your not putting your logic under FixedUpdate are you? Of course not..

 

I am not here to win any thing, i have no personal desire to do so. I left my epeen long time ago. I just pretend that this is a normal forum where you can disuses things in a normal constructive fashion.

 

Let me quote the documents on that one -

So you could use LateUpdate for stuff that needs to interact with stuff that moves before it. As in, the example they provided. Not because it i some x second stuff.

Ironmax, you are speaking tripe. You have been told many times about solutions that exist within Unity that can provide interval based logic. Using these, you can write your own system where events are triggered every x seconds. It is trivial to write a simple singleton that could allow other to register to an on x second event system.

Now, your manner in this thread has been awful. People have questioned why you would need this and have told you why you Unity doesn't need this. See above. Yet you haven't, once, given any kind of constructive counter argument. You are trying to sound like you are some expert, when it is evident that quite the opposite is true. Quoting forests and trees really? Could you been any more belittling?

 

** Ignoring drama jibb jababa j.. ***
So since you quoted and copy/past the correct explanation you agree that there are needs for more than1 Update method
for different situations. Even we could have used another implemented tools to achieve the same thing, doesn't mean
you have to..

We could have manged just fine without Coroutines also.. But Its there for a reason..you can argue all day if you want.

The question you didn't answer is why.. I tell you why : Because it helps make things simpler, and faster for the developer.

What is awful is that the majority of new developers put all there logic in to Update method. Because the tools that can be used are not made simplified for them. I bet many of the poster here use distance check in Update even without quad, its not a good practice.You don't have to be an under the "hood" Unity expert to know this.

Working with frame is not the same as working with Time. Period.

 

Insanity. Only plausible explanation. Good luck guys, but I'm out on dealing with this.

 

It's okay. Programming doesn't come easy to some of us- it takes a lot of time and effort. If you keep at it, and you don't give up, you'll get there eventually though. I have faith in you! Just get some books on C# (maybe some on basic logic too), do some tutorials, maybe pick up a few demos from the AssetStore and go through them line by line, and slowly but surely you'll get better and better. One day, you might even be able to hold a sensible conversation on the subject! I look forward to it.

Your 3D models aren't bad, so let that knowledge hold you over for awhile I think, while you learn and grow into this new field you've decided to transition into.

 

Hehe funny guy, i have plenty of dev books in c++ java and csharp + lots of others. We see in other threads if i care to teach you or confuse you down your own codes. I have 16 years of code development experience. How about you? My 3d experince are just bonus. The last code i saw you made you allocated a var inside a custom object. Maybe you can teach me about overheads and what happens on the heap / stack?

 

Just ignore him, guys. Pretend the thread has been closed.

 

How about you leave my thread and stop pretending to be a moderator? It is against the forum rules + your not contributing nor stying on topic.

 

How long have you been coding Ironmax? How long have you been using Unity?

What you're talking about can be resolved pretty easily using built in functions. Arguing the point because you think people dont get where you are coming from just makes you look stupid, especially when you are arguing with people who are obviously more advanced in both coding and Unity.

Main use for LateUpdate is to update postion/rotation after animations have been run. But you already knew this right...

 

Obviously people here are so advanced that they can't even read or comprehend. Obviously people here are more advanced in coding than me since they allocate variables inside an object, and put it in to Update. And your Inferno game James are clearly more advanced than any of the games I made. You lack skill in both Unity design and coding. Your camera behaviour looks strange in all your games., yet you come here with big mouth thinking you know me ,or my projects. That is pretty rude and stupid at the same time.

LateUpdate main use is for execution order. It all depends what you put in update, what you put in lateupdate, Camera movements that follows character example, you also failed on understanding the reason why i took LateUpdate as and example, maybe you just have short memory, and couldn't get that far with your answer? I have to assume something..

I am not very impressed with the level of intelligence here, not going to wast more time explaining simple things, or repeat my self because people cant read.. I don't force you to comprehend the difference with frames and time. Going personal attack on me, is just immature and pointless.

 

Wow, someone has delusions of grandeur

This is my last comment to be honest, people have tried to reason with you - stated their opinions. Explained how, if you need such a system, you can build it with APIs and methods available in Unity already.

People have even given you working solutions in this thread.

Yet, you will not be happy until Unity implements a specific system that you want for you. Even though it provides all the tools you need to implement that system yourself.

Update, FixedUpdate, LateUpdate all exist because they are general methods that game objects will probably use one or two of. Not all game objects require an On1SecondExpired, On2.4342SecondsExpired event. These are very specific requirements - Unity provides the tools for you to easily implement them yourself - Coroutines, counting time in FixedUpdate. Then Using SendMessage or delegates to invoke those methods on GameObjects that have them.

You have failed to argue these points - just saying Unity should have it and then personally attacking people who present solutions and arguments against it.

Go ahead, please enlighten me.

The same could be said about you based on your replies here.

This is exactly what I quoted from the documents. This and doing stuff after animations have been updated as JamesLeeNZ said. You are trying to show this as your opinion, like you knew all along

 

You don't know the difference? Lol .. okey..

 

stop posting stupid pictures and nonsense in my thread, if there is any trolling here, its clearly you Lordofduct. Now stop with this..

 

In response to a very basic example for a novice demonstrating that a coroutine can accomplish moving an object. Ironmax says to me, derailing someone else's thread:

As well as:

I respond with:

With that said, I'm bringing it back to HIS thread rather than pollute Sticky's thread with Ironmax's opinions.



So, please, DO tell me why declaring a float and 2 vectors as field members of the class this method would be in is OH so much better than if those values were declared in the function where they were used. What benefits are there for this?

Why should I increase the object size of the class rather than the keep them scoped to the only place they're needed in the function that is being called?

Because I should "never allocate a var inside an object"? Oh, and in what magic places are those vars being allocated when scoped as a field member of a class? Because as far as I can tell, classes are constructed into objects, and they're allocated as members of that object.

 

@lordofduct

Really I am done with him. He posted some nasty stuff on
@JamesLeeNZ RTS project thread as well. Also attacked me in another thread. Strange that we happened to be the people who disagreed with him. Just coincidence though, right?

This thread needs to be closed to be honest. Although it makes me laugh.

 

More sane reading for Lordofduck ..go read it..and get sane
https://docs.unity3d.com/353/Documentation/Manual/iphone-Optimizing-Scripts.html
and another one from Unity:
http://docs.unity3d.com/Manual/MobileOptimizationPracticalScriptingOptimizations.html

I make it clear for you since you have problem reading:

Avoid Allocating Memory
You should avoid allocating new objects unless you really need to, since they increase the garbage collection overhead when they are no longer in use. You can often reuse arrays and other objects rather than allocate new ones and doing so will help to minimise garbage collection. Also, you should use structs instead of classes where possible. Struct variables are allocated from the stack like simple types rather than from the heap like object types. Since stack allocation is faster and involves no garbage collection, structs will often improve performance if they are fairly small in size. While large structs will still avoid allocation/collection overhead, they will incur a separate overhead due to "pass-by-value" copying and may actually be less efficient than the equivalent object classes.

 

Yes I understand how garbage collection works.

And I understand about mitigating the penalty incurred by it.

But I also understand how to write scalable code, and I do optimization where needed when needed when targeting systems that will need that. Since I don't write many mobile apps, I don't need to waste my time complicating my code so as to save an extra 4 or 8 bytes here or there.

Or as I break down more concisely for Articus in another thread:
http://forum.unity3d.com/threads/ho...n-a-single-function-call.345331/#post-2233753

A thread mind you where you actually gave advice that increased heap memory usage. Because you made the mistake of assuming Articus's example code contained functions that created objects... which they don't. Iterator functions do (those used by coroutines), but not regular old functions. The state of those just sit on the stack, and by moving the variables used in the scope of them to the scope of the class, you've actually increased the memory foot print of the object made of the class.

As well as incurred some possible scope issues that render the function single stated, so that it can't be used in easy subsequent calls.



Listen ironmax, you have to reduce use of objects. But you can't completely AVOID it. Because objects are how we represent state. And if the operation we're performing requires state... we need to maintain some state. Yes, this will incur some heap memory usage... but that's the cost you pay to get the results you want.

If you wanted to keep the heap free of allocations. You wouldn't have a game. Because just creating a GameObject in scene costs heap memory!


You seem to believe I'm some uneducated simpleton who has never written code in his life.

I've written commercial software for years for various companies, software used through out the world by businesses every day to run their multi-million dollar companies. I now write video games with my partner who is a veteran of an Activision studio working on titles like 'Guitar Hero', 'Transformers', and 'Marvel Ultimate Alliance'.

We know how to do our job. And I know how to do a cost/benefit analysis of my practices.

Other members on this forum also have years of experience with what they do. They hang out here to SHARE each others knowledge and opinions, as well as hoping to learn something new.

Clearly you write a lot of mobile apps, garbage collection is a concern for you and not for me. The requirements of my software, to meet the needs of my customers, don't require me to concern myself with GC as much as you do. That doesn't make me wrong, or you wrong, it just means we have DIFFERENT use cases.

So please... SHARE your ideas and opinions. But don't act like you know exactly the one and only right way of doing this, and that the rest of us are morons basking in the awe of your pure genius.