Forums Bug Reports $away bug

Put this in your remotes:

type:
/away test
returns $true
type:
/away
returns $true ?????
type:
/away
returns $false

Using ver 6.2

I don't think so

Here's my test:

/away test
$true 306 xDaeMoN You have been marked as being away

/away
$true 305 xDaeMoN You are no longer marked as being away
** $away would return true since you're still in away mode, then the server unsets your away mode

/away
$false 305 xDaeMoN You are no longer marked as being away
** $away would return False since you're no long in away mode

[16:09:31] -> Server: away :Test
$true
[16:09:38] -> Server: away
$true
[16:09:40] -> Server: away
$false

As tested with mIRC 6.20. This is a bug: As the server has sent you a 305 [No longer away], pre-processing should include setting $away to $false before you call it. Just like it does for a 306 [Becoming away], when it sets $away to $true before remote processing.

edit: You do know that the result is displayed when the server has sent you something, right?

-
306: $true
You have been marked as being away
-
305: $true
You are no longer marked as being away
-
305: $false
You are no longer marked as being away
-

I do believe it should be returning $false since the server unsets you from away mode then sends you the 305 confirming the "unset" of away.

Confirm: 6.17+

- PhantasyX

Yep, It should set $away to $false before triggering the event, and unset $awaymsg and $awaytime afterwards.

I disagree with that, i think the fault lies more with the orginal one resulting with $true
ie: (and assuming you were not already away)

/away test
returns $true
I dont think this is right, the raw event trips before the defualt action of mirc so its a ^ event
type:
/away
returns $true
I think this IS correct, your not yet unset from away when this goes off, it should be $true, you might want to take some action based on the fact its $true (locally) and that the server just unset, so now you display its been unset remotely
type:
/away
returns $false

example code where the problem would appear


/timer 0 1 echo -a .... $away
.... $false
.... $false
/away
[04:05:19] your away state remains off
.... $false
.... $false
/away test
[04:05:21] your away state remains on (Thats not right now I just turned it on!)
.... $true
.... $true
/away test
[04:05:23] your away state remains on
.... $true
.... $true
/away
[04:05:25] your away state is now off
.... $false
.... $false
/away
[04:05:27] your away state remains off
.... $false
.... $false

As you see mircs setting its $away state before reciving confirmation by the irc server that the state was set is infact the error, the 1st /away after that should remain with $away still true untill after the event, as that is the ^event that is going to unset $away from being $true

Logically mIRC SHOULD update the $away identifier beforehand, for example if im calling /checkaway to display my away information in a toolbar, and calling it from raw 306 and raw 305. Perhaps the solution whould be to add an ON AWAY and ON UNAWAY which only trigger when your away status changes (actually only if the UNAWAY status changes, or diffrent awaymsg is set), and to set the $away to update before triggering any raw event.

On that logic, mirc should undate your nick to a new nick BEFORE the irc server says it accepted the change on nick as well. Now thats not going to happen now is it.

you guys confused me, shouldnt ^ happen before stuff is updated/sent, otherwise all information should be updated before the event/raw is triggered.
also wasnt there a command to force mirc to update some things, or am i off in fairly land and imagining things

^ events happen before some/most (but not all) of the defualt actions mirc takes based on said irc server signal, raws from memory also occur before mircs default action.
In ^ events you can use halt/haltdef to stop the default action (or at least it displaying) obvious exceptions occur like you cant stop mirc from adding someoen to the nciklist of a channel; when they join no matter if u have a ON ^JOIN { halt } or not. but you could stop the join message displaying in the chanenl for instance.

As to the other things you mentioned about updating then and there, im not sure what your talking about either way sorry.

Im saying update the identifer before triggering the event not before the server message is received.

Since its a raw event so doesnt use the ^ pre event system, why but why would you have the event already having modified the identifier.

The idea of being able to catch the event is to take what actions you want based apon the system at the time of the event and the event in question, not what the system well be like after the event.

So with that logic you wouldnt know a persons $address in the on join event because mirc wont update it beforehand???

No i never said that, and really it sounds like your just grasping for an arguement to use, and not a good one at that.

Your arguement if faulty for one glaring reason, $address like $nick is filled in by the event itself, it is not adjusted, so of course it should be known, be the even be a ^ event or not.

I well leave it at this, we choose to differ.

You've missed my point, ill put it in simpler terms if im inside and I walk outside, and theres a person in the garden watching when I come outside (like raw 305) the moment he sees me im outside, not inside not in the basement not in the attic. $outside = $true

This is one of those behaviours that I've changed back and forth over the years based on requests by users.

When $away was being set before 305 triggered, users complained that they wanted to know whether they were already away when the event was triggered, so I changed it back.

There are other events where the choice to set a value during an event is somewhat arbitrary, and may be useful in one situation and not useful in another.

How about $isaway and $wasaway ?
Similar to /whois /whowas commands?
That way $away can be left as is, and yet people can check in a logical manner if they are currently set as away $isaway, and check if they were away $wasaway, or perhaps something along those lines. Scripts / Scripters knowing how to use the methos as stated in another post...


could use it.. yet peope wanting to get their head around that could use an on away event and identifiers similar to above to avoid confusion?

oh yeah is it really? Check out what your assumption would result in.

on *:WALKOUTSIDE:*:{ if ($outside == $true) { msg $nick Glad to see your still outside } | else { msg $nick Glad to see you just came outside } }

Amazing you just waked outside from somewhere else, and he says "Glad to see your still outside" oh how correct that is!

You essentially just said the exact same arguement u used before, and i gave you the exact same reason it isnt right in an event that is triggered for the possable change of situation, it is preferatable to have the previous status avaialable to be tested during the event, since you know what the event is, you know what the status well change to, so its previous status is more important than knowing what it well be, as you know what it well become by being in the event.

But what if I was to implement it like this?

I think we should agree to disagree, I like the idea of the $wasaway identifier

That would be pointless, as u might as well have hard coded it and improved performance.

Your seeming to ignore what im saying totally, if you have an event that goes off BEFORE the mirc defualt action, then it SHOULD NOT have the changed identifiers of that default action.