Upcoming Events! Community Event Calendar

Relay Replay: Sep 3rd - 7th Written Monday 10th of September 2018 at 03:43am by Shiver_Bathory

Erris and Shiver summarise the developments for the week in Star Citizen

Calling All Devs

  • CIG have been talking internally about Tessa. Currently her voice lines are not hooked into any facial data or animations. One particular point CIG want to address is what to do with the existing lines. I.E Do they want the actress to do lip synch to them. In addition to some other technical issues they need to overcome. CIG do want to bring her back though

  • If a player isn’t in the cockpit of their ship and a new ship is detected on radar, CIG want an audible alarm that you could hear across the ship to alert you and allow you to respond. The on board computer will likely pipe in other audio alerts/information as well

  • Calix was working on a prototype a long time ago that would have different status reading from around the ship and then displayed on various monitors using the render to texture technology. CIG envision a security MFD that allows a player to open/lock/close all the doors, set gravity etc

  • If a cargo bay is being depressurised an alarm will sound. Unless it is specifically turned off that is, be it for security reasons or even if it just because you are doing it so often that it gets on your nerves

  • CIG have not got a definite decision on where the first jump point will navigate to. A few factors come into play such as, where can they build, what can they work on while still bringing on new tech etc. There have been talks on it, so it is on CIG’s radar, but they do want to get the Stanton system a lot more built out first  


  • Wala and Lyria are two of ArcCorp’s moons that are currently being worked on. Wala is a simple barren moon with geode minerals outcropping from the surface. Lyria is a ‘dirty’ ice planet with deep crevices and cryo-volcanoes

  • Drop off lockers are for collecting or delivering cargo. Work has gone into making the lockers the right size for a player to interact with. They’re awaiting the Missions Team to implement them into the game

  • A player may find themselves having to use the lockers on a delivery mission, the locker will check to see if you have a delivery record, if a player doesn’t have one or they are using the wrong locker they will be denied access. If a player is at the right locker it will open the shutter up and ask the player to drop the item on the shelf

  • The Design Team is making progress on the major location signage for Loreville to aid in navigation and add context to the city’s transit areas

  • The Banu Defender has been completely blocked out in white box and interior has entered the grey box phase


  • OCS is a huge part of Star Citizen being one huge play area without loading screens

  • Right now OCS is client side with server side OCS coming after. This will mean that players will be using less resources when playing Star Citizen resulting in a smoother experience

  • Due to the sheer amount of variety in PCs the performance improvement with OCS is a best guess, this being said the client and server will only load what you need, reducing the performance footprint and memory use

  • OCS judges an object by its size as to if to load it. For instance Levski would load up very far away but a small ship would not. The system will take into account your distance from the object which is handled server side

  • When first envisioned OCS consisted of three steps. Bind culling decides to unload entities based on distance, making them essentially not exist to the player, but the server will make you aware of a marker that is relevant to you but it is just that marker not the actual object which is far less drastic of a drain on a system. Rather than actually rendering the objects as they do now, it will in essence be the client and server just communicating smaller amounts of data where applicable i.e. on your radar or as a remote marker. Serialised variables are the packets of data that represent the objects of interest to you as a player. For example: a player has a marker for a planet but they are very far away from the location. The player still needs to keep track of the marker but bind culling would have made the planet ‘not exist’, rather than load the entire planet and render it client side, which would hit performance, the data of what the object is and its current location is sent, this is a serialised variable, essentially keeping track of objects and their location and if the player needs to know about them and at what frequency if at all the item needs to be updated for the player.

  • OCS is also needed in Squadron.

  • A-sync entity loading is a part of OCS. Currently when an item is spawned it is done on the main thread, which will make the main thread blocked until that entity is spawned, A-sync will allow that process to be moved onto a background thread, allowing other entities to be loaded until it is ready to spawn on the main thread. Bind culling enables this information to be sent as a smaller data package to the server/other clients

  • Right now the team is working on putting all the tech together and working with each other and in game.

  • Testing OCS involves a lot of travelling around, but also testing changing states for one player without changing things for another. Looking for lots of edge cases as well. Things are fine, but occasionally there’s a stall when it say brings Levski in.

  • An example used was if you and a friend are in a dogfight, and the friend gets far enough away, that dogfight will be culled so it’ll no longer be in his system. Now if you drop a cargo crate while he’s gone, and then he comes back, the cargo crate will have to show to him as being in space, etc… There are many different states of things that have to propogate. Becomes even more difficult when there are people all over space too, not just in one place.

  • They’ve been using zombie characters to fill the system with, so they can see what the load is like on the server when there are people everywhere.

  • When OCS does go live, there *will* be issues. There’ll be things they’ve never seen, problems they haven’t been able to see in QA and so on. It’s all for testing. There are many things also being updated with OCS, so there’ll be many issues, as OCS hits almost all of SC - everything has to be converted to work with it.

  • OCS is not a magic bullet. There will still be network improvements, still be optimization improvements.

  • More players per instance is not linked to OCS. improvements from OCS are *only* client side. There’s actually more server side traffic due to OCS.

  • Server-side streaming requires more tech that they don’t have yet;

  • OCS shouldn’t affect view distances, though there *may* be some slight pop-in

  • Might take less time to load the game. Also, some people who couldn’t load the game before might now be able to load it, since it doesn’t need as much memory anymore.

  • There’s no limit to the number of containers they can have. There’s the System container, then planetary containers, then, say, a Grim Hex container, then containers for each of the shops, etc…

  • Bugs you might see - missing entities, pop-in, stalls as you approach stations, etc…

  • OCS for SQ42 plays into the size of the maps.

  • OCS has been a company-wide multi-year process. It’s touched every single element of the game, and continues to. And it won’t be done with this patch either, there’ll always be more to add. Server-side streaming is next, and there’s more beyond that too.


Director of EU Operations

The consummate English gentleman, Shiver Bathory can be found posting news to The Relay, when not making puns that is.When not typing furiously at his keyboard he enjoys hanging in chat with The Relay community and every once in awhile can be found playing some game or another. Every Wednesday on The Base he hosts Dead Air - An alternative and extreme metal music show