So I made this post on SA, in response to Shitizen dreamweaving...
D_Smart posted:
The lols will come when backers see that both serialized variables and network traffic culling get implemented (LOL!) and they still have piss-poor network performance. In fact, I have to believe that the engineers KNOW that it won't make much difference, and that's why they keep kicking the can down the road. The day they release a build with that stuff in there, and it's "meh", we're looking at 3.1 lols like we did when 3.0 Jesus Patch landed. And we're still loling at that one.
It could be even worse than that. They could be genuinely trying to cull traffic, and it could help, but the lack of concrete design makes the task impossible. The same reason why nothing else works.
For example, lets say you wanted to do something simple, and not update a player about other ships that are > 5km away.
Network lead: Hey Chris, we're putting in distance culling and we need to know how the long range scanning system will work. What rules decide if a ship can be detected in a scan? How often must these updates happen? What information shows up in the long range scan; position, rotation, shields, energy signatures, what? Is the scan continuous or is it a one-shot thing? By the way, you told us last week that you wanted long range torpedoes. Does the player need to see ships that can fire these? Also, should the Acme Indefatigator particle beam show up past 5 km?
CR: (Handwaving commences)The long range sensor shows you the location and the general composition of other ships and asteroids if you want more information you can focus on one area to get higher resolution but other ships might pick up these emissions you also have passive sensors that might see a spike in energy readings from weapons fire or ships exploding far away but this depends on your own heat and RF output and objects that are blocking your scan the torpedos are cloaked but if you have a SMXGT-17 military sensor you can see them in your frontal arc whenever the torpedo makes a turn but if your wingman has a transponder you can see his ship anywhere a data-link signal can reach which relays all the information about his contacts to your sensor display remember the datalink is blocked by hydrogen clouds unless they have the dish array get it done by next week because we need it for the anniversary sale of the... (handwaving intensifies until airborne. CR tumbles down the hall bouncing off the walls and ceiling)
Network lead: Right away.
First of all, let me offer this emote to you for bringing up something that I keep forgetting about.
Now to the fun (dev) part.
Even though my 5km range was hypothetical, it serves to highlight precisely how they have fucked up this whole thing by - you guessed it - doing a 64-Bit precision hack.
I wrote about that, amid much derision by our Shitizen friends.
09/26/2017:
Ben Parry11/22-2015:
my article11-20-2015:
Here on SANow they've got huge numbers. And it's space.
Because ANY implementation of a radar scan HAS to know the position of an entity being scanned, that location data not only needs to be obtained, stored, and updated - in real time - but that CANNOT be done without actually having accurate position data for the entity being scanned.
You can't have an object that is 6km away, not show up on scanners that have a range of 5km. Sure, the object may exist, but the scanner has to not only cull out that info, but it HAS to rely on ACCURATE position and state changes for that object - REGARDLESS - of whether or not it is "in scope".
Why?
Fucking :lol: ....because, consider this. ObjectX (target in the world that's likely to be scanned)
pos1.client1: 4km from ObjectX // receives data
pos2.client2: 5km from ObjectX // receives data
pos3.client3: 6km from ObjectX // receives no data
Now imagine that there are 8 clients at pos1 and 8 at pos2; all those clowns in their chariots are going to need info about ObjectX.
It doesn't matter that another 8 clients at pos3 aren't going to get anything; and the performance is negligible to the extent that it's not even noticeable - at all.
The fact remains that in a situation where you have to plan for your max clients (e.g. 24 clients in a capped Star Citizen instance) to ALWAYS be within range of EVERYTHING at ANY TIME, you haven't actually solved the problem with serialized variables or network traffic culling. No. All you've done is mitigated the issue to the extent that you are hoping that your clients remain spread out over time.
And that is why these games have instances. Which are client-capped.
And that is why, even in games with the best multiplayer, when you have a group of clients in generally the same place, doing all kinds of shit, there are performance issues from both rendering and networking aspects.
So imagine a group of SC clients in their chariots doing combat with less clients within their "bubble". Then something (combat, trade run etc) forces them all to be within a 5km range of each other - and the radar has to be accurate etc. If it's not, guess what happens. Yes, you guessed it. They would not see objects on radar, they would go to a last known location and nothing be there etc.
Trust me when I tell you this: The minute those devs enabled this, EVERYTHING is going to break.
And here you were concerned that they can't do ramps or functional doors.
Like I said, I have to believe that the devs KNOW what's going to happen and that it's going to break more things and then NOT solve the problem. That's why they keep kicking this crucial can down the road.
ps: object container streaming is the same bullshit.
Then I was reminded of this...trust me, it's hilarious AF
Back in 2014 when Chris and backers were figuratively intoxicated with dreams they thought they would be able to code all of this in non-Speed of light communications. I of course heard about it was after the fact but that still stands out to me as one of the most absurd dreams.
2014 Chris: "in our universe there is no FTL communication. Basically communication happens at the speed the ship can travel or a radio wave can travel in system."
2014 Chris: "The way that the communications are gonna work is that it travels our in-fiction communication's speed. Which means that when you're in-system and someone beams a message, it gets beamed at the speed of light, and it gets beamed to a relay station, or a message station. This is in the structured universe where the UEE runs it and there's a lot of infrastructure. So one of these stations is right by a jump point so it gets all the information and then it will launch out a message drone or a messenger ship. It goes through the jump point to the other side, where there's probably another relay station, it's collected, then the data gets beamed across to another relay station and so-on and so-forth if it has to go multiple systems."
Not surprisingly that didn't work out, I think a dev said something or all the talk about Spectrum made it clear. Communications were going to be instant even across long distances.