Linkdeath & Character Death -- A solution?

[Asmoth]

Not everyone is link dead on purpose.  What if their power went out or their isp went down?

Thats understandable, don't think anyone said that all link dead folks are horrible idlers.

I honestly don't know why there isn't a code in place to boot them after like a half an hour of inactivity.

Other than allowing them to be stabbed in the face, they aren't really at risk of anything since the code already stops hunger and thirst.

It feels to me like link dead characters are half done and an auto quit code would finish them up.

Inactivity can't be the only criteria for booting someone's character out of the game. There are situations in the game that involve the character being - inactive. Sometimes longer than a half hour.

In addition to the above if someone is idling and alt-tabbing, there's no reason why the code should auto-boot them. If I had a noble character who needed to be available, but *I* the player had other things I needed to do, I'd log in, park myself with my barrier turned off, and go do whatever things I needed to do offline. If I heard a beep or had a sound trigger set if the word "you" appeared on my screen, I could easily alt-tab back and check it out.

Personally if it were me I'd type "save" every 5-10 minutes, but that doesn't mean everyone else has to.

I get it, but then you just code your own custom timer to pop off every ten minutes or so and if you end up stabbed in the face its your fault.

However if say Joe Armers internet goes down for a day, the code will kick in and do its job to remove the idle player, then when he gets that sorted, he comes back unmolested.

I think the code should be proactive to assistance moreso than detriment.

[Lizzie]

Not everyone is link dead on purpose.  What if their power went out or their isp went down?

Thats understandable, don't think anyone said that all link dead folks are horrible idlers.

I honestly don't know why there isn't a code in place to boot them after like a half an hour of inactivity.

Other than allowing them to be stabbed in the face, they aren't really at risk of anything since the code already stops hunger and thirst.

It feels to me like link dead characters are half done and an auto quit code would finish them up.

Inactivity can't be the only criteria for booting someone's character out of the game. There are situations in the game that involve the character being - inactive. Sometimes longer than a half hour.

In addition to the above if someone is idling and alt-tabbing, there's no reason why the code should auto-boot them. If I had a noble character who needed to be available, but *I* the player had other things I needed to do, I'd log in, park myself with my barrier turned off, and go do whatever things I needed to do offline. If I heard a beep or had a sound trigger set if the word "you" appeared on my screen, I could easily alt-tab back and check it out.

Personally if it were me I'd type "save" every 5-10 minutes, but that doesn't mean everyone else has to.

I get it, but then you just code your own custom timer to pop off every ten minutes or so and if you end up stabbed in the face its your fault.

However if say Joe Armers internet goes down for a day, the code will kick in and do its job to remove the idle player, then when he gets that sorted, he comes back unmolested.

I think the code should be proactive to assistance moreso than detriment.

The game server relies on packets sent to and from it to determine whether or not there's a "live" connection between it and you. If it receives pings and packets even after you lost your internet at your end, then it will continue thinking you haven't lost your internet. You could turn your computer completely off and - if your data line/wifi/router/cable still sends packets, then ginka will think your character is still legitimately in the game.

[Asmoth]

Not everyone is link dead on purpose.  What if their power went out or their isp went down?

Thats understandable, don't think anyone said that all link dead folks are horrible idlers.

I honestly don't know why there isn't a code in place to boot them after like a half an hour of inactivity.

Other than allowing them to be stabbed in the face, they aren't really at risk of anything since the code already stops hunger and thirst.

It feels to me like link dead characters are half done and an auto quit code would finish them up.

Inactivity can't be the only criteria for booting someone's character out of the game. There are situations in the game that involve the character being - inactive. Sometimes longer than a half hour.

In addition to the above if someone is idling and alt-tabbing, there's no reason why the code should auto-boot them. If I had a noble character who needed to be available, but *I* the player had other things I needed to do, I'd log in, park myself with my barrier turned off, and go do whatever things I needed to do offline. If I heard a beep or had a sound trigger set if the word "you" appeared on my screen, I could easily alt-tab back and check it out.

Personally if it were me I'd type "save" every 5-10 minutes, but that doesn't mean everyone else has to.

I get it, but then you just code your own custom timer to pop off every ten minutes or so and if you end up stabbed in the face its your fault.

However if say Joe Armers internet goes down for a day, the code will kick in and do its job to remove the idle player, then when he gets that sorted, he comes back unmolested.

I think the code should be proactive to assistance moreso than detriment.

The game server relies on packets sent to and from it to determine whether or not there's a "live" connection between it and you. If it receives pings and packets even after you lost your internet at your end, then it will continue thinking you haven't lost your internet. You could turn your computer completely off and - if your data line/wifi/router/cable still sends packets, then ginka will think your character is still legitimately in the game.

Simple enough to fix. Have it look for a command every X minutes or consider you disconnected.

This really isn't rocket science, it would take someone with hardly any coding ability (me for example) about ten minutes to code if I typed slow.

[CodeMaster]

