These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

[Rubicon 1.3] Drone Assist change

First post First post First post
Author
Previous Topic Next Topic
X Gallentius
Black Eagle1
#1381 - 2014-02-18 22:49:06 UTC
2D34DLY4U wrote:
....and you should also gain in game advantage from force multipliers such as better fleet disciplines and/or better weapons that are built over the long term.
Isn't "more players in your fleet than the other guy's fleet" enough of a force multiplier already?
Aramatheia
Tiffany and Co.
#1382 - 2014-02-19 13:48:00 UTC
Sgt Ocker wrote:
Markku Laaksonen wrote:
Sgt Ocker wrote:
Fix Sov wrote:
Why would that be necessary? What makes incursions so special?
Valhalla Project obviously don't want their ability to passively do incursions taken away.
Incursions have always been the ideal isk farm.
A few knowledgeable players to guide the masses to farm a lot of isk.
With drone assist being reduced it will mean more knowledgeable players needed in each fleet.
Instead of Fc (drone bunny) and a couple of logi, it will now require Fc logi and 2 additional players who know how to follow broadcasts.
This change may mean it will take them 2 mins longer to finish tiks, which would be bad for the incursion community as it reduces their hourly income.

(sarcasm intended)


50 drone limit for drone assist won't effect Vanguards at all. Your sarcasm masks the fact that you don't know what you're talking about.
LOL, your funny and maybe you should read the post I was responding to.

I've done enough incursions to know the reduced drone assist will have little to no effect.. Hence the sarcasm
And who says it was Vanguards the comment was in reference to. I responded to a specific post sarcastically, what in that says I don't know what I'm talking about?

Do you know what "Sarcasm" is?


A troll will troll regardless of whether it is relevant or not..


tvp has a solution to drone assist changes, it is called Legion Commander!

ok maybe only when im in fleet but still, give me 50 drones + my legion and i'll get it done. I mean i can get it done neutral in site, 23 claimed wrecks is my record to date
General Lemming
The Marmite Mercenaries
BLACKFLAG.
#1383 - 2014-02-19 19:11:47 UTC
Now more alliances need to train their members to F1 X I should setup masterclasses now.
Reaver Glitterstim
The Scope
Gallente Federation
#1384 - 2014-02-21 08:18:24 UTC
Drones need to be rebalanced such that normal ships prefer fewer, larger drones instead of more, smaller drones, to reduce the number of drones on the field in large fleet battles. Two light scout drones should have less DPS than 1 medium scout drone, since they have superior tracking and mobility.

Base Hobgoblin DPS: 6.0
Base Hammerhead DPS: 9.6
Base Ogre DPS: 19.2

Brutix with 5x Hobgoblins: 30 DPS
Brutix with 5x Hammerheads: 48 DPS
Brutix with 2x Ogres: 38.4 DPS

Drake with 5x Hobgoblins: 30 DPS
Drake with 2x Hammerheads and 1x Hobgoblin: 25.2 DPS
Drake with 1x Ogre: 19.2 DPS

Each ship gets the most DPS out of a 5 drone setup

=====================================
LETS PLAY WITH THE NUMBERS A LITTLE BIT:
=====================================

Hammerheads have DPS increased by 50% (14.4)
Ogres have DPS increased by 100% (38.4)

For balance, we will leave drone bay sizes the same but decrease Brutix bandwidth to 40 mbit/sec.
Brutix with 5x Hobgoblins: 30 DPS
Brutix with 3x Hammerheads and 2x Hobgoblins: 55.2 DPS
Brutix with 4x Hammerheads: 57.6 DPS
Brutix with 1x Ogre and 3x Hobgoblins: 56.4 DPS
Brutix with 1x Ogre, 1x Hammerhead, and 1x Hobgoblin: 58.8 DPS

Drake does not need its bandwidth reduced because it is only 25 mbit/sec.
Drake with 5x Hobgoblins: 30 DPS
Drake with 2x Hammerheads and 1x Hobgoblin: 34.8 DPS
Drake with 1x Ogre: 38.4 DPS

