open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Letter from the CSM
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: first : previous : ... 3 4 5 6 7 8 9 10 [11]

Author Topic

Phsyco Bob
Caldari
Moon Humpers
Growth Disorders
Posted - 2011.04.15 00:06:00 - [301]
 

First one to make a post time dialation pvp vid. to the time warp gets a prize.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.15 00:16:00 - [302]
 

i really wanted to ask something specifically to CCP Veritas tbh.. and it was something i had proposed in the original AH Forum, as i know he hates clients that unnecessarily rack up his servers with a ton of requests.

ripped from the original AH post...
Originally by: GeeShizzle MacCloud

if anything Bosse could write an automatic program that can hunt down clients sending massive amounts of requests compared to a normal amount for a particular ship (as SC's will be putting out more requests to the server from fighters etc than an ecm BS for example.)
what bosse wants to do with these people is up to him and CCP, but forcing a client DC with a re-logging cooldown timer i dont think would be that harsh bearing in mind what that person is trying to do.



I'd loooove to know if this is possible... as im sure you can group server requests by ip address and watch over them to look for excessive levels.

DaiTengu
Gallente
GoonWaffe
Goonswarm Federation
Posted - 2011.04.15 03:36:00 - [303]
 

Edited by: DaiTengu on 15/04/2011 03:38:59
Originally by: GeeShizzle MacCloud
i really wanted to ask something specifically to CCP Veritas tbh.. and it was something i had proposed in the original AH Forum, as i know he hates clients that unnecessarily rack up his servers with a ton of requests.

ripped from the original AH post...
Originally by: GeeShizzle MacCloud

if anything Bosse could write an automatic program that can hunt down clients sending massive amounts of requests compared to a normal amount for a particular ship (as SC's will be putting out more requests to the server from fighters etc than an ecm BS for example.)
what bosse wants to do with these people is up to him and CCP, but forcing a client DC with a re-logging cooldown timer i dont think would be that harsh bearing in mind what that person is trying to do.



I'd loooove to know if this is possible... as im sure you can group server requests by ip address and watch over them to look for excessive levels.



Wait, what? you want clients that cause more lag such as carriers and supercarriers to disconnect? how is that even remotely fair?


Edit: oh, I see. a script that would force clients to disconnect if they were doing more things than a ship like that was supposed to.

Thing like that is it's really hard to judge. If a Supercarrier engages drones, primary is suddenly switched, then it engages drones again, except on the original target, then eventually on the new primary, and then fires off an ECM burst, that could be considered "excessive" even though it was just a mistake on the pilot's part.


Sounds like it would be a ton of work for very little gain. Besides, the script would have to run on the server, adding to system load.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.15 12:01:00 - [304]
 

completely understand your criticism on this, and tbh id expect it and encourage it!

when i say excessive i really do mean excessive, for example for a supercarrier pilot swapping their drones targetted aggro between 5 or more targets cyclicly, or recalling and then re-aggroing drones, but doing this constantly and in quick succession, purely to send a ton of requests to the server in order to push the server over.

i guarantee this will become the tactic to push time dialation levels up as much as possible, in order to give caps more life expectancy in fights (barring alpha strikes ofc). and with all nav, combat and module speeds reduced it'll become exceedingly obvious who's trying to legitimately play the game and who's forcibly trying to push the server over.

yes it would chew up cpu time, but in that sense time dialation can be used to add some headroom for this to work.
you can test this with thin clients to quickly work out what would be acceptable, what level may constitute a warning and what level and for what duration a forcable DC and cooldown should occur.

im not trying to annoy and screw up epic battles, i really feel a proactive measure to curb metagaming that circumvents game-mechanics should be considered. and this way its not a nerf all button but targetted to the ones that cause the most issues.

Lord Zim
Goonswarm Federation
Posted - 2011.04.15 12:53:00 - [305]
 

Originally by: GeeShizzle MacCloud
when i say excessive i really do mean excessive, for example for a supercarrier pilot swapping their drones targetted aggro between 5 or more targets cyclicly, or recalling and then re-aggroing drones, but doing this constantly and in quick succession, purely to send a ton of requests to the server in order to push the server over.

Honestly I wouldn't expect the act of sending orders to his fighter bombers would be what's causing the servers to run out of CPU capacity, but the act that they're actually in use, firing missiles or whatever it is they do today.

I'm hesitant to consider any mechanic that actively disconnects anyone in what could be a very critical point of a fight.

CCP Veritas

Posted - 2011.04.15 15:26:00 - [306]
 

Originally by: GeeShizzle MacCloud
I'd loooove to know if this is possible... as im sure you can group server requests by ip address and watch over them to look for excessive levels.


If it becomes a problem, yo, I'll solve it.

mkint
Posted - 2011.04.15 17:41:00 - [307]
 

Originally by: Lord Zim
Originally by: GeeShizzle MacCloud
when i say excessive i really do mean excessive, for example for a supercarrier pilot swapping their drones targetted aggro between 5 or more targets cyclicly, or recalling and then re-aggroing drones, but doing this constantly and in quick succession, purely to send a ton of requests to the server in order to push the server over.

Honestly I wouldn't expect the act of sending orders to his fighter bombers would be what's causing the servers to run out of CPU capacity, but the act that they're actually in use, firing missiles or whatever it is they do today.

I'm hesitant to consider any mechanic that actively disconnects anyone in what could be a very critical point of a fight.

I actually like the idea. It assumes you have a small number of people actively trying to ruin the gameplay of thousands of people in a fight by manipulating the servers through non-gameplay in order to increase their own survivability. To punish/prevent what could be considered an exploit, forcing a dc and thus reducing their survivability to practically nil seems a compelling reason to not attempt to cheat. Even more compelling if they are trying to cheat at a critical point in a fight.

SSN 609
Amarr
The Graduates
Morsus Mihi
Posted - 2011.04.15 19:31:00 - [308]
 

I actually don't mind TD, and I understand why people are thinking its just gonna get worse and worse by the amount of people that can potentially get to a system that is DT (so scales up and up because of RF fleets).

Perhaps TD should scale down surrounding systems as well depending on the amount of people in the target system.

Think of it like an earthquake... the epicenter is gonna be horrible, but it ripples out from source.

The only problem would by people jumping to system in capitals and using bridges to avoid this ripple effect, however, you could adjust the "wait to jump" time. Basically having a simple pop up that you already have when waiting to jump to next system, but have it optional. Saying something like, "Time to jump to system is 3 min would you like to proceed?"

mkint
Posted - 2011.04.15 20:05:00 - [309]
 

Edited by: mkint on 15/04/2011 20:06:16
Originally by: SSN 609
I actually don't mind TD, and I understand why people are thinking its just gonna get worse and worse by the amount of people that can potentially get to a system that is DT (so scales up and up because of RF fleets).

Perhaps TD should scale down surrounding systems as well depending on the amount of people in the target system.

Think of it like an earthquake... the epicenter is gonna be horrible, but it ripples out from source.

The only problem would by people jumping to system in capitals and using bridges to avoid this ripple effect, however, you could adjust the "wait to jump" time. Basically having a simple pop up that you already have when waiting to jump to next system, but have it optional. Saying something like, "Time to jump to system is 3 min would you like to proceed?"

I don't think the ripple effect is needed. An attempt to jump into a dilated system should bring up the "jumping" notice on the bottom of the screen with a countdown timer, and any new commands issued should interrupt the timer. Thus the players are required to decide to dilate their time voluntarily before even entering the system regardless the method they use to enter.

The real issue is if a cyno timer runs on dilated time (making it last longer and thus easier to kill) or on real time (giving normal window to position capitals to jump.) I'd say a compromise of the beacon itself running real time, but the module (with the penalties) running on dilated time.

Issues with sov and POS timers are probably trickier to deal with because they affect longer term strategy more than short term tactics.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.15 21:32:00 - [310]
 

The way i see it working is everything that should be affected by time dialation to work of an augmented time calculation '(t/n)' where 'n' is a number between 0 and 1. 1 being normal non - TD time and 0 being a theoretical infinite (that u really do not want to reach!). The 'n' would correspond to a value that the server determins in respect to how well its responding to server requests, if theres a queue the number comes off 1 and moves towards 0, creating the time dialation.

This calculation would be the replacement for the normal 't' index representing the time variable in calculations for whatever eve related calculations u want augmented by TD.

You would then be free to use it on speed calcs, module cycle time calcs and the like. Keeping the original for POS timers, skill training etc... that would run at the standard eve speed.


I would have to say im not in any way an expert on this, but thats how i have it figured in my head.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.15 22:14:00 - [311]
 

Edited by: GeeShizzle MacCloud on 15/04/2011 22:15:23
Originally by: SSN 609

Perhaps TD should scale down surrounding systems as well depending on the amount of people in the target system.

Think of it like an earthquake... the epicenter is gonna be horrible, but it ripples out from source.

The only problem would by people jumping to system in capitals and using bridges to avoid this ripple effect, however, you could adjust the "wait to jump" time. Basically having a simple pop up that you already have when waiting to jump to next system, but have it optional. Saying something like, "Time to jump to system is 3 min would you like to proceed?"


im all for the ripple effect! though i do believe that if TD gets to a point it should auto-cynojam a system and possibly cut off gate jumping into it due to the massive sudden change in time dialation.

could say something like...

Quote:
"Due to highly energetic and gravametric fluctuations, your jump drive targeting systems cannot acquire a lock to the target cynosaural field in XXXX-X system"


and

Quote:
Emergency Jump Gate Lockdown Protocol - unable to jump into XXXX-X. Sudden changes in the gravametric conditions would Rip your hull apart. Jump sequence Aborted.

Anela Cistine
Amarr
GoonWaffe
Goonswarm Federation
Posted - 2011.04.16 09:43:00 - [312]
 

Edited by: Anela Cistine on 16/04/2011 09:47:49
Edited by: Anela Cistine on 16/04/2011 09:44:45
Originally by: Gnulpie
I don't think people are frustrated because lag causes unfair conditions (lag doesn't, every random result evens out after a while, you win some, you lose some, nothing unfair about this)


Actually, there is something unfair about it.

The CVA roleplayer's paradise, NRDS rule of Providence was great, it added a lot of flavour to Eve. It was a place where the little guy could dip his toes in 0.0 without having absolutely everyone shooting at him. PVPers loved it, because it acted as a sort of "hunting preserve," a place where a small gang could go and always find a fight, and keep fighting until they eventually get killed, just for kicks. Being such a great place it got crowded, and eventually they tried to expand into Catch. This didn't go so well, but at first it looked like AAA only intended to deliver a spanking, not utterly destroy the Proviblob, because AAA enjoyed having a hunting preserve right next door.

Then the proviblob capfleet blackscreened. Blind, deaf and paralyzed they were unable to fight, unable to defend themselves, unable to even log out. This by itself would be terribly unfun, but being stuck in that state while your fleet is systematically slaughtered is terribly demoralizing. Doubly so when the news came out that people at CCP had been taking heroic measures to keep the server up, which naturally lead to speculation that a crash might have saved hundreds of blind ships and permitted a real battle to take place. Providence was never the richest region in the game, so many of those capital ships were not able to be replaced instantly as they would be for a richer alliance. Their capfleet was simply gone. Perhaps more important was the morale blow. Why bother trying to fight when a Russian blob arriving first means that you won't even get to load the system? For all those little guys getting their first taste of 0.0, the only sane thing to do was save what portable wealth they could and get out. I've never been affiliated with CVA, in fact I've never been to Providence at all, but I was sad to see it die that way. Sad Yes, recently CVA has recaptured part of Providence, but it isn't quite what it was. What happened there was in no way fair.

By now most big alliances have been on both sides of a blackscreen at least once, and the thing is it isn't fun no matter which side you are on. Blackscreening is terrible. Being on the "lucky" side means mindlessly shooting at dead ships that react less than a POS, and warping around the system chasing sensor ghosts that may or may not be shootable ships, all the time wondering if your guns would actually fire when you find a valid target. But you do it, because that's what you are supposed to do if you get lucky. It isn't just boring because it is slow, it is objectively terrible in every way. It is not PVP.

Of course things have gotten better than they were when Dominion first came out, mad props to the guys working on that. Eliminating situations where hundreds of players are left unable to play, and unable to log out, has to be a priority. If time dilation can help, I'm all for it.

Salpun
Gallente
Paramount Commerce
Posted - 2011.04.16 18:25:00 - [313]
 

I am showing a pass word needed for the server for the fire side chat. When will it be open.

SecretMoonBase
Posted - 2011.04.16 18:33:00 - [314]
 

Originally by: Consortium Agent
Edited by: Consortium Agent on 14/04/2011 23:01:23

And my, how easy it is to shake up the goons with a few words roflmao. Easy, way too f'ing easy. :P I might actually enjoy watching you tards sign your own death warrant with this whole CSM thing. Doh!


I'm gay

Dr BattleSmith
PAX Interstellar Services
Posted - 2011.04.17 23:23:00 - [315]
 

CCP reacts to one thing and one thing only.

Bad publicity.

20 page thread on General Discussion = action.

500 page thread in CSM = lol we managed to hide our unhappy customers


They know that people check game forums before making purchases.

Top page of "General Discussion" is the only place where CCP takes action on problems.


Dr BattleSmith
PAX Interstellar Services
Posted - 2011.04.17 23:27:00 - [316]
 

Originally by: Consortium Agent
Hmmm... since the CSM believes it is like a governing body, ought we not have an impeachment process in case something like, I dunno, the goons taking over CSM happens and we need to take action against their single minded agenda?

CCP? Comments, please.


For this to be an issue CCP would have to think of CSM as something other than a joke.

Peralandra
Posted - 2011.04.18 06:26:00 - [317]
 

Edited by: Peralandra on 18/04/2011 06:27:33
oops wrong thread

Ortan Murdak
Liberty Storm
Atlas.
Posted - 2011.04.21 10:43:00 - [318]
 

Quote:
Of course things have gotten better than they were when Dominion first came out, mad props to the guys working on that. Eliminating situations where hundreds of players are left unable to play, and unable to log out, has to be a priority. If time dilation can help, I'm all for it.


I would whole heartedly agree with you except for one issue that I see with TD. As a fix for lag,it will work great, but only temporarily. Up until now, the war on lag has been about making the code more efficient and less conducive to lag, but TD will simply hide the problem. The initiative we have seen so far to reduce lag will most likely disappear, and (in an extreme case) TD will become the end of the war on lag.

I think we should be careful to avoid becoming too comfortable with TD and focus on the ideal situation in which TD is a fail safe, and not the norm in large fleet fights.

A way to do this may be to monitor the levels of dilation and frequency of use. Say for example that each in game tick becomes two ticks. I think that is reasonable so long as it doesn't happen every time five hundred people get in a fleet fight. Every tick becoming even 1.1 ticks is a significant jump in processing time, so 2 should be unheard of. On the other extreme, making every tick x ticks ALL THE TIME should not be acceptable either, and TD should be the last option that is even considered to keep a node from dropping requests.

I'm gonna shut my mouth now before I ramble for any longer.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.22 16:45:00 - [319]
 

thats totally understandable, although i do feel that if TD is implemented properly team gridlock would have some breathing room to work hard re-coding the server to utilise multicore. once thats achieved there will be a massive reduction in lag as currently everything on the server nodes are run on a single core, albeit hyperthreaded.

utilising multicore on the server will be like playing on 4 servers tied together... and with TD on that too im pretty sure u coould have the most epic of battles with only minimal lag!

Consortium Agent
Posted - 2011.04.29 11:29:00 - [320]
 

Heh... all this talk about how CSM wants to hold CCP responsible for failed features and yet they're all about supporting this band-aid for lag. Isn't that counter-productive? Just sayin'.

Falin Whalen
Gallente
GoonWaffe
Goonswarm Federation
Posted - 2011.05.02 17:19:00 - [321]
 

Originally by: Consortium Agent
Heh... all this talk about how CSM wants to hold CCP responsible for failed features and yet they're all about supporting this band-aid for lag. Isn't that counter-productive? Just sayin'.


Dude, you have DEVs saying, in this very thread, that it is only a bandaid to give them breathing room to fix the things that were not so easy to fix. At least now you will have the hampsters walking when they get tired, instead of running until they keel over and die.


Pages: first : previous : ... 3 4 5 6 7 8 9 10 [11]

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only