[Release] TimeOut functions

03/24/2015 23:51 pintinho12#1
Hello guys, i think this will be my first real contribution to the forum. By the way, it's nothing so hard to do heheh.

I've been working on my WCProject and on the Battle System that is based on Demons Source, i noticed that they have those classes implemented.
Firstly, i tried using what most sources use, DateTime and Environment.TickCount, I don't know if this class will save or spend more resources, but i don't need to rewrite Update and Reset codes all the time, and it got a lot easier to code timers with this now.

Note: This do not execute anything automatically, just stores the time.

First, you need a Unix Timestamp class, something to return Seconds and Milliseconds.
I will provide my code, if you have anything better to contribute, i will edit here.

Unix Timestamp.cs
*
Below, i have the TimeOut and TimeOutMS classes.
TimeOut hasn't been tested yet, but i am using TimeOutMS on my Meele Attack, and it's working like a boss.


I will provide commented code and examples later. ^_^
Hope it helps anyone #00

Almost forgot...
Calculations does contains this

03/25/2015 01:30 pro4never#2
Unless I'm blind and missing something, all that code is just a fancy way of dealing with unix timestamps and has nothing to do with actually DELAYING an action.

There's no threading referenced and there's no actions.

Not saying it can't be useful but just seems like a needlessly large amount of code when it's not actually accomplishing something.
03/25/2015 08:52 Xio.#3
[Only registered and activated users can see links. Click Here To Register...]

I wrote that a few weeks ago. Take a look
03/25/2015 13:59 -impulse-#4
This code has a bit more overhead than is needed. Instead of using DateTime to get the Unix time you could use Environment.TickCount which gives you more resolution to work with (milliseconds instead of seconds). The only "issue" with using Environment.TickCount over Unix time is that every 43 or so days the tick count resets to 0.
03/25/2015 14:27 pintinho12#5
This does not have anything to do with Threading.
I have an OnTimer method on my classes that will need things handled.
The point is that i can use var tm = new TimeOut(5); and check elsewhere with .ToNextTime() or .IsTimeOut()
When I get back home tonight I will check the sugestions, tho, this class works pretty fine, since i use both on my Status handlers, for shackle, fog, etc
Ty for the feedback.
03/25/2015 14:37 Xio.#6
Quote:
Originally Posted by -impulse- View Post
This code has a bit more overhead than is needed. Instead of using DateTime to get the Unix time you could use Environment.TickCount which gives you more resolution to work with (milliseconds instead of seconds). The only "issue" with using Environment.TickCount over Unix time is that every 43 or so days the tick count resets to 0.
Every 25 days and its a 100 ns increment not a ms increment. If you need more accuracy you can use the Stopwatch class.
03/25/2015 18:49 -impulse-#7
Quote:
Originally Posted by Xio. View Post
Every 25 days and its a 100 ns increment not a ms increment. If you need more accuracy you can use the Stopwatch class.
1 ms.

[Only registered and activated users can see links. Click Here To Register...]

And if you use Environment.TickCount as an unsigned number you get 49.8 days.
03/25/2015 20:43 Xio.#8
Quote:
Originally Posted by -impulse- View Post
1 ms.

[Only registered and activated users can see links. Click Here To Register...]

And if you use Environment.TickCount as an unsigned number you get 49.8 days.
Wow thanks, I thought Ticks is the same o_o

[Only registered and activated users can see links. Click Here To Register...]
03/26/2015 05:46 pintinho12#9
So, if i use that on this same function, i will save a lot of time then?
03/26/2015 13:11 -impulse-#10
Quote:
Originally Posted by pintinho12 View Post
So, if i use that on this same function, i will save a lot of time then?
Not "a lot" but that something adds up to a whole lot after a while. Yes, it's worthwhile changing your base (Unix timestamp) to the local TickCount. If you need stuff like day of the month you should use DateTime.UtcNow because it's a bit faster but for keeping stamps of seconds it's faster to use TickCount. Depends on the usage really.
03/26/2015 14:42 pintinho12#11
It's most used for methods that wont store more than a few minutes or hours, i believe the server wouldn't be more than a 2-3 days online without a restart, so i think that this will be great. I'll take a look at this tonight.
03/27/2015 01:08 U2_Caparzo#12
I checked your project, you are trying to make it the more similar possible to the EO source, so why not keep doing it that way, it may become a really useful resource for those who are much more familiar with C# than C++