Each ship gets the most DPS by using the largest, and therefore fewest, drones.

_________________________________________________________________
*******************************************************************************************
THE RAW FACTS OF MY SUGGESTION AND EXAMPLE:


  1. Brutix/Drake drone DPS may be increased by as much as 22.5%/28% but only with larger drones which have worse mobility and tracking
  2. Brutix maintains its ability to carry two sets of small drones
  3. Both ships may still field 5x small drones at no loss in damage
  4. Large fleets will have fewer total drones on the field


all that needs to be done is take this example and extrapolate it to all the rest of the ships

FT Diomedes: "Reaver, sometimes I wonder what you are thinking when you sit down to post."

Frostys Virpio: "We have to give it to him that he does put more effort than the vast majority in his idea but damn does it sometime come out of nowhere."
Mournful Conciousness
Federal Navy Academy
Gallente Federation
#1385 - 2014-02-21 08:37:24 UTC
All talk of reducing drone numbers, although well intentioned, is at best a temporary fix.

Effort would be better directed in modifying game mechanics to discourage large fleets.

For example, as the total mass of a grid increases, warp drives become less accurate.

As total radio traffic on a grid increases, targeting systems suffer due to interference.

And so on.

This then gives FCs a tactical incentive to keep fleet sizes and therefore engagement sizes smaller.

The dev team would then have an opportunity to manage server load by rewriting code so that each grid is given its own blade rather than each system.

Embers Children is recruiting carefully selected pilots who like wormholes, green killboards and the sweet taste of tears. You can convo me in game or join the chat "TOHA Lounge".
Fix Sov
#1386 - 2014-02-21 08:47:52 UTC
That won't help anything, because the problem usually isn't system-wide, it's grid-wise. And given the way the code for switching from one process to another (and iirc it's worse when going from one node to another as well), this would just exacerbate the problem.

The proper fix is to reduce the size of fleets, but not through fiddling with warp drives or targeting systems, but through fixing a horribly broken sov system which not only encourages ever increasing blob sizes on a single grid, but basically require them.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Mournful Conciousness
Federal Navy Academy
Gallente Federation
#1387 - 2014-02-21 08:59:31 UTC  |  Edited by: Mournful Conciousness
Fix Sov wrote:
That won't help anything, because the problem usually isn't system-wide, it's grid-wise. And given the way the code for switching from one process to another (and iirc it's worse when going from one node to another as well), this would just exacerbate the problem.

The proper fix is to reduce the size of fleets, but not through fiddling with warp drives or targeting systems, but through fixing a horribly broken sov system which not only encourages ever increasing blob sizes on a single grid, but basically require them.


First, we are largely in agreement.

The problem certainly is system wide because currently the entire system is encapsulated in one thread on one server.

Allocating each grid to a thread is a precursor to gaining benefits from smaller fleets.

Once we get to the point where the most advantageous fleet size is 250 ships, and each grid of 500 ships is in a separate process, tidi will be a thing of the past.

Sharing data between processes is easy and efficient using a publish subscribe high performance bus. I have built such things for investment banks.

Embers Children is recruiting carefully selected pilots who like wormholes, green killboards and the sweet taste of tears. You can convo me in game or join the chat "TOHA Lounge".
Fix Sov
#1388 - 2014-02-21 09:32:53 UTC  |  Edited by: Fix Sov
Mournful Conciousness wrote:
Once we get to the point where the most advantageous fleet size is 250 ships, and each grid of 500 ships is in a separate process, tidi will be a thing of the past.

This is unrealistic, for one simple reason: it won't work. There's always going to be some situations where 250v250 is just not going to cut it, and the only thing your suggestions of making warps and targeting etc fuzzy is going to do is make things annoying when they do exceed 250v250, and chances are high that what you'll actually do is make the lag problem worse because of the need to move players from one process (or worse, node) to another every time they warp outside of the grid they're currently at.

