Jump to content

Timers.zh

Overview
Creator: Timelord Updated: 24 Sep 2014 Tags: Global, Library Downloads: 29
Rating[?]: Rating: 1/5 (2 ratings)
View Script Download Script
(5.58 KB)
Information

Description Setup Reviews Comments

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.
 

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