EVE Search - A real solution for CCP concerning (fleet) login-traps

All Channels

Player Features and Ideas Discussion

A real solution for CCP concerning (fleet) login-traps

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: [1] 2 3 :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Extreme	Posted - 2006.06.30 14:01:00 - [1] CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job . .
Extreme	Posted - 2006.06.30 14:01:00 - [2] CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job . .
Paddy Murphy	Posted - 2006.06.30 14:21:00 - [3] not that CCP will actually give a flying ** (why should today be different?) but.. /signed * Originally by: Paddy Murphy Edited, snide remarks about mods can be made here [email protected] -Dyvim
Maruk Ihnati	Posted - 2006.06.30 15:31:00 - [4] /signed
Zarch AlDain	Posted - 2006.06.30 15:55:00 - [5] It wouldn't need to be restricted to 0.0 systems - although I can see it being awkward in places like Jita if it wasn't. It should not apply to people docked in stations. Zarch AlDain The Blackwater Brigade Huzzah Federation
JAG Wolfe	Posted - 2006.06.30 17:09:00 - [6] SIGNED! You need to fix this cr*p CCP.. -------------------------------------------------------------------------------- [VAF]<ASCN>
Shi Mun	Posted - 2006.06.30 17:50:00 - [7] Nice Idea, me likey
Maya Rkell	Posted - 2006.06.30 19:07:00 - [8] Originally by: Extreme CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job Great, so now when the server crashes in fleet you're put into a nice firing line ready for execution when you log back on! Whoo!
Legende	Posted - 2006.06.30 19:07:00 - [9] Lots of ASCN/AXE representation here, I can't imagine why . I'll /sign for this too, login trapping should be considered an exploit since you are bypassing in-game mechanics and tactics such as scouting ahead for a fleet.
Tessa Yor	Posted - 2006.06.30 19:13:00 - [10] Signed. Even allowing to log in 1 person every 1 second would solve the problem for large fleet log on traps, not to mention reduce lag.
Extreme	Posted - 2006.06.30 19:18:00 - [11] Originally by: Maya Rkell Originally by: Extreme CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job Great, so now when the server crashes in fleet you're put into a nice firing line ready for execution when you log back on! Whoo! You imply too much coincidental influences. And in the situation that fleets are in 1 system and the server crashes then CCP can program the server that way that clients that enter the game from a queue will appear at random spots in the system. * FIXED * . .
Vardemis	Posted - 2006.06.30 19:37:00 - [12] Good idea Extreme, if you combine it with an activation delay on all modules for 5 minutes. That would render login traps completely useless.
Vera Nosfyu	Posted - 2006.06.30 19:56:00 - [13] Originally by: Vardemis Good idea Extreme, if you combine it with an activation delay on all modules for 5 minutes. That would render login traps completely useless. An activation delay would also ensure the death of anyone who has a disconnect or CTD during combat. ----------------------------------------------------------- "Violence solves all problems, no man, no problem." --Josef Stalin
DarkVipper	Posted - 2006.06.30 20:02:00 - [14] /signed
Maya Rkell	Posted - 2006.06.30 20:08:00 - [15] Originally by: Extreme Originally by: Maya Rkell Originally by: Extreme CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job Great, so now when the server crashes in fleet you're put into a nice firing line ready for execution when you log back on! Whoo! You imply too much coincidental influences. And in the situation that fleets are in 1 system and the server crashes then CCP can program the server that way that clients that enter the game from a queue will appear at random spots in the system. * FIXED * If you can't see the abuse potential for that... And no, it's a pretty regular occurance on overstressed nodes. Vardemis, and absolutely ensure that relogging from a dropped client would be suicide. You're then off until such time as you either win control of the system with people who were not dropped or decide your time's being wasted and sacrifice the ship and pod.
El'Tar	Posted - 2006.06.30 20:16:00 - [16] well it can only get better from here... so... sure /signed Proud citizen of ASCN
Tadamitsu	Posted - 2006.06.30 20:17:00 - [17] Originally by: Extreme CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds I see the three fast ways to fix this. delay module activation (I don't like this) Stream the clients online (I like this with reservations) 3rd point logon. When you log back on you come online at a third safe spot. We must take into acount battle fleet crashes where we may be seeing alot of people coming on quickly but they are in a third location /SIgned FIX THIS please. and the POS tracking log bug. and the BM in your cargo bay exploit. co-CEO Solar Storm Want to join the storm?
Vardemis	Posted - 2006.06.30 20:28:00 - [18] Originally by: Maya Rkell Originally by: Extreme Originally by: Maya Rkell Originally by: Extreme CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job Great, so now when the server crashes in fleet you're put into a nice firing line ready for execution when you log back on! Whoo! You imply too much coincidental influences. And in the situation that fleets are in 1 system and the server crashes then CCP can program the server that way that clients that enter the game from a queue will appear at random spots in the system. * FIXED * If you can't see the abuse potential for that... And no, it's a pretty regular occurance on overstressed nodes. Vardemis, and absolutely ensure that relogging from a dropped client would be suicide. You're then off until such time as you either win control of the system with people who were not dropped or decide your time's being wasted and sacrifice the ship and pod. Armor repairer and shield booster are very popular modules for bigger engagements, hugh? In smaller engagements where you will be most likely scrambled, aka you don't warp out, you will be most likely killed before you are back online again anyway. And in case you are not scrambled, well you could warp to a safespot. No need to sacrifice anything.
Maya Rkell	Posted - 2006.06.30 20:45:00 - [19] "Armor repairer and shield booster are very popular modules for bigger engagements, hugh?" Where did thay come from? And you're making assumptions about smaller engagements which..I sdon't think it's a good idea to make. If you have no modules online/avaliable, I will scamble and kill you even if you're in a BS with an Inty in 5 minutes.
Pilk	Posted - 2006.06.30 21:14:00 - [20] 15s seems a bit harsh, especially in the case of a net.split or laggy jump where a dozen or more people in my fleet lose connection, but ignoring the number for a moment: /signed And, absolutely, let's not turn this into a debate about other things that could be done that might or might not be better--the question before this forum is, is this idea a good one? (Read: Vard, for the good of the thread, take it to another thread, please.) --P
Stockarian	Posted - 2006.06.30 21:51:00 - [21] Logon traps are completely Suxor and the lamest of the lame. /SIGNED. Athelas Loraiel > "This isn't a fleet, we are only the appetizer." Cheers, Stock
Jhar'An	Posted - 2006.06.30 21:57:00 - [22] If Module Activation is a possible fix to be considered, make it so only aggressive modules are delayed. Can still activate reppers, Afterburners, hardeners etc. /signed
Volatar	Posted - 2006.06.30 22:06:00 - [23] i sign on the 1second que Crrently training: Nerd Lvl
Ben Derindar	Posted - 2006.07.01 00:31:00 - [24] Hehe Extreme, stealing my idea. Not that I don't mind, it's certainly something that needs urgently addressing. Originally by: Maya Rkell Great, so now when the server crashes in fleet you're put into a nice firing line ready for execution when you log back on! Whoo! Consider it an added disincentive to blob up to begin with, then. /Ben
ArcticFox	Posted - 2006.07.01 00:35:00 - [25] Edited by: ArcticFox on 01/07/2006 00:35:42 Originally by: Maya Rkell Originally by: Extreme Originally by: Maya Rkell Originally by: Extreme CCP you can fix this fleet-mass-login-'feature'/exploit very simple. SOLUTION When more than an X-amount of clients logon at the same time (say more than 5 clients) in a (0.0) system then the server will put these clients into a queue. Say 1 client per 15 seconds This should do the job Great, so now when the server crashes in fleet you're put into a nice firing line ready for execution when you log back on! Whoo! You imply too much coincidental influences. And in the situation that fleets are in 1 system and the server crashes then CCP can program the server that way that clients that enter the game from a queue will appear at random spots in the system. * FIXED * If you can't see the abuse potential for that... And no, it's a pretty regular occurance on overstressed nodes. Vardemis, and absolutely ensure that relogging from a dropped client would be suicide. You're then off until such time as you either win control of the system with people who were not dropped or decide your time's being wasted and sacrifice the ship and pod. Maya, is there any change to Eve that you would not consider a negative one? On a more serious note, the timer between allowed logins is certainly not a perfect system. Certainly if youre entire fleet crashed at once and none of the enemy fleet did it would be bad, but bear in mind you're debating this in a thread created by someone who was in EC-p8R when there were 600 pilots in local, a member of an alliance that is absolutely no stranger to overpacked systems and lag situations. There certainly are still problems with a timer system, but I consider those problems quite a bit less than the ways in which the current system can be exploited, where a hundred or more pilots may log on simultaneously all at one exact spot, creating what can only be described as a massive lag-bomb. You honestly intend to say that this is more acceptable than what might happen in the remote possibility than a fleet suffers a massive, one-sided crash in an overpacked system? -------------------------- What to do about High Sec Suicide piracy...
Cyril	Posted - 2006.07.01 00:52:00 - [26] /signed
Maya Rkell	Posted - 2006.07.01 01:06:00 - [27] Edited by: Maya Rkell on 01/07/2006 01:06:18 Ben Derindar, game mechanics dictate that if he blobs, I can either blob back or not fight and he pushes me back and kills my POS by default. Well, I got annoyed and gave that all up for small group combat, but eh. ArcticFox? I agree with loads of stuff. People just remember where I vehemently disagree. The usual stuff in here is the same old and it's been shot down 100 times. You run out of origional ways to improve it the 25th or so time people ignore them. You've identified the key factor, though, per grid. Rate limit THAT, but incidently I'd NOT limit logins in a station. If someone gets ganked outside a station, that's HIS fault. Then add say a 60 second lockout on highslots from login. And I wouldn't limit it to 0.0 either.
Ben Derindar	Posted - 2006.07.01 01:17:00 - [28] Originally by: Maya Rkell Ben Derindar, game mechanics dictate that if he blobs, I can either blob back or not fight and he pushes me back and kills my POS by default. Correct. But in a situation where simultaneous logon numbers would be restricted at the system level, the enemy's blob would be just as susceptible to server failure as yours. /Ben
laotse	Posted - 2006.07.01 01:46:00 - [29] signed 80.126.192.128:8888/tfd/uploads/1121735338/gallery_11_8_1124480365.jpg[/img] Please resize image to a maximum of 400 x 120, not exceeding 24000 kbs, ty - Cortes
PaND3M0NiUM	Posted - 2006.07.01 02:23:00 - [30] Signed. Period. Never eat yellow snow...

Pages: [1] 2 3 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.