Linkdeath & Character Death -- A solution?

[Asanadas]

This is a continuation of the side-conversation in http://gdb.armageddon.org/index.php/topic,50382.75.html, in order to get that conversation about being link-dead out of a thread based on Ranger quit. I don't really have much to add, other than what I've posted before. If those off-topic posts could be moved here, that would be really cool.

[Armaddict]

Going on...I agree that linkdead characters should be put onto a timer where at some point, they are removed from the game world.  I do not know the exact amount of time I'd like this to be.  15 minutes seems pretty short to me, enough time that someone pursuing you steadily but slowly across the known can arrive to where you just decided to go linkdead after your skirmish and disappear.

This would be more tolerable if there was indication, again, that someone had logged out there recently so that it could be reported, and if a trend is noticed, it could be dealt with by those who consistently see those reports.

I do not agree that just idleness should disconnect you.  There are large portions of people who go afk for periods of time, myself included...it's a habit, to keep my character available for Waying or any other stuff and things.  I have never, even in newbie states, used 'idleness' as a request for resurrection.  Because that's my bad.  I'm in game, I"m available, I'm volunteering to interact with things...if bad things happen because I took a 30 minute afk to cook dinner instead of logging out, that's just kind of how that cookie crumbles.  As noted elsewhere today, I give some leeway to other people who seem idle/afk, but this proposal is an all out protection.

[Resurrection derail]
Resurrection for these kind of things don't and shouldn't exist.  That may seem callous, but the danger in a permadeath game is not destruction of the narrative --  The narrative will continue, you will have new characters, things will go on in our static sandbox.  The danger is setting precedence.  Once precedence is set for instances, they can be referenced by anyone and everyone with knowledge of it in order to make arguments for favoritism, or against actions.  Traditionally, the way I always saw Arm's harsh sentiment towards resurrections was that it maintained this level field.  Yes, it sucks.  Yes, we can see that you were -probably- afk, but making afkness an excuse for it is just asking for a floodgate.  Does it suck when your militia recruit gets killed for smuggling spice when it's an object that is unrecognizeable as spice but is coded as spice?  Yes.  Yes it does.  But granting a resurrection over it opens up an entire avenue of argument and hostility over what decisions have to be made, resulting in a scenario where those who know the harsh rule, who would have settled down and moved on, prior, now have a precedent to feel injustice over.
[/derail]

Anyway.  Yes.  Protect the linkdead.  Do not make it so that someone can arbitrarily argue that link was lost when there's no proof of it on the other end, or it becomes an easily manipulated argument where staff is in a position where there -is- no correct way to deal with it.

[Asanadas]

Lol I'm going to stop myself from getting in a fight over resurrection semantics, since that got me in trouble in the first place. Let me go on record saying I've got many issues with the current policy, and leave it at that.

But anything to stop someone from having to deal with that policy is a good idea, in my book. So knocking characters off of the PC playing field when they can't react to the world will prevent a few useless character deaths, and enable characters perhaps reach their potential past the time their player's city block blacked out, or their internet cut off.

[RogueGunslinger]

I'm not really sure what sort of floodgate opening you're expecting Armaddict. A floodgate of people who should rightly get resurrections because the game fucked them in the ass OOCly? Oh, no, the horror. A floodgate of people whining about not getting rezzs in the past? Tough shit for them.

You say there will be argument and hostility like we don't already have tons of that. The argument and hostility is BECAUSE of the strict rez policy. I really don't see how letting some people rightly have their characters back after a shitty bit of code fucks them over is going to cause any more emotion than NOT getting the rez is causing now.

My problem with the policy is it's vague, undefined, and incredibly strict. The vagueness makes for more room for people to argue for and against. If it was strictly explained what instances were and weren't worth a rez, then nobody would be able to rightly whine about not getting one, because they wouldn't meet the requirements.


Also, I doubt anyone's going to talk about ways to deal with link-dead people when this topic of rezzes is much jucier. Case already solved that problem for us:

