Bug - Fixed "You are now in away mode, chat will update more slowly until you say something."

[Fluxxdog]

"You are now in away mode, chat will update more slowly until you say something."

This line gets repeated several times a minute when using the Modern Chat (with tabs) in the relay browser. It will flood the chat and events tab in mafia as well. When you go to the main map, you will have a very long list of notifications of that line.

This does not happen in vanilla.

Any way of stopping this?

 

[Veracity]

This doesn't happen to me. Can you explain exactly what you are doing, please?

What channel are you in and what channels are you listening to?
Are you running native chat and KoLmafia's GUI chat at the same time? (Your mention of the "chat and events tab" makes me think so.)
How long does it take before the "You are in away mode" message starts? (and yes, that is standard KoL behavior; I am sure that you have seen that when you do /whois on somebody, it sometimes says "xxx is away from KoL in channel /clan" or something.)
Is this new behavior, or is it something you've noticed for a long time?

 

[Fluxxdog]

This doesn't happen to me. Can you explain exactly what you are doing, please?

What channel are you in and what channels are you listening to?

How long does it take before the "You are in away mode" message starts? (and yes, that is standard KoL behavior; I am sure that you have seen that when you do /whois on somebody, it sometimes says "xxx is away from KoL in channel /clan" or something.)

[COLOR="#008000"][12:48] Fluxxdog (#2014321), 11th level Chaotic Canine, 1st level Cool (In Ronin)
This player is currently online in channel clan and listening to dread, games, hardcore, hauntedhouse and trade.
[13:03] You are now in away mode, chat will update more slowly until you say something.
[13:04] You are now in away mode, chat will update more slowly until you say something.
[13:04] You are now in away mode, chat will update more slowly until you say something.
[13:04] You are now in away mode, chat will update more slowly until you say something.
[13:05] You are now in away mode, chat will update more slowly until you say something.
[13:06] You are now in away mode, chat will update more slowly until you say something.
[13:06] You are now in away mode, chat will update more slowly until you say something.
[13:06] You are now in away mode, chat will update more slowly until you say something.
[13:07] You are now in away mode, chat will update more slowly until you say something.
[13:07] You are now in away mode, chat will update more slowly until you say something.
[13:07] You are now in away mode, chat will update more slowly until you say something.
[13:07] You are now in away mode, chat will update more slowly until you say something.
[13:08] You are now in away mode, chat will update more slowly until you say something.
[13:08] You are now in away mode, chat will update more slowly until you say something.
[13:09] You are now in away mode, chat will update more slowly until you say something.
[13:09] You are now in away mode, chat will update more slowly until you say something.
[13:10] You are now in away mode, chat will update more slowly until you say something.
[13:10] You are now in away mode, chat will update more slowly until you say something.[/COLOR]

So about 15 minutes. The message repeats but not in a consistent pattern.

Are you running native chat and KoLmafia's GUI chat at the same time? (Your mention of the "chat and events tab" makes me think so.)

Yes, both the relay and GUI chats are open.

Is this new behavior, or is it something you've noticed for a long time?

Sadly, it's something I noticed before, but I don't use the Relay chat often, so it generally slipped my mind. With HR, though, I've been spending WAY more time in the relay, so I open the chat to speak with clannies. Of course, they aren't there all the time, and thus the kick-in-the-pants to finally report this.

And just in case, a copy of all "chat" containing preferences:

> prefref chat

addChatCommandLine (global, now 'true', default 'false')
chatBeep (global, now 'true', default 'false')
chatFontSize (global, now 'small', default '')
chatLinksUseRelay (global, now 'true', default 'false')
chatStyle (global, now '0', default '0')
innerChatColor (global, now '#ffa98c', default '#ffa98c')
logChatMessages (global, now 'false', default 'true')
logChatRequests (global, now 'true', default 'false')
mergeHobopolisChat (global, now 'true', default 'false')
outerChatColor (global, now '#b4460f', default '#b4460f')
relayFormatsChatText (global, now 'false', default 'false')
relayUsesIntegratedChat (global, now 'true', default 'false')
useChatToolbar (global, now 'true', default 'true')
useShinyTabbedChat (global, now 'true', default 'true')
useTabbedChatFrame (global, now 'true', default 'true')
chatbotScript (user, now '', default '')
chatbotScriptExecuted (user, now 'false', default 'false')
chatLiterate (user, now 'false', default 'false')
chatServesUpdates (user, now 'false', default 'false')

 

[lostcalpolydude]

I'm pretty sure that's a consequence of using mafia's chat GUI.

 

[roippi]

Do we actually respond to being put into "away mode"? In the mchat source I see that it sets its repeat interval by responding to the "delay" attribute that it gets with every response:

var gotChat = function (res) {
    if (!res || res == null) return;
    delay = parseInt(res.delay);
    // rest of message handling
};

var cycle = function () {
    //if (lastrequest && !lastrequest.status) return;
    if (lastdelay != delay) {
        clearInterval(timer);
        timer = setInterval(cycle, delay);
    }
    lastrequest = $$.ajax({
        url: '/newchatmessages.php?j=1&lasttime='+lastlast,
        dataType: 'json',
        success: gotChat,
        timeout: 5000
    });
    lastdelay = delay;
};

I don't see anything in our chat system that parses delay, or adjusts our polling rate - just:

			for ( int i = 0; i < ChatPoller.CHAT_DELAY_COUNT
					&& ChatManager.isRunning(); ++i )
			{
				pauser.pause( ChatPoller.CHAT_DELAY );
			}

(which is a goofy way of pausing, but anyway)

Admittedly I don't begin to understand the whole situation with newchat/oldchat and the interactions therein so it's possible I'm looking in the wrong place (either in the js or in chatpoller).

 

[Veracity]

KoLmafia's internal chat does not communicate using mchat, where the response come in a JSON structure.

newchatmessages.php?lasttime=xxx -> get new messages using old format
newchatmessages.php?lasttime=xxx&j=1 -> get messages using new format.

... and similarly submitnewchat.php with or without j=1 field gets the response in old or new format.

Additionally, as discussed in the other Bug thread, I have learned that even if the Browser is using mchat and submits a request with a "lasttime" field, KoLmafia does not submit that field; it omits it, which results in getting "any messages since I (or anybody?) last asked for them", whereas the chat GUI uses "lasttime" and keeps track of the last timestamp.

So, if someone has the chat GUI running and also mchat in the Browser, ChatPoller periodically asks for new messages using the old protocol and the Browser periodically asks for new messages using the new interface. Each has their own idea of the "lasttime" timestamp that they want messages from - and KoLmafia subverts that for the browser by not passing on the requested field.

It will be a project (or just a can of worms?) to try and get the chat GUI to peacefully coexist with the browser running mchat. Not a project that I want to be submitted before we spin a new release.

 

[roippi]

Oh I see, ChatPoller.handleNewChat is only invoked by RelayRequest. Yup.

I think between the two threads we (ok mostly you) have cleared up a lot of the "black magic" inherent in the chat system. It sounds doable - though yes a lot of work - to make the two play nicely together. After the point release.

 

[Bale]

Some time after newchat was implemented, I decided to stop using the KoLmafia chat GUI and the replay browser chat simultaneously, because of little things like this. It was easy enough to only use one at a time.

It's really cool that they are being addressed after the IotM is implemented. Awesomely I think there's a really good chance that Thor's Pliers will be reasonably easy to implement. (Probably just a weapon with easy bonuses that also grants lightning regeneration and free meatcrafting.) Fixes for this issue could be bugging up KoLmafia as early as next week.

 

[Veracity]

Bumping this to revisit, now that I have made our chat GUI (running the lchat protocol) interoperate acceptably with the Relay Browser running the mchat protocol.

I'll also take the opportunity to consider making the chat GUI slow down when KoL decides we should be in "away" mode.

 

[Veracity]

Some observations.

lchat ("loathing" (non-tabbed) chat):

It has a variable "paused" which determines if you are active.

(ms. between refreshes)
paused==0 -> normaltime = 4.5 * 1000 = 4.5 seconds
paused==1 -> afkoltime = 30.0 * 1000 = 30 seconds

(cycles before we transition from normal to afk)
(bicycles * (normaltime / 1000)) > (60*15)
-> 900 / 4.5 = 200 = 200 cycles. In any case, 15 minutes.

If you type /afk or /away, it sets paused to 1 and says:

You are now in away mode, chat will update more slowly until you say something or <click here> to mark yourself as active.

Supposedly, if it refreshes (requests new messages) for 15 minutes without you saying anything, it will say the same thing and set paused=1. I say "supposedly" because I waited 30 minutes and did not see that.

It polls by submitting:

newchatmessages.php?lasttime=xxx&afk=PAUSED

In other words, it is the "afk" field submitted by the browser itself which sets you to "away" and it is the browser itself which voluntarily slows down polling.

Observation: the relay browser does not pass the "afk" field up to KoL. That seems like a bug.

mchat ("modern" (tabbed) chat):

Poll via:

newchatmessages.php?j=1&lasttime=xxx

("j=1" presumably is "json"). There is no "afk" field. KoL itself decides when the browser is to slow down. The browser starts out polling every 5000 ms. KoL includes a "delay" value in the response to the poll. The browser will use it, as long as it is between 1 and 60000 ms., otherwise, it sticks with 5000.

I have not captured this yet, but, unlike lchat, it is not the browser which tells you that you are in "away" mode (and tells KoL to go there via afk=1). It is KoL, sending down some sort of event message - which is what the OP is complaining about.

I'll go start up the chat GUI and modern chat in the Relay Browser and see exactly what that is.

 

[Veracity]

I've now confirmed this issue - and I have a DEBUG log of 15 minutes of the chat GUI and mchat in the browser both open.

 

[Veracity]

With only mchat in the relay browser, it polls every 3 seconds until the "You are now in away mode" appears, and then it polls every 10 seconds. The message is not repeated. When you type something to send, KoL says "Welcome back" and the delay goes down to 3 seconds again.

With both the KoLmafia chat GUI and mchat running, once away mode starts, mchat slows down, but the chat GUI continues to poll at its old rate. It is KoL itself which keeps sending down the green "You are in away mode" message, which the browser and chat GUI dutifully keep repeating.

So, this is definitely an result, somehow, of both the chat GUI and the browser polling.

 

[Veracity]

To sum up my thinking on this:

- If the browser is running lchat, it submits newchatmessage.php?lasttime=xxx&afk=0 (if active) or afk=1 (if "paused").
- The browser with lchat polls every 4.5 seconds (if active) or every 30 seconds (if "paused")
- The browser "pauses" when you type the /afk or /away command, or after 15 minutes idleness
- The browser stops "pausing" when you click on the link it gives you or submit a message.
- KoLmafia not only ignores the "afk" parameter, but suppresses it; it does not pass it to KoL.

- If the browser is running mchat, it submits newchatmessages.php?lasttime=xxx&j=1
- The browser with mchat polls every 5 seconds - but KoL responds to each poll with a requested delay, which mchat obeys
- KoL's normal delay is 3 seconds, but when it decides that you are "away" after not posting for 15 minutes, it backs off to 10 seconds.
- The browser does not seem to recognize /afk or /away. Nor does it give you a link to become un-idle. KoL itself sends you a message saying that you are idle.

- If the chat GUI is open, it has its own poll loop. It was polling every 5 seconds, but I recently made it poll every 4.5 seconds, like lchat.
- The chat GUI does not recognize being "away". It does not slow down its polling.
- The chat GUI will fetch messages whether or not chat is open in the browser. But if the browser is polling, messages from that source will get fed into the chat GUI.
- The chat GUI's poller will not fetch new messages if the browser has polled since the chat GUI last requested messages. This means that if the browser is polling faster than the chat GUI, it will never poll, but will depend on the browser to keep it fed.

I'm thinking that the chat GUI, which runs the lchat protocol, could poll more like lchat
- there is a "normal" poll time of 3 seconds (like mchat)
- there is a "slow" poll time of 10 seconds (like mchat)
- if the browser is running lchat, notice the "afk" parameter from the browser - and pass it on through! - and switch between "normal" and "slow" and back, depending on whether afk=0 or afk=1
- keep track of "sent" messages, like lchat does, and move from "normal" to "slow" and back depending on idleness.
- if the browser is running mchat, use KoL's specified "delay" parameter

Since the chat GUI runs lchat protocol, setting the "afk" field appropriately will mean that KoL will properly mark you as being "away" if you are idle - just like it does with lchat.
Even though the chat GUI runs the lchat protocol, I see no reason it shouldn't use KoL's idea of good delays, as seen in mchat.

I'll try this, by and by.

 

[Veracity]

Revision 15766 fixes this. I whacked the Chat Poller to have a "normal" delay and a "paused" delay, just like lchat. It also gets a timestamp every time the browser polls and will not poll itself if the last browser poll was within it's own poll interval. Lastly, if you are running mchat in the browser, KoL itself gives the delay and the chat GUI's poller picks that up and obeys it.

The only thing which will break this, as far as I know, is if you have the chat GUI and the browser chat open at the same time, go into "away" mode in the browser (which lows down the chat GUI too) and then exit browser chat without leaving "away" mode. The chat GUI will continue polling slowly.

I intend to fix this, but let's see how things work right now, leaving that corner case. By and by, I will do this:

- When we process a "sent" message - either from chat GUI or browser - record timestamp and setLChatPaused( false )
- Each time through the ChatPoller's loop, check time since we last sent a message. If greater than 15 minutes, setLChatPaused( true )
- Detect when lchat in browser enters & leaves away mode. Log it in chat GUI?
You are now in away mode, chat will update more slowly until you say something.
Welcome back! Away mode disabled.

I believe this issue is Fixed, but I'll leave this Bug Open until I can do that last bit.

 

[Veracity]

Revision 14781 makes the chat GUI go into "away" mode if you have not typed anything for 15 minutes. It leaves it when you next type a message.

We are STILL not quite done here since lchat in the Browser never seems to go into "away" mode if you happen to be running the chat GUI at the same time. That means that even if the GUI goes "away", the next time lchat refreshes in the browser, it leaves "away", since the browser submits a request with "afk=0".

I'll investigate more tomorrow.

 

[Veracity]

lchat in the Browser never seems to go into "away" mode if you happen to be running the chat GUI at the same time.

Correction: lchat in the Relay Browser never goes into "away" mode, period, since for some reason we disable that feature via the following code in RequestEditorKit:

			StringUtilities.globalStringReplace( buffer, "cycles++", "cycles = 0" );

I assume this was because the chat GUI couldn't handle "away" mode at the time, but now it can, and that page adjustment is toxic. It drove me bonkers, trying to understand why the Javascript in the vanilla browser behaved differently from that in the Relay Browser, until I decided to see if we were modifying it. Aargh!

 

[Bale]

Heh. That's the worst kind of bug/feature.

 

[Veracity]

OK, I think that revision 14789 sorts it all out.

- It no longer disables "away" mode in the relay browser running lchat
- It does "away" mode nicely in the chat GUI
- If you have the chat GUI running simultaneously with either lchat or mchat in the relay browser, it handles "away" mode as well as it can.

There is a glitch which I don't think I can fix. Since the chat GUI needs to be able to operate all by itself, it decides on its own whether or not to enter "away" mode. However, if it makes that decision before the browser makes the same decision, it may say "entering away mode" and again when the browser decides to do it.

It can only happen if you are running both the chat GUI and the browser chat at the same time. I'll run like that for the next few days and see if there are other glitches or if I can figure out a way to deal with this, but otherwise, I am happy.

It also fixes the issue reported in this bug report; if you are running mchat in the browser and KoL decides to put you into "away" mode, the chat GUI is no longer spammed with repeated events telling you that.

I'm marking this fixed.

 

[Veracity]

Aaaaand, just as I was about to go to bed, I had an idea: make the interval after which the chat GUI enters "away" mode be slightly longer than KoL's interval. Say, 15 minutes + 10 seconds. If lchat or mchat go into "away" mode after 15 minutes, if you are running them simultaneously with the chat GUI, they will always enter "away" mode first, and we will follow their lead.

I'll try this tomorrow.

 

[Bale]

Whoa! Congratulations on solving this!