Jump to content
Eternal Lands Official Forums
saxum

Setting to control grue timer

Recommended Posts

This happens a lot more often to me now while traveling than it does at home but I think it would be useful to all players.

 

Suggestion: User controlled setting to control how and after how much no response time does a player grue.

Observation: Grue does not appear to be directly connected to connection for I have kept a continuous trace route with no hiccups and still grued; it has also occurred shortly (under a minute) after a player action so not sure what all factors go into a grue.

Suggested controls:

  1. Current grue settings would not change unless a player, preferably per character, changed settings manually.
  2. Have setting to automatically attempt to reconnect after a grue for a period of time. Very useful for players AFK reading or just listening to messages
  3. Have grue check time as setting; Grue will occur if two successive checks within this period fail. Players could adjust it to smaller number when in dangerous situation or to larger period of time when in

Command line interface for these settings would be useful.

 

As currently implemented punish players, In addition to the above mentioned interruption of reading there are cooldown on items, interrupt and cooldown on harvesting, very annoying grues before end of hour which can take away ability to gain harvest experience for an hour and other unnecessary minor effects.

 

When I was asked about grues as a new player I was told it was to protect players from such things as being attacked and to prevent abuse by logging out and in quickly hence cooldown but it now seems to be a mini-event which needs to be overcome too often.

Share this post


Link to post
Share on other sites

Especially we need an way to tell the client to restart login as i often have to wait up to 5 minutes between me gruing and the client regognizing that i am out of game. I know that because the players online page has me logged out while my client is still waiting to accept that.

Share this post


Link to post
Share on other sites

idk I can stay logged in (and afk) for days without gruing.

He's not complaining about gruing itself. The issue here is if one 'lane' in your connection has issues (for example packet loss on uplink), you can lag out and the client cannot tell quickly that you are offline because of long timeout period. In other words, the client doesn't know yet that you are offline.

So at least on Linux, the grue message may sometimes literally never ever appear until I disable the network interface completely and re-enable it (even though I am not behind a router and I have a static external IP address). The client will then notice that I am not online and bring out the disconnected message.

Somehow, especially on Linux, the client is waiting for the server to tell it you disconnected and so it can take long minutes before you get the disconnected/reconnect message.

 

And as Vino said, we have no manual re-login option.

 

Maybe at least make typing #ping give us an option to relogin if the resultant latency goes above 60 seconds?

 

Or a #relogin option that logs us back in if there is a connection to server and the server says we are offline. The same command can say "You are already online" if the server says we are still online (to avoid usage spam).

Share this post


Link to post
Share on other sites

Maybe at least make typing #ping give us an option to relogin if the resultant latency goes above 60 seconds?

Or a #relogin option that logs us back in if there is a connection to server and the server says we are offline. The same command can say "You are already online" if the server says we are still online (to avoid usage spam).

After a bit of playing around (failing to get any indication of a disconnect from the network functions) this looks like a viable combination:

A "#relogin" command (or similar name) that does a test "#ping". If it does not get a response within a set time, the client enters the disconnected state and will attempt a reconnect after a key press (as is normal when in that mode). It's only a minor change so I could commit it when I've cleaned the test code up a bit. What do you think?

Share this post


Link to post
Share on other sites
After a bit of playing around (failing to get any indication of a disconnect from the network functions) this looks like a viable combination:

A "#relogin" command (or similar name) that does a test "#ping". If it does not get a response within a set time, the client enters the disconnected state and will attempt a reconnect after a key press (as is normal when in that mode). It's only a minor change so I could commit it when I've cleaned the test code up a bit. What do you think?

That would be a great change for some players like myself with occasional unstable connections. Thank you.

Share this post


Link to post
Share on other sites

OK, I've committed the change. The command is "#relogin" as discussed. It waits for up to 10 seconds for the server response before taking action. Both name and timer value are easily changed. If you can test it let me know how you get on.

Share this post


Link to post
Share on other sites

Is there a windows version?

 

With the repeated issue with grue due to DDoS or DDoS Firewall the grue timer should be increased,

Even better would be a setting so if you are sitting in storage you can sit it on "high" but if training "low".

 

It is annoying to walk away for lunch and discover a minute after you left you grued out.

Share this post


Link to post
Share on other sites

I just posted in the unable to connect thread that I have temporarily opened access to all users on my proxy server

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×