Pages: 1 2 3 4 [5] 6 7 8 9 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 22 post(s) |
Swayzz
ROC Deep Space
0
|
Posted - 2011.10.01 13:36:00 -
[121] - Quote
Swayzz wrote:ok you have said that there is a 2 sec pause to keep sync ... so what happens when you jump 2-3 titans into a dialated system each with 100-200 ships ... would this desync everything or pause the whole system till eveything is loaded ?
and why can't we add more servers? to eve ..is it the money or the hardware ?
well it could be titans and motherships ,dreads,carriers .. all with support ... if theres a way round it it will be found and exploited ..?
so if the sever is already maxed out .. and more jump in then it would have no option either to crash or pause ?
can we not add 2 servers combined to a single system working like a raid drive ? |
Trebor Daehdoow
Dirt Nap Squad Dirt Nap Squad.
911
|
Posted - 2011.10.01 13:40:00 -
[122] - Quote
I was going to +1 on the first page, but for some... reason... my... browser... started... toooooo..... ssssssss....lllllll....ooooo...wwwww..... dddddddddddddddddddddddddddddddddddddd....... CSM - because I have not yet plumbed the depths of my inherent masochism! CSM 6 Activities Summary | My CSM blog |
Cybele Lanier
Viziam Amarr Empire
1
|
Posted - 2011.10.01 14:13:00 -
[123] - Quote
ThisIsntMyMain wrote:Will DestroyYou wrote:Concerns: 2. Dilation for players is different to lag, HOW???
Lag = UNCONTROLLED degradation of the server, missed requests ie the enemy guns fire and yours don't, modules stick, free cap for active hardeners, you dying on a blackscreen and never loading grid. TiDi = Everyone gets a FAIR SHARE of the server time. All requests are serviced - ie your guns fire at the same rate as everyone else, modules cycle slowly at the same rate as everyone else, no free cap for your active modules, slow loading into system but no dying on a black screen and waking in station. I.e. its completely different. No it doesnt "remove" lag but it does give us the best "fix" that you can expect.
Just quoting this for the benefit of people who aren't understand what's on offer, because it makes my points better. This does accomplish something, by making lag predictable, moving it to "This is kinda slow, but at least I'm doing stuff." from "An hour of staring at a black screen, then ten minutes between shots at a ship that turned out to have died half an hour ago, and then losing because half the fleet got killed before they loaded grid." |
Lors Dornick
Kallisti Industries
7
|
Posted - 2011.10.01 14:20:00 -
[124] - Quote
Swayzz wrote:
can we not add 2 servers combined to a single system working like a raid drive ?
No, as has been explained several times over, the current codebase doesn't allow clustering or sharing server load of anything smaller than one system.
A design decision taken way back in the dark ages of EvE development. And not an easy one to correct without _massive_ amounts of rewrites, and most most likely a likewise massive amount of new wierd bugs ... |
Malcom Dax
Blacklight Incorporated Broken Chains Alliance
5
|
Posted - 2011.10.01 14:46:00 -
[125] - Quote
Playing devil's advocate here: what about bigger/better servers?
Although I was under the impression that the Eve servers are already pretty top-end. Is there any information out there that talks about Eve's servers? |
Caius Sivaris
Dark Nexxus S I L E N T.
16
|
Posted - 2011.10.01 15:19:00 -
[126] - Quote
CCP Veritas, doing his best to keep people subscribed and having fun. Could CCP clone him? They could use proteins from useless waste of biomass like CCP Zynfandel. |
GeeShizzle MacCloud
4
|
Posted - 2011.10.01 15:39:00 -
[127] - Quote
Malcom Dax wrote:Playing devil's advocate here: what about bigger/better servers?
Although I was under the impression that the Eve servers are already pretty top-end. Is there any information out there that talks about Eve's servers?
yahh there is tho digging it out would take a while, i know last fanfest they bought a top secret IBM super server to act as the dedicated server, that had a previously unreleased and unnamed new main board on it which was housing a previously unreleased and un-named new top of the range Intel CPU on it.
to my mind the only way CCP could do more hardware wise to their servers is to take a leaf out of that film 'Sunshine' and house the whole server farm in liquid coolant/liquid nitrogen. and thats a pretty mental and horrendously expensive thought! so right now its all about software optimisations!
i would say that CCP's code monkeys are seriously pushing python to its absolute limits. I know some critics say '**** it, write the damn thing in C' and thts kinda what theyre slowly doing. from what i remember CarbonIO and its underpinned python extensions are practically fooling python and sidestepping its main disadvantage!
it might be that in the future CCP can release itself from python, but it cant be something wished out of thin air, and it cant be something that they dedicate all their dev time to it, cause eve would suffer from being left in the shadows of other games in the marketplace. |
Swayzz
ROC Deep Space
0
|
Posted - 2011.10.01 15:42:00 -
[128] - Quote
Lors Dornick wrote:Swayzz wrote:
can we not add 2 servers combined to a single system working like a raid drive ?
No, as has been explained several times over, the current codebase doesn't allow clustering or sharing server load of anything smaller than one system. A design decision taken way back in the dark ages of EvE development. And not an easy one to correct without _massive_ amounts of rewrites, and most most likely a likewise massive amount of new wierd bugs ...
then istead of running after console games market you would think that rewrite would be first on the list .. or does the pc market now stagnant because of some of the larger issues like lag and such to be over looked for the more rich rewarding console market ?
but with a player base that could be double or tripled if these things could be done not even warent a look at ? |
Akira Zendragon
EVE University Ivy League
0
|
Posted - 2011.10.01 15:48:00 -
[129] - Quote
Veritas,
I'd just like to give some serious kudos for this. Being a developer, I find this is quite an elegant solution to the issue of graceful degradation. Bit of a stroke of genius, IMHO.
As to the "more hardware" approach, IIRC your current brick wall is 1 node = 1 system, right? Have you considered the possibility of 1 node = 1 grid? Granted this is probably a pretty major, hairy, overhaul of server code, but as a long term project, perhaps? |
GeeShizzle MacCloud
5
|
Posted - 2011.10.01 15:51:00 -
[130] - Quote
think of it as more like.. the rewards of the one could fuel and pay for the improvements of the other! =)
if CCP unlock themselves to a wider player base, that wider player base could very well generate them more cash that they can re-invest in eve's main servers and code development to make it run faster for more people. |
|
Malcom Dax
Blacklight Incorporated Broken Chains Alliance
5
|
Posted - 2011.10.01 15:54:00 -
[131] - Quote
Akira Zendragon wrote:Veritas,
I'd just like to give some serious kudos for this. Being a developer, I find this is quite an elegant solution to the issue of graceful degradation. Bit of a stroke of genius, IMHO.
As to the "more hardware" approach, IIRC your current brick wall is 1 node = 1 system, right? Have you considered the possibility of 1 node = 1 grid? Granted this is probably a pretty major, hairy, overhaul of server code, but as a long term project, perhaps?
How much difference would that realistically make? From what I understand in a major fleet fight most of those involved are on the same grid anyway. I don't really see you getting a particularly big improvement in performance by doing this. At least not enough to justify the effort that would go into doing it. |
Steve Ronuken
Cossette Moana
5
|
Posted - 2011.10.01 16:18:00 -
[132] - Quote
Even if you get down to one node is one grid, TiDi is still worth having.
For when that grid gets overloaded. As has been mentioned, build a better server and people will just bring more ships. |
Tedric
Outcast Heroes Destructive OuTcaSts
3
|
Posted - 2011.10.01 16:46:00 -
[133] - Quote
When i first heard of the idea of time dilation i loved it! It does not solve the underliying problems but it allows EVE to suffer more gracefully. I agree with most people here saying that the UI should not be slowed in its responsiveness, but everything ship based must be slowed.
If you allow the UI to be slowed in time with dilation the perception of 'This time dilation business does not work, it is still laggy' will happen and EVE will get negative PR. i.e. CCP writes code to spin wheels that do nothing.
Video: I like it.
Notes:
1. i would like to see the timer PULSE when the time dilation value CHANGES. mainly cos I want my attention drawn to it when its state changes, so i can adjust my perception of what is going on.
2. When someone is in a system next door and starts the 'jump in' process, I would like a notice saying that the system is under time dilation and an indication of how much. Not sure how I would like this done. It could be the gate looks/behaves differently or the UI jump button is coloured differently (follows the time dilation factor colour code). Personally, I would like to see this information before i commit myself to starting the 'jump in process'.
3. If a system is under heavy time dilation, would it be sensible to lightly dilate the systems surrounding it. This is to prevent the 'run around the block to the other gate' concept. It would also give an indication that 'big *&!* is going down next door' and also reduce the huge difference in time dilation values.
4. The new font: yes the 0O and 6G are clearer. I'm unsure if it is easier to read. It is certainly _harder_ to read when using the Black colour scheme.
+1 overall.
Tedric.
edit: typos. |
Malcom Dax
Blacklight Incorporated Broken Chains Alliance
5
|
Posted - 2011.10.01 17:12:00 -
[134] - Quote
Tedric wrote: I would like to see this information before i commit myself to starting the 'jump in process'.
Hadn't thought of that. Now you bring it up, I agree.
Tedric wrote:If a system is under heavy time dilation, would it be sensible to lightly dilate the systems surrounding it. This is to prevent the 'run around the block to the other gate' concept. It would also give an indication that 'big *&!* is going down next door' and also reduce the huge difference in time dilation values.
It was my understanding of that if TiDi is applied to the whole node and affects all the solar-systems on that node the same way. So this kind of happens anyway, in some situations.
I'm assuming that a node has a set of adjacent/near-by solar systems on it, rather than random ones. Does anyone know if this is indeed the case? Could get some interesting situations if not. |
GeeShizzle MacCloud
5
|
Posted - 2011.10.01 18:11:00 -
[135] - Quote
Malcom Dax wrote:I'm assuming that a node has a set of adjacent/near-by solar systems on it, rather than random ones. Does anyone know if this is indeed the case? Could get some interesting situations if not.
yes this is the case, only 1 or 2 exceptions to this ie jita node and the dedi server used when a particular system is reinforced. |
Lykouleon
Wildly Inappropriate Goonswarm Federation
95
|
Posted - 2011.10.01 18:35:00 -
[136] - Quote
Praise be to our CCP Veritas overlord. Lykouleon > CYNO ME CLOSER SO I CAN HIT THEM WITH MY SWORD |
GeeShizzle MacCloud
5
|
Posted - 2011.10.01 19:12:00 -
[137] - Quote
nice mass test veritas! im working on a video of it atm and will post it :) have to say tho on the pos bash part when you put TiDi to 50% i swear you can see on missiles the 2 second sync checksum looping! LOL! |
I'thari
33
|
Posted - 2011.10.01 20:48:00 -
[138] - Quote
CCP Veritas wrote:Schmell wrote:Ehm...why the user interface (camera, spitter etc) is slowing down in the first place? I thought time dilation is server side and should not affect strictly client-side things Because I want to convey the slowdown to the player. In essense, make space *feel* slower when it really *is* slower. Do note that it's only a couple UI elements plus the camera, and I might go back on the camera one. Couple or not - seeing stuff moving slower plus having an indicator is "feel" enough without adding artificial UI lag to the pile. "Normal" speed is there for a reason, you know - if possible you should keep it (or just make everything slower permamently and make it new norm), not make stuff running slower than it should and call it a "feature". |
Aineko Macx
Royal Amarr Institute Amarr Empire
6
|
Posted - 2011.10.01 20:54:00 -
[139] - Quote
Excellent!
The one things that seems odd is that you plan on also reducing the client fps when time dilation kicks in. There is no good reason for that. Just the bad one that the graphics subsystem is probably incapable of running at a different simulation speed than the physics one... |
Will DestroyYou
0
|
Posted - 2011.10.01 22:23:00 -
[140] - Quote
This will be a serious disadvantage to dictor (or any fast tackle ship really, bombers?) pilots.
The enemy FC has much more time to react now... |
|
Will DestroyYou
0
|
Posted - 2011.10.01 22:34:00 -
[141] - Quote
Will DestroyYou wrote: Fix the source of the problem. The blobs. You don't need 1000 (or 2000 with this dilation system) people firing on a single target. Change the game mechanics to split them over multiple targets (optimally in multiple grids or even systems). Change the mechanics to make NAPfests a disadvantage. Change the game to make alliances pay a price for becoming bloated.
Fix the cause, don't just patch up the symptoms. This is exactly why eve has always had lag issues.
GeeShizzle MacCloud wrote: you're not wrong that a huge amount of people are the cause of lag, but Eve Online is the ONLY game in the world that doesnt actually enforce limitations on player participation, in MMO's it is its Unique Selling Point and eve without it wouldnt be Eve!
on the subject of NAPs, they will happen regardless of any constructs that u place. ive been in fleets engaging only particular reds and making sure other alliances red to us, that were on grid werent shot at, on prior agreement. you cannot enforce the eradication of NAPS
All I am saying is enforce limits at a level that keeps it just under the node's ability.
-or-
Force blobs to split up with mechanics and spread the load. |
Zirse
Brutor Tribe Minmatar Republic
76
|
Posted - 2011.10.01 22:38:00 -
[142] - Quote
Question for you Veritas- can you describe the scaling procedure?
I've heard that at tidi: 10%, 10 RL seconds = 1 ingame second/tick.
Does that mean at 90% dilation we're looking at 1.5 minutes for each in game second? That seems abusrd?! |
|
CCP Veritas
C C P C C P Alliance
93
|
Posted - 2011.10.01 23:44:00 -
[143] - Quote
Aineko Macx wrote:The one things that seems odd is that you plan on also reducing the client fps when time dilation kicks in.
I never have planned that and I continue to not plan that. Where'd you get the idea that I ever did plan to do that? CCP Veritas - Senior Programmer - EVE Software |
|
Vincent Athena
V.I.C.E.
49
|
Posted - 2011.10.01 23:44:00 -
[144] - Quote
Will DestroyYou wrote:........
Force blobs to split up with mechanics and spread the load. Have the number of guns shooting a target effect tracking and missile damage (with a max effective dps on the target being proportional to sig radius).
Basicly, fix the problem at the source.
Using game mechanics is a good idea, but so far every idea I have seen will not work. Take your example above. Fleets already subdivide into "firing groups" (all of which are on grid). With your suggestion the firing groups would be sized to minimize the penalties and maximize their total DPS. Now the fleet with the most firing groups can attack the most enemy ships at once. Hence bigger you blob the better.
You might say "make the penalties be based on fleet size". Then players will make many small fleets and blob them.
You might say "Make it based on the number of ships on your side". Then players will drop standings and use out of game tools to keep track of who is the enemy, and keep right on blobbing.
You might say "limit the number of players on one system". Then a system can be held just by filling it up with your players.
Its a really hard problem, its why we have blobs.
When you consider a possible mechanic, also think "What would the most devious metagamer do to get around it or take advantage of it"? CCP employees should never proclaim a feature to be awesome. Only subscribers should. |
Vincent Athena
V.I.C.E.
49
|
Posted - 2011.10.01 23:50:00 -
[145] - Quote
Zirse wrote:Question for you Veritas- can you describe the scaling procedure?
I've heard that at tidi: 10%, 10 RL seconds = 1 ingame second/tick.
Does that mean at 90% dilation we're looking at 1.5 minutes for each in game second? That seems abusrd?!
90% means 10 RL seconds = 9 in game seconds.
TiDi amount = ( In game seconds ) / ( RL seconds )
A values I call Gamma, after the term used in Relativity.
CCP Veritas: Really liked the test. On seeing the "slowed camera" I find its fine the way it is. I expected something much worse. But if you slow time below 10% I would leave the camera at the 10% level. CCP employees should never proclaim a feature to be awesome. Only subscribers should. |
|
CCP Veritas
C C P C C P Alliance
93
|
Posted - 2011.10.01 23:52:00 -
[146] - Quote
Zirse wrote:Question for you Veritas- can you describe the scaling procedure?
I've heard that at tidi: 10%, 10 RL seconds = 1 ingame second/tick.
Does that mean at 90% dilation we're looking at 1.5 minutes for each in game second? That seems abusrd?! Gettin' the numbers switched around. The way I'm describing it, normal speed is 100%, paused is 0%, 10% is, well, one tenth of the way from paused to normal speed.
So at 10% speed, 1 simulation second takes 10 wallclock seconds. At 90% speed, 1 simulation second takes 1.11 wallclock seconds. CCP Veritas - Senior Programmer - EVE Software |
|
Zirse
Brutor Tribe Minmatar Republic
76
|
Posted - 2011.10.01 23:58:00 -
[147] - Quote
I see, thanks. |
Salpun
Paramount Commerce Masters of Flying Objects
37
|
Posted - 2011.10.02 00:04:00 -
[148] - Quote
CCP Veritas wrote:Zirse wrote:Question for you Veritas- can you describe the scaling procedure?
I've heard that at tidi: 10%, 10 RL seconds = 1 ingame second/tick.
Does that mean at 90% dilation we're looking at 1.5 minutes for each in game second? That seems abusrd?! Gettin' the numbers switched around. The way I'm describing it, normal speed is 100%, paused is 0%, 10% is, well, one tenth of the way from paused to normal speed. So at 10% speed, 1 simulation second takes 10 wallclock seconds. At 90% speed, 1 simulation second takes 1.11 wallclock seconds.
Sounds like a good wiki artical to me. I would write it but some one would call me a lier. |
ThisIsntMyMain
Republic University Minmatar Republic
16
|
Posted - 2011.10.02 00:31:00 -
[149] - Quote
Will DestroyYou wrote:All I am saying is enforce limits at a level that keeps it just under the node's ability.
-or-
Force blobs to split up with mechanics and spread the load. Have the number of guns shooting a target effect tracking and missile damage (with a max effective dps on the target being proportional to sig radius).
Basicly, fix the problem at the source.
The "source" of the problem is Us - The players.
You cannot stop us blobbing in a system by artificially limiting numbers in the system because we will find ways to exploit this by
- Stacking those numbers in our favour by filling the system with our bigger blob before you are ready -or-
- If the attacker and defender numbers are balanced by CCP to be say 400v400, then you can forget 3 way fights, surprise hot drops, and having that hidden subcap fleet one titan bridge away.
You cannot force us to split up by using multiple simultaneous objective because you will hand a massive advantage to the defenders. Why ...
- If the attacker must complete all objectives the defender needs only to defend at one point -or-
- If the attacker must complete the majority ( say 3 out of 5), Attacker must attack 5 times, defender must defend only 3 times.
Its easy to SAY "fix the problem at source". I don't like "blobbing" any more than you do, but its a reality of Eve. I also, probably like you, really really HATE the completely FUBARed chaos that is an overloaded node.
Yes, TiDi is a compromise, but please stop whining about how you don't want it because you will only accept your own version of a "perfect" solution. |
Will DestroyYou
0
|
Posted - 2011.10.02 01:19:00 -
[150] - Quote
ThisIsntMyMain wrote:Will DestroyYou wrote:All I am saying is enforce limits at a level that keeps it just under the node's ability.
-or-
Force blobs to split up with mechanics and spread the load. Have the number of guns shooting a target effect tracking and missile damage (with a max effective dps on the target being proportional to sig radius).
Basicly, fix the problem at the source. The "source" of the problem is Us - The players. You cannot stop us blobbing in a system by artificially limiting numbers in the system because we will find ways to exploit this by
- Stacking those numbers in our favour by filling the system with our bigger blob before you are ready -or-
- If the attacker and defender numbers are balanced by CCP to be say 400v400, then you can forget 3 way fights, surprise hot drops, and having that hidden subcap fleet one titan bridge away.
Earlier I suggested time dilation be changed to effect the ones causing the server problems more. If people exploit this it is no different to dropping cans or any other lag causing exploit, and should be handled the same way as those. Temporary (or permanent if they are repeat offenders) bans, or other appropriate punishments.
It has been deemed "not ok" to dump large numbers of cans to create lag, where is the difference? Exploiting lag is exploting lag.
ThisIsntMyMain wrote:You cannot force us to split up by using multiple simultaneous objective because you will hand a massive advantage to the defenders. Why ...
- If the attacker must complete all objectives the defender needs only to defend at one point -or-
- If the attacker must complete the majority ( say 3 out of 5), Attacker must attack 5 times, defender must defend only 3 times.
Easy fixed by making each structure matter. eg: Add more system upgrades (including guns, NPC defenders, more levels of current upgrades, etc), and each one you do not defend means you loose something importent, decreasing your ability to defend or taking other advantages away.
ThisIsntMyMain wrote:Its easy to SAY "fix the problem at source". I don't like "blobbing" any more than you do, but its a reality of Eve. I also, probably like you, really really HATE the completely FUBARed chaos that is an overloaded node.
Yes, TiDi is a compromise, but please stop whining about how you don't want it because you will only accept your own version of a "perfect" solution.
I never said my solutions are perfect, but at least they address the cause instead of fixing the symptoms temporarilly.
Large alliances don't/won't like it for obvious reasons (and i really don't care - I want a fun game, not a laggy game), but there is a more thorough solution here (on the old forums): http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1569381
|
|
|
|
|
Pages: 1 2 3 4 [5] 6 7 8 9 :: one page |
First page | Previous page | Next page | Last page |