I'm pretty certain that what you'll find would be a better solution to CCP's scalability problems isn't to try to split people across grids (with the performance hit it takes every time you enter and leave a grid, keeping in mind that every time you land you make "a grid") would be more along the route of shifting the processing from the current model of one node/process dealing with all instructions on a per solar system basis, to a new model where one process is responsible for keeping the data of everything within one solar system, receiving all the instructions from clients before the processing tick hits, splitting all the instructions into bitesized chunks and sending it along with the solar system data to a processing farm (which can be scaled infinitely), receive back a delta, update the solar system and sending the updates to the clients once every processing node has done their bit.

This means that the players should be able to get into much, much larger engagements than today if they so desire, but the point of the sov system fix should be that while much, much larger engagements than today would be possible (and would be a lot more devastating than they currently are, even beyond "just" 70ish titans dying in a single engagement), they would be very rare because of the following factors:
1) it would be seriously detrimental to pack your entire force in a single system
2) any engagement would take much, much less time to play through than, say, the 22 hours of B-R, where 2 hours (or less, since while tidi was at 10% the actual server load went well beyond 10% where 1 second ingame would take 10 seconds IRL, the reality was that things like damage and rep output was vastly below what it would've been at a true 10% tidi, because the system node just couldn't do all the processing it needed to do in the 10 sec processing ticks 10% tidi implies), which means that large-scale random engagements like Asakai etc won't escalate into the entire eve universe converging on a single system/grid, and ******* up by jumping instead of bridging means you can't tidi the system to get more of your dudes in to rep/fight the other guy, as is common today.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Reaver Glitterstim
The Scope
Gallente Federation
#1389 - 2014-02-21 09:38:35 UTC
Fix Sov wrote:
That won't help anything, because the problem usually isn't system-wide, it's grid-wise. And given the way the code for switching from one process to another (and iirc it's worse when going from one node to another as well), this would just exacerbate the problem.

The proper fix is to reduce the size of fleets, but not through fiddling with warp drives or targeting systems, but through fixing a horribly broken sov system which not only encourages ever increasing blob sizes on a single grid, but basically require them.

That's a good idea.

What if the attacker gained some bonus for attacking multiple systems at the same time...thus giving the attacker incentive to spread forces out which causes timers to come down at the same time, which causes defenders to spread forces out to defend. It would also potentially help smaller corps by giving them a chance to defend something in the way of the attacker potentially bringing less ships to any one engagement.

FT Diomedes: "Reaver, sometimes I wonder what you are thinking when you sit down to post."

Frostys Virpio: "We have to give it to him that he does put more effort than the vast majority in his idea but damn does it sometime come out of nowhere."
Fix Sov
#1390 - 2014-02-21 09:43:01 UTC  |  Edited by: Fix Sov
There's no need to give the attacker a bonus, at worst all we need to do is remove the ability for the defender to defend just the last timer and completely save the system (i.e. make it so you can't flip and rep the station, anchor and online the ihub and tcu all in one go) but have to go through stages to actually undo the damage an attacker has done, but I would prefer it if CCP went to a new system of smaller objectives which would be designed to come out simultaneously in as many systems as you can create timers so everyone has to pick and choose where they defend and where they attack (if at all).

The problem with the first option is that while it does fix the waterfall problem of today's sov system, it doesn't fix the grind-through-massive-amounts-of-EHP problem, but on the other hand it has the benefits of being a relatively minor change on an already established system while the second solution would be a rather drastic (but in my view, almost required) change, and if it's done right it could possibly lead to a possible round-the-clock fighting instead of today's prevalence of a fight a day.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Mournful Conciousness
Federal Navy Academy
Gallente Federation
#1391 - 2014-02-21 10:24:08 UTC  |  Edited by: Mournful Conciousness
Fix Sov wrote:
Mournful Conciousness wrote:
Once we get to the point where the most advantageous fleet size is 250 ships, and each grid of 500 ships is in a separate process, tidi will be a thing of the past.