Our connections to the MUD are completely rudimentary with no keepalives or pings being sent back and forth.  That's the problem - when nothing's being sent or received, how do you know if the connection is still there?

Estimating any coding task in a nontrivial codebase at ten minutes is probably a little tight!

[Armaddict]

Yeah.  I'm betting Arm's code is a giant ball of yarn at this point.  Saying anything will only take ten minutes is not taking into the account that every code edit will require you going through everything else that points to that thing or uses that thing to make sure you didn't just break it.  If it's heavily object oriented, then it's a bit easier, but if I recall correctly it was asked how Arm is coded and it's in C, which is not object oriented.  I could be mistaken on that count though.

That said.  I am for protections to linklost characters.  But I am also not going to demand that it be done super quickly since I do not know what is involved with such changes.  I just know it should be on the list, and in a position that is relative to cost/benefit, which is how it's done already.

[Asanadas]

The "easiest" way would be to sever connections on people idle for [arbitrary time], but it's also the most sloppy. I haven't played with "beep" very much... I think it has a special return if someone isn't logged in? That means the MUD is already capable of client communication.

If we had a stealth "beep" on all connected players (on the WHO) every 20 minutes or so, that could solve the issue of ghost connections; but it doesn't solve the PC still being in the virtual world. There could be an alert on staffnet that "X beep failed: disconnecting..." and then the staff member could manually quit-out the player: not unlike currently. Or, it could be automated to quit out all link-dead people... It's complicated and I'd have to look at the databases to really suggest something, which ain't happening anytime soon.  :-P

[Asmoth]

Yeah.  I'm betting Arm's code is a giant ball of yarn at this point.  Saying anything will only take ten minutes is not taking into the account that every code edit will require you going through everything else that points to that thing or uses that thing to make sure you didn't just break it.  If it's heavily object oriented, then it's a bit easier, but if I recall correctly it was asked how Arm is coded and it's in C, which is not object oriented.  I could be mistaken on that count though.

That said.  I am for protections to linklost characters.  But I am also not going to demand that it be done super quickly since I do not know what is involved with such changes.  I just know it should be on the list, and in a position that is relative to cost/benefit, which is how it's done already.

Our connections to the MUD are completely rudimentary with no keepalives or pings being sent back and forth.  That's the problem - when nothing's being sent or received, how do you know if the connection is still there?

Estimating any coding task in a nontrivial codebase at ten minutes is probably a little tight!

You know why I know it wouldn't be drastically hard to do?

Code Select Expand

Connected to host ginka.armageddon.org
                                _______                                ___
                              /\\_____//~-_                        _-~\\__
                             (~)       ~-_ ~-_                  _-~ _-~   
                            (~)           ~-_ ~-_            _-~ /-~     
Welcome to Armageddon!     (~)              `~-_ ~_======_--~~ __~       
                          (~)               _~_\__\____/__/_--\ ~`-_   
                           \           _-~~            _-~~~-_ \_  ~-_ 
You may:                    ~-       __--~`_    /   _-~         ~.     ~_
(N) Create a new account           -~        \     _~       ___,  \ ~-_  \
(C) Connect to your account      ,~ _-,       ~  _~         \   \  | , \ \ 
(V) Toggle ANSI/VT100 mode      / /~/      -~   /            ~  /  /  \~  \
(B) Toggle 'brief' menus        | | \     _~    |        __-~  / _/  \~  '\
(D) Documentation menu          \ ~-_~   -   |  _      ~-____-~ .~  \~    |
(X) Exit Armageddon             /`.  __~~   ~   `_          __-~   \~    \~
(?) Read menu options           \_ ~~   .  |  .   ~-____--~~   \ \_~   _/~ 
                                /\___--~       ~--_      /   ____~ _/~~     
                                \         /        ~~~___  /     _-\\~\     
                                /\       /                   _-\~\\~\\~\   
                               / | \   \ | /    /         _-~ )\\~\\~\\~~\ 
                              { /\ \             /      _~ \  ~`~~\\~~\\~~\
