Anyone solve this? - mIRC Discussion Forums

Just a problem I've encountered.

I'm trying to do it so that a points system which gives points every 5 minutes would allow me to make a different command called !watchtime. It would be good if it could take the number from the points system file and take them in a specific format using a bunch of if statements. ie if the user has watched for less than an hour it would show in minutes, if the user had watched for over an hour it would show in hours and minutes then if they're addicted and have days worth of points it would show days hours minutes. I've given it a go however I can't seem to get it working.
The problem seems to be in the initial IF statement as I've tried it with a simple message following it. Here's what I tried...

Code:

on *:text:!watchtime*:#:{ 
  if (($readini(Points.ini,$+(#,.,$nick),Points)) < 12) { msg # $nick has watched the stream for $calc($readini(Points.ini,$+(#,.,$nick),Points) * 5 ) minutes. }
  if (($readini(Points.ini,$+(#,.,$nick),Points)) > 12) && (($readini(Points.ini,$+(#,.,$nick),Points)) < 287 ) { msg # $nick has watched the stream for $floor($calc($readini(Points.ini,$+(#,.,$nick),Points)) / 12 )) hours. }
  else { msg # I'm not working. }
}

The else statement is just there so I know

Try using the $duration identifier.

Help details: /help $duration

e.g: //echo -a $duration(300)

But is there a way to use the

Code:

 if (($readini(Points.ini,$+(#,.,$nick),Points) > 12) && (($readini(Points.ini,$+(#,.,$nick),Points) < 287 )

section as that is the problem area?

Untested, and not sure if this is what you want either.

Code:

on *:text:!watchtime:#: { 
var %points ($readini(Points.ini,$+(#,.,$nick),Points)
var %time $calc(%points * 5 * 60)
var %duration $duration(%time)
msg # $nick has watched the stream for %duration $+ .
}

At a quick look that method doesn't seem to work.
So nobody knows if the initial if statement will work?

If $1 is the first word a user inputs, is there a way of doing this for a bot automatically in a similar way, so for example

Code:

on *:text:!watchtime:#: { 
  msg # FIRSTWORD has watched the stream for %duration hours .
}

Is there any way of taking this FIRSTWORD and putting it elsewhere in the same script?

Set FIRSTWORD as a variable?

Been brainstorming this for the past few days and the problem area is the readini. Does anyone have an idea as to why this would be, why can't it recall the number from the ini. Is it because of the format in which it is written, which is
[#jb_uk.jb_uk]
Points=23
Could it be for that reason?

EDIT: Tested with removing the Points= section and still no result...

Well try using this code i have also adding and some other commands maybe is that you want for.

Code: http://hawkee.com/snippet/16078/

- Report here for any problems or anything else.

Code:

on *:text:!watchtime*:#:{ 
  echo -s DEBUG: $!isfile: $isfile(points.ini) ~ $!ini: $ini(points.ini,$+(#,.,$nick)) ~ $!readini: $readini(points.ini,$+(#,.,$nick),Points) 
  if (($readini(Points.ini,$+(#,.,$nick),Points)) < 12) { msg # $nick has watched the stream for $calc($readini(Points.ini,$+(#,.,$nick),Points) * 5 ) minutes. }
  if (($readini(Points.ini,$+(#,.,$nick),Points)) > 12) && (($readini(Points.ini,$+(#,.,$nick),Points)) < 287 ) { msg # $nick has watched the stream for $floor($calc($readini(Points.ini,$+(#,.,$nick),Points)) / 12 )) hours. }
  else { msg # I'm not working. }
}

Can you have someone try to run the script and then post the message that is echoed to your status window here?

Also, are you aware that your script will trigger for values less than 12, and values more than 12, but not values that are actually 12?

Your first if statement uses "< 12" (less than 12) and your second uses "> 12" (more than 12) but nothing handles 12 itself. If 12 is your points value then the else statement will be triggered and your script will say "I'm not working."

<= 12 or >= 12 would catch 12 as well, as these mean 'less than or equal to' and 'more than or equal to' respectively.

Hi Nillen,

Please don't take this as a criticism because I think you're a valuable contributor to this forum, but I just wanted to make you aware of something.

The help file says that the syntax for setting a variable using the /var command is:

/var [-switches] %variable = <value>

Usually you can get away with not using the = sign, but not using the = has historically caused problems. See these threads:

https://forums.mirc.com/ubbthreads.php?ub...true#Post177377
https://forums.mirc.com/ubbthreads.php?ubb=showflat&Number=177387&page=1#Post177387

If you ever do run into such a problem then it will cause you major headaches in trying to figure out what is wrong with the script because it does work the vast majority of the time, but occasionally quirks in the parser have caused it not to work.

Interestingly, the issues highlighted in those threads are no longer a problem, but it seems like it is safer to use the correct format.

Cheers

Edit2: I gotta have to agree with wims. It feel unnatural for me to use the '=', even though it might have been a problem earlier I haven't seen it at all. So it feels better to do it the way I've always done it. Sorry mate. Interesting read though.

Edit1: Looking back at the code I posted here, I see that I accidentally kept a ( bracket in the first %variable when I copy pasted from your code. If you try fixing that, can you try the script again JB? I get the feeling that it is what you want.

Quote:

[23:46] <@nillens> !coins
[23:46] <@nillensbot> *Nillen has 58388 total coins.
[23:46] <@nillens> !watchtime
[23:46] <@nillensbot> *Nillen has watched the stream for 28wks 6days 17hrs 40mins.

using the same script, modified to use my own points system.

Code:

on *:text:!watchtime:#: { 
  var %points $coins(read,$nick)
  var %time $calc(%points * 5 * 60)
  var %duration $duration(%time)
  msg # $nickpref($nick) has watched the stream for %duration $+ .
}

Well, originally the equal sign was added to help with parsing /var (which is stupid, there is no need for it to help parsing, it even leads to quirk).
It was made optional after I more or less strongly suggested for that, and this since 6.21, not using the equal sign will not produce an error since 6.21, so nobody will ever run into problem because of it.
And there is no reason to argu that it should be used because the help file states it should, the help file is outdated/wrong/incomplete in a lot of point.
More importantly, using the equal sign today can only lead to quirk, not the other way around.
The correct format is the one that was available first, and that is WITHOUT the equal sign.

Do you have any links to examples where using = causes issues and not using it doesn't? I have never heard of that before.

The help file being incomplete does not mean you should ignore it. I would suggest it is still better to use the documented syntax rather than undocumented.

No link, but an example:

Code:

//var -s % $+ a = 1

This is actually a clue showing the '=' was added after and that it wasn't added properly, that's why I recommend not using it, it can only lead to issues, while not using it cannot.

Quote:

The help file being incomplete does not mean you should ignore it. I would suggest it is still better to use the documented syntax rather than undocumented.

That's really what I was talking about, people recommend using it because the help file recommends it, and yes, one should typically follow the help file, the problems start when the help file is actually misleading, that you should not be following it or it won't work properly, and the mIRC help file unfortunately has a lot of this.

I can see the argument for both sides now. It's a strange situation.

I was a victim of a nasty bug in one of my scripts arising out of not using = and that's why I started to use it.

That said, either the help file should be updated or this bug fixed.

So was I, but instead of accepting the fail, I had to blame something else

It seemed unecessary and it was made to work correctly in the next version so I was rather happy with it, the only problem one had not using it before was because ",%var" would be seen as a new declaration:
var %a 1,%b $mid(text,%a,1) would fail without '=' with $mid invalid format.
That's the kind of stuff that won't be fixed, the help file is only misleading because it doesn't work properly, but it is supposed to, and it's not like Khaled wants to document all the quirks in mIRC, would take an entire lifetime, though we started working on http://wikichip.org/wiki/mirc for this reason, so the real behaviors and all the known and important quirks are documented, with better examples and documentations.

I admire your enthusiasm. I'd rather just have the easy life and use the documented format than argue that the undocumented format should work

I will continue to use = until the help file says we shouldn't, which will be until the end of time given Khaled's tenacity for not wanting to break existing scripts with mIRC updates. That might be why he hasn't fixed this issue, in case it breaks existing scripts that rely on the quirky behaviour.

I have to say though that although you have highlighted a bug, I don't think it is one that most people will encounter. I can't think of any situation where you would want to dynamically name a local variable.

It's not about easy or hard life, it's about knowing, being aware. Most scripters nowadays use evaluation brackets to:
-Set dynamic variable, but why, it's not needed/faster, it's just useless and makes the code ugly.
-Retrieve dynamic variable, well that's faster than $eval, but that's because $eval is a huge quirk in itself and it's not like people use it arguing 'what? i'm winning pico seconds here'

The answer is monkey see, monkey do, we don't need/want no monkey. Quirks are fine as long as they are known and documented, each language has its good and bad practices, its quirks etc, the mIRC community is the only one I see not trying to get better regarding this. Codes uploaded on hawkee are usually terrible, among all the code with possible injection via timers/scon, 95% of them are vulnerable with no $safe, there is nothing telling them about those injections anyway.
This 'bug' is actually not a bug but a quirk, difference being that it's incorrect behavior but it won't be fixed because of its nature (requires change to the parser, which khaled avoids, *understandable*). I want more awareness for people, more communication/documentation from khaled regarding the quirks, cause for now, it's who is the most aware and who you trust the most and you need to find the thread from the 200X years where khaled said something about a quirk to justify it.

The timer/scon thing is most definitely not a bug, but the issue being discussed here is.

The fact is that the assignment symbol (=) is being used as part of the variable value when it shouldn't be. That's a bug, not a quirk.

I think the more unusual things you are trying to do with your code, the more quirks and bugs you will come across, and setting dynamic local variables is unusual (although this also occurs with /var -g).

Likewise if you start messing around with things like:

Code:

//set %x $!time | timer 1 5 echo -a % $+ x $(| unset %x,0)

Rather than using the neater and more preferable alias method:

Code:

alias echotime {
  echo -a %x
  unset %x
}

Code:

//set %x $!time | timer 1 5 echotime

Then you're more likely to run into issues.

There must be thousands of quirks in every scripting and programming language, it would be impossible to document them all and a pretty pointless exercise when most users will never come across them.

I said a quirk is a bug that won't be fixed, otherwise you would call it a bug and it would get fixed

And I disagree strongly, at best what you are describing is a lack of thinking before implementation, if K didn't want ugly abuse with the timer command, he would have forced the call of an alias only, he didn't, he wants to keep compatibilities and he defends those who might be relying on either bugs or quirks, even the most illogical ones.
And let's be clear, the "Use the correct syntax and you'll be good" is a stupid argument, if each time I make a typo in my code, mIRC crashes, I'm going to complain, that's normal. If mIRC does not crash with my typo but I figure out it can do some undocumented stuff and people like it, they will use it, that's normal.

In general, you should provide the parser with as much information as possible so that it does not have to guess what you mean. In this case, using the = sign with /var makes it clear to the parser, and to you when you later read the script, exactly where the assignment is taking place. The more information the parser has, the more likely the script will work in the way you expect. This applies to the = sign, brackets, and anything else that makes it clear to the parser what you mean.

As the parser supports $+ and [] brackets, which allow you to create dynamic command lines and parameters, this creates all kinds of problems for the parser, since it has to guess how to evaluate a line based on context and the evaluation priority of different parser features.

I would say that allowing /var without an = sign was a bad idea (I cannot remember the context of its implementation). However, it was probably implemented that way so that it would work like /set, which also does not need an equal sign. The = sign support was added later (I think) because of /var support for multiple variable definitions, each of which could have their own assignments leading to ambiguity if an = sign was not used.

Thanks for your comments on this topic everyone.