This is unrealistic, for one simple reason: it won't work. There's always going to be some situations where 250v250 is just not going to cut it, and the only thing your suggestions of making warps and targeting etc fuzzy is going to do is make things annoying when they do exceed 250v250, and chances are high that what you'll actually do is make the lag problem worse because of the need to move players from one process (or worse, node) to another every time they warp outside of the grid they're currently at.

...


Sure I'm just a humble software engineer who happens to write massively scalable high performance computing systems for a living. What would I know about it?

Blink

Embers Children is recruiting carefully selected pilots who like wormholes, green killboards and the sweet taste of tears. You can convo me in game or join the chat "TOHA Lounge".
Fix Sov
#1392 - 2014-02-21 11:01:37 UTC
Mournful Conciousness wrote:
Fix Sov wrote:
Mournful Conciousness wrote:
Once we get to the point where the most advantageous fleet size is 250 ships, and each grid of 500 ships is in a separate process, tidi will be a thing of the past.

This is unrealistic, for one simple reason: it won't work. There's always going to be some situations where 250v250 is just not going to cut it, and the only thing your suggestions of making warps and targeting etc fuzzy is going to do is make things annoying when they do exceed 250v250, and chances are high that what you'll actually do is make the lag problem worse because of the need to move players from one process (or worse, node) to another every time they warp outside of the grid they're currently at.

...


Sure I'm just a humble software engineer who happens to write massively scalable high performance computing systems for a living. What would I know about it?

Blink

Well, for one your solution doesn't take into account the fact that fights larger than 250v250 not only can, but will occur, and if you're going to go to the lengths of redoing the way instructions are processed, you do it properly and in a way which can scale (for all intents and purposes) infinitely. Putting "each grid" in one process is not scaling anything any better than today's system is, because sov fights or impromptu cap fights don't happen on multiple grids, they usually happen on a single grid. And the "incentive" you're proposing should be added will just be an annoyance players will be powering through anyways, just like every other ****** mechanic players have been powering through the past 10 years.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Mournful Conciousness
Federal Navy Academy
Gallente Federation
#1393 - 2014-02-21 12:42:39 UTC
Fix Sov wrote:
Mournful Conciousness wrote:
Fix Sov wrote:
Mournful Conciousness wrote:
Once we get to the point where the most advantageous fleet size is 250 ships, and each grid of 500 ships is in a separate process, tidi will be a thing of the past.

This is unrealistic, for one simple reason: it won't work. There's always going to be some situations where 250v250 is just not going to cut it, and the only thing your suggestions of making warps and targeting etc fuzzy is going to do is make things annoying when they do exceed 250v250, and chances are high that what you'll actually do is make the lag problem worse because of the need to move players from one process (or worse, node) to another every time they warp outside of the grid they're currently at.

...


Sure I'm just a humble software engineer who happens to write massively scalable high performance computing systems for a living. What would I know about it?

Blink

Well, for one your solution doesn't take into account the fact that fights larger than 250v250 not only can, but will occur, and if you're going to go to the lengths of redoing the way instructions are processed, you do it properly and in a way which can scale (for all intents and purposes) infinitely. Putting "each grid" in one process is not scaling anything any better than today's system is, because sov fights or impromptu cap fights don't happen on multiple grids, they usually happen on a single grid. And the "incentive" you're proposing should be added will just be an annoyance players will be powering through anyways, just like every other ****** mechanic players have been powering through the past 10 years.


You can't scale fleet fight infinitely. There are a few bottlenecks:

1. client processing power (this is a showstopper)
2. client network bandwidth (also a showstopper)
3. mutexes
4. cost of sharing data between nodes (on a finite internal network).

A solution which that will work will not come through infinite scaling because I can tell you for a fact that there is no such thing in computer science. The communication costs and mutex stalls eventually outweigh the parallelism.

Neither can you put hard limits on player behaviour because it feels wrong and is unappealing.

