Exactly what moosh said. Most beginners only import std out of habit, and by the time people start importing other directories for use in creating scripts, they likely know What the number 100 is.
No offense, but this is pretty useless.
- Current Location:
- PureZC
- » PureZC Forums
- » Scripts
- » Timers.zh
Timers.zh
Overview
Creator:
Timelord
Updated: 24 Sep 2014
Tags:
Global,
Library
Downloads: 29
|
View Script
Download Script (5.58 KB) |
Information
Timers.zh is a set of library functions to use at a local, or global scope. that allow the easy implementation of timers in ZC quests.
Description Setup Reviews Comments
Timers.zh is intended for users of any level of experience, but it would be best for users who understand how constants work, and how to implement functions in other code.
This library file includes one array, with an index size of '10', and assigns dummy constants to each of these ten elements. You will need to modify this to suit the needs of your game.
Otherwise, the main functions run inside any type of loop (e.g. the main while(true) loop of your global active script), and the functions to set, or re-set the timer, or to check the timer values, can be called from anywhere. This code includes an example global active script.
This library file includes one array, with an index size of '10', and assigns dummy constants to each of these ten elements. You will need to modify this to suit the needs of your game.
Otherwise, the main functions run inside any type of loop (e.g. the main while(true) loop of your global active script), and the functions to set, or re-set the timer, or to check the timer values, can be called from anywhere. This code includes an example global active script.
Set-up of this library is not technically complicated, but can be time-consuming, depending on how many timers you need, and how you want to remember them, and their values, when using functions in instructions.
The included ZIP archive contains a basic list of commands in a text file, with details on usage.
Detailed information on using Timers.zh follows, that assumes you are a novice at ZScript.
A Note About Arrays
This library uses a single array to hold all of its timer values, and the default array has ten (integer) elements. Thus, if you need more than ten timers, you will need to expand the side of the array.
It looks like this:
Next, you will need to define your constants, so that they'll be useful.
Constants Set-Up
The header includes dummy constants for the included array, TV_MYTIMER_1 , to TV_MYTIMER_10 , that you should change to something you will easily remember, that doesn't conflict with other defined constants, or variables. For this reason, it's best to use a prefix--in this case, TI_, for TImer, and later TD for Timer Duration--followed by the name of the timer. TD_DUCK, or TD_EXPLOSION, would be good examples of easy to remember constants.
The number on the right side of these constants matches it to the array, so that you can easily modify the timer values, later.
If you have expanded the size of your array beyond 10 elements, you will want to add more constants for your additional timers here. The first element of an array is '0', and for that reason, TV_MYTIMER_1 = 0 : A reference to TV_MYTIMER_1 is passed as the value '0, when reading from, or writing to the array.
You may assign multiple constants to one index value, either for the purpose of naming conventions (e,g. TV_RED, TV_RUBY), or for other reasons; however you will want to avoid this unless you intend to use either term to reference the same timer.
The next set of constants, is a series of Duration Values, with the prefix 'TD_' (Timer Duration). These are not assigned to the array indices, but rather, they are a count (in frames) for pre-set durations. You may want to establish your own naming here too, but I've provided a list of pre-defined time durations, including fractional-seconds, seconds, and minutes.
You may use these as-is, and utilise multiplications thereof, or combinations thereof, to define durations; else specify a duration directly in an instruction,
Note If you need very long timers, you may need to use tiered timers to expand beyond the ZC MAX_INT limitations.
You will see that the number to the right of these is the length, in frames, for that constant, so if you have any durations that you expect to need commonly, this is the place to add them.
Note: You can manually enter values for timer durations as numbers, when coding instructions.
Using the Libraries
Once you have established your values, you can begin using the functions. The code includes a sample global active script, that runs one timer.
Timer Initialisation
The idea is that for each timer that you have running, you run this pair of functions:
The second, when running in any loop, that has a Waitframe() instruction at its end, will decrement the same timer by '1' each frame. It is also overloaded to accept a custom value that you may specify:
The setTimer() function will not reset the value of the timer when run in a loop, until[/i] that timer reaches '0'; and when that happens, it will automatically reset to the value specified as TD_TIME.
Using Timers
To use these timers, you call upon either the boolean functions checkTimer() and zeroTimer(). The first, checkTimer is less sensitive, and will return 'true' when the timer is at 1, or less; whereas the second, zeroTimer() is strict, and returns 'true' when the timer is exactly zero.
You may call these as any boolean condition:[/i]
As an alternative, you may use the function returnTimer() to read the exact value of the timer, and use that as a condition. This can be useful in some circumstances, and you may use this with conditional statements (if, else, else if) similarly to the boolean conditions, or write custom-defined booleans to meet your needs.
Usage Syntax:
Example:
Advanced Use
The above, is the most basic usage of this library, and Timers.zh includes methods of multiple, en-masse timer creation, and manipulation. Please read the enclosed documentation for more information.
This version (v1.5) released on 24th September, 2014, requires no other libraries, or headers.
The included ZIP archive contains a basic list of commands in a text file, with details on usage.
Detailed information on using Timers.zh follows, that assumes you are a novice at ZScript.
A Note About Arrays
This library uses a single array to hold all of its timer values, and the default array has ten (integer) elements. Thus, if you need more than ten timers, you will need to expand the side of the array.
It looks like this:
int Timers[10]={0,0,0,0,0,0,0,0,0,0};Simply change the value '10' to the value that you need (max 214747), and add additional zeros to the set, separated by commas; save for the last value, that should not have a comma. (See above.)
Next, you will need to define your constants, so that they'll be useful.
Constants Set-Up
The header includes dummy constants for the included array, TV_MYTIMER_1 , to TV_MYTIMER_10 , that you should change to something you will easily remember, that doesn't conflict with other defined constants, or variables. For this reason, it's best to use a prefix--in this case, TI_, for TImer, and later TD for Timer Duration--followed by the name of the timer. TD_DUCK, or TD_EXPLOSION, would be good examples of easy to remember constants.
The number on the right side of these constants matches it to the array, so that you can easily modify the timer values, later.
If you have expanded the size of your array beyond 10 elements, you will want to add more constants for your additional timers here. The first element of an array is '0', and for that reason, TV_MYTIMER_1 = 0 : A reference to TV_MYTIMER_1 is passed as the value '0, when reading from, or writing to the array.
You may assign multiple constants to one index value, either for the purpose of naming conventions (e,g. TV_RED, TV_RUBY), or for other reasons; however you will want to avoid this unless you intend to use either term to reference the same timer.
The next set of constants, is a series of Duration Values, with the prefix 'TD_' (Timer Duration). These are not assigned to the array indices, but rather, they are a count (in frames) for pre-set durations. You may want to establish your own naming here too, but I've provided a list of pre-defined time durations, including fractional-seconds, seconds, and minutes.
You may use these as-is, and utilise multiplications thereof, or combinations thereof, to define durations; else specify a duration directly in an instruction,
Note If you need very long timers, you may need to use tiered timers to expand beyond the ZC MAX_INT limitations.
You will see that the number to the right of these is the length, in frames, for that constant, so if you have any durations that you expect to need commonly, this is the place to add them.
Note: You can manually enter values for timer durations as numbers, when coding instructions.
Using the Libraries
Once you have established your values, you can begin using the functions. The code includes a sample global active script, that runs one timer.
Timer Initialisation
The idea is that for each timer that you have running, you run this pair of functions:
setTimer(TI_MY_TIMER,TD_TIME); reduceTimer(TI_MY_TIMER);The first instruction, initiates the timer that you specify as TI_MY_TIMER, with a staring count of TD_TIME.
The second, when running in any loop, that has a Waitframe() instruction at its end, will decrement the same timer by '1' each frame. It is also overloaded to accept a custom value that you may specify:
reduceTimer(TI_MY_TIMER,3);This would reduce a timer by a value of '3' per frame.
The setTimer() function will not reset the value of the timer when run in a loop, until[/i] that timer reaches '0'; and when that happens, it will automatically reset to the value specified as TD_TIME.
Using Timers
To use these timers, you call upon either the boolean functions checkTimer() and zeroTimer(). The first, checkTimer is less sensitive, and will return 'true' when the timer is at 1, or less; whereas the second, zeroTimer() is strict, and returns 'true' when the timer is exactly zero.
You may call these as any boolean condition:[/i]
if ( checkTimer(TI_MY_TIMER_1 ) { //Do something }Whatever instructions you placed where 'Do something' is noted, would execute when the timer TI_MY_TIMER_1 dropped below a value of '1'.
As an alternative, you may use the function returnTimer() to read the exact value of the timer, and use that as a condition. This can be useful in some circumstances, and you may use this with conditional statements (if, else, else if) similarly to the boolean conditions, or write custom-defined booleans to meet your needs.
Usage Syntax:
checkTimer(TI_TIMER); zeroTimer(TI_TIMER); returnTimer(TI_TIMER);The remaining function allows arbitrary manipulation of timer values.
Example:
changeTimer(TI_MY_TIMER,151);This would set the timer 'TI_MY_TIMER' to a value of '151', without regard to whatever value it holds at present.
Advanced Use
The above, is the most basic usage of this library, and Timers.zh includes methods of multiple, en-masse timer creation, and manipulation. Please read the enclosed documentation for more information.
This version (v1.5) released on 24th September, 2014, requires no other libraries, or headers.
Moosh
Edited 23 September 2014 - 10:22 PM
This header contains only functions and constants for things that can easily be done without them. I do not need a constant for the length of two and a half seconds in frames, nor do I need a function to set or check a global variable. For that matter, I don't need a global array for most cases where I'd use a timer. So not only is the header redundant, but it's only situationally useful. To put the icing on the cake, the setup instructions are longer than the header itself.
And then I just noticed this:
And then I just noticed this:
const int TD_100 = 100;This is the single most redundant constant I've ever seen. And I'm the guy who once didn't know you could convert hex to decimal in ZScript and tried making constants for it.
- Joelmacool , Twilight-Prince and HavoX like this
Timelord
Posted 24 September 2014 - 01:51 PM
Because you asked, that's a list of constants that I use in my RPG framework, and the odd durations are used in formulae, such as (2p5_SECONDS * MIND), or (1p5_SECONDS * Level). I did remove the majority of those constants in the update. Most people will never need to do such convoluted calculations, and can suffice with ( TD_ONE_SECOND + TD_HALF_SECOND ) to build their own duration instructions.
(The update from today, also manages to make far better use of the global scope of the library, which is the prime reason for the updated version, for this is still very much a work-in-progress, like everything else that I'm doing...)
I did leave the Trace commands in the sample script there (in v1.0), intentionally, for novice users to test if their timers work (as an example of how to do that). You'd be shocked how few people know that Trace(), and TraceB() exist, let alone know how to use them, especially with syntax involving functions that have arguments.
The latter part, is why I left them intact; however, I did disable them with comment marks in the update, so that people who need the syntax will have it; but they won't flood allegro.log.
The 1.5 release should give some shape, and context to what I'm making with this library, assuming that PZC didn't eat it. I had to edit it, twice, because of errors, first with a triad of typos not caught by the compiler, and then (again) because PZC decided to add BR marks to every line; at least when I viewed it.
It also has a ZIP download option, that has the library, plus a much simpler, and straightforward usage guide, Timers.zh_v1.5_.txt, for people who will understand it without detailed explanations.
I never pre-imagine a target audience that knows what they're seeing: Many of the requests that I've received are from people that could modify some code, but can't create it; or won;t create it, and a good assortment of the recent requests have needed some kind of timer system, so instead of adding singular timers everywhere, I just started implementing exactly what I'm going to be using in my own games.
IMO, that makes it much easier to produce things for people in a streamlined manner, and in a way that won;t conflict with later things that I publish that they may want to use. (This allows me to make somewhat complicated FFCs, and such, that can all share one timer system that I know, inside, and out.) You may have noted that I have a tendency to make dependencies a part of quite a lot of my shared code, for this exact reason.
I don't think that requiring someone to import a library is anywhere near as bad, as using variables in multiple scripts that, when a user attempts to mash together, fail because the variable is shared; although I suspect that I'll need to keep track of how many scripts use a timer from this point onward, so that I update the declarations to always have enough elements, so that they never conflict. Perhaps, that's just, and righteous punishment for volunteering so readily to make things for other people.
(The update from today, also manages to make far better use of the global scope of the library, which is the prime reason for the updated version, for this is still very much a work-in-progress, like everything else that I'm doing...)
I did leave the Trace commands in the sample script there (in v1.0), intentionally, for novice users to test if their timers work (as an example of how to do that). You'd be shocked how few people know that Trace(), and TraceB() exist, let alone know how to use them, especially with syntax involving functions that have arguments.
The latter part, is why I left them intact; however, I did disable them with comment marks in the update, so that people who need the syntax will have it; but they won't flood allegro.log.
The 1.5 release should give some shape, and context to what I'm making with this library, assuming that PZC didn't eat it. I had to edit it, twice, because of errors, first with a triad of typos not caught by the compiler, and then (again) because PZC decided to add BR marks to every line; at least when I viewed it.
It also has a ZIP download option, that has the library, plus a much simpler, and straightforward usage guide, Timers.zh_v1.5_.txt, for people who will understand it without detailed explanations.
I never pre-imagine a target audience that knows what they're seeing: Many of the requests that I've received are from people that could modify some code, but can't create it; or won;t create it, and a good assortment of the recent requests have needed some kind of timer system, so instead of adding singular timers everywhere, I just started implementing exactly what I'm going to be using in my own games.
IMO, that makes it much easier to produce things for people in a streamlined manner, and in a way that won;t conflict with later things that I publish that they may want to use. (This allows me to make somewhat complicated FFCs, and such, that can all share one timer system that I know, inside, and out.) You may have noted that I have a tendency to make dependencies a part of quite a lot of my shared code, for this exact reason.
I don't think that requiring someone to import a library is anywhere near as bad, as using variables in multiple scripts that, when a user attempts to mash together, fail because the variable is shared; although I suspect that I'll need to keep track of how many scripts use a timer from this point onward, so that I update the declarations to always have enough elements, so that they never conflict. Perhaps, that's just, and righteous punishment for volunteering so readily to make things for other people.
Evan20000
Edited 24 September 2014 - 12:11 AM
const int TD_60_SECONDS = 3600; const int TD_1_MINUTE = 3600;ಠ_ಠ
Why are there so many constants for increments of a second or minutes? Wouldn't it make way more sense to TD_1_MINUTE*Amount instead of having a needlessly large amount of constants? Also, this is stuff that almost all scriptwriters already know (people who are the target audience for header files).
while(true){ setTimer(TI_REPEAT,TD_1p5_SECONDS); reduceTimer(TI_REPEAT,1); Waitdraw(); Trace(returnTimer(TI_REPEAT)); //Prints vale of timer TI_REPEAT to allegro.log Waitframe(); }Why are we flooding allegro with timer values in the release version of a header?
- HavoX likes this