Anyways, because of the topic i'm posting this :p , i coded a task scheduler few months ago as well, it was supposed to handle things like remove items from floor, effects, etc... i think that it's a decent one (except that the PriorityQueue is List based and insert should be far away from O(log n) ^^)

Use example:
Code:
        public static TaskScheduler TaskScheduler;
        static void Main(string[] args)
        {
            TaskScheduler = new TaskScheduling.TaskScheduler();
            ScheduledAction<string, string> delayedAction1 = new ScheduledAction<string, string>(Write, DateTime.Now.Second.ToString(), "This action is executed in the TaskScheduler thread");
            ScheduledAction<string, string> delayedAction2 = new ScheduledAction<string, string>(Write, DateTime.Now.Second.ToString(), "This action is executed in the ThreadPool");
            delayedAction2.ExecuteInThreadPool = true;  // default = false, false to execute the action in the TaskScheduler thread, or true to execute 
                                                        // in the ThreadPool, note that if the action takes too long to finish and is not executed
                                                        // in the ThreadPool, next actions may be executed with an extra delay
            TaskScheduler.Schedule(delayedAction1, 3000);
            TaskScheduler.Schedule(delayedAction2, 5000);
            Console.WriteLine("Actions added to the TaskScheduler at second " + DateTime.Now.Second);
            delayedAction2.Await();     // Blocks the thread untill the ScheduledAction has been executed
            Console.WriteLine("\ndelayed action 2 executed at second " + DateTime.Now.Second);
            TaskScheduler.Stop();
            Exit();
        }

        static void Exit()
        {
            Console.WriteLine("Press any key to exit...");
            Console.ReadKey();
        }

        static void Write(string value0, string value1)
        {
            Console.WriteLine("\n\t" + value1 + "\n");
            Console.WriteLine("\t\t[ThreadId=" + Thread.CurrentThread.ManagedThreadId + "] Original DateTime second: " + value0);
            Console.WriteLine("\t\t[ThreadId=" + Thread.CurrentThread.ManagedThreadId + "] Now DateTime second: " + DateTime.Now.Second);
        }
03/27/2015 01:43 pintinho12#13
Just came back from work and got some things to do, i will do a check on this later too, thanks. xD
I think that using while and Thread.Sleep() is awful, so those things might be useful to me.
03/27/2015 13:41 KraHen#14
Instead of Thread.Sleep(1) in a loop you can use WaitOne with a time parameter.
03/27/2015 20:59 -impulse-#15
Quote:
Originally Posted by KraHen View Post
Instead of Thread.Sleep(1) in a loop you can use WaitOne with a time parameter.
It won't make any difference. Other than beautifying your code, maybe. Although if you use WaitOne/Sleep in a piece of code, that code shouldn't really appear in lots of places in the source, because you shouldn't Sleep your working threads anywhere.

Probably off-topic:
Depending on the OS, Windows in our case, every thread has a given time span to do its job then when it calls Sleep(...) it sleeps at least the rest of that time span. For Windows it's 20 ms (+/-), so even if you trigger the event you called for WaitOne, it will still wait until the 20 ms are done.

Even more weirder, is that calling something like Thread.Sleep(20) would return one time after 20 ms and one time after like 36 ms.
Anyway, you can't really have a task scheduler that works with millisecond values under like 40. Unless I am wrong and someone knows a way to go have more accuracy, in which case I beg you to show me how.