Text Clock

I would like to make a text box. In every tick, it would set the text to something like:

Friday, 3rd July 2011
23:51:05 (clock)[/code:24e6u4ms]

I want the date/hour to be based on the Windows clock, so if I alter the time in Windows' taskbar, it would also change in the application. I tried using the Date object (experienced with the Day of the Week) and it gave me a 5. Now, Friday is the 5th day counting from Monday, but how do I replace the 5 with Friday, 1 with Monday and so on?

Thanks in advance.

EDIT: Just figured it by myself.  

I'll post a .cap later for other people to be able to do that too if they need.

HERE: [url=http://dl.dropbox.com/u/14813307/Clock.cap]http://dl.dropbox.com/u/14813307/Clock.cap[/url]
It just cranks on mine and get's stuck (stops updating the time), can someone help me?

Here's a simple (talking) clock i made about a year ago.

It displays the time and date, and if you click on it it speaks the time.

<img src="http://dl.dropbox.com/u/22173473/clock.png">

http://dl.dropbox.com/u/22173473/talking%20clock.cap

(only tested on XP, i dont think Vista or windows 7 has the same speech engine)

Hope this helps.

I haven't made a time clock since .62, but I'm wondering how well the global variables for time hold between layouts now? In .62 I made 2 clocks in one layout:

One ran on a timescale like 12:00 and counted down every second.

The other ran on a scale like :35 and counted down every second.

But when I switched to different layouts, the clocks would break, and after I began playing the game the :35 clock would disappear and never reappear again. That was weird. I'm going to check into this in the new versions and see if this is still a problem.

I haven't made a time clock since .62, but I'm wondering how well the global variables for time hold between layouts now? In .62 I made 2 clocks in one layout:

One ran on a timescale like 12:00 and counted down every second.

The other ran on a scale like :35 and counted down every second.

But when I switched to different layouts, the clocks would break, and after I began playing the game the :35 clock would disappear and never reappear again. That was weird. I'm going to check into this in the new versions and see if this is still a problem.

Can't answer your question, but you could check out the following post:

http://www.scirra.com/forum/viewtopic.php?f=2&t=9732#p74556

I made some examples using the date object as well as timer. If everything is set up accurately it works reliably.

For counters, I recommend using the system expression timer only. The technique is straight forward: Whenever a countdown is needed, set a timestamp. Compare timestamp against timer and that's it. timer returns the time passed since start of the game, it does not reset across layouts, so you can rely on that.

+ bomb('armed') = 1

-> bomb('timestamp') = timer

-> bomb('time') = 35

-> bomb('output') = 35

-> bomb('armed') = 2

+ bomb('armed') = 2

-> bomb('output') = floor(bomb('time') - (timer - bomb('timestamp')) / 1000)

++ bomb('output') <= 0

--> bomb('armed') = 3 (signal for explosion code)

++ Else

--> Set text to "0:" & right("00" & bomb('output'), 2)

Or have a look at the examples (like Verve!, etc.)

For using the counter across several layouts, make bomb global.

^^ That's a bit different from what I was trying to do, but you are 100% correct about the point of having it set correctly.

When I brought up my issue from last year, I was looking at it from the perspective of what I'd done last year when I was still learning how to manipulate the timers. I hadn't touched it since then, but my skill with this program has increased since that time, so I just went in and gave it another crack and I figured out what I was doing wrong last year. Turns out, it all came down to me using "add to value" instead of "set value". Using set value works for this, while "add to value" seems to keep adding to the value every tick or something to that effect, and that's what was breaking the clock and returning these glitchy values.

This make me wonder: why does "add to value" add to the value constantly rather than just adding to the value you've set once and then stop adding? Was it created this way intentionally, or is it a glitch?

I hope I don't misunderstand you, but every expression does its job on every tick, unless it is forced not doing so by using conditions.

+ Always

-> Add 1 to a

-> Set b to 1

This will add 1 to the currrent value of a (whatever it is) on every tick as well as setting the value of b to 1 on every tick.

Tick 1

a = 0

b = 0

doing always-event:

a = 0 + 1

b = 1

Tick 2

a = 1

b = 1

doing always-event:

a = 1 + 1

b = 1

Tick 3

a = 2

b = 1

doing always-event:

a = 2 + 1

b = 1

etc.

But using another condition breaks it:

Tick 3

a = 2

b = 1

+ a less than 2:

a untouched

b = 1

EDIT: Add to value is nothing more than a shortcut for n = n + 1

^^^Yep, that makes perfect sense, I understand. Last year I didn't get it yet though. The bad code I had last year was this:

<img src="http://farm4.static.flickr.com/3553/5814162638_5f7c9897c5_z.jpg">

^^^When I input the code last year I didn't realize that by using add to value and not adding any other conditions into the mix, I'd be adding the number constantly rather than just one time and then stop. So when I went into the next layout the clock would read out a number like :-0 or disappear because the numbers didn't jive right. I guess at the time I thought because it says "add to value" it would just add a number to it once based on the event and stop until the event repeats itself or another event is connected to it in some way. I of course was wrong and didn't understand a way around it, but that was last year.

My new code this year which works perfectly is:

<img src="http://farm4.static.flickr.com/3345/5813596579_9c2fefcae8.jpg">

On this one, I have the Global Variable in Line 6 set to "Greater than 45" because in a corresponding layout the value is set to be greater than 45, so when the game jumps back to the layout of the code I posted, the timer will reset back to :45 exactly the way I want it.

Yes, the new code makes more sense

But being the smart ass I am I can't let go and need to talk about the expression 'timer' again. You are using 'Every 1000 milliseconds', which isn't a bad thing. But you are not counting seconds this way. And this is why:

Every event including every x ms can only be triggered on a tick. A tick has a duration, and that duration depends on many details, e.g. the number of events that need to be executed (something that differs from tick to tick), the processor speed, the cap is run on, even the system may interfere because of heavy hd access or other background tasks.

This all leads to totally different tick durations, even when overall the game runs with stable 30, 60 or whatever fps. So when will every x ms be executed? On the nearest tick right on or after the specified time. In other words, every 1000 ms may be executed after 1002 ms the first time, after 1011 ms the second time, after 1000 ms the third time, etc.

I know, this might not be essential for a game, but then again, if you really want to count seconds (up or down) you can only rely on 'timer' (followed by timedelta), because those are counted outside of the event loop, so whenever you ask for 'timer' you get a very accurate time measure.

But, as I said before, this might not be that important for a game

Thanks Tulamide, that's some good information on how Construct handles the milliseconds. Although it being off by like a thousandth wouldn't make a noticeable difference for the type of project I was working on, I'm sort of a perfectionist so now that you mention that I'm definitely going to incorporate it. It's one of those things that would bug me not to have exact down to the decimal even if the user couldn't tell. I think they call my condition OCD, lol