Honestly, it should keep a timer since last command, and if none is entered in say 15 mins, it should linkdead you. That's the failsafe. If this is implemented currently, it's not working perfectly for some reason.

Otherwise it should be detectable iff it fails a send to a connection that has been torn down or otherwise lost that is able to return an error. Lag will muck it up, a firewall being overzealous might return nothing, or I dunno, DNS breaks or something weird. This should be covered by the failsafe.

In the case of the game lagging and halting its timers, we have a problem. The connections will time out but not correctly be torn down, the lag is of N length and players may have to go, and upon resumption it'll still take the failsafe time to linkdie people. So maybe a check to system time each series of game loops that can detect this problem.

[Asanadas]

My thread will get locked if you keep talking about the rez policy. 

But yeah, that quote from Case would solve the issue, I think.

[Armaddict]

...no.

You're talking in terms of what actually happened.

I'm speaking in terms of people insisting they were linkdead when their mushclient had actually just frozen up due to their inactivity.  Or someone who suddenly got lag because their roommate started downloading porn, and insisted that the game was disconnecting them, which explains their delays.  The 'floodgate' is not the justified resurrections, but the excuses created for why everything fits into those justified categories, of which there are far more than the ones that are simply justified.

Edit:  Such is, I believe, the reason for current policy.  It's verifiable.  It's not something that can be bent around too much.  It becomes blatantly obvious between IC and OOC problems.  If there is a blurring, it's not fucked with, or it sets precedent for the grey area to become arbitrary.  Arbitrary bad.  Set guideline good.  Especially in a game where 90% of death leaves you feeling cheated because it's always cutting SOMETHING short.

[RogueGunslinger]

...no.

You're talking in terms of what actually happened.

I'm speaking in terms of people insisting they were linkdead when their mushclient had actually just frozen up due to their inactivity.  Or someone who suddenly got lag because their roommate started downloading porn, and insisted that the game was disconnecting them, which explains their delays.  The 'floodgate' is not the justified resurrections, but the excuses created for why everything fits into those justified categories, of which there are far more than the ones that are simply justified.

Dude that sort of shit would be easy to spot and differentiate from the real issues. It's not like we're asking for a blanked rez for anyone who got a hiccough of lag. I'm talking about starving/parching to death when you PC has fucking food and water in their hands. Or other similar shit that wouldn't make any sense to try and falsify.

[Armaddict]

Maybe in that particular instance, that's what you're talking about.  But you've been on kind of a mission in this regard to far less black-and-white scenarios for awhile now, which is why I oppose the fringes of your arguments even when they seem harmless, because I know where you want it to end up.

Rerouting, so that you stop responding to the derail I actually labeled as a derail for a sidenote of why I had a less forgiving approach to linkdead deaths...

Yes.  Protect the linkdead.  Do not make it so that someone can arbitrarily argue that link was lost when there's no proof of it on the other end, or it becomes an easily manipulated argument where staff is in a position where there -is- no correct way to deal with it.

I am for linkdead people being saved from pretty much most manner of death, with safeguards in place.  I'm assuming the thirst/hunger while linkdead thing is there to prevent going linkdead to give more time for someone else to rescue you, which is silly, but I'm not sure how common that kind of thing is, either.

[RogueGunslinger]

The thread is about character death as well as linkdeath... I don't think Resurrection is that far of a stretch to discuss. If it really bothers someone another thread could be split off... but we've already done that twice, lol.

Maybe in that particular instance, that's what you're talking about.  But you've been on kind of a mission in this regard to far less black-and-white scenarios for awhile now, which is why I oppose the fringes of your arguments even when they seem harmless, because I know where you want it to end up.

I have no idea what you're talking about here. What mission am I on, exactly? Why would you think I want less black and white rezzes? There are plenty of different cases where the situation was black and white and there was still no rez given. It's the entire reason why I want the policy to be altered and better defined. With better definitions it would be really easy to tell the black and white instances from the ones that weren't.

