Pages: 1 2 [3] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Xavieer Naidoo
Oberon Incorporated Morsus Mihi
|
Posted - 2008.10.01 03:51:00 -
[61]
I *****heartedly agree. Node crashes are unacceptable, therefore all ships should be reimbursed.
|
Shinma Apollo
The Graduates Morsus Mihi
|
Posted - 2008.10.01 05:27:00 -
[62]
Originally by: Irongut
Originally by: Shinma Apollo The current policy of refusing all large scale losses for reimbursement is harmful, illogical, and is in need of reconsideration.
This is not the "current" policy, it has always been the policy. Since it has worked for 5 years there is no need to fix it. New Eden is a harsh and unforgiving place, learn to live with it.
I have learned to live with it. it's the part when I'm trying to get into New Eden that's bothering me
|
Soto ShinDo
Federal Navy Academy
|
Posted - 2008.10.01 05:37:00 -
[63]
/signed
|
Venkul Mul
Gallente
|
Posted - 2008.10.01 11:01:00 -
[64]
Originally by: Somealt Ofmine
You should not lose ships in this game while staring at a loading screen, period, whether its a Frigate, or a Titan. That's just about the epitome of crappy, ill-coded game play.
If their logs can't show them that the player wasn't actually in the game when their ship died, they damn well need to enhance their logger.
Having a ship replaced that died before you loaded shouldn't even require a petition. It's a defect in how the game is coded, and if they can't fix it, they should at very least fix it so that players aren't disadvantaged by it.
Little logic problem: - logging more data to check if the player had not loaded when killeld use up more server capacity and database capacity; - using up more server capacity will reduce further the size of usable fleet; - as people will not reduce the fleets more crashes will occur.
End results: more ship losses, longest petitions queue, ship are reimbursed after months.
Option 2. - data are stored player side; - some player discover how to hack the data day 2 of the change; - no one ever loss a ship in PvP.
|
Venkul Mul
Gallente
|
Posted - 2008.10.01 11:08:00 -
[65]
Originally by: Somealt Ofmine Edited by: Somealt Ofmine on 30/09/2008 22:33:34
Originally by: Shinma Apollo
This is simply a question of CCP taking responsibility for its errors, even if it means an increased workload.
Really shouldn't even be a matter of increased petitions and workloads, though. Losing your ship before you are actually in the game = broken / defective / not working right.
Can anyone really say with a straight face that your ship arriving in the game before you do, and dying before you ever get there is "working as intended"?
Look, it's not rocket science. There is a protocol (set of messages that go back and forth between the client and the server) when you log in. Like so:
1. Server recieves login request from client.
2. Server authenticates the user, and starts sending game data.
3. Server places the player's ship on the grid
4. Data transmission to the client is complete, client starts rendering the game (you stop seeing the "entering game" screen).
5. Client finishes rendering the game, and gives the player control (you can start clickin stuff and activating modules).
What's wrong with the above? It's pretty obvious. Step 3 shouldn't happen before step 5. They coded it wrong. In low-load situations, it's not obvious that it's coded wrong, becasue the time lapse between 3 and 5 doesn't matter much. In high load situations, it is obvious, and it breaks the game.
Since it's coded wrong, if they can't easily fix it, they should just put an extra bit in there where the server goes "damn, his ship got blown up before step 5, stick another one in his hanger".
The end. It's broken. Fix it.
Invert step 3 and 5 and what you get?
Your ship will lock and start firing before being registered by the other players.
So you will need a step 6. Ship is frozen and invulnerable until all other ship have acknowledged his presence on grid. But at that point you can simply say: ship will never load in a fleet battle.
|
sthymj
The Graduates Morsus Mihi
|
Posted - 2008.10.01 16:08:00 -
[66]
I fully endorse this suggestion.
|
Kerfira
|
Posted - 2008.10.01 17:53:00 -
[67]
Edited by: Kerfira on 01/10/2008 17:53:57 Not signed!
There are already TOO many caps in EVE. If anything should be done, caps should not be insurable or reimbursable.
If you bring them (or any other ship) into a lag-fest, that's your own problem...
EDIT: Oh, and 68th in an NC whine thread!
Originally by: CCP Wrangler EVE isn't designed to just look like a cold, dark and harsh world, it's designed to be a cold, dark and harsh world.
|
destinationZERO
Minmatar Pain Management Services
|
Posted - 2008.10.01 18:09:00 -
[68]
Edited by: destinationZERO on 01/10/2008 18:14:02 not supported!
loose a battle due to your own incompetence, and then want the ship back? lol.
I'm wondering, why is there no bob posters supporting this issue? they never lost a capital ship ? or they just don't whine? :)
NEXT TIME BRING MORE, THAT SHOULD SOLVE THE PROBLEM...
and if you loose youll just get them back! now that's an idea. :)
|
Katarina Arisdeed
Caldari Macabre Votum Morsus Mihi
|
Posted - 2008.10.01 18:31:00 -
[69]
Originally by: destinationZERO Edited by: destinationZERO on 01/10/2008 18:14:02 not supported!
loose a battle due to your own incompetence, and then want the ship back? lol.
I'm wondering, why is there no bob posters supporting this issue? they never lost a capital ship ? or they just don't whine? :)
NEXT TIME BRING MORE, THAT SHOULD SOLVE THE PROBLEM...
and if you loose youll just get them back! now that's an idea. :)
Nobody has a problem loosing in an actual fight, the problem here is there was no actualt fight, we got to stare at a blank screen for 4 hours
|
destinationZERO
Minmatar Pain Management Services
|
Posted - 2008.10.01 19:09:00 -
[70]
if I couldnt afford to fly one, I wouldnt bring it.
if I had a FC that will just cyno in at a gate, I wouldnt take part in the fight.
not only you had a blackscreen, keep that in mind.
|
|
Katarina Arisdeed
Caldari Macabre Votum Morsus Mihi
|
Posted - 2008.10.01 19:32:00 -
[71]
Originally by: destinationZERO if I couldnt afford to fly one, I wouldnt bring it.
if I had a FC that will just cyno in at a gate, I wouldnt take part in the fight.
not only you had a blackscreen, keep that in mind.
Understandable, everyone knows that the golden rule in eve is not to fly something you cant afford to loose, thats not the issue here, personally I had bought a new carrier and had it fitted and back up in tribute as soon as I was finally able to load into my medical clone, the point of this is that ANYONE who looses a ship this way shouldnt just be expected to eat it, Honestly if the GBC posted something like this should they have lost ships in a situation like this I would support them in saying they should be re-embursed as well, we may be enemies in game but that doesnt mean they deserve to have thier in-game experiences ruined because of a hardware problem thats outside of their control
|
LUKEC
Destructive Influence Band of Brothers
|
Posted - 2008.10.01 22:09:00 -
[72]
Oh dear.
|
Arturus Vex
Macabre Votum Morsus Mihi
|
Posted - 2008.10.01 22:43:00 -
[73]
Edited by: Arturus Vex on 01/10/2008 22:45:54
Originally by: Venkul Mul some stuff
Adding one reply packet to the end of the initial grid-loading data stream to make/confirm player intractability is hardly going to cause a bump in server performance.
And 'that it might be hacked' is hardly a good reason to not fix such obvious issues.
|
Venkul Mul
Gallente
|
Posted - 2008.10.02 06:04:00 -
[74]
Originally by: Arturus Vex Edited by: Arturus Vex on 01/10/2008 22:46:59 Edited by: Arturus Vex on 01/10/2008 22:45:54
Originally by: Venkul Mul some stuff
Adding one reply packet to the end of the initial grid-loading data stream to make/confirm player intractability is hardly going to cause a bump in server performance.
'It might be hacked' is hardly a good reason to not fix such obvious issues. Implement properly and it won't get hacked without a lot of effort.
"Adding one reply packet to the end of the initial grid-loading data stream "
Ypu are forgetting a little point from each ship. Each ship need to acknowledge that you have been loaded or you will be invisible for some of them when you start firing.
But at that time your "single" packet can be some hundred confirmations, all subject to lag and packet loss. And it will require to be redone every time a new ship load. Care to guess how long it will take? I think several hours.
|
Arturus Vex
Macabre Votum Morsus Mihi
|
Posted - 2008.10.02 06:47:00 -
[75]
Originally by: Venkul Mul
"Adding one reply packet to the end of the initial grid-loading data stream "
Ypu are forgetting a little point from each ship. Each ship need to acknowledge that you have been loaded or you will be invisible for some of them when you start firing.
But at that time your "single" packet can be some hundred confirmations, all subject to lag and packet loss. And it will require to be redone every time a new ship load. Care to guess how long it will take? I think several hours.
No. That's not the right way to implement it at all.
1.) Your client sends a packet (or set of packets) at the end of a grid load. This confirms that you indeed have objects and other players loaded and in place on your grid (the objects and players that the server sent... ie, 'hey i'm rendering stuff, time to start the shooty-shooty' ). 2.) The server logs the data and activates hostilities between yourself and other players. 3.) Profit? ($$$)
We aren't looking for a perfect system where we make sure everyone is rendering everyone, we are looking for an imperfect system where we can determine 'this person was rendering something and sending instructions' or 'what was this person rendering at time of death, and could he send instructions?'. Logs themselves could even be sent to a completely different log server (making any point about increased load moot from that perspective).
You also have to remember that the server is most likely already sending and receiving lots and lots (and lots) of packets every second in such a situation. Maybe you wouldn't have to do this type of checking in highsec, but in lowsec or 0.0 these appear to me to be a particularly important few packets that aren't being dealt with.
This is more about proper implementation and design than which side lost what, tbh (if this happens to BoB they should be reimbursed too, it is a sucky/frustrating way to lose ships). I see it as a design flaw that this could happen, rather than some sort of red vs. blue issue.
|
Vaal Erit
Science and Trade Institute
|
Posted - 2008.10.02 08:06:00 -
[76]
Morsus Mihi loses a fleet fight and spams the forums and demands their ships back, god you guys look like huge whiners.
The problem is not the reimbursement, the problem is that you are dying while staring at a black screen. If your enemy spent the fuel/strontium and ammo and killed a black-screened guy instead of someone who loaded then that they should get an insta kill button as reimbursement as well. Your idea is just terrible.
You should not be loaded and on-grid and shootable unless your client has loaded the screen. I'm no programmer but I don't see why something cannot be worked out.
Big yes to fixing dying to a black screen.
Big NO to being pompous because your alliance died to a lag fight, do you think this is the first time someone lost a ship due to lag? --
http://desusig.crumplecorn.com/sigs.html
|
Shinma Apollo
The Graduates Morsus Mihi
|
Posted - 2008.10.02 08:18:00 -
[77]
Edited by: Shinma Apollo on 02/10/2008 08:19:46
Originally by: Vaal Erit Morsus Mihi loses a fleet fight and spams the forums and demands their ships back, god you guys look like huge whiners.
The problem is not the reimbursement, the problem is that you are dying while staring at a black screen. If your enemy spent the fuel/strontium and ammo and killed a black-screened guy instead of someone who loaded then that they should get an insta kill button as reimbursement as well. Your idea is just terrible.
You should not be loaded and on-grid and shootable unless your client has loaded the screen. I'm no programmer but I don't see why something cannot be worked out.
Big yes to fixing dying to a black screen.
Big NO to being pompous because your alliance died to a lag fight, do you think this is the first time someone lost a ship due to lag?
As much as we the playerbase like to inundate these forums with "Remove the lag" posts, CCP has been taking steps to sort the lag problem. The desync problem is seperate. All I am asking is that while they put us through alpha and beta tests on their new systems, that they take accountability for their non-performance. This is not a question of BoB, the Northern coalition, or anyone else for that matter, nor do I presume to be in the first fleet to lose a battle to lag.
This does not invalidate the point that the reimbursement policy when such non-performance does occur is poorly designed. This is not conspiratorial, we're not alleging any underhandedness in the matter, this is not partisan, this isn't about spiting one alliance or another. This is simply saying, telling people that their time is simply not worth even investigation or what essentially appears to be a macro response letter, much less fairly compensating a customer for a product's non-performance is a policy that should be changed. As for the whiner comment, I suggest you peruse the killboards from that battle for my loss I'm 'whining' about, or more specifically, the lack thereof.
|
TempSniper
Battlestars GoonSwarm
|
Posted - 2008.10.02 08:32:00 -
[78]
|
Terazuk
Rogen's Heroes THORN Alliance
|
Posted - 2008.10.02 11:57:00 -
[79]
Originally by: Somealt Ofmine
You should not lose ships in this game while staring at a loading screen, period, whether its a Frigate, or a Titan. That's just about the epitome of crappy, ill-coded game play.
If their logs can't show them that the player wasn't actually in the game when their ship died, they damn well need to enhance their logger.
Having a ship replaced that died before you loaded shouldn't even require a petition. It's a defect in how the game is coded, and if they can't fix it, they should at very least fix it so that players aren't disadvantaged by it.
QFTFT! You're pretty handy with the hammer there mate... two thumbs fresh.
OPS got my support.
|
Venkul Mul
Gallente
|
Posted - 2008.10.02 12:37:00 -
[80]
Originally by: Arturus Vex
Originally by: Venkul Mul
"Adding one reply packet to the end of the initial grid-loading data stream "
Ypu are forgetting a little point from each ship. Each ship need to acknowledge that you have been loaded or you will be invisible for some of them when you start firing.
But at that time your "single" packet can be some hundred confirmations, all subject to lag and packet loss. And it will require to be redone every time a new ship load. Care to guess how long it will take? I think several hours.
No. That's not the right way to implement it at all.
1.) Your client sends a packet (or set of packets) at the end of a grid load. This confirms that you indeed have objects and other players loaded and in place on your grid (the objects and players that the server sent... ie, 'hey i'm rendering stuff, time to start the shooty-shooty' ). 2.) The server logs the data and activates hostilities between yourself and other players. 3.) Profit? ($$$)
We aren't looking for a perfect system where we make sure everyone is rendering everyone, we are looking for an imperfect system where we can determine 'this person was rendering something and sending instructions' or 'what was this person rendering at time of death, and could he send instructions?'. Logs themselves could even be sent to a completely different log server (making any point about increased load moot from that perspective).
You also have to remember that the server is most likely already sending and receiving lots and lots (and lots) of packets every second in such a situation. Maybe you wouldn't have to do this type of checking in highsec, but in lowsec or 0.0 these appear to me to be a particularly important few packets that aren't being dealt with.
This is more about proper implementation and design than which side lost what, tbh (if this happens to BoB they should be reimbursed too, it is a sucky/frustrating way to lose ships). I see it as a design flaw that this could happen, rather than some sort of red vs. blue issue.
As you have blocked the rendering of your ship to the other machines, you will start firing from invisible and invulnerable. Very kewl for you, a lot less for your targets. Don't seem an improvement.
|
|
Kim Wilde
Covenant
|
Posted - 2008.10.02 14:42:00 -
[81]
|
Hydrofil
|
Posted - 2008.10.02 20:50:00 -
[82]
Ofc I am ready to lose the ship I am flying, but that is a stupid argument, so just cuz I am ready to loose it I should sacrifice it just because I can. I want to keep it as long as possible, so that I loose it cuz a server problem and have no chance to fight back or even activate my modules just sucks.
|
Katarina Arisdeed
Caldari Macabre Votum Morsus Mihi
|
Posted - 2008.10.06 13:22:00 -
[83]
bump
|
thoth foc
Destructive Influence Band of Brothers
|
Posted - 2008.10.06 17:51:00 -
[84]
Originally by: Shinma Apollo The current policy of refusing all large scale losses for reimbursement is harmful, illogical, and is in need of reconsideration.
The policy is very logical. It discourages blobbing past the limits of server performance.
If this policy was reversed it would leave the game open to more harmful abuse, where the largest blocks in the game could potentially field node breaking fleets without risk. ------------------ x-DSMA (Menta) x-CA (OMEGA/BOS) x-.5.(ATUK) BOB (DICE) |
Praetor Novak
Macabre Votum Morsus Mihi
|
Posted - 2008.10.06 18:11:00 -
[85]
Originally by: thoth foc
Originally by: Shinma Apollo The current policy of refusing all large scale losses for reimbursement is harmful, illogical, and is in need of reconsideration.
The policy is very logical. It discourages blobbing past the limits of server performance.
If this policy was reversed it would leave the game open to more harmful abuse, where the largest blocks in the game could potentially field node breaking fleets without risk.
It surprising how Bob/pets pilots constantly act like they've never been on the laggy losing side of a grid load or crashing node. Perhaps it's because they haven't been. The hubris and sheer volume of posts of Bob/pets toward declaring the current game mechanics and client/server performance are more than adequate is also surprising. Perhaps it's because the lag and crashes never seem to quite effect them.
|
thoth foc
Destructive Influence Band of Brothers
|
Posted - 2008.10.06 18:57:00 -
[86]
Originally by: Praetor Novak
It surprising how Bob/pets pilots constantly act like they've never been on the laggy losing side of a grid load or crashing node.
No, i just don't waste my time trying to blame everyone else for my actions. ------------------ x-DSMA (Menta) x-CA (OMEGA/BOS) x-.5.(ATUK) BOB (DICE) |
Ineun
House An'geles Wildly Inappropriate.
|
Posted - 2008.10.07 10:13:00 -
[87]
as usual CCP are doing a Masangsoft on us and just going the communist china route of:
ignore, ignore, ban, ignore, do it our way pr gtfo
1sec THEY DONT GIVE A FLYING **** YOU STILL PAY RIGHT!?
only way to make these corporate ***** actually do anything is to take some money away or go get a cyno in polaris and assualt magicland and stationcamp them all until we get banned
:) ohai i is your resident Socialist... |
Joss Sparq
ANZAC ALLIANCE Southern Cross Alliance
|
Posted - 2008.10.07 11:19:00 -
[88]
I support the reimbursement system being examined simply because I'm personally biased: I've had a (comparatively) substantial loss refused reimbursement inspite of a much smaller loss easily reimbursed and both eventuated in virtually the same circumstances. Consequently I more inclined to think that a (comparatively) substantial loss is likely to be little more than an ISK sink, even when you have a credible case against that.
Also that the logs are more likely to be 350 ft long and made of solid oak than they are to resolve your problems.
|
Irongut
M'8'S Frontal Impact
|
Posted - 2008.10.07 16:12:00 -
[89]
Originally by: Praetor Novak
It surprising how Bob/pets pilots constantly act like they've never been on the laggy losing side of a grid load or crashing node. Perhaps it's because they haven't been. The hubris and sheer volume of posts of Bob/pets toward declaring the current game mechanics and client/server performance are more than adequate is also surprising. Perhaps it's because the lag and crashes never seem to quite effect them.
C'mon take off that tin foil hat and cancel your subscription to Paranoia Weekly. We experience the same lag, desyncs and other problems you do. We just don't whine about it. When it happens stay calm, get everyone to try logging back in or whatever and if you lose a ship take it on the chin.
--
The future is Black. Brace for Impact! |
|
|
|
Pages: 1 2 [3] :: one page |
First page | Previous page | Next page | Last page |