Game Discussions Star Citizen Discussion Thread v12

[Agony_Aunt]

If it ends with a BANG, it's more like Manhattan one.

I suspect, release or no release, it will end with a big whimper.

 

[kilvenny]

I am fascinated by the fact that in eight years we still only have one system. That makes no sense since two systems would provide all the mechanisms to expand out to the 100 systems promised. I think their problem is that currently they have no way of moving between two systems without a massive loading screen similar to the initial loading screen. All these "miracle techs" they keep inventing are trying to overcome that inherent problem. Trouble is they made much of the fact that there are no loading screens and none of the instance hand shakes like ED has. The problem is made worse because a lot of the stuff is happening server side so they need a mechanism to move it.

 

[Tippis]

I am fascinated by the fact that in eight years we still only have one system.

Well… part of a system. Bits of it are missing and other bits shouldn't even be there but have been added because they were available. So maybe ½ ± ¼ a system.

 

[Navigare Necesse Est]

https://www.reddit.com/r/starcitizen_refunds/comments/j96grd

Source: https://www.reddit.com/r/starcitizen_refunds/comments/j96grd/grey_market_refund_milestone_letter_from_the/
$250,000 ÷ 182 = $1,374 "refunded" per backer

Grey market "refund" my rear. It's just handing off to some unwitting soul or worse.

 

[Viajero]

Trouble is they made much of the fact that there are no loading screens and none of the instance hand shakes like ED has

The thing is, if I understand this correctly, that those ED instance handshakes are actually de facto “server meshing”. The instances are hosted at the player PCs but the actual decision to place and move players and content from one to another is already “server meshing”.

Instances will always have a player cap. In the case of a twitch sim game those caps are rather low. Even games such as War Thunder or DCS that use dedicated private servers to host instances cough their lungs out when you get above 30 players. First person shooter games which in theory may be less demanding such as BF or CoD are limited to around 60. Squad is limited to 100.

SC will need to limit actual player count in the same manner. The “thousands” of players often referred to by CIG hyperbolically is probably rather related to a central server view about who is where similarly to the ED galaxy server. In all cases players will need to be partitioned to smaller groups and instances if they concentrate in the same locations. And moving from one instance to another will always require some kind of instance hand shake like EDs.

 

[Navigare Necesse Est]

The thing is, if I understand this correctly, that those ED instance handshakes are actually de facto “server meshing”. The instances are hosted at the player PCs but the actual decision to place and move players and content from one to another is already “server meshing”.

Instances will always have a player cap. In the case of a twitch sim game those caps are rather low. Even games such as War Thunder or DCS that use dedicated private servers to host instances cough their lungs out when you get above 30 players. First person shooter games which in theory may be less demanding such as BF or CoD are limited to around 60. Squad is limited to 100.

SC will need to limit actual player count in the same manner. The “thousands” of players often referred to by CIG hyperbolically is probably rather related to a central server view about who is where similarly to the ED galaxy server. In all cases players will need to be partitioned to smaller groups and instances if they concentrate in the same locations. And moving from one instance to another will always require some kind of instance hand shake like EDs.

And CI have been misleading about the "thousands" of players for years.

 

[Firkrayt]

There actually exists a technology for realtime battles involving thousands of players. Has nothing to do with Christopher and Ci-G though.

 

[Skizomeuh]

Would this be a good time to repost those SC manual pages where he compares the creation of a highly derivative WC-in-jets with the making of the cinema-history landmark Apocalypse Now?

Actually it looks more and more like a Lost in la Mancha but with The Room. Star Citizen: The Disaster Con-Artist.

 

[Tippis]

SC will need to limit actual player count in the same manner. The “thousands” of players often referred to by CIG hyperbolically is probably rather related to a central server view about who is where similarly to the ED galaxy server. In all cases players will need to be partitioned to smaller groups and instances if they concentrate in the same locations. And moving from one instance to another will always require some kind of instance hand shake like EDs.

…and before anyone jumps in with more talking points from CI¬G — a company that has demonstrated no working knowledge of multiplay gaming in general and networking in particular — no, “server meshing” will not solve that problem. In fact, it could just as likely to make it worse if it was attempted.

