mIRC Homepage

/timer addition

Posted By: Doomstars

/timer addition - 27/08/03 09:44 PM

/timer -t 1062020595 1 1 echo -s It is now $asctime(1062020595)

I think that's pretty self-explanatory.
Posted By: xemacs

Re: /timer addition - 27/08/03 10:05 PM

/timer 02:00:34 1 1 echo -s its now 02:00:34

wink
Posted By: Doomstars

Re: /timer addition - 27/08/03 11:16 PM

No. Ctime is specific. Ctime doesn't repeat itself everday like $time does. Currently there is no simple way to set a timer to go off on a specific date. Keyword: simple
Posted By: xemacs

Re: /timer addition - 27/08/03 11:20 PM

hm then do a workaround
Code:
  timer 0 1 ctimer <ctime> <commands>

alias ctimer {
if ($1 == $ctime) {
$eval($2-)
$ctimer off
}

}


or something like that
Posted By: Doomstars

Re: /timer addition - 27/08/03 11:26 PM

As I said, "Keyword: simple". I think it should be added to ctime can be chosen instead of just the daily time.
Posted By: codemastr

Re: /timer addition - 27/08/03 11:32 PM

Yet again, his script is 2 lines long, how is that not simple? It's an if statement. Thats not simple? And if an if statement is something you consider complex, then perhaps you should reconsider mIRC scripting, because an if statement is probably one of the most simple things there is. Fine, if you want to say it is so complex, it can even be made shorter:

Code:
alias ctimer {
   if ($1 == $ctime) {
      $2-
      $ctimer off
   }
}


/timer1 0 1 ctimer 1062027400 echo -s it is now 1062027400

That script is so incredibly basic, even if you've never seen an mIRC script before it shouldn't be hard to figure out!
Posted By: Doomstars

Re: /timer addition - 27/08/03 11:37 PM

This is called Feature Suggestions. That's your opinion, but it's the opposite of my opinion.
Posted By: feud

Re: /timer addition - 27/08/03 11:38 PM

i think this would be a nice addition. it is duly noted however, that in the meantime, there is a relatively simple workaround.
Posted By: codemastr

Re: /timer addition - 27/08/03 11:48 PM

No it's not my opinion, it's a fact, that is a very simple script. It is also a fact that if you don't find that script to be simple, then mIRC scripting is over your head. That script is no more complex than a simple "hello world"
Posted By: Doomstars

Re: /timer addition - 27/08/03 11:50 PM

If it were to get anymore complicated than this, an ON TIME event would be needed. But obviously that would hurt resources. Having something like...

ON *:TIME:year:month:week:day of the week:day number:hour:minute:second:commands

ON *:TIME:2003:8:35:WED:27:16:48:49:echo -s test

ON *:TIME:2003:8:35:WED:27:4AP:48:49:echo -s It's either 4am or 4pm

And ON *:GTIME: for the $gmt to be used instead.
Posted By: Doomstars

Re: /timer addition - 27/08/03 11:53 PM

Other people have voiced their opinion on how your posts are. I'm staying out of this after one more comment. Then I'll just start ignoring.

Remove the simple code and it can break a lot of scripts.
Posted By: codemastr

Re: /timer addition - 27/08/03 11:58 PM

I think the problem here is you just want mIRC to do everything for you, and if thats the case then scripting isn't needed. If this is added then all of these should be added as well

