Requesting method for resetting client.inactivity to 0

Page: 1 2
ID:133418
 
Sep 4 2008, 4:45 pm
Short of actually having the user do something in Dream Seeker, I could not find a way to reset the client's inactivity variable. I tried setting up a looping /proc to force the client to call various other procs and commands but to no avail.

The variable itself is "constant" so says Dream Maker when attempting to change it manually.

Unless someone has already figured out how to do this using DM code, I imagine something would have to be changed in Dream Maker itself.
Sep 4 2008, 5:33 pm
walk(src,0) should be enough to reset it. Or calling any of the movement procs.
Sep 4 2008, 6:17 pm (Edited on Sep 4 2008, 6:23 pm)
In response to Nadrew
 
client
    proc
        handle_inact()
            walk(src,0)
            spawn(10) src.handle_inact()
    
    Stat()
        stat("inactivity", src.inactivity)
        ..()
    
    New()
        src.handle_inact()
        ..()


I'm pretty sure I did that correctly, but it did not work. The inactivity continued to rise.

EDIT: I am using version 427.997
Sep 4 2008, 6:23 pm
In response to Larynx9
Try calling a hidden client verb instead. This works for me:

Actually, scratch that. Seems it was a bug. :P This won't work either.
Sep 4 2008, 6:38 pm
In response to Larynx9
Nadrew is mistaken. Nothing I've tried has worked, even using call() to call the verb in the proc and then calling Move(), walk() and even Northeast(), all without affecting the inactivity, even though Northeast() makes you move. It seems only the client can cause movement to reset it's inactivity. :/

I'm going to try a few more things, but it doesn't look like this is doable right now.
Sep 4 2008, 6:45 pm
In response to Xooxer
Thank you for your assistance. I hope for your success.
Sep 4 2008, 6:50 pm
In response to Larynx9
Unfortunately, nothing seems to affect it. I even tried really really bad code to try and break it, but no luck. Seems inactivity is rock solid from our end. :/


this won't work, but it compiles with no runtimes
client
    New()
        ..()
        spawn() handle_inact()

    Stat()
        stat("inactivity", inactivity)
        ..()

    proc
        handle_inact()
            inactivity >> inactivity << inactivity
            spawn(10) .()
Sep 4 2008, 8:05 pm
In response to Xooxer
Yeah, seems it was changed (or fixed depending on how you look at it) since the last time I messed with it. Sorry for the misinformation.
Sep 4 2008, 9:40 pm
In response to Xooxer
client/Command() was not resetting client.inactivity to zero. (Tiberath) ([link])

Could be that fix broke it in other places.

Anyhow, try calling client/Command() and see if that resets client.inactivity back to zero.
Sep 4 2008, 9:43 pm
In response to Tiberath
-_-' I can't believe I missed that. I must be tired. Thanks!
Sep 4 2008, 9:48 pm
In response to Tiberath
Odd, that doesn't work either. o_0 Maybe it's broken again?

client
    New()
        ..()
        spawn() handle_inact()

    Stat()
        stat("inactivity", inactivity)
        ..()

    Command()
        ..()

    proc
        handle_inact()
            Command()
            spawn(10) .()
Sep 4 2008, 9:59 pm
In response to Xooxer
Well, I'm lost.

I tried forcing the client to call Click(), Command() and even mob/Click().

Short of the user actually doing something themselves, I'm guessing client.inactivity is exactly that, how long the client user has been inactive.
Sep 4 2008, 10:04 pm
In response to Tiberath
There is one way to set it to 0, but it requires logging the client out and hoping they log back in instead of leaving like a sane person who gets disconnected every second from a game they're trying to play, so I doubt that's of any use at all. :P
Sep 5 2008, 12:03 am
In response to Xooxer
Ignore if wrong,
what about moving them once up, then back(using locate()).
Sep 5 2008, 12:41 am
In response to Xooxer
One way that works fine as expected is to force the client to send a command with winset(). From the DM Reference:

Another use for winset() is to send commands to the client that normally can only run from there, like .profile or .quit. To do this leave the window argument null, and just use a parameter called "command"

And it can also be used with a dummy verb, and will reset the inactivity. This works for keeping the inactivity down: 
mob/verb/Test()
    set hidden = 1
    src << "Hello ([client.inactivity])."

mob
    New()
        spawn(1) if(client) for()
            //cause Dream Seeker to send the command to execute the verb
            winset(src, null, "command=Test")
            sleep(1)
        
    Stat()
        stat("inactivity",client.inactivity)
Sep 5 2008, 7:21 am
In response to Bakasensei
Tried that, didn't work. Seems Kaioken found a workable solution, though. Don't know why I didn't try that last night. :P
Sep 5 2008, 2:47 pm
In response to Xooxer
It works for Dream Seeker, but it does not work with telnet, unfortunately. I guess I'm not surprised, considering winset() is involved with changing the graphical client, of which there is none for a telnet user, obviously.


The code I used:

client
    proc
        handle_inact()
            winset(src, null, "command=activate")
            spawn(10) src.handle_inact()
        
        report_inact()
            src << "inactivity: [src.inactivity]"
            spawn(10) src.report_inact()

    verb
        activate()
            set hidden = TRUE
            // do nothing

    New()
        src.report_inact()
        src.handle_inact()
        ..()

    Command(args)
        // the most basic of telnet support
        if(findtext(args,"hi")) src << "hello."
        ..()
Sep 5 2008, 6:06 pm
Larynx9 wrote:
Short of actually having the user do something in Dream Seeker, I could not find a way to reset the client's inactivity variable. I tried setting up a looping /proc to force the client to call various other procs and commands but to no avail.

Yeah, client.inactivity is setup to only track actual user input, so by its nature it cannot be overriden.

That said, I don't see any harm in making it writeable, in cases where you specifically want to do this. We'll have to see if there's a real restriction here (I'm assuming Dan put this in circa 1996), but I doubt it's a problem.
Sep 5 2008, 7:10 pm
In response to Tom
Thank you, Tom.

I was trying to figure out a way to bypass BYOND's automatic booting of telnet clients, which happens after roughly 13-15 minutes of idle time. I had assumed that if I could reset client.inactivity to 0 every so often before that happens, I could successfully bypass it. This is assuming that the automatic-booting draws off of client.inactivity.

Not counting this, and the delay coupled with "(Hit enter to continue.)" when first establishing a telnet connection, I believe BYOND's telnet support is flawless.


While on the topic of telnet, I found that if a telnet client sends more than 1021 characters/bytes of data, the connection crashes and the server disconnects them.

I don't consider this a problem or bug, but I just wanted to let others know of the limit, if they were interested in the subject.

client/Command(args)
    if(length(args) > 255)
        src << "Input too long, please shorten."
        return
    ..()


This bit of code does not seem to have any effect on keeping the clients from crashing, either.
Sep 5 2008, 7:16 pm
In response to Larynx9
Larynx9 wrote:
I was trying to figure out a way to bypass BYOND's automatic booting of telnet clients, which happens after roughly 13-15 minutes of idle time. I had assumed that if I could reset client.inactivity to 0 every so often before that happens, I could successfully bypass it. This is assuming that the automatic-booting draws off of client.inactivity.

I believe that the automatic booting is a client-side issue, where telnet shuts the connection if it hasn't sent a packet in a while. Usually telnet clients have a "keepalive" option to subvert this (although I'm not sure what the server will do with such packets). Why don't you look through the options on your client and see if there is something like this (on Putty it is in the "connection" section).
Page: 1 2