The problem is fundamentally one of keeping the instance and everyone in it updated with the information needed to see the world around them. The stupendous but wholly ignorant idea that has been floated on top of CI¬G PR is that, through meshing servers, you get around the processing limits implied by such a division by having different servers deal with subsets of the workload. Double the number of players = four times the communication needed (because it's an O(n²) problem to keep everyone updated) = mesh four servers to deal with it… right? Except no, because this assumes that player 1 will only deal with instance-partition 1, and ignores that the whole point is that they also see players 35, 88, and 159 in the other three partitions. So all those updates still need to happen, and all partitions need to be aware and updated on the state of all players. Perhaps not the entire state, so some gain could be had by filtering out and not sending that data all over the place, but for the exact same reason, that data would not be a huge part of the workload to begin with. And that would count against the increased overhead of keeping the meshing going and figuring out what other partitions need and need not be updated with.

They're trying to parallelise an asymmetric and stateful problem that therefore cannot be parallelised, and they're seemingly ignoring the overhead costs even if that could be done.

So server meshing would “solve” the problem of not being able to deal with 2× the players (i.e. 4× the work) in a single instance by spinning up three more servers and making them deal with 15× the workload. Why 15 rather than just 4? Because, again, the work can't be cut cleanly; each of the four servers will still need to know most of the things about those other players — not all, but most, and especially the parts that already create the majority of the workload — and a whole bunch of syncing overhead on top of that. Congratulations, instead of having 1 server be 300% over capacity, your server meshing has made 4 servers be 275% over capacity. That's a whole lot of overworked servers for no gain (everyone is still stuck on an overworked and stalled server) when the intelligent and sensible solution — and therefore the one that CI¬G is fundamentally, almost genetically, incapable of producing — is to decide on a hard limit to the partition size and… you know… design a game that operates within those limits.

But that requires forethought; it requires planning; it requires letting limits drive creativity; it requires saying “no”. It will never ever happen with this company and these people in charge.

 

[Agony_Aunt]

…and before anyone jumps in with more talking points from CI¬G — a company that has demonstrated no working knowledge of multiplay gaming in general and networking in particular — no, “server meshing” will not solve that problem. In fact, it could just as likely to make it worse if it was attempted.

The problem is fundamentally one of keeping the instance and everyone in it updated with the information needed to see the world around them. The stupendous but wholly ignorant idea that has been floated on top of CI¬G PR is that, through meshing servers, you get around the processing limits implied by such a division by having different servers deal with subsets of the workload. Double the number of players = four times the communication needed (because it's an O(n²) problem to keep everyone updated) = mesh four servers to deal with it… right? Except no, because this assumes that player 1 will only deal with instance-partition 1, and ignores that the whole point is that they also see players 35, 88, and 159 in the other three partitions. So all those updates still need to happen, and all partitions need to be aware and updated on the state of all players. Perhaps not the entire state, so some gain could be had by filtering out and not sending that data all over the place, but for the exact same reason, that data would not be a huge part of the workload to begin with. And that would count against the increased overhead of keeping the meshing going and figuring out what other partitions need and need not be updated with.

They're trying to parallelise an asymmetric and stateful problem that therefore cannot be parallelised, and they're seemingly ignoring the overhead costs even if that could be done.

So server meshing would “solve” the problem of not being able to deal with 2× the players (i.e. 4× the work) in a single instance by spinning up three more servers and making them deal with 15× the workload. Why 15 rather than just 4? Because, again, the work can't be cut cleanly; each of the four servers will still need to know most of the things about those other players — not all, but most, and especially the parts that already create the majority of the workload — and a whole bunch of syncing overhead on top of that. Congratulations, instead of having 1 server be 300% over capacity, your server meshing has made 4 servers be 275% over capacity. That's a whole lot of overworked servers for no gain (everyone is still stuck on an overworked and stalled server) when the intelligent and sensible solution — and therefore the one that CI¬G is fundamentally, almost genetically, incapable of producing — is to decide on a hard limit to the partition size and… you know… design a game that operates within those limits.

But that requires forethought; it requires planning; it requires letting limits drive creativity; it requires saying “no”. It will never ever happen with this company and these people in charge.

Yup. server meshing can solve the total "server" cap to some extent but not the instance cap.

 

[Viajero]

There actually exists a technology for realtime battles involving thousands of players. Has nothing to do with Christopher and Ci-G though.

From what I can see this technology helps when it comes to partition the “universe” into smaller cells that can handle the entity/players in them. The engine partitions the space as required to cope with the data handling limits for one instance/cell. I.e. it does not magically increases those limits, it “simply” subpartitions as required to stay under those limits.

I wonder how it is managed when one entity/player moves from one cell to another existing one. There still needs to be some kind of “cell/worker” hand shake anyways no?

 

[Agony_Aunt]

I am fascinated by the fact that in eight years we still only have one system. That makes no sense since two systems would provide all the mechanisms to expand out to the 100 systems promised. I think their problem is that currently they have no way of moving between two systems without a massive loading screen similar to the initial loading screen. All these "miracle techs" they keep inventing are trying to overcome that inherent problem. Trouble is they made much of the fact that there are no loading screens and none of the instance hand shakes like ED has. The problem is made worse because a lot of the stuff is happening server side so they need a mechanism to move it.

Part of the problem is CIG seem intent on making all the systems together one giant map, rather than discerete areas like ED does it. There is no gameplay benefit to be gained from this, only technical headache. Womhole jumps should be a mini-game loading screen, not actual traversal between two joined maps. That just leads down the road to insanity.

 

[Agony_Aunt]

From what I can see this technology helps when it comes to partition the “universe” into smaller cells that can handle the entity/players in them. The engine partitions the space as required to cope with the data handling limits for one instance/cell. I.e. it does not magically increases those limits, it “simply” subpartitions as required to stay under those limits.

I wonder how it is managed when one entity/player moves from one cell to another existing one. There still needs to be some kind of “cell worker” hand shake anyways no?

I presume it works by throttling the data from one cell to another so you get less "fidelity" looking across a cell border at another player.

But this could make battles happening at the intersection of cells problematic.

I guess how they could handle it would be to have dynamically forming cells with limits. So as battles progress the cells are constantly shiftng. But then what happens when too many players congregate too close together?

Disclaimer: Did not read the article so could be talking a load of poo poo.

 

[Firkrayt]

I wonder how it is managed when one entity/player moves from one cell to another existing one.

I guess how they could handle it would be to have dynamically forming cells with limits.

EVE and Minecraft mechanics are quite different from SC, so I can only guess: space can be divided into instances basing not on strict grid, but on amount of players in given area, and those areas can overlap. Sure, it produces overhead and race condition, but as long as your cloud is big enough and you aren't doing cybersports, it is solvable. Not by Ci-G though, it's too difficult for them.

They're trying to parallelise an asymmetric and stateful problem that therefore cannot be parallelised, and they're seemingly ignoring the overhead costs even if that could be done.

Surely iCache will solve that problem. Something that is named by prepending a small "i" to its name can. not. fail. Right? Right?!

 

[Tippis]

I wonder how it is managed when one entity/player moves from one cell to another existing one. There still needs to be some kind of “cell/worker” hand shake anyways no?

That is indeed one the most fundamental problems that CI¬G (or any of the theorycrafters they have in tow) have never been willing or able to discuss, much less answer. There has always been this notion that, yes it will work perfectly to have a ship that fills a server to capacity fight other ships that fill a server to capacity because each will be its own instance and then they will mesh together seamlessly so it looks like there are N:ty times more players than the servers can deal with and that's fine because no-one will ever actually see all players at once.

…except, that's the problem right there: players. They will get ideas. Ideas such as, hey, why don't all of us (who fill up a server) hop over into the gap (that is handled by a server that is filled up with ships) and board that other ship (that is handled by a server filled to capacity by that crew). So how do you allow that to happen without splashing a “sorry, you can't board your enemy — instance is full”, or, hell, just a “sorry, cannot eject — due to instance limit, you just exploded instead” message across the screen? Do you always reserve half the server capacity to account for players getting player ideas?

But then, how do you solve the next problem, where three other ship crews get the same idea? Everything is at half capacity now, but only as long as people transition in an orderly manner to their next destination that will then be filled to capacity, and we're right back at square one: “sorry, you cannot board your enemy — they are already being boarded, and the instance is full” and “sorry, can't eject — too many did that already… just explode instead”, respectively. Do you kick the can down the road and put the servers at quarter capacity to deal with that problem? But now, none of your capacity-filling ships can be filled. And no matter how far you kick that can, ye olde goonrush will still be a favourite tactic among players looking to break the servers. You've made DDoS:ing a straight up in-game tactic rather than some external metagame strategy, and you're paying an awful lot for all that unused capacity that still won't keep that from happening.

 

[Firkrayt]

So how do you allow that to happen without splashing a “sorry, you can't board your enemy — instance is full”, or, hell, just a “sorry, cannot eject — due to instance limit, you just exploded instead” message across the screen?

Ah, that one is easy. You just seamlessly transition to BSOD.

 

[Navigare Necesse Est]

That is indeed one the most fundamental problems that CI¬G (or any of the theorycrafters they have in tow) have never been willing or able to discuss, much less answer. There has always been this notion that, yes it will work perfectly to have a ship that fills a server to capacity fight other ships that fill a server to capacity because each will be its own instance and then they will mesh together seamlessly so it looks like there are N:ty times more players than the servers can deal with and that's fine because no-one will ever actually see all players at once.

…except, that's the problem right there: players. They will get ideas. Ideas such as, hey, why don't all of us (who fill up a server) hop over into the gap (that is handled by a server that is filled up with ships) and board that other ship (that is handled by a server filled to capacity by that crew). So how do you allow that to happen without splashing a “sorry, you can't board your enemy — instance is full”, or, hell, just a “sorry, cannot eject — due to instance limit, you just exploded instead” message across the screen? Do you always reserve half the server capacity to account for players getting player ideas?

But then, how do you solve the next problem, where three other ship crews get the same idea? Everything is at half capacity now, but only as long as people transition in an orderly manner to their next destination that will then be filled to capacity, and we're right back at square one: “sorry, you cannot board your enemy — they are already being boarded, and the instance is full” and “sorry, can't eject — too many did that already… just explode instead”, respectively. Do you kick the can down the road and put the servers at quarter capacity to deal with that problem? But now, none of your capacity-filling ships can be filled. And no matter how far you kick that can, ye olde goonrush will still be a favourite tactic among players looking to break the servers. You've made DDoS:ing a straight up in-game tactic rather than some external metagame strategy, and you're paying an awful lot for all that unused capacity that still won't keep that from happening.

Good point. I always imagined the ships in instance determine that. But multicrew is a problem there, when people can join up at a later stage. I guess you simply can't join the session then. Unless you are in the same instance and maybe choose to respawn at the multicrew position. So you wouldn't reserve such slots but rather have total player limit. And when that limit is reached the slots are closed be it MC or not.
What with the boarding I cannot say. I have no idea how the "map instance" and "ship instance" interact - if they are indeed separate.

 

[Viajero]

That is indeed one the most fundamental problems that CI¬G (or any of the theorycrafters they have in tow) have never been willing or able to discuss, much less answer. There has always been this notion that, yes it will work perfectly to have a ship that fills a server to capacity fight other ships that fill a server to capacity because each will be its own instance and then they will mesh together seamlessly so it looks like there are N:ty times more players than the servers can deal with and that's fine because no-one will ever actually see all players at once.

…except, that's the problem right there: players. They will get ideas. Ideas such as, hey, why don't all of us (who fill up a server) hop over into the gap (that is handled by a server that is filled up with ships) and board that other ship (that is handled by a server filled to capacity by that crew). So how do you allow that to happen without splashing a “sorry, you can't board your enemy — instance is full”, or, hell, just a “sorry, cannot eject — due to instance limit, you just exploded instead” message across the screen? Do you always reserve half the server capacity to account for players getting player ideas?

But then, how do you solve the next problem, where three other ship crews get the same idea? Everything is at half capacity now, but only as long as people transition in an orderly manner to their next destination that will then be filled to capacity, and we're right back at square one: “sorry, you cannot board your enemy — they are already being boarded, and the instance is full” and “sorry, can't eject — too many did that already… just explode instead”, respectively. Do you kick the can down the road and put the servers at quarter capacity to deal with that problem? But now, none of your capacity-filling ships can be filled. And no matter how far you kick that can, ye olde goonrush will still be a favourite tactic among players looking to break the servers. You've made DDoS:ing a straight up in-game tactic rather than some external metagame strategy, and you're paying an awful lot for all that unused capacity that still won't keep that from happening.

Indeed. This reminded me of one of those CIG videos with Tony Zurovec a year or 2 ago, where on this particular topic he handwaved something along the lines of (paraphrase) “to prevent the issue of too many players attempting to concentrate in a single spot we will limit player numbers with in lore reasons to avoid immersion breaking situations”.

Even CIG seems to acknowledge the fundamental problem and the need to have quite strict player caps. CR can not seem to bring himself to be honest with backers and prefers to double down on the “thousands of players” fallacy presumably to keep hype and therefore funding up.

 

[Agony_Aunt]

Indeed. This reminded me of one of those CIG videos with Tony Zurovec a year or 2 ago, where on this particular topic he handwaved something along the lines of (paraphrase) “to prevent the issue of too many players attempting to concentrate in a single spot we will limit player numbers with in lore reasons to avoid immersion breaking situations”.

What on earth did i just read?

Erm... ok, so the lore reason is... erm... after the outbreak of covid in the 21st century humanity operated a strict law regarding the number of people who were allowed to congregate in a certain region of space or on stations. Covid kept evolving until it achieved sentience and basically agreed not to infect humans again as long as they didn't turn up in groups greater than 50!

How's that Chris?

"Works for me!"

 

[Agony_Aunt]

Sarsa from SA did a FUD report... erm, i mean trip report on 3.11 (and hope FD's filter does the needful)

3.11 Trip Report:

It's time for the once-per-major-patch descent into Star Citizen. Since there was really nothing new or interesting about this patch, and most normal activities were going to be constrained by people attempting to PVP for that 50-unique-kills reward, I decided that my self-imposed mission this time would be to find the Big Benny's Stonehenge landmark that apparently they give you a free helmet now just for reaching.

Right off the bat- I was forced to pick one of the three big cities as my spawn point. I did so and was treated to about 60 seconds of a blank screen- it seems load times are growing out of control even on an SSD. When I finally woke up in the pod, I was clipped halfway through the geometry and most of the textures in the scene had not loaded in properly. After another 30 seconds or so the scene finally managed to render itself, and I began to struggle through the now all-too-familiar process of exiting the wankpod, taking the elevator down, getting on a train to the spaceport, running to the terminals to spawn a ship, getting on another elevator to get to the ship, etc etc. As I did all this, what really struck me was how bad the performance was. I remember Loreville on the week that it went live- stuttering and feeling like the whole server was going to die any second. Two or so years later, and it's actually worse than it's ever been. My frame rate the entire time I was in the city was in the single digits. The sky was flickering bright green and back with every other frame. NPC's were still standing on chairs, and the general feeling of lifelessness that permeates everything in Star Citizen had only increased. I accidentally sprinted too fast while heading up some stairs and clipped right through them, falling on my face underneath the metal surface- thankfully I escaped that one without having to suicide and start over.

Sadly, I don't have a lot of funny or interesting anecdotes to bring back from the rest of the trip, which was just pure tedium. I got my ship launched without any further incident, then spent 30 minutes flying across the system to Yela, and another 20 minutes trying to triangulate the position of the stupid landmark I was hunting for based on distance to the planet and various other spots. It was nothing but flying in straight lines for 50+ minutes, without me even touching the controls, so opportunity for bugs or really anything to happen was pretty limited. I only actually found the drat thing in the end because there were some dead spaceships parked outside it that showed up on my scanner when I was in the general vicinity- otherwise I'd probably have quit after wandering around for a half hour. There were no other commandos on the structure, and it was exactly as advertised- a bunch of vending machines stacked up. Thrilling. I received no message for finding it, and there was no hat in my inventory, so I guess we'll see if I earned it or not.

Final thoughts: I mean, it seems more stable, so good for them on that front? But it's still a big empty world with nothing to do. They've clearly made some stabs at improving the HUD and other minor quality-of-life changes like the guided exit paths when taking off from the city, but honestly these made next to no difference because the vast majority of gameplay is still sitting and not doing anything while your ship travels. Longstanding bugs like the QT drive never activating right the first time the player hits it are still alive and well. Even-longer-standing bugs like the planetary textures just completely failing to load are also doing quite well. Performance sucks so bad that the game is basically unplayable in the major hubs- I know my video card is old but it's never struggled like this before. The only other players on the server were all gathered in a corner somewhere to shoot each other for the 50 kills holiday helmet, which in hindsight was probably a way more interesting use of my time than sightseeing. The anti-fun gremlin that usually appears at the last minute to ruin my missions did not rear his head this time, but then- I didn't have a single minute of fun in the entire trip. I also didn't interact with any system more complex than "Push w to make ship go forward," largely out of fear of some negative consequence. So perhaps his work here is done, after all.