EVE Search - Invulnerability at system entry?

All Channels

Test Server Feedback

Invulnerability at system entry?

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

Monitor this thread via RSS [?]

Pages: [1] :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
illuminati	Posted - 2003.09.08 09:50:00 - [1] Hi, the flamewar is on about this. Camping a system entrypoint with 1 sec target time and several ships or drones is unbalanced. I would like to see invulnerability for enough time for the pilot to respond to threat. I would like to see discussion on how to make "non consentual attacking" possible without needing to use game lag mechanics. Target lock is now very definite, once you have it you own and since it's nearly impossible to get it due to invulnerabilities, maybe it should be softened. Maybe shorten invulnerability to 5 seconds, make a warpscramble take 5 seconds to kick in? That way you can hit people faster and get cat/mouse working, thats more fun imo. We still need more work on how to engage in combat, run from it, ambush and similar.
Ana Khouri	Posted - 2003.09.08 10:46:00 - [2] Problem is that at those points the lag can last far longer than 5.10 secs. free speech not allowed here
Ezra	Posted - 2003.09.08 14:27:00 - [3] The solution would be not to have a ship appear in space until the client has fully loaded. We're seeing now that CCP's fix for canlag was merely a workaround for underlying flaws in game architecture. Unfortunately, it seems like CCP saw fit to fix canlag alone with the jettison timer and leave it at that. :( ------------ Ezra Cornell pe0n, Xanadu Corporation
illuminati	Posted - 2003.09.08 15:09:00 - [4] I agree with you Ezra that the invulnerability is a fast patch for game mechanics. Instead of having invulnerability, let client load environment and when done, eject ship from warptunnel. You could then possibly remove invulnerability alltogether?
Arch Aggelos	Posted - 2003.09.08 16:00:00 - [5] I would love to see invulnerability removed in favor of not loading the ship in space until the Client had caught up. This makes so much more sense than invulnerability. Come on CCP! Lets have it!
Ezra	Posted - 2003.09.08 18:22:00 - [6] Quote: I agree with you Ezra that the invulnerability is a fast patch for game mechanics. Instead of having invulnerability, let client load environment and when done, eject ship from warptunnel. You could then possibly remove invulnerability alltogether? I was referring to the jettison timer as a fastpatch for object lag, but your solution is the same as what I propose. I agree - In such a situation, it would be possible to remove invulnerability altogether. The invuln timer and the jettison timer are both quick hacks. I would not have minded if CCP had put effort into fixing the underlying problem, but it's obvious that they have not, and hence, load-lag has returned in another form. ------------ Ezra Cornell pe0n, Xanadu Corporation
NoS Dingo	Posted - 2003.09.08 21:36:00 - [7] They could also just simply randomise the entry point there by making camping it near impossible since they don't know where people will land. Camping entry points is BS, since it is a 99% certainty that the incoming ship will be dead before even realising due to load lag. A REAL challenge.
Mark A	Posted - 2003.09.08 22:51:00 - [8] Agreed. [BTW it's not invulnerability, it's lock immunity which means you can do other things like spam them with smartbombs, or shoot torps at a secure can left at the jump-in point or station undocking port]. Obviously the best fix is to synchronise the client, without opening up any client-hack cheating possibilities. Doesn't seem like this should be impossible, but we can't count on it being done anytime soon IMHO - if they could think of a fix we wouldn't have the current hacky solutions. I think one thing which would help a lot would be not deactivating modules such as shield hardeners when you jump - this is a big factor in making camping jump-ins effective. Ideally you could do this for station undocking also (ie pre-activate modules) which can suffer similar lag issues and the resulting appear-half-dead situations. The fundamental principles we want to get at here are: 1. People should be in control of their ships when combat actually commences. 2. There should still be a way to lock people down fair-and-square if they choose to come to a place where they know there are enemies waiting, if you have the right modules and they don't have enough counter-measures. ____________________________________
KIPPAN	Posted - 2003.09.08 22:52:00 - [9] Randomizing warp-in points are not necessary if the loadlag is handled properly, it's just another aspirin. Appearing to the "enemy" at the same time you get control over your ship makes it fair play. I must say that I was really disappointed when they "solved" the can lag problem with the timer. Very unprofessional solution. Maybe devs at CCP haven't trained Programming skill to lvl5 yet.
Drutort	Posted - 2003.09.09 05:48:00 - [10] Quote: Agreed. [BTW it's not invulnerability, it's lock immunity which means you can do other things like spam them with smartbombs, or shoot torps at a secure can left at the jump-in point or station undocking port]. Obviously the best fix is to synchronise the client, without opening up any client-hack cheating possibilities. Doesn't seem like this should be impossible, but we can't count on it being done anytime soon IMHO - if they could think of a fix we wouldn't have the current hacky solutions. I think one thing which would help a lot would be not deactivating modules such as shield hardeners when you jump - this is a big factor in making camping jump-ins effective. Ideally you could do this for station undocking also (ie pre-activate modules) which can suffer similar lag issues and the resulting appear-half-dead situations. The fundamental principles we want to get at here are: 1. People should be in control of their ships when combat actually commences. 2. There should still be a way to lock people down fair-and-square if they choose to come to a place where they know there are enemies waiting, if you have the right modules and they don't have enough counter-measures. i was posting in the other sections there how this can be done... because other games have done this... using prediction data and stats you can use some calc's to get an estimated performace rating for a system and same for internet connection... this cna be stored on server and client... they can do compare checks... to make sure none of the data is altered then having to read it directly from the server. you use time stamps on the packets that are sent to server etc... and use prediction code... thus you can create complex yet effective system that would load for each person differently and in the right time so that its all done and the person is ready to combat... to those people going to say it lags... hmm you have no idea how its done... there are many ways this can be done and it can be shared with server and client.. meaning the client can hold the data but the server has copy at some point and it just checks to make sure that things are == thus not having to load the data directly from server... this info can be updated when the person logs or is in station or whatever... you can also code stuff to take X% of working power and spread it over Y time... so that it doesnt lag your computer/game while it does this. other less complex ideas but could be hacked if not done right are to either have imunity or just not to show the ship until it finishes to load... and there should be a max time so that it starts to show the ship but you cant lock on to it... and then another time that it must let people target it... this all has to be ballanced so that there is no hack out there that an exploit these features and give advantage to someone from evaiding combat when they feel they might lose due to some hack/cheat... its quite a bit of work but its dueable support Idea: QuickInfo an alternative to ShowInfo my MoBlog
Drutort	Posted - 2003.09.09 05:49:00 - [11] oh there was another idea its not as good but make both sides load or sync so that way neither side gets an advantage... beats me how it can be done support Idea: QuickInfo an alternative to ShowInfo my MoBlog
Archemedes	Posted - 2003.09.09 13:16:00 - [12] Synching the client and server would be quite simple: 1) Upon gating or warping, the player's ship is removed from the game. 2) The client loads the new area WITHOUT displaying anything on the screen. All ship and camera controls are disabled. 3) Once the loading is complete, the client sends a signal to the server. When the server receives this signal, the player's ship is inserted into the new area and and the client is told to proceed. 4) The new area is displayed on the screen and the ship controls start working. The player is now able to navigate, target, and be targeted. That's all there is to it. Sure you'd want to add some encryption or cheat detection, but there really would be no advantage to hacking the client since the server ignores all commands until the client signals ready, and that signal makes the ship vulnerable. The only real technical challenge is minimizing server load and bandwidth so it doesn't increase lag.
Ezra	Posted - 2003.09.09 13:29:00 - [13] These WOULD allow for the creation of a "radar hack" similar to Excalibur for DAoC, but in a game like EVE a "radar hack" would be far less damaging than in games like DAoC and EQ due to the nature of combat in EVE. All of EVE's lag problems stem from CCP's attempts to make EVE completely immune to radarhacks of any form. An admirable goal, but all of the lag exploits it has caused show such radarhack immunity attempts to be a failed attempt and a bad design decision. The thing is, knowing that enemy corp Foo has n ships on the other side of a jumpgate isn't that much of a tactical advantage when you are already committed to arriving at the destination in question. It's not like DAoC or EQ where packet-sniffed information can influence decisions of where to go - If precaching for system entry and warp endpoints is implemented, it doesn't matter if you know what's there, because by that time you are going there no matter what. ------------ Ezra Cornell pe0n, Xanadu Corporation
Hikaru Okuda	Posted - 2003.09.09 16:45:00 - [14] Edited by: Hikaru Okuda on 09/09/2003 16:47:47 It is admirable that they are trying to prevent the radar hacks. Since the server seems to take the client's request to load an area as the trigger to show the ship to the people in the area while the client commences downloading the area data, how about this idea: What if they created some "invisible" object that is ordered to be the last thing downloaded no matter how many other objects are added to the area. When this final object is downloaded, then the server triggers the display of the ship (people in the area see and can target it) and the client starts rendering the data it just downloaded. It would probably be difficult for them to implement now though depending on how they designed their data structures. But this method wouldn't actually require the client to do anything other than download data like it does now--the server software however would need some changes to do it. Just thinking out loud. But this does remove the need for the client to tell the server "I'm ready" after downloading however much data there is to download because the server would know when "invisible object" is downloaded. Who knows... I do design network software (but not gaming related) so issues I normally have to deal with are quite different. Just throwing the idea out there and someone with online game programming experience can rip it apart as they wish.
fireal	Posted - 2003.09.09 16:50:00 - [15] If they do this the client needs to tell the server when he is finished loading. That means that I can start a hack program that can just tell the server when I am finished loading whenever I want. If they find a sollution they might be the first to do so.
Hikaru Okuda	Posted - 2003.09.09 22:08:00 - [16] Edited by: Hikaru Okuda on 09/09/2003 22:14:46 Actually what I was suggesting would be similar to the way the trigger for showing your ship seems to work now. The client has to download data from the server, correct? The server has to know what object has been requested for downloading in order to send the data to the client. So when object X starts getting downloaded, show the ship. I was suggesting an ordered data structure that makes sure object X in always at the bottom of the list of available objects on the server to download. Once a client tries to access that, then the server would show the ship. Now if it takes your client 5 minutes to load object X, or you crash, well your ship shows up and you die because your client does not tell the server anything (beyond "give me all the objects please"). It just accessed object X. So like this: Player says "Jump to New Caldari" client requests data for the system new caldari and starts downloading. At the jump in point there are 15 battleships and Object X stored in some data structure on the server. Right now I think the server shows your ship as soon as the client says "download stuff in New Caldari". And those 15 battleships can commence blowing you up The current system seems to do this: Load system data <--display your ship download battleship 1 (lag) download battleship 2 (lag) .... My suggestion was to not show you when that happened but do something like this: Load system New Caldari download battleship 1 download battleship 2 ... download object X <-- server now displays your ship Then everything continues If the data was ordered differently it could do this Load system data download battleship 1 download object X <-- server now displays you ship download battleship 2 (oh no! you are lagging out now) ... download battleship 15 That's what I was suggesting. The server has to serve the data, I was just suggesting triggering "show ship" when object X was served out rather then when "load system data" starts. I guess if you figured out what object X was you could see that "someone" had just jumped in, but that info is on the map already. But I don't know their code, so it's probably not even remotely possible. Maybe they pack all the objects into one data stream and just dump it and forget it--the client makes it or not. What do I know, though... I'm not an expert on the game design.
NoS Dingo	Posted - 2003.09.09 23:48:00 - [17] How is random entry point an "aspirin fix"? I am watching Andromeda and notice that when they exit "slipstream" the entry point is random, due to the pilot not being perfect. To me it makes perfect sense to resolve the issue in this way. Simple, realistic and in keeping with space themes. Why does the entry point need to be the same every time anyway?
Archemedes	Posted - 2003.09.10 02:41:00 - [18] Edited by: Archemedes on 10/09/2003 02:41:40 Radar hack? Who cares? We HAVE radar and a scanner, and they can show us what's there as soon as we arrive. As long as no information is sent until you jump or warp, there's no problem since you can't abort even if you see a horde of battleships waiting by hacking the client (a bannable offense, by the way!) Just make sure the ship can't actually DO anything until the server has placed it in the sector and have code to detect if someone blocks the acknowledgement and logs off (go ahead and make the ship appear for the required 1-2 minute if connection is lost)... Any minor exploit resulting will be: 1) Based on hacking the client or intercepting packets, so perma-bannable 2) FAR less disruptive than letting people be podded before they even see their ship!
Roba	Posted - 2003.09.10 03:44:00 - [19] I like the idea of getting rid of the 10 seconds of not doing **. When you are warping into a zone without anyone lagging the ** outa you like a roid belt with 0.0 pirates. It would be nice for me to be able to kick in the crusier's lasers at once and start to waste them rather then having to wait 10 seconds after I warp in and let them close in on me to warp scramble and web. My buddy almost got killed the other day because of this when his MOA warped in about 5km from 3 4k pirates. He got webbed by two the second his 10 secs were up. The whole time him not being able to shoot or begin to target. I would like it a hell of a lot more for the shp to just not apear till everything is fully loaded. The 10 secs lets gate campers scorps and blackbird have time to get ready. It really does become a quick draw rather then quick reflexs, being awake, and having a agile/fast ship. The same goes for the guys camping the gate. Other day some TTi guys in FA space were able to recon our gates about 3 times because they were protected by that 10secs.
illuminati	Posted - 2003.09.10 14:05:00 - [20] Edited by: illuminati on 10/09/2003 14:07:36 1. People should be in control of their ships when combat actually commences. 2. There should still be a way to lock people down fair-and-square. Good points, I can accept getting my ass kicked as long as I can see it and react to it Randomizing system entry is a fast fix that is needed atm although it doesnt solve warp exit lag and no-lock. Not sure how to solve this view hack possibility though if environment loads before ships are shown. I assume it can be done as soon as the client gets ship location data, even though it isnt "supposed" to show them.
Klydor	Posted - 2003.09.10 15:00:00 - [21] Edited by: Klydor on 10/09/2003 15:03:03 To be honest I don't care if players see what is coming via a hack etc. After all they can do naff all to change matters. Its also much better than the current warp in and die to ships you cannot see. Which is a great in built hack. Also why not preload the entire environment outside of the station, after all shouldn't people be able to see whats outside via a viewport. Let us know whats sat outside a station, this will remove 100% lag of undocking. So the only items left are jump and warp lag. Well once you've nearly finished jumping/warping allow the entire env to be loaded. Ensure you don't come out of warp until the env has fully been sent to your client. Then when the client responds to say its ready, drop em out of warp. After the last peice of information regarding the new env has been sent, activate a short timer of a few seconds for the client to respond to say it's received the data. If it doesn't respond due to excessive net lag then tough, spawn the player anyway. The above isn't fool proof, nor a perfect solution, but in my opinion its a step in the right direction. To avoid the need for hacks to be made to display the ships as they're streamed in one by one, giving that player a slight advantage. Just display them for everyone without the need for a hack. Make up an excuse like sensors will indicate potential obsticles/targets prior to exiting warp or jump gate. Or compleatly ignore the above and work on a better solution :) Either way so long as "something" is done, I don't mind what it is. Plus I've no idea how workable the above idea is, since I've no idea how the clients written, nor how much data is been sent, or what potential exploits you could get.
Ezra	Posted - 2003.09.10 17:27:00 - [22] Quote: Edited by: Klydor on 10/09/2003 15:03:03 To be honest I don't care if players see what is coming via a hack etc. After all they can do naff all to change matters. My point exactly. If objects at warp destinations are precached, it doesn't matter if a "hack" allows them to be seen in advance, because once you're in warp, you're committed to going all the way to a predetermined destination. Same with jumping - There's nothing you can do if you know in advance that the spawn point is camped, because you are going there no matter what. The idea of not displaying a ship in space until all data is sent would be a good idea as long as the data sending process is aware of the maximum bandwidth of the connection and takes that into account. Very likely the server process has logic exactly like what is described as a solution - It sends all the data, then pops the ship into space. The problem is that the data gets held up at the OS network stack level, so the server is not aware that it's taking a while to send the data to the client. There's no solution that doesn't involve either: a) Waiting for acknowledgement from the client. This is "hackable", but what damage can such a hack do? You're going to have to come out of space evenetually. (A good solution would be to have a timeout - Far longer than any lag situation might cause, but short enough to prevent a client hack from allowing someone to "stick" themselves for hours to save their ship. 1-2 minutes should be long enough.) b) Taking measures to reduce peak bandwidth, by taking advantage of periods with low bandwidth usage and spreading the data out over time. c) Tighter integration with the server OS's networking stack so the server is aware of client lag from insufficient bandwidth. I personally think b) is the best solution. ------------ Ezra Cornell pe0n, Xanadu Corporation
SUNchaser	Posted - 2003.09.10 19:13:00 - [23] Edited by: SUNchaser on 10/09/2003 19:30:11 fully randomize entry points and due to "energy emmisions" from jumpgates weapons don't work withing 30km( or some such story line). No more gatecamping and entry camping would be pure luck if every entry was sent to a spot randomly. or after a specified period of time within 39km of jumpgate all modules deactivate and can only be reactivated at station. or within 30km of jumpgate all targeting takes at least 60 seconds due to the background emmisions from jumpgates. or hopefully making the point that a solution is there just need some creative thinking and staying in the story line is possible too.
Kasha	Posted - 2003.09.10 19:53:00 - [24] SUNchaser , thats the dumbest idea I have ever heard.
Cookie	Posted - 2003.09.10 19:58:00 - [25] well, the solution with 'client-says-ready' seems to good for me, as long the client doesn't display anything until the server drops the ship.

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