Posted - 2006.07.18 08:19:00 - [31]

 

From what I hear this tactic is spreading, so dev's its time for you to start looking at this a bit more seriously. It is a clear exploit as it causes lag. To see people start talking about how we can use this tactic to gain an advantage is worrying. So far we have said this is an unaceptable tactic but if it become the norm for thoose that attack us what are we supposed to do.
Dev's please take a look at this issue.

Posted - 2006.07.19 10:52:00 - [33]

 

Originally by: Miss Overlord

---

things are fine as they are. Everyone can use the login loggoff tactic easily enough so it doesnt favour anyone.

---

Tactics like this are a huge liability for RP factions, and any that use this tactic are seriously abusing the game mechanics in a way that is not in any way explained by any of the cannon fiction or science presented thus far for the EVE universe. While I understand that assigning an action timer that prevents people from doing anything, something must be done to prevent further abuse of this tactic, as it is becoming more widespread and is extreamly unbalancing to RP groups trying to conduct any operation. In fact, log on traps are expressly forbidden in KD's ROE.
My suggestion to deal with this problem is unfortunatly not much better than the action timer, but to not allow for X amount of time, the player to use any targetable modules, target, or be targeted outright. They still can however warp, accept gang invites, etc. This would not seriously affect people who lose connection as a 15-20 sec timer would expire before you could get back to a deadspace mission zone anyways. You would be visable, you can warp, but you cannot interact with the environment. A location randomizer (not huge, just +300km so as to be out of visual range) might be a little over the top. If the first part of this solution prove to be inadequate, then it could be implimented at a later date.
Hoshi also brought up a good point that warp bubbles and dictors do not prevent log off warp out. If this is true, it should be fixed. If I was trying to run a blockade and EVE crashed when I was still cloaked at the gate, I would feel it was a fair catch, as I dont think you can cloak in a warp bubble (counts as an object?) so I would have been killed anyways..

Posted - 2006.07.19 16:11:00 - [35]

 

I've said before that I think when you login, in space, you should be cloaked and sit for 60 seconds at the warp away spot, then you would be warped back to your spot. That gives slow users time to load fully before being shot again, and it prevents login traps since you get ample time to realize someone's using an extremely ******ed tactic.

Posted - 2006.07.19 23:18:00 - [37]

 

Login traps are bad,mkay?

Posted - 2006.07.20 12:26:00 - [39]

 

So how to make emergency warping fit the game mechanics, prevent login traps, and fix a couple of loopholes without punishing people who are genuinely disconnected?

I see the mechanic of logging out being explained by a loss of control of a vessel by a capsuleer. Basic routines in the shipboard systems detect the lack of control and take over to preserve the vessel and the capsule.

With that in mind, here are some suggestions which really need to be considered as a whole to approach the issue of login traps.

1. Make emergency warp out use 100% cap, and maybe even have a chance of offlining a module or draining shields. It's an emergency; it should carry some element of risk.

2. When logging back in, a player who has emergency warped should remain in the spot that they warped to, and not get a free ride back to their last location. They will then be in a remote spot, with 0% cap, and possibly a module offline or their shields depleted. (It might be necessary for cap injectors to be put offline to balance this. It can be explained as the load on the capacitor of emergency warping requiring the cap injector to be disconnected.)

3. Introduce ship anchoring (requires Anchoring I). This allows someone to choose to not have their ship emergency warp on logout, but instead to have it remain in space as per any abandoned ship. Ideal for players who choose to log out at a POS or a safespot with the risk of being discovered but without the risks inherent in an emergency warp.

4. Prevent ships caught in Warp Disruptor Fields or Interdiction Spheres from emergency warping. Emergencies should not allow physical laws of the universe to be overcome.

Posted - 2006.07.21 02:50:00 - [41]

 

Originally by: Belien Jenton

---

In my humble opinion this issue could be solved rather easyly with a technical solution. Simply flag clients as logged out when they shut down EVE themselves (incl ALT-F4 etc). Last packet sent to the EVE servers would be this flag - which of course wouldn't be sent if a client crashes or gets disconected under abnormal circumstances.

Now when people relog with a flagged successfull logout you could impose any of the above restrictions, which are all more or less good in my opinion. But those would not apply to players who got disconnected.

---

I can force disconnect way quicker than this one. Just pull off the LAN cable, co clicking, no marking etc - looks like normal crash :)

Posted - 2006.07.23 11:48:00 - [43]

 

A solution, originally by: c0rn1:

"let people who weren't online for the past 15 mins have a login cooldown in space of 10 minutes where they aren't able to activate any module on their ship. 15 minutes because if you crashed in a fight you can login regularly and participate in the fight again. but if you were logged off longer than 15 minutes in space, it can be considered as a NON-incombat crash."

I think it addresses the issues raised in this thread by making ship reaction dependent on purpose of loggoff.

Posted - 2006.07.27 00:36:00 - [45]

 

Just FYI: Not sure if any of you have used the new client on sisi, but it queues logins. I don't have any information as to whether this is a testing device or if this will be included in the final version but there it is.

Posted - 2006.08.04 21:09:00 - [47]

 

Im not letting this die. I would like an answer.