EVE Search - Don't make me visible until after I've loaded grid

All Channels

Assembly Hall

Don't make me visible until after I've loaded grid

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

Monitor this thread via RSS [?]

Pages: [1] 2 :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
BurntCornMuffin GoonFleet GoonSwarm	Posted - 2010.01.16 06:58:00 - [1] It would appear that with the Dominion patch, more than ever are we experiencing large fleet fights of 1000+ pilots. While both player and developer alike are enchanted by the thought of large internet spaceships reducing each other to slag en masse, these fights are also come with a deeper, more personal, and much less glamorous struggle that has ended more ships than anything during these large, server-breaking fights: The struggle to get the damn grid to load while your ship sits helpless and targetable. As it stands, a player who has jumped or jump bridged into a loaded system and especially into a grid during which a battle is taking place, system and grid both take a very long time to load (usually never loading). In the meanwhile, the ship that player is flying appears on grid, but since the player cannot see or do anything (as he hasn't loaded grid yet) the ship is left vulnerable and can be shot down without incident by anyone who is already on grid. Since a defending force is usually already sitting on grid waiting for the attacker, this puts them at a very solid advantage as they have already loaded grid and can shoot down the ships of an attacker before the offending pilots even load grid. While this is a solid slap in the face to CCP's usual "lag affects both sides equally" statement, and also brings into question a number of networking issues that ought to be resolved, this isn't the point of this post as CCP is already trying to resolve it's network issues, such that those efforts are. Instead the goal is to address this specific problem, being that a ship belonging to a pilot appears on grid and is vulnerable before the pilot himself loads grid and can actually do anything, leaving it defenseless when it should be otherwise participating in battle and defending itself. To correct this, I would propose not displaying the ship or it's warpin/jumpin animation until after grid has been loaded. While this doesn't solve any netcode issues and people may still get stuck loading grid, at least they won't have to worry about their ship blowing up while they're stuck. Once that persons grid has loaded, then the server can display their ship and they can participate happily in the fight.
Aineko Macx	Posted - 2010.01.16 07:26:00 - [2] Yes, altho this should only be a temporary solution till the grid load issue is fixed.
Hirana Yoshida Behavioral Affront	Posted - 2010.01.16 07:49:00 - [3] If it is even possible to code, then that would be the most elegant solution of all. Perhaps make ships visible/probable but invulnerable. An indefinite gate-cloak seems a little "meh" and would benefit an attacker/jumper far more,
EdwardNardella Capital Construction Research	Posted - 2010.01.16 17:22:00 - [4] Edited by: EdwardNardella on 16/01/2010 17:23:13 Supporting a fix to an issue I hae not personally experienced but has still gotten significant negative coverage outside of the EVE community. [Edit] Supporting something i support. CCRES is recruiting pilots who want to live in WSpace/Wormholes. Fill out an application here!
Drake Draconis Shadow Cadre Looney Toons.	Posted - 2010.01.16 17:27:00 - [5] This... is something that's troubled me for some time now...never experienced it but I would rather not experience it. You'd think there would be some sort of communication between the server and the client to be able to indicate you've loaded onto the grid. But potentially there could be an exploit here as well. Supporting with caution. ========================= CEO of Shadow Cadre http://www.shadowcadre.com =========================
No Mauk'Ob Minmatar Murientor Tribe	Posted - 2010.01.16 19:22:00 - [6] the issue I see here is that you would have fleets loading grid piecemeal and becoming visible in small groups. you might take 2 minutes to load grid but your fleet mate may take 1 minute. he's dead long before you get the grid loaded and become a viable target. this would effectively act as a nice force multiplier for any fleet that you jumped into. -No ------------------------------------------------ Captain No Mauk'Ob Murientor Tribe Navy 1st MCW MURIE is Recruiting!
Xtover Suicide Kings	Posted - 2010.01.16 19:28:00 - [7] Supporting, although I don't see how this would be possible to code the way the devs have described the engine.
Sokratesz	Posted - 2010.01.16 19:35:00 - [8] An elegant solution but I fear it will be difficult for the server to objectively determine whether or not a client is 'ready' Want to test a supercap on SISI but don't have one?
darius mclever	Posted - 2010.01.16 19:40:00 - [9]
Aineko Macx	Posted - 2010.01.16 20:55:00 - [10] Edited by: Aineko Macx on 16/01/2010 20:55:32 Originally by: Sokratesz An elegant solution but I fear it will be difficult for the server to objectively determine whether or not a client is 'ready' Assuming the grid takes ages to load because of server side delay in computing & sending all the grid info to the client, it's very easy to determine when the grid loaded: After all grid info was sent to the client.
Sokratesz	Posted - 2010.01.16 20:58:00 - [11] Originally by: Aineko Macx Edited by: Aineko Macx on 16/01/2010 20:55:32 Originally by: Sokratesz An elegant solution but I fear it will be difficult for the server to objectively determine whether or not a client is 'ready' Assuming the grid takes ages to load because of server side delay in computing & sending all the grid info to the client, it's very easy to determine when the grid loaded: After all grid info was sent to the client. From what I gathered in the past it is usually the client that is unable to keep up with the server. Loading all the decals and models for example, and working out all the GFX effects. That also explains certain weird behavioural thingies experienced under heavy lag, such as drones doing full damage over time for the server even though they show as doing nothing for the client. Either way, if they can make it work in a fair way, it would be awesome hence why I support it :) Want to test a supercap on SISI but don't have one?
Aineko Macx	Posted - 2010.01.16 21:13:00 - [12] Originally by: Sokratesz From what I gathered in the past it is usually the client that is unable to keep up with the server. Loading all the decals and models for example, and working out all the GFX effects. This would mean that turning all effects off and setting graphics to minimum would reduce the chance of getting grid load lag or reduce the time it takes to load the grid. This hasn't been confirmed yet. What has indeed occurred is that client side performance (as in fps) dropped. If that is or isn't related to grid load also hasn't been confirmed. Interesting enough, the grid load bug only seems to appear after jumping or portaling, never when warping to a blob. You can speculate if this is a new form of desync. Just to exemplify: It takes some time to compute the subset data (the grid) and send it to the client. If this takes too long, the simulation advances in the meantime, hence new updates have to be computed and sent. This is possible as the server code seems to not process each request with a strict first come first server priority order (ever noticed that under extreme lag movement commands are responded to more quickly than say, ammo change?). If the client waits until it is in sync with the current simulation tick, it makes complete sense that it fails ever to become "ready" if the server is under high load and takes too long for each update.
Sokratesz	Posted - 2010.01.17 01:28:00 - [13] Originally by: Aineko Macx Originally by: Sokratesz From what I gathered in the past it is usually the client that is unable to keep up with the server. Loading all the decals and models for example, and working out all the GFX effects. This would mean that turning all effects off and setting graphics to minimum would reduce the chance of getting grid load lag or reduce the time it takes to load the grid. This hasn't been confirmed yet. Having a faster pc and reducing GFX settings has been confirmed to work in the past. Want to test a supercap on SISI but don't have one?
Praesus Lecti Senex Legio Get Off My Lawn	Posted - 2010.01.17 03:38:00 - [14] Edited by: Praesus Lecti on 17/01/2010 03:38:39 Originally by: Sokratesz Having a faster pc and reducing GFX settings has been confirmed to work in the past. That's having minimal effect, if any at all with Dominion. 3.8ghz Intel Core I-7, 12gb RAM, 2x 1GB ATI 4870's in x-fire. Effects off, turrets off, no brackets and all graphics at lowest setting and loading grid is no faster nor no slower than loading it with effects on, turrets on and graphics at maximum. Brackets, though, makes a difference.
maya ibuki2 THORN Syndicate Mostly Harmless	Posted - 2010.01.17 04:45:00 - [15] supported. since communications between client and server is already necessarily bilateral i cant see why some kind of check cant be put in place, it would definitely be worth the (probably) moderate amount of man hours/work of a small group of devs... 0ok!
Greygal Sephray Industries	Posted - 2010.01.17 12:48:00 - [16] This is an elegant - and logical sounding - solution, well presented. Wish I knew if it would be difficult to implement. Supported, as a short-term solution until the underlying issues are resolved. Greygal
Luminus Mallus	Posted - 2010.01.19 07:11:00 - [17] Sound idea. Supported. If you can't see your enemy because of a technical issue related to network and servers, the least you should expect is that you don't get destroyed for it.
sue AGPlant Rionnag Alba Triumvirate.	Posted - 2010.01.19 11:43:00 - [18] OMG I'm agreeing with a goon it isn't much fun being on a turkey shoot and its less fun being the turkey CCP: destroying the game we love 1 nerf at a time.
Scoop EMP	Posted - 2010.01.19 16:06:00 - [19]
ShadowandLight Amarr Hammer Of Light Aegis Militia	Posted - 2010.01.19 16:18:00 - [20] +1
Pesets The Hunt Club	Posted - 2010.01.19 17:21:00 - [21] Edited by: Pesets on 19/01/2010 17:21:39 Could be a potential exploit but, hell, couldn't be much worse than what is there now. Maybe make the player visible but not targetable until he has loaded grid.
Nekopyat	Posted - 2010.01.19 20:49:00 - [22] The only way I could picture this being implemented would be a client side "I am ready" signal, which I give people about a week to figure out how to block/delay. In theory I would love this since personally I have lost ships (and pods) before I even loaded leaving form station... but the alternative seems even worse.
Spazz21 Rage For Order Systematic-Chaos	Posted - 2010.01.19 21:33:00 - [23] Edited by: Spazz21 on 19/01/2010 21:34:17 Good Idea, grids need to expand as well. Multiple times people will be at the end of a grid, than while aligning people start to go off grid.
Pedro Sangre Ars ex Discordia GoonSwarm	Posted - 2010.01.20 16:04:00 - [24] Originally by: Spazz21 Edited by: Spazz21 on 19/01/2010 21:34:17 Good Idea, grids need to expand as well. Multiple times people will be at the end of a grid, than while aligning people start to go off grid. If you're referring to what I think you are, thank your allies (-A-), they love to shrink grids. Normal grids aren't that bad.
Bagehi Association of Commonwealth Enterprises Gentlemen's Club	Posted - 2010.01.20 17:03:00 - [25] Edited by: Bagehi on 20/01/2010 17:07:22 Originally by: Sokratesz An elegant solution but I fear it will be difficult for the server to objectively determine whether or not a client is 'ready' The same way a server knows it needs to resend a packet when the packet is "lost" - the clients send countless confirmations back to the server already for everything the server sends them. Elegant solutions: 1. Don't spawn the ship into the new grid until the client confirms it has loaded. 2. Use the "jump cloak" feature when entering a grid that is heavily loaded (have the timer equal to expected load time). I'm fairly confident that part of the issue comes from the logs in the new fleet thing. Perhaps it would be wise to not send notifications for client logs until the client has loaded the grid? I've been watching this in fleets recently. That lovely rubberbanding effect seems to happen about the same time as everyone and their sister is broadcasting (warp/align to and need reps often start flooding all at the same time as everyone is trying to load the grid). Impatient people that we are, when people in fleet don't see everyone warp right away some have been known to spam the "warp to" button. Similarly, when people are dying and not being instantly repped, they have been known to spam the "need reps" button. Perhaps putting a short timer on those buttons would help (for everyone else's sanity at least)? I think the loot logger also has/had an issue where it was logging some kind of combat event as well... for everyone in the fleet - not sure if that was fixed? I don't remember what it was exactly. Drones being returned? Ammo switched? Something like that. Originally by: Pedro Sangre Originally by: Spazz21 Edited by: Spazz21 on 19/01/2010 21:34:17 Good Idea, grids need to expand as well. Multiple times people will be at the end of a grid, than while aligning people start to go off grid. If you're referring to what I think you are, thank your allies (-A-), they love to shrink grids. Normal grids aren't that bad. I know a goon didn't just complain about another alliance playing grid mechanics games. I vividly remember being in a fleet where the goon FC told everyone to jet single units of ammo as much as possible just before an enemy fleet jumped in to attack a station. None of the alliances really should point fingers when it comes to grid games. Fix Local
Xtover Suicide Kings	Posted - 2010.01.20 17:46:00 - [26] Originally by: Pedro Sangre If you're referring to what I think you are, thank your allies (-A-), they love to shrink grids. Normal grids aren't that bad. the magic "grid fu" document was written by goons, for goons.
Marcus Gideon Federal Defense Operations	Posted - 2010.01.22 16:49:00 - [27] Just my 2 cents... I'd kinda like to see an entire rework of the visual stuff. Basically, people complain now and then about warping through planets, stations, etc. And then this talk of warping/jumping into a grid, and dying before you even saw what was there. So I'd like to see travel more akin to Star Trek or Babylon 5. Either your ship aligns to warp, and then disappears or enters a conduit. Then you travel through whatever'ness until you arrive. But before then, the "camera drones" we see the world through, warp ahead faster. They arrive on scene, and start loading the grid. When everything is loaded, then we arrive... either out of the conduit or just flying up like we do now. How do we know when it's loaded, you ask? I'd say we use the same gate cloak timer stuff. If you warp to a location, and do nothing, then you will "arrive" in 30 seconds. If you are loaded, and attempt any action, then you will "arrive" at that point. Now I realize this could easily lead to a lot more ambushes. Having an entire fleet suddenly spawn and open fire would be... unpleasant. But the usual rules for targeting time would still apply. So incoming ships would not have an advantage of already locking before they've "arrived". While ships in site will now be able to target a ship as soon as it "arrives", rather than waiting for the warp invulnerability to wear off. I'm sure there's kinks to iron out, but that's the gist of it.
Kiri Serrensun	Posted - 2010.01.22 17:32:00 - [28] Originally by: No Mauk'Ob the issue I see here is that you would have fleets loading grid piecemeal and becoming visible in small groups. you might take 2 minutes to load grid but your fleet mate may take 1 minute. he's dead long before you get the grid loaded and become a viable target. this would effectively act as a nice force multiplier for any fleet that you jumped into. -No As opposed to half the fleet appearing to the enemy, but being unable to do anything? Seems like very little difference to me.
Lord FunkyMunky	Posted - 2010.01.22 18:16:00 - [29] Optimally fix the grid load problem, and grid crashing, but at minimum give the attacker a chance to act, so yes i agree with proposal
Z'Zhairi	Posted - 2010.01.22 19:37:00 - [30] I dont like this idea, yet. To explain, there are times that the grid does load, and pilots can see that there is a gate camp. So they use a second login, to boot their still cloaked ship off the grid, while still cloaked. Then, their ship warps off. While it is still logging in on the new login, they do it again. This resets the point where they will reshow up on the grid, ussually 10,000's if not 100,000's of KM from where they exploited this. Until the developers fix this exploit, I would say no to this. As, if you jump, and then on your voice coms, such as outside services such as mumble, vent or Teamspeak, get the "holy crap" signal, pilots could then use the exploit mentioned above. We recommend that any time a pilot is logging out, that you continually return to that same point on the origional grid. And that that point not be changed for 180 seconds from inital logout, or until your ship is actually back on the on a grid where they first initially logged out.

Pages: [1] 2 :: 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.