[Armaddict]

I apologize.  That phrasing was poor, it makes you sound incredibly dastardly and malevolent in your wish for fairness.

I'll just say that your version of black and white is much larger, and your grey area much smaller than me. My black and white zones are very small, and the grey area huge, where I shift it over into the 'better safe than sorry' category as far as establishing precedence and thus room for arbitrary decisions, which was the reason for my derail (I hate arbitrary). Anytime code consequences are unforeseen, you see it as something worthy, where I think strange consequences fit in (i.e. My example of my militia giant being killed for spice-that-wasn't-spice.  I requested a resurrection for it, but only out of a false hope; I was already resigned to the fact that it happened and would not be reversed, because he -was- in reality caught for an illicit substance, even if it's one that I didn't think was recognizable since I didn't recognize it.)

Note that the linkdead death is actually an area that I am in alliance on, where it is odd, however, I was jumping on you kind of pre-emptively to try and reign in what I thought was going to be a segue on resurrections as a whole; It did more damage than good.  Whoooops.

Note to reader:  RGS IS NOT ON A MISSION TO MAKE THE MUD NON-PERMADEATH.  I just like punishment for mistakes or acting without forethought a lot more than he does, and my 'fairness' area is smaller.  He's just been pretty vocal about trying to get that 'fair' area expanded which I am in disagreement with, firmly.

[RogueGunslinger]

Ah. Yeah we could probably argue for hours on what we think is black and white. If your giant really had an illegal substance, then I agree, no rezz should be given. We can agree on that at least.

