Star Citizen, Squadron 42 & Theatres of War News, Guides, Videos & Gameplay by BoredGamer


Welcome to some more Star Citizen with a Summary of the Reverse the Verse – Object Container Streaming OBS Livestream that went over parts of OBS coming in 3.3 and beyond and what we can expect from the technology.

Object Container Streaming (OCS) has touched every part of the game and taken a long time to develop. At it’s core it’s the intelligent loading/unloading of assets & entities to optimize performance & remove the need for any loading screens or pauses.

SC Alpha 3.3 is focusing on client Side OCS (rather than Server Side which is also required), in the future Servers will benefit from the tech too AND the implementation of OCS in 3.3 is certainly not the final version, lots of testing and iteration is required & more supporting tech / dialing in, so set expectionations accordingly.

OCS will load and unload content based on it’s size and distance from you. Planets are loaded in further away (obviously at reduced LODs) than ships for example which are smaller. This will also be used for SQ42.

Bind Culling is in a feature complete state, it aides in the server side control of OCS on client PCs. They also need to make sure that objects, damage, door states and changes are the same & synchronized for the server and all clients.

The Server decides what to load and unload for the client, distant objects will receive fewer updates from the server.

They can use Headless Clients, that simulate a player being logged in to test OCS underload and in different circumstances.

The entire game, every object has been updated to support this OC/S which is one of the reasons they had to rebuild the Stanton System from 2.6.3 to 3.0. There is going to be bugs!

All parts involved with OCS needed to be made & spawned “thread-safe” (basically functioning correctly during simultaneous execution of multiple threads & be able to share data with one or more threads at any given time)

This also required them to convert all of the LUA code to C++

With some of their tests they have had “drastic performance improvements” BUT we won’t know anything until we have a build in our hands, lots of things could change & new systems could cause issues. Server load will be heavier in the short term until they get the Servers using OCS efficiently themselves, which will be in a future iteration of OCS as it requires some additional tech they are working on. Client PC Memory usage will be lower, which is great news & will allow them to add more things in the Verse.

Initial Load times are also down.

There are general improvements when it comes to resources being used so CPUs will also benefit.

So the initial version of OCS won’t benefit from the Server Side OCS improvements that the technology will eventually bring, such as more players per instance. Though server caps will be increased once Server Performance does improve.

Once completed Server based OCS will see the server standby OR loadout areas of a system or Object Containers that are not currently needed.

There are no limits to the amount of containers that can be placed in each other.

A Star System (so Stanton) is the parent/root object container that all others in that area will be placed in. So a planet, building, space station, room can all be individual containers.

Typical bugs with OCS will be crashes, objects popping in/out or jittering.