/timer -d [day]
trigger a timer on a specific day of the week.
/timer -c [#channel]
trigger the timer only if I'm on #channel
/timer -u [uptime]
trigger the timer after mIRC has been running for uptime seconds
/timer -U [uptime]
trigger the timer after Windows has been running for uptime seconds

All of those suggestions are just as equally valid. If your suggestion is deemed to be needed, then so are each of the ones I just mentioned; sure they can be scripted, but thats "too complex"
Posted By: Doomstars

Re: /timer addition - 28/08/03 12:05 AM

"/timer -d" would be better suited in an ON TIME event. Since it can get too complex for /timer itself with so many possibilities.

Like months and such, as I said before. "/timer -c" would have too many questions. Like whether it will trigger based on the channel window being open, or if I'm on that channel. And if it were just for channels, what about for message windows and so on? There are too many possibilities on this one. Small steps I think should be taken first in other directions. Like I said, /timer -t to specific a certain ctime. Just a first step in any direction we go.

"/timer -u" and "/timer -U", I don't know when those would be used. I know my suggestion of ctime could be useful for many different things. Birthday reminders, reminders to do stuff, and such. Just use your imagination. For uptimes, I don't know why it would be needed to do something at a certain uptime. If it has that many uses at all. But that's my opinion, and I'm willing to hear those who are saying an uptime timer would be useful.
Posted By: codemastr

Re: /timer addition - 28/08/03 12:08 AM

You don't know when those would be used?

/timer -u 86400 1 /amsg My mIRC made it past the 1 day uptime, yeah!

/timer -U 86400 1 /amsg Wow, I managed to get Windows ME to run for 24 hours straight!

As for the -c, that is obvious, I said "I am on the channel" not "is the channel window open" just like ischan. Ischan only triggers if you are on the channel, not if the channel window exists.

Why would -d need an ON TIME event? There are 7 possibilities
/timer -d [sunday|monday|tuesday|wednesday|thursday|friday|saturday]
Posted By: Doomstars

Re: /timer addition - 28/08/03 12:11 AM

But what if someone wanted to trigger months and weeks and years in /timer, that's when/where ON TIME would be involved.
Posted By: codemastr

Re: /timer addition - 28/08/03 12:15 AM

But if it is in an ON TIME, then that is going to involve a signifigant amount of scripting which is going to make it complex.
Posted By: zac

Re: /timer addition - 28/08/03 01:00 AM

Or, even easier:

alias ctimer timer 1 $calc($1 - $ctime) $2-

ctimer <ctime> <command>

Or the like.
Posted By: cold

Re: /timer addition - 28/08/03 06:47 AM

(This is directed to everyone)

Quote:
Or, even easier:

alias ctimer timer 1 $calc($1 - $ctime) $2-

ctimer <ctime> <command>

Or the like.


Yeah, I'd suggest that, because the other code they posted above doesn't make sense, unless they've meant "$ltimer off" instead of "$ctimer off", which would still be wrong and wouldn't work. BTW, with some corrections following that idea, the code would force the parser to evaluate <commands> twice. Not a big deal, but not nice either.

However, your scripts don't support everything /timer supports and that's one of the reasons why I second Doomstars' suggestion. Yes, all the support that is needed can be scripted as well. But the fact is that it'd be not that simple anymore, although not difficult either.. I've been messing with it.

That said, this "No, this can be easily scripted" argument applies to /timer's time support too ("/timer 12:00 1 0 blah"). Following the same functionality shown above, it can be quite easily scripted. Let's drop it then?
No, we're all able to make good use of it, and we can be sure it will always support any incoming changes and additions that the /timer command could suffer. Why? Because it's built-in. Does this bother anyone, given the fact that it can be easily scripted? I don't think so. Would it bother Khaled? I really don't think so. Now if everyone who scripts it has to keep updating it to support new /timer flags, changes etc, would this bother anyone? I think so. At least a suggestion to make it built-in would come to mind.
So why shouldn't this feature be added? You didn't convince me. Show me a script that decently substitutes anything (including an easy syntax) a built-in version would have and I'll still have the updating argument.

I guess that all I said ends up to what Doomstars said.. "keyword: simple". Simple feature, simple use. Not really necessary if you see no problem in scripting it, so then you script it. Some people prefer it built-in with enough good reasons in their opinion. Sorry, "script it" is *not* an ultimate incontestable solution and unfortunately you won't change that. Workarounds are not necessarily solutions to everyone, even less in a "Feature Suggestions" board.
Posted By: Doomstars

Re: /timer addition - 28/08/03 07:47 AM

I dislike workarounds for certain reasons. I have to make sure if I give out certain scripts, they have the workaround alias in them. Like the $gmt bug which doesn't recognize daylight savings time correctly in some operating systems. Also, $duration, that's messy if you don't want weeks, but days. So 1 week 3 days is 10 days, I have to make sure all my scripts have a workaround duration in them so they don't break. Or even $season, which I agree shouldn't be built in since it would be hard to be exact, and then there is the Northern/Southern hemisphere issue.
Posted By: cold

Re: /timer addition - 28/08/03 08:00 AM

Yeah, this is another issue I don't like either. I can't avoid it, though.. only if I were Khaled. grin
Posted By: cold

Re: /timer addition - 28/08/03 08:54 AM

Quote:
I think the problem here is you just want mIRC to do everything for you, and if thats the case then scripting isn't needed.

It is a suggestion, not a problem. If he wants mIRC to do that job for him (to support ctime on /timer, which I'd want too), it doesn't mean he wants it to do everything for him. However, if this is a personal opinion of yours, I don't see why do you bring it since it's obviously not going to improve the discussion.

Quote:
/timer -c [#channel]
trigger the timer only if I'm on #channel

Unrelated. I don't see anything here related to combinations of more features (IRC/ON JOIN, in that case) into /timer's parameters. What I see is a suggestion to add another time value to /timer, following its pattern and making sense, since mIRC already offers one (HH:nn) - which could be easily scripted as well. Then..
Quote:
All of those suggestions are just as equally valid.

..this is an opinion of yours. From the point of view of who wants mIRC to do everything for him/her, they might be equally valid. But since you brought an idea not really related to the suggestion, they don't seem equally valid following it.

Quote:
That script is no more complex than a simple "hello world"

Yeah, it isn't. It doesn't work, anyway. zac shows one that works and it's even simpler, but it doesn't offer all /timer's features, that's something I suppose Doomstars has pointed out talking about simplicity. In this case, simplicity not only to script it, but to "port" it and make use of it too. If he's not, I am.

Anyway, a lot of small features that could be scripted are now built-in, yet, from what I see, nothing has worsen about it to who disagrees or has never needed its inclusion. People who agrees with it and/or needs it end up using it, justifying such small additions. This is only another one, which I think that would be used. As a suggestion to Khaled, others should at least not diminish it.
Posted By: Doomstars

Re: /timer addition - 28/08/03 10:01 AM

The only problem I see with adding to mIRC is how big the exe file is getting. If resources of certain computers will be able to handle it. It may not seem significant if you have a good computer.
Posted By: starbucks_mafia

Re: /timer addition - 28/08/03 10:25 AM

I have a 6+ year old pentium 133 w/32mb RAM that can handle it as it is. I don't think it's an issue yet (provided nothing ridiculously resource-whoring gets added). The size of the exe is meaningless (again provided a 20mb jump isn't in order for the next release).
Posted By: Doomstars

Re: /timer addition - 28/08/03 06:52 PM

I assume you don't use Windows XP Pro then.
Posted By: _D3m0n_

Re: /timer addition - 28/08/03 08:16 PM

very good assumption seeing as xp pro minimum resources are as follows:

Here's What You Need to Use Windows XP Professional
PC with 300 megahertz or higher processor clock speed recommended; 233 MHz minimum required (single or dual processor system);* Intel Pentium/Celeron family, or AMD K6/Athlon/Duron family, or compatible processor recommended
128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported; may limit performance and some features)
1.5 gigabytes (GB) of available hard disk space*
Super VGA (800 600) or higher-resolution video adapter and monitor
CD-ROM or DVD drive
Keyboard and Microsoft Mouse or compatible pointing device


as reported on Microsofts website

now keep in mind alot of ppl still use windows 9x OS so why add things to mirc that would limit them ppl from using it?

an on time event is enormously resource hungry and cannont be utilized by older os's id really have to say this type of event wouldnt be a really good addition at this time. just based on the fact ppl still use these older OS's.
© 2019 mIRC Discussion Forums