What you can do is reward correct behaviour. If (for example) 250 in a fleet gives (say) double the actual effectiveness per person than 500 in fleet, then a rational FC will develop strategies around 250 in a fleet. Fleets of more than 500 will be inefficient, and a good commander will achieve twice as much by splitting his forces.

This is not actually unrealistic. You just don't see trench warfare anymore in real world conflict. It's too inefficient.

Once the fleet sizes tend to be smaller (through emergence, not rules), you can start to optimise your architecture around that.

I'll give you this first lesson in high performance computing for free...

Embers Children is recruiting carefully selected pilots who like wormholes, green killboards and the sweet taste of tears. You can convo me in game or join the chat "TOHA Lounge".
Fix Sov
#1394 - 2014-02-21 14:08:45 UTC
Mournful Conciousness wrote:
You can't scale fleet fight infinitely. There are a few bottlenecks:

1. client processing power (this is a showstopper)
2. client network bandwidth (also a showstopper)
3. mutexes
4. cost of sharing data between nodes (on a finite internal network).

1) Client processing power is pretty much irrelevant in this context, as no actual processing is done on the client side.
2) Same goes for this.
3) I'm talking about sending data to a completely different node for processing, I'm not talking about local multitasking.
4) You send the solar system data and a list of instructions to the processing node, the processing node processes the instructions and sends the modifications back. This is not going to be a bottleneck.

Mournful Conciousness wrote:
A solution which that will work will not come through infinite scaling because I can tell you for a fact that there is no such thing in computer science. The communication costs and mutex stalls eventually outweigh the parallelism.

Let me point you to the phrase "for all intents and purposes". I'm not saying it'd actually be infinite, but for all intents and purposes it would seem infinite, because it would scale beyond the point EVE will likely ever grow.

As for communication and mutexes etc, what I'm looking at is taking a batch of data, a set of modification instructions, sending that to the processing node, it crunches everything in the same manner things are processed now (only in smaller batches so it can finish its part of the job well before 1 second has passed), and it sends back a delta. I'm not talking about a huge amount of data, I'm not talking about a constant stream of data and instructions, in fact I'm not really talking about anything which would require controlling multiple processes accessing the same data, I'm talking about sending just enough data for each processing node to process the instructions it's given the responsibility of processing once a second, so the amount of data won't be a problem, and the amount of mutexes utilized for this will be negligible.

Mournful Conciousness wrote:
Neither can you put hard limits on player behaviour because it feels wrong and is unappealing.

What you can do is reward correct behaviour. If (for example) 250 in a fleet gives (say) double the actual effectiveness per person than 500 in fleet, then a rational FC will develop strategies around 250 in a fleet. Fleets of more than 500 will be inefficient, and a good commander will achieve twice as much by splitting his forces.

This is not actually unrealistic. You just don't see trench warfare anymore in real world conflict. It's too inefficient.

Once the fleet sizes tend to be smaller (through emergence, not rules), you can start to optimise your architecture around that.

I'd say your system sounds like it's much closer to putting "hard limits on player behaviour" than mine, as it would have to be made so that not only would adding another person to the fleet yield diminishing returns (which it does, since each person added is relatively speaking a smaller increase than the person before), but actually start to make it so going from x people on grid to x + 1 people on grid reduces the efficiency of everything put together, meaning you've effectively said "there shall be x people on grid, no more". My system doesn't care how many you put on grid X, it just punishes you if you end up putting too many people on grid X and the other guy attacks Y and Z instead, which is a lot more dynamic than "well you're now x people, that's all you can ever shove in there, now make sure those x people are in the biggest, most powerful ships you can use", which is what it sounds like your system would promote.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Lee Keldar
Deep Core Mining Inc.
Caldari State
#1395 - 2014-02-21 14:52:28 UTC
Nice,
one more Goon + change.

Mournful Conciousness
Federal Navy Academy
Gallente Federation
#1396 - 2014-02-21 17:33:59 UTC  |  Edited by: Mournful Conciousness
Fix Sov wrote:
...


again I think in principle we agree that fleets should be encouraged to be smaller.

