Since some people still were asking, here's a little boil-down to as much as I understood how these systems work.... Hope it makes sense...if you have anything that needs to be added or corrected, feel free. :wink: Object Container Streaming: Step1: Space is being divided into different containers which are in a hierarchy, so that you'd have something like a file system on your computer: Solar system / Planets / Moons & Space Stations / Outposts on those Moons / rooms and hangars in those outposts / Space ships in the hangars / boxes in the space space ship Each level has different kinds of information, varying in details. For example: If you are flying around a planet, you'll see the space station that is in orbit right in front of you. But because you can't see the inside, your computer won't get updates about what's going on on the inside. It's a different container and you can't see it anyways. Step2: You are in space, you only have a certain range at which you can see objects because the further they are away, the smaller they become. OCS knows how big an object is (different sizes of space ships, space stations, satellites, etc.) and it knows at which distance that object will be only 1 pixel in size on your screen. Because you don't see anything that is smaller than one pixel, OCS streams the object out as soon as it would be smaller. If something gets in range to appear as a single pixel, it is streamed in. Due to this, smaller ships, like the M50 or an Aurora, are streamed in and out visually at shorter distances than bigger ships, like a Starfarer, and Idris, a Hull C, etc. Step3: Your radar usually picks up objects way before you can visually see them. Therefore, OCS streams in SOME information about the object your radar picks up. That means, your Client will get infos like position, movement, what type of object it is, etc. But it will not load the ship's body mesh, textures, etc. because you can't visually see it yet. Same with space stations, if you can't visually see them, your Client doesn't get the information about how it looks. It only gets position updates and so on. This saves Client performance as all these information won't be stored in your RAM, because you don't need them. And it saves a bit of CPU performance because you don't have to process all that data. ---------------------------------- Serialized Variables: SVariables is just what it says - variables that are serialized ("numbered") so that a program can look at single lines in the code and compare them to the package it sent before. Those variables are things like your ship's name, paint job, fuel amount, speed, position, orientation, damage state, shield states, ammo count, number of passengers, etc. Every piece of information about you or your ship or any object in the game is a variable. --------------------------------- Network Bind Culling: Culling or "hiding" unecessary data actually is combining both the OCS and the Serialized Variables as follows: Step1: OCS tells the server what kind of data is being sent to you about an object that is within radar or visual range. Step2: After that data has been transmitted, the Server looks at the variables and figures out wether something has changed since the last update or not. Step3: IF data has changed (for example position and orientation of a ship), the Server then sends ONLY those values that changed to the client with the next update. Everything that did not change (paint job, ship name, damage values, etc.) doesn't need to be updated, so it is not included in that package, it is "culled out". It trims down the size of the data packages that need to be sent between Server and Client, which should give us a more stable network, not necessarily faster, but more stable. --------------------------------- Example - Exploration: Now if you are exploring space and you are trying to make long distance scans, you are ACTIVELY sending the server a request for information in a certain area (which is defined by where you point your scanners and how far they reach). IF something is within that scanner area, the Server will check through OCS if you can see the object visually or if you only need a certain amount of data to be transmitted. Maybe you'll only see an EM signature and not yet know what it is, then you'll get closer and scan again and you'll get more information. Until you reach a point where you can visually see it, then all the information is available to you. At the same time, Serialized Variables makes sure that you are not getting any information twice. So if your object is static, you will not receive the package that includes the position, because that value did not change. ---------------------------------- Example - Beacon: If you have a beacon, you only get it's signal when you are within range. That means, you are inside the area where you can receive the signal. OCS gives you the position of that beacon and maybe a message (like if it is a boye that marks a jump point). Your PC only processes that information, no data about how it looks, it's damage states, etc. When you get within visual range of that beacon, OCS gives you the visual data as well. Serialized Variables again excludes the position data from the packages that are exchanged between server & client, because those values did not change.