I could make an argument that gate-guards murderizing people is stupid and shitty and need fixed though. (I haven't seen that in a long time so maybe it is)

[Lizzie]

The system doesn't know mushclient timer freezes. And - if you're the victim of it, you don't know it either. You eventually get a disconnect message, but that message is from mushclient - not the game. The game is likely to see that you're still connected for quite awhile before IT finally severs the connection. I've had to deal with this a few times already. I've also had to deal with server disconnections on -my- end, where the data packets were still hopping away to the game even while I was in the process of rebooting my computer.

That's the problem with resurrection for linkdead. The game server recognizes linkdead accounts under its own specific criteria. Often that criteria has nothing to do with "my game client froze and my phone went dead."

During the time that the game doesn't recognize your account as being linkdead, your character is vulnerable to everything.

Once it DOES recognize it's linkdead, the hunger/thirst timer shuts off. It'd be nice to get some additional messaging, and perhaps code wandering/spawning mobs to not go into that room until that PC is no longer occupying it (whether because it's dead or someone logged it out or the player reconnected and moved it himself). For other PCs wandering into the room to see the linkdead guy, I'd like to see maybe some kind of "gone" message whenever you try to interact with him in any way. Something like "This character is linkdead and unable to respond. Though he is vulnerable, any further interaction will be logged and reviewed by the staff."

This way - you know he CAN be killed, if your character feels he should be killed. And if you, the player, are in the right, you have nothing to worry about when the staff checks the log. But if you, the player, make a habit of PKing/robbing/creating problems for linkdead characters, that will also be brought to the staff's attention.

If something like that was codeable, I'd be all for it. I'm -not- in favor of linkdead people being immune to circumstances. I -am- in favor of everyone else being notified that the person is, in fact, linkdead, and that anything occuring following that notice will be logged autologged by the system for maybe an hour or something. (including your way conversations, thinks, emotes, etc).

[Asanadas]

I remember coming across a logged out 'Rinthi PC standing with a bloody knife in the Red's. (This was over a year ago.)

We were all getting ready to jump him, when we wished up and asked about it. A staff member then made the character quit (so-and-so has departed from Zalanthas) and we just went back to our own business.

Though we really could have screwed this guy over for where his character was, I thought it was better that the link-dead character was removed from that situation in retrospect.

And just recently, I wished up to try and save the skin of someone who was link-dead, but there wasn't a response to that request that I knew of. So it seems like it's on a staff-choice basis. Or maybe it depends on if you're actively trying to kill/harm the person.

I think any situation where the character dies without a player controlling them is a bad situation, and, while resurrections are not going to be handed out due to potential malignancies  at least this framework could be brought up to speed to the 21st century with auto-quits for linkdead individuals.

[nauta]

And just recently, I wished up to try and save the skin of someone who was link-dead, but there wasn't a response to that request that I knew of. So it seems like it's on a staff-choice basis. Or maybe it depends on if you're actively trying to kill/harm the person.

I've wished up and had them removed in both friend and foe situations.  More than likely, the actual answer is there wasn't a staff with the privs logged in at the time.

(I alway carry a piece of chalk on me so I can scribble dicks on a stick figure of the linkdead person.)

It wouldn't catch -all- the cases, but wouldn't the simplest solution be to simply quit the linkdead person (defined as someone who received the echo 'has disconnected or lost link' or whatever that echo is) after 30 minutes or so?  (Some clients and VPN setups won't get that echo, and so it wouldn't catch those cases.)

[Asanadas]

That makes more sense! I try to have optimism about conversations on the Imm level.

[Adhira]

If you see someone linkdead in game wishing up is a great idea.  Staff don't have a method to be able to identify linkdead PCs in the game. Our 'who' list only returns people who have an active connection to the mud, with their idle timers.  We will always purge linkdead people if there is a staff member around who is able to do so. As an FYI the only staff members who are unable to do so at this time are our newest staff members who aren't yet out of probation.

[Armaddict]

...wow, okay, that's good to know.  I'll make a habit out of wishing up myself, then.

[Lizzie]

Yeah I've wished up any time I see someone who's anywhere that could *typically* get them killed. Usually a staff member will silently remove the character from the room/game.

Also for those who want to find out if it's just someone alt-tabbing to another window on his computer - some new players might not realize we have a BEEP command.

Beep                                                               (Gameplay)

  You are able to cause another player's terminal to audibly beep (if
their terminal has such capability). This can be used to check that another
player has not gone link-dead, as may be the case if they have not
indicated (via the ooc or gone commands) that they are occupied in real
life, but also have not performed any visible actions with their characters
for some time. Use this command very sparingly, if at all.


Syntax:
  beep <character name>

Example:
  beep savak

See also:
  gone, ooc

I don't use it often but it does come in handy during times when you cross paths with someone who really -should- be paying attention to their game screen, but for whatever reason, is unresponsive.

[Asmoth]

Yeah I've wished up any time I see someone who's anywhere that could *typically* get them killed. Usually a staff member will silently remove the character from the room/game.

Also for those who want to find out if it's just someone alt-tabbing to another window on his computer - some new players might not realize we have a BEEP command.

Beep                                                               (Gameplay)

  You are able to cause another player's terminal to audibly beep (if
their terminal has such capability). This can be used to check that another
player has not gone link-dead, as may be the case if they have not
indicated (via the ooc or gone commands) that they are occupied in real
life, but also have not performed any visible actions with their characters
for some time. Use this command very sparingly, if at all.


Syntax:
  beep <character name>

Example:
  beep savak

See also:
  gone, ooc

I don't use it often but it does come in handy during times when you cross paths with someone who really -should- be paying attention to their game screen, but for whatever reason, is unresponsive.

And if they are playing another game in another window, will have a momentary heart attack thinking their character has died.

[Armaddict]

I have forgotten I was in Arm before, and heard that dreaded beep.  It really does give a heart attack.

I've had it be both death and someone beeping me.  The reaction is the same.  Realize, when you are doing it, you are killing me in RL for a half-second.

[Saellyn]

If you'd answer me within five seconds when I rp with you, Armaddict, I wouldn't HAVE to be sitting in a courtroom on charges of attempted murder!

[RogueGunslinger]

Hah, I sometimes get impatient and beep people. Not my fault you aren't looking at the screen without using the Gone command.

[chrisdcoulombe]

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

[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.

[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.

[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.