the way you write about parallel computing suggests that you have thought about it but never done it.

your general thinking is correct, but I'm afraid there is devil in the detail.

Embers Children is recruiting carefully selected pilots who like wormholes, green killboards and the sweet taste of tears. You can convo me in game or join the chat "TOHA Lounge".
Fix Sov
#1397 - 2014-02-21 20:20:16 UTC
Mournful Conciousness wrote:
again I think in principle we agree that fleets should be encouraged to be smaller.

We do, the only difference is the fact that your system would impact every engagement, whereas my system would just have the potential for impacting every engagement.

Mournful Conciousness wrote:
the way you write about parallel computing suggests that you have thought about it but never done it.

No, I've done plenty of parallel computing.

Mournful Conciousness wrote:
your general thinking is correct, but I'm afraid there is devil in the detail.

Such as?

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Mournful Conciousness
Federal Navy Academy
Gallente Federation
#1398 - 2014-02-21 21:05:26 UTC
Fix Sov wrote:


When many people arrive on a grid, there are two things that break. One is the server node and one is the client. It's by no means unusual for someone's client to crash while trying to load up a grid.

There can be many reasons for this, but I suspect one of them is available resources (handles, GPU memory, system RAM and so on). One of the great uncontrollable variables in CCP's life is the client hardware. They have no way of predicting what machine you will be running on and what other competing programs are running at the same time.

Thus the client is a bottleneck, and a very volatile one at that. Distributing software to many thousands of users on disparate kit is fraught in of itself.

I just brought this up because you seemed to discount it as a bottleneck. This would be a mistake.