Read the documentation        { |\     __ _           _-\   \  \\~~\\~~\\~~\
menu before creating your     | ||~_ /`    ~\  /    _/~  )   | |\\~~\\~~\\~~
character, please.            | ||  \|"""""""|_ __-~     ;   | |~\\~~\\~~\\~
                              \ \\  ({"""""""}\\        _~  /  /~~\\~~\\~~\\
Armageddon is OPEN.
Choose thy fate:

You have been idle too long, please reconnect when you are back.
Voila, all you gotta do is some Object Oriented Programming.

[Lizzie]

The "easiest" way would be to sever connections on people idle for [arbitrary time], but it's also the most sloppy. I haven't played with "beep" very much... I think it has a special return if someone isn't logged in? That means the MUD is already capable of client communication.

If we had a stealth "beep" on all connected players (on the WHO) every 20 minutes or so, that could solve the issue of ghost connections; but it doesn't solve the PC still being in the virtual world. There could be an alert on staffnet that "X beep failed: disconnecting..." and then the staff member could manually quit-out the player: not unlike currently. Or, it could be automated to quit out all link-dead people... It's complicated and I'd have to look at the databases to really suggest something, which ain't happening anytime soon.  :-P

That might work for people who allow the beep to reach their ears. My previous example was just that - a hypothetical example. I don't have speakers on my computer and I only wear headphones when I'm listening to music - which I don't do when I'm playing Arm. I'd never hear a beep. Thankfully I -do- watch the screen most of the time. But if I'm not watching it, I won't know you beeped me.

[Asmoth]

The "easiest" way would be to sever connections on people idle for [arbitrary time], but it's also the most sloppy. I haven't played with "beep" very much... I think it has a special return if someone isn't logged in? That means the MUD is already capable of client communication.

If we had a stealth "beep" on all connected players (on the WHO) every 20 minutes or so, that could solve the issue of ghost connections; but it doesn't solve the PC still being in the virtual world. There could be an alert on staffnet that "X beep failed: disconnecting..." and then the staff member could manually quit-out the player: not unlike currently. Or, it could be automated to quit out all link-dead people... It's complicated and I'd have to look at the databases to really suggest something, which ain't happening anytime soon.  :-P

That might work for people who allow the beep to reach their ears. My previous example was just that - a hypothetical example. I don't have speakers on my computer and I only wear headphones when I'm listening to music - which I don't do when I'm playing Arm. I'd never hear a beep. Thankfully I -do- watch the screen most of the time. But if I'm not watching it, I won't know you beeped me.

Could possibly get beep to actually BEEP through the system speakers.  Like if you hit shift 5 times fast.

That way even people without speakers will beep, granted it's not very loud.

[Armaddict]

Well.  If it's in C, you can't do OOP. (Edit: Unless I don't know what I'm talking about, I'm almost exclusively C++ based)

What you've pointed to is a procedure that runs on connection, not the creation of an object that is your connection with some refreshing variable that is your idletimer.  Pulling the idle check out of that procedure and pasting it over into the runtime procedure that starts after moving on from connection could be easy, or it could be irritating and bogged down.  I really couldn't tell you without looking at some of the code.

However, I will operate under the assumption that the game has run for 20 years and there is more reason to it not being there than just 'We think linkdead people should die and this would take us a whole 10 minutes to change.'  I do agree it should be done.  I'm just saying that you're attempting to make it look asinine that it hasn't been done, and I'm acknowledging that that very well may not be the case.

[boog]

Can I just say that my internet goes out and I don't appear link dead until I reconnect? Because that's happened about a million times in my time at Armageddon.

[Asmoth]

Well.  If it's in C, you can't do OOP. (Edit: Unless I don't know what I'm talking about, I'm almost exclusively C++ based)

What you've pointed to is a procedure that runs on connection, not the creation of an object that is your connection with some refreshing variable that is your idletimer.  Pulling the idle check out of that procedure and pasting it over into the runtime procedure that starts after moving on from connection could be easy, or it could be irritating and bogged down.  I really couldn't tell you without looking at some of the code.

However, I will operate under the assumption that the game has run for 20 years and there is more reason to it not being there than just 'We think linkdead people should die and this would take us a whole 10 minutes to change.'  I do agree it should be done.  I'm just saying that you're attempting to make it look asinine that it hasn't been done, and I'm acknowledging that that very well may not be the case.

Fair points all of these...

However, look at it like a problem solver and not a pessimist.

these are some truths of the code:
1. You can quit ooc anywhere.
2. Admin can disconnect you at the drop of one command. (They sometimes do it when you wish up, "Hey Boog is afk again!")

So let's play devil's advocate and say that the way the game checks for connection right this instant is buried in legacy code that would be too time consuming to do the code in the "Normal" way. (Which with the number of code additions they have made while I've been playing since 2007 ish, I would say it's not.) But let's ride that chain of thought anyways.

Why not simply create a process based off the staff "boot" command that simply keeps track of player input on that packet connection and after 30 minutes of no player connection, script runs, player vanishes to logoutland.

That's just one example of probably ten I have off of the top of my head that could be reasonable done.  Now am I being literal with the ten minutes? Nope, but you get the idea.

Coding isn't always clean and sometimes you can make some interesting hacks by thinking above and beyond the conventional level that most look at things.  That's what I mean by object oriented programming, don't carve the wheel from a brand new piece of stone, just use the same wheel that already works for another device and purpose of to your aims.

(I used to code for a now defunct mud that used a proprietary script and command base when I was like 17 and that's how I created many new features by altering code of existing staff commands and or skill commands and simply changing the way it worked for players versus staff.  For instance I made a teleport spell with limited rooms by creating in essence and alias and a dice roll versus magic ability to see if the player succeeded by programming room 1009 to be recognized as the town gate and having the character cast teleport town gate, which really if successful just staff teleported him with mana cost to that room and with flashy messages.)

You gotta be inventive and break the game a lot, but you'll make cool shit eventually.