My point is the load would be compounded heavily when the session data was pushed over to a different node (in a dynamic system). How much that is, I’d imagine only CCP woudl know. But the migration of the data would most definitely be a noteworthy event. In this case, you’ve incurred the cost of instantiating it on your existing node, as well as the cost of moving it to the new node. Yea the load is lower after, but that migration will be heavy.
Do you… do you know what CCP’s servers are at the moment? If not, I’d encourage you to do a little reading. They’ve got some wonderfully beefy servers. To quote the dev blog:
For those who don’t know it, the database servers are two Lenovo x880 dual CPU servers with 768 GB RAM. We knew that Lenovo does have a special clip designed for the FLEX platform where you essentially dock together servers, much like GPU SLI, so when this clip was put in place and we fired up the server, the windows operating system see’s 4x CPUs and 1.5 TERABYTES of RAM!
As I said in the OP, they’ve already scaled up. It’s time to scale out.
Sorry, forgot to reply to you. Wasn’t ignoring you, just got a little triggered lol.
5000 is an arbitrary number. I was under the mistaken impression that 9-4 was 5k players in system… apparently it was 6k.
There would be no change in admittance to how it is now… whether 6 players, 6000 players, or 30000 players in system.
The difference is exclusively in what server hardware you’re on, which is based by where you are in space rather than whose fleet you are in. In my example, there would be 4 servers running the system (rather than 1). With 4 servers running it, and players spread between those 4 (by being in 4 different locations in the solar system, all by their own choice or FC orders, fighting for objectives or just being disruptive eve players) you can remove the underlying problem of simply too many players on a single server.
To shoot down the armed and fully operational battlestation you have to also shoot at the shield deflection generatores on the moons? As long as you hit the DPS limit on the generators the resists on the citadel drop from 80% to 50%?
Large citadels have generators on the moons in the same system, extra large citadels have generators on moons in the same constellation? No need for medium and small ones. (And no more extra large citadels in WHs?)
The defenders gain nothing by actively controlling the node. They’ll just be two groups, one defending the citadel and the other roaming around moons trying to kill the attackers
The attackers would need to be VERY spread out. This makes them weak and easy targets. If they don’t need to spread out, the goal of spreading them out isn’t accomplished. I chose 4 objectives (1 of them being not optional, the structure itself) because it’s enough to really reduce the load without causing too much spread (because really, would you deploy 10 ships to each only to have a roaming gang of 50 come and wipe them out one at a time?). If the number of moons with shield gens were capped, that would help with this line of thought.
The DPS cap is rarely an issue, so reducing resists wouldn’t help at all for 99% of battles… you’d see people spread out. In the case of the keep in 9-4 had TiDi not tanked it for them, they’d have easily hit the damage cap. Yes they could spread out, but there’s no real incentive to spread out because the DPS cap will be capped regardless.
Get the ■■■■ out of this thread. Toasters don’t belong in the game, let alone in citadel fights.
Unless you said toasting but meant controlling. This would follow FW mechanics more than it would follow toasting. You would fight for and then maintain control of the node by shooting people at the control point until only your side was there. Whoever chose to interact with the control point at any time during the conflict, could do so.
I’m not seeing how the node load would be anymore for grid-nodes than it would be for systems. i.e. your 100 ships jumping example, if it had been from one system to another instead of one grid-node to another.
Could the optional objective points be in other systems? Or could a fight system spin up some sorts of wormholes off of it with an optional objective in each one? I think the wormhole idea is kind of dumb game-wise, but it could implement your idea without any real changes.
Because you need to maintain session persistence. It’s like if you’re migrating a virtual machine to a different host.
If it’s powered off (akin cold session change such as jumping gates) you don’t have to shove the memory over to the host… just give the new host a lock on the disk files.
If the VM is powered on (akin to a “hot” session change from one node to the other during/immediately preceding combat) you’ve got to shove allllll of the active memory from the current host to the new host, and then do a cut-over, in addition to the differential on the disk files while you do the disk file lock swap.
As a quick-and-dirty fix, yes, 100% this would do it. I agree game-wise you’d have a lot of people grumbling (plus there’d be the same lack of visibility you have when you’re poking your nose into a wormhole, with the same camping-the-entrance potential) but as a technical solution to the load, this would do it.
Is there a reason they can’t have it on when no one is in it?
Why are we moving the nodes? How many servers does CCP have, how many reinforced servers do they have? I will example with one node/server, but the idea is the same with less hardware, just with some physical servers hosting more than one node.
Node 1 - keepstar - reinforced server, no matter what we do this is still be where the most action is, it gets the best.
Node 2-4 - optional objectives - (reinforced) server, these are known locations that CCP knows will be part of the fight, the grid-node is up and running from the start, pilots might come and go, but these grid-nodes stay up.
Node 5-X - empty nodes - server, these are spun-up grid-nodes waiting for some pilot action, they are set up as unassigned grids. While in warp to a currently off-grid location, one of these grids becomes active as that location, it doens’t need to be spun-up, just told what its coordinates are. If the number of active empty nodes is less than the allotted number of empty nodes, a new one is spun-up. When the last ship leaves one of these nodes, it gets recycled, wrecks written to the DB to be restored after the battle, because ship graveyards are cool, then it’s reset to an empty node.
The assigning of empty nodes vs creating a new node could even be handled in a way that it tries to guess the load the node might get: FC warps fleet to bookmark-> use empty node. guy running for his life in a pod-> create new node.
Just because normal wormholes have only one hole to any other system, doesn’t mean our special wormholes have to, give them five or ten holes between the base system and the wormhole containing the optional objective; or have a public cyno on the optional objective, either side can warp to it; there are a few different ways around it. (For the multi wormhole bridges option, they’d have to be clearly identified so you know where you will end up on the other side, and they shouldn’t require any sort of scanning to find them. (The idea isn’t to emulate existing wormholes, but to use the existing tech to make the battles better. The optional objective wormholes should also connect to each other.)
Different example. Imagine you’ve got two notebooks. One of them full of notes, the other empty.
You need to take half of the notes out of one notebook and put them into the other. The only way to do that is to copy the information from one book to another.
The instantiation process is simple… it’s probably so trivial that it’s not even worth mentioning. But I’m not talkinga bout the instantiation… I’m talking about what happens when nodes 5-X need to be used.
Say for example, two groups of pilots on node 5. Group one probes down group two, they warp, and start fighting. No undue load here yet - in fact we’re better off because they’re all on node 5 while nodes 1-4 are all ticking along nicely.
Group one however springs the trap and lights a cyno. In come 100 carriers. The internal logic says “oh we just broke the threshold, it’s time to put these pilots in a new node”. Except you can’t have pilots on the same grid in different nodes. So it drops the entirety of groups one and two, including those 100 who just session changed in, to node 6, so that node 5 can be free for the red-cycled cyno that group 1 left behind when they warped to group 2.
That act of transferring active combatting players from node 5 to node 6 (as the carriers who just cynoed in triggered the dynamic logic) will be an ungodly disruption to the fight.
Okay, still assuming one grid-node per physical server, just because it’s easier to talk about. So each node is a grid is a server.
Two groups of pilots can’t be on node 5, only one is, the other group is on a different grid/node. Now there are two groups on on grid on node 5. Then 100 carriers cyno in to the grid-node, the node doesn’t move servers or anything, it’s just like any other gate/cyno jump. No need to move a node.
When there are no players on a grid, anything in it, gets written to the database or moved to the main node if it needs to be scannable. That grid-node then forgets what grid it is and waits to be reassigned.
Assuming 5 servers and 3 secondary objectives, all the dynamic grid-nodes could be on one server, and the other 4 servers each handle one of the main combat points. Maybe gates would also have dedicated nodes. The pint I’m getting at here is that you would never need to move a node between servers, and unless someone slow boats from one grid to another, the only time to have to move pilots from one grid-node to another is while they are in warp/jumping.
While splitting the server load among grids or quadrants could be a creative method for improving performance, I’m still not sure if it would be quite enough to be able to turn these battles into an exciting event. There are only two ways I can think of to alleviate the issue.
One method would be to implement a mechanic that actually applies pressure to the player base to reduce the number of ships that are being fielded. (through lore, you could say that too many ships cause subspace damage)
-One way of doing this would be to apply a system, or grid-level debuff that causes increasing levels of damage to a ship while they are active in an overloaded area or system.
For the other method, you could spread the battle across multiple instances of the same system. (Say that having too many ships fractures subspace causing multiple realities)
-Each fleet or fleet subdivision, along with many system assets would be spread across the instances. Each instance could be kept at a manageable server load level, and a timer will count down to determine the next subspace shift in which players will be randomly re-allocated to another split instance together with their fleet group (or maybe even completely at random)
-Certain ships or ship modules may be able to allow some players to shift between instances (cloaks?)
-Lighting a cyno will cause you to appear in all instances.
Nothing help without redesigning pvp mechanics. TiDi existing itself is a problem.
5000. Even with 2000 nightmare begins. It’s just inappropriate (and unacceptable for manies) to play the game in this conditions.
Only making pvp mechanics better will help for example - removing tracking, velocity, signature factors.
The event itself is at best unexciting. Citadel bashes are literally boredom in liquid form. Citadel bashes on TiDi, you’ve got liquid boredom on an IV drip.
By redesigning the entire mechanic of how the fight works to encourage players to fight for multiple objectives, the prevalent strategies “turtling” and “stalingrading” are simply ineffective. This alone makes the fights a little bit less of an exercise in tedium, because now you’ve got a fluid battle with a lot of to and fro happening. It becomes muuuuch more dynamic. Which is good.
I’m not going to say it’s “more fun” controlling the objectives… but I will say that it’s “more fun” when you are PVPing without lag.
You’ll have vanguard groups striking objectives hard to break entrenched forces, while heavier ships follow in behind them to help secure and hold the objective. You can’t just have heavy ships though, because when one objective starts to fall, if you want to hold it you’ll have to move a lot faster than battleships/caps can move.
This is anti-sandbox.
So I bridge in 500 somethings with smartbombs, and alpha their fleet?
All anti-sandbox. The cyno part would also probably be impossible without starting from the ground up.
Which would literally break pvp? Congrats, everyone’s in battleships with arty because there’s no tracking/sig/etc. We get perfect application, and can now literally volley massive swaths of the ships on grid every 20 seconds.
How about you don’t insist on blobbing in the first place and do some Fozzie-Sov node entosising instead?
Have citadel nodes appear in all systems of a region and “conquer” them with the entosis thingy. Lots of small fights and gate camps and little to zero tidi.
Because nothing says fun like orbiting a node in a gimped ship shooting it with your space wand, right?
I do agree that using fozziesov mechanics (with different grids on different servers) would help with the blob issue and thus reduce tidi, but… it’s just so boring. And you’ll basically just see roving hordes of combat cepters blapping toasters. You don’t need to control the grid, you literally just land, blap, and warp. Slippery petes, ■■■■, even just bombers. 75 of them decloak, volley with torpedos, and warp. There goes your toaster.
I’d far rather a small number of control points that remain static, so as to encourage conflict. Said control points exist for the duration of the fight, allowing for lots of time for strategy to form. Said control points don’t need a ship doing anything to them, they just need to be turned on or off, after which they’re the way they are until someone changes them.