MultiTimer

[sdphantom]

Here's another script that I wrote that allows the user to setup a numerous amount of timers, limited to 254 that can be stored by the config file. The script is made to be capable of handling an unlimited number of timers itself though.

Download Here

The idea of having timers saved to config is for some need to keep track of timers that span several hours (ex. Signal Pearl, Warp Cudgel, EXP Rings, etc.), even through the event of the script being shut down for any reason.

The timer is made to continue counting down even while it's not running by storing the expected expiration time (provided by the system clock and the delay offset given by the user) instead of how much time is remaining. This script was designed around keeping track of the massive cooldowns that some items have, not really for how long effects last. (Later versions may supply different timer behaviours by type.)

All timers are identified by the name that is given to them. Using the Set command on an existing timer will overwrite it with the new duration and will reset it afterward.

The config file is updated everytime the display is moved or any timer is set, reset, or removed (including when the clear command is executed).

MultiTimer v1.0
	Written by Zytre
	[e-mail]

Introduction:

MultiTimer allows the user to create and manage the use of timers displayed on FFXI.
As a feature, all timers are saved in a config file and are reloaded when the script starts.

Commands:
-Commands are case insensitive.
-All arguements are required.
-All commands may be combined and are seperated by a single space.

	move <X> <Y>
		Moves the display to coordinates (<X>,<Y>) on the screen.

	set <name> <duration>
		<name> may be incased in quotes.
		<duration> is timer length in seconds.
		Creates/Sets timer <name> with length <duration>.

	reset <name>
		<name> may be incased in quotes.
		Resets timer <name>.

	remove <name>
		<name> may be incased in quotes.
		Removes timer <name>.

	clear
		Removes all timers.

	exit
		Closes the script.

History:
	v1.0
		First public release

[TinyTerror]

I got rid of the double post for this topic

[sdphantom]

admin said:

I got rid of the double post for this topic

Heh, thx ^^;
Thought it was weird when I did the first edit, nothing poped up saying "edited <whatever time>"

[DarkAquaus]

just thought I'd go to say is if script is terminated time will be way off because script ended.
Id suggest to make it a totally sepporate script not dependent on the windower using strait LUA and then using a "read" script to show info to the user >.> or something... caus if the read script crashes with luna then the info will not be lost caus u would just need to reload it and the reload would just look at the primary script for its info when the user requests it. or when the timer is up or somethin >.>

[sdphantom]

darkaquaus said:

just thought I'd go to say is if script is terminated time will be way off because script ended.
Id suggest to make it a totally sepporate script not dependent on the windower using strait LUA and then using a "read" script to show info to the user >.> or something... caus if the read script crashes with luna then the info will not be lost caus u would just need to reload it and the reload would just look at the primary script for its info when the user requests it. or when the timer is up or somethin >.>

Can you be more specific? Like the lengh of time the timer was set, the values the countdown was at both when you unloaded and reloaded the script, how long the script was unloaded.

Also, the timer was made to continue counting down even while it's not running by storing the expected expiration time (provided by the system clock and the delay offset given by the user) instead of how much time is remaining. This is a feature by design, not a bug. (I guess I should've been more clear about that.) ^^;

This script was designed around keeping track of the massive cooldowns that some items have, not really for how long effects last.

Maybe in a later version, I'll put in an option to pause the timer, which you'll need to do to preserve the countdown state before unloading the script. This'll be more helpful for some other things.

[kodama]

Nice work, using it right now to keep track of NM pops ^^

btw, it took a while to figure out how to feed commands to your script (I havent used lunar for a while) ^^

Incase anyone else forgot this. For example to set a timer you type this is the terminal.

.Lunar command multitimer.lua set test 10

[sdphantom]

I'm working on a newer version that is a bit easier on the eyes to look at. It's all in color and the timers are color-coded to tell when a timer is still counting down, hits critical state (reaching within 10 seconds of expiration), and when the timer has expired. The new version also says how long a timer has expired by displaying a negitive value.

I'm also putting in the capabilities to put in different types of timers. Temperary timers won't be recorded in the config file and will be lost when the script is exited. Consistent timers behave exactly as the current version does, the timers are stored and it continues acting as if the timers are counting down even if the script isn't running. Runtime timers will be stored in config as well, but are considered paused while the script isn't running.

I'll have to bump the config file version, so the old config file won't work with this. Config file versions are auto-detected. I designed the code at the beginning to write the version number to the first byte of the config file.

---

After puting in the code for the different timer types, I've chosen that runtime timers actually take too much time to be constantly updating the config file as needed after every display update. The config file is being reverted back to version 1 since the timer type identification byte is no longer needed.

I'm still going to put in code for temperary timers, all that's needed is a flag in the timer array that tells the code whether to include that timer or not in the config file.

On another note, there is a delay between each line being updated. I'm looking at ways to optimize the code and make it run faster.

[sdphantom]

Ok, the newest version (MultiTimer v1.1) is almost ready for release. I just need to smooth out the code a little and update the readme. I also have some ideas on code that accepts formatted input for time, such as H:M:S or just M:S as well as accepting a straight seconds value. This'll push the release for the new version back a bit, but shouldn't affect the look of the output.

Here's a screenshot of the new version so far.

Ya, I got lazy and started using just numbers for the names of the timers. -.-;
Oh, and "<Temp>" is added by the script to indicate a temperary timer in case anyone was wondering.