Keeping track of the geometries and positions of 4000, 8000, 16000 objects (pick a number, we're talking about a scalable game system here) requires a lot of memory, a lot of computations, and a lot of memory moves. The latter in particular are relatively expensive on PC architecture when compared to say, just computation.

Now turning to the server. I understand where you are going - you want to keep one canonical model of the system on a server, share that model and then instruct each server in the cluster to compute deltas to part of it, to be communicated back to the master copy. These deltas can then be filtered and sent selectively to clients.

But this master model, having been updated with the deltas (each requiring a move across a process boundary or a network segment) will then need to be send to each other compute node after the update cycle, otherwise their copies of the master model will be out of date.

So in effect, you're copying the entire model 'n' times per compute cycle where n is the number of compute nodes.

In addition, the computations per cycle will need to be ordered in some way, and worse, the causal domain of some actions is global (smartbomb, ecm burst, effects of cloaking, blowing up, and so on). There is some complexity around just *how* you would split the computation into parallel streams.

I submit that higher throughput can be achieved by using a high speed pub-sub bus, where each object is represented by a binary payload on a unique topic. Even then, there is some complexity in deciding how far to normalise your data representations of entities - you're trading off management overhead against wasted data transfer.

And then on top of all of this, you have to figure out how to fan out this data to the 4000, 8000 or more clients that are interested in the millions of updates generated in one large grid full of moving, shooting, exploding ships.

Scale it far enough and the NIC itself becomes a bottleneck, or your ISP - certainly the less-than-optimal ADSL connection that travels 4 miles over ancient copper to my 18th century barn conversion in the Welsh countryside.

I just wanted to point out that at no point have I proposed a multi-threaded, single box solution. The term mutex can be taken to mean any point at which two asynchronous jobs must share a resource, whether that is data, a network segment, a bus or a semaphore.

Now I also think you misinterpret my proposal for encouraging people into smaller fleets.

Let's take a simple example. Let's say that after 250 in a 'fleet' (how we define that is another issue), scan resolution for the entire fleet increases by 1% per extra ship. No more, no less.

What would be the effect?

The effect would of course be lock time, pure and simple. A smaller fleet would get faster locks, possibly able to arrive, lock, alpha something and warp off before the larger fleet could get a lock.

This is a reasonable proxy for the real-life difficulties in co-ordinating any large army. The bigger your information networks, the more difficult it is to communicate effectively.

This is why real armies break their organisations down into platoons, squads and so on, and why each element of that chain is equipped to act autonomously.

It is not reasonable that one fleet commander of 4000 is able to say "everyone shoot at the guy in the red shirt", and for everyone to instantly shoot the right guy. That's reasonable (just) for a squad of 10. In a fleet of 4000, that command would need to ripple through the fleet and finally arrive at the ears of the gunners, who would need to consult their navigation and targeting guys. There would be a delay.

Thus, fleet commanders can choose fleet size. 1, 10, 100, 1000, 10000. But there are diminishing returns for every ship above some threshold (arguably, why have a threshold at all?) It is entirely up the FC where he draws the line. I have imposed no hard limits whatsoever. It's just that if you bring 2000 ships your battleships will have the lock times of dreadnoughts. You either deal with that or split your forces. Your choice.

Embers Children is recruiting carefully selected pilots who like wormholes, green killboards and the sweet taste of tears. You can convo me in game or join the chat "TOHA Lounge".
Fix Sov
#1399 - 2014-02-21 23:08:19 UTC
I'm going to be snipping heavily just to get this to fit. If in danger or in doubt, read your own post and look for the anchor.
Mournful Conciousness wrote:
Thus the client is a bottleneck, and a very volatile one at that. Distributing software to many thousands of users on disparate kit is fraught in of itself.

I just brought this up because you seemed to discount it as a bottleneck. This would be a mistake.

The reason I "discount it as a bottleneck" is because in all the years I've been playing, and I've been in most of the really big fights the game has seen, including the last really big fights such as 6VDT, HED, B-R etc etc etc, and at no point has the client been anywhere near being "the bottleneck". The bottleneck has always been the computational capacity of the server, and that has been hilariously woeful every single time. I'm not saying there won't ever be a time where the client won't be the bottleneck, but right now it's nowhere near that mark, so until the server architecture has been improved sufficiently to the point where the client is actively being a bottleneck, I'm going to discount it as a bottleneck.

Mournful Conciousness wrote:
Now turning to the server. I understand where you are going - you want to keep one canonical model of the system on a server, share that model and then instruct each server in the cluster to compute deltas to part of it, to be communicated back to the master copy. These deltas can then be filtered and sent selectively to clients.

But this master model, having been updated with the deltas (each requiring a move across a process boundary or a network segment) will then need to be send to each other compute node after the update cycle, otherwise their copies of the master model will be out of date.

So in effect, you're copying the entire model 'n' times per compute cycle where n is the number of compute nodes.

If we're going for the pure separation of the data node and the computational nodes, then yes, the entity data in the solar system would be sent once per computational node. You can muddle this by adding filtering logic so a computational node only receives the entities which the instructions would affect, i.e. movement, initiate warp, target, firing and getting hit etc, but this would put more stress on the data node and would probably be what I'd consider a premature optimization which could very well be more of a hindrance than a help. I'd go with sending all the entity data to every computational node the data node decides it needs to split all instructions across just to get all the computation done within the timeframe of the tick and see what the network bandwidth utilization was as you crank up the number of clients and number of servers used.

And there's nothing to stop us from using a processing instance on the same node as the data node up until you exceed some sort of limit, either be it for the physical node itself, or the number of people/instructions in a given solar system, just to cut down on the cross-network chatter.

Mournful Conciousness wrote:
In addition, the computations per cycle will need to be ordered in some way, and worse, the causal domain of some actions is global (smartbomb, ecm burst, effects of cloaking, blowing up, and so on). There is some complexity around just *how* you would split the computation into parallel streams.

This isn't really complex, though. I'd boil it down to a 2 stage process, where the first stage is at tick x, where actions are performed, and where the second stage is at tick x + 1, where the consequences of an action is evaluated. That way you can take situations where f.ex 2 people are shooting eachother, and both of them deliver the "killing shot" on tick x, and both of them blow up on tick x + 1 because tick x + 1 notices that their health are below 0. Alternatively there's the slightly more complex situation of 2 guys being in an engagement and one decides to warp off while the other decides to warpscramble the first guy. Tick x sees the first guy not being scrambled, so the processing tick sees that he's at the right speed, angle and not flagged as warp scrambled and thus applies the "in warp" flag, and at the same time he gets the "warpscrambled" flag from the other guy's instruction going through. The complexity here would lie in tick x + 1 looking at the guy warping and going "well he's got the in warp flag set, so the warp scrambled flag is irrelevant".

Mournful Conciousness wrote:
I submit that higher throughput can be achieved by using a high speed pub-sub bus, where each object is represented by a binary payload on a unique topic. Even then, there is some complexity in deciding how far to normalise your data representations of entities - you're trading off management overhead against wasted data transfer.

And then on top of all of this, you have to figure out how to fan out this data to the 4000, 8000 or more clients that are interested in the millions of updates generated in one large grid full of moving, shooting, exploding ships.

I see no reason to make any changes in the communication between the clients and the eve cluster as a result of the internal changes to the way the cluster does processing.

Mournful Conciousness wrote:
Scale it far enough and the NIC itself becomes a bottleneck, or your ISP - certainly the less-than-optimal ADSL connection that travels 4 miles over ancient copper to my 18th century barn conversion in the Welsh countryside.

I strongly doubt we'd see things like the NIC, the ISP or ADSL becoming a bottleneck any time soon, but if it does then chances are we're looking at fights which make today's major fights look like playscraps between kittens. I, for one, have no problems with that, because that means that EVE has become vastly more popular than it is today.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.
Fix Sov
#1400 - 2014-02-21 23:15:35 UTC
Mournful Conciousness wrote:
Now I also think you misinterpret my proposal for encouraging people into smaller fleets.

Let's take a simple example. Let's say that after 250 in a 'fleet' (how we define that is another issue), scan resolution for the entire fleet increases by 1% per extra ship. No more, no less.

What would be the effect?

The effect would of course be lock time, pure and simple. A smaller fleet would get faster locks, possibly able to arrive, lock, alpha something and warp off before the larger fleet could get a lock.

This is a reasonable proxy for the real-life difficulties in co-ordinating any large army. The bigger your information networks, the more difficult it is to communicate effectively.

This is why real armies break their organisations down into platoons, squads and so on, and why each element of that chain is equipped to act autonomously.

It is not reasonable that one fleet commander of 4000 is able to say "everyone shoot at the guy in the red shirt", and for everyone to instantly shoot the right guy. That's reasonable (just) for a squad of 10. In a fleet of 4000, that command would need to ripple through the fleet and finally arrive at the ears of the gunners, who would need to consult their navigation and targeting guys. There would be a delay.

Thus, fleet commanders can choose fleet size. 1, 10, 100, 1000, 10000. But there are diminishing returns for every ship above some threshold (arguably, why have a threshold at all?) It is entirely up the FC where he draws the line. I have imposed no hard limits whatsoever. It's just that if you bring 2000 ships your battleships will have the lock times of dreadnoughts. You either deal with that or split your forces. Your choice.

The problem with your solution is that you can't differentiate between one side bringing 1 fleet of 256 guys, and the other side bringing 8 fleets of 256 guys, so unless you've got an amazing way of determining who's on which side and increasing that side's locktimes (and no, standings won't cut it), the only thing you'd end up with is both sides having absolutely **** locktimes and no real impact on the effectiveness of either side, which means people'll just grin and bear it and keep bringing more people than the other side, just like now.

No, I still think that the proper solution is one which is rooted in treating the cause of the huge blobs, i.e. the sov system. Well, that and the way cap fights and supercaps tend to bring tidi, which lets everyone and their dog derp into the same system, but I'd settle for "just" sov being fixed.

The current sov system is too heavily reliant on the defender saving systems by stuffing as many people as possible into the system for the final timer, instead of incentivizing attacking (and defending) multiple systems at the same time by splitting their forces into multiple fleets and using actual intelligence/strategy. This must change.