As I've been going through the newest server engine I'm coding, I've decided to clean things up a bit, as well as streamline things a bit more, by using libraries to house different aspects of the engine code.

This tad bit of extra work has prompted me to go all out and cut any ties in the code that might require part of my engine.asl file and make them all function indepenently.

The very first of these small libraries is the Questnet Time Library. This library adds a simple 24-hour clock and all the variables, procedures, etc necessary for the clock & time to run.

While designed for Questnet, the Questnet Time Library will (and hopefully continue to) function fine in Singleplayer games as well.

The only thing I haven't included in the library are the commands to set the time or to view the time. The readme file explains and provides examples of how to create these commands. These commands were left out so that users could customize not only the commands, but the requirements to set or view the time as well from within their own code without the need of touching the library.

View the readme for use guidelines as well as installation help.

Download TimeLib.zip (2.89k)

Jees - that's kinda complicated isn't it?

Any particular reason you were doing it like that?

EDIT:
Oh, and you also forgot to use .Tick...

Still think you could have simplified ALOT of it though.

It's not too simplified because, I'm going to throw in 24/12 hour format preference and a calendar. But .Tick is a leftover from pulling it out of my old code you're right, so are the .Wizardtemp's , I'll snip that out at the same time.

I kept a lot of the unnecesary code around so it would be a little self-explanatory that the procedures were reading the clock information. Trying to show that multiple clock objects could exist and be customized. It could have been much simpler if I had just assumed only a standard clock as we know it, but the aim is to have it support an assortment of varying "clock" objects each running their own seperately scaled time.

This way you could have one group of people logged into your server playing your new game "Slimeslashers 9" together, and they can retrieve the time in their game world as, "2 bell tolls untill the high sun" and people chatting or viewing forums you host on your Questnet Server can still see the local server time, or the local server time +/- to match their local.

Yeah - I got the different clocks and everything - that's the reason I tought you had the object... Although - it'll only work with that object right now (not so hard to put in an array).

- Your wizardtemp's are there for a reason from what I saw - turning strings into numerics.

You asked me (very funny BTW - I had a good chuckle when I woke up) what I meant by simplified... I'd say that all your code cheks for time-setting within the various limits (which can be changed via the object - nice touch!)... But That doesn't REALLY need to be there since I don't think quest supports '-' numbers (or even if so - just cut off the - easily using a one-line command), and the other reason is that in 1 second it'll be reset to 0:00:00 anyway.

Another simplification is moving all the time checking, and object updating into the "onchange" of the variables... Either that or put the variable names' in an array and scan through them, checking/setting them with one function - but I don't know if quest supports variable-variable name setting (ie "set <#variablename#; John>")...

The "timeset" function only displays the time - minor niggle with the naming there... The whole hourset/minuteset procedures could be simplified if instead of .minute or .second - you put them into an array (Alex - does an array work with status variables?)... [0] [1] [2]... That way you just pass "1" or "3" to the procedure and it comes up...
Another way is to put it all on one function and have;

if ($param(?) = 1) then set <var.minute; #whatever#>
if ($param(?) = 2) then set <var.second; #whatever#>

Instead of going through the same code 3 or 4 times.

Lastly the timer runs a procedure and what have you... This way of working seems really awkward for me to understand - just different brains I guess.
The advantage of moving the procedures into the "on change" part of the variables means - all you have to do with the timer is add one to the second variable. That saves coding a call to the procedure.

ALSO... That object idea is great - but it means all clocks have to be the same, unless you rework the code to add to the object properties instead of the variables (which I think you might have started out doing - as that's the only reason I see for not adding them to the variable's on change routine).

All in all the code's neat and tidy, quite readable etc. Nothing bad with the code itself... Just thought I'd explain how I'd go about it differently.

I think Alex said once that he uses signed variables which would obviously mean -32,768 to 32,767. Or was that in reference to object/room limits?