So in the latest
schedule roadmap, Network Bind Culling (CIG totally made that up btw) has been moved - again. This time from 3.1 (scheduled for end of Mar - maybe) to 3.2 (end of June - maybe)
Needless to say, the tribe - who actually don't have a fucking clue what that optimization actually means or entails, are upset.
https://www.reddit.com/r/starcitizen/comments/7zrndp/so_bind_culling_pushed_to_32_dammit/9 months ago:
13 months ago:
15 months ago:
Those chuckleheads are in for a surprise.
1) I am 99% certain that CIG won't be able to implement it. At least not as planned. They will probably half-ass it, and it won't make any difference either way. As a result, both performance and networking will continue to suck and be sub-par. But they're
totally making an MMO though.
2) I wrote about this
MONTHS ago. Yet they're somehow shocked its been moved again. It was first scheduled to be coming in 2.6 - back in 2016.
DEC 2017
http://dereksmart.com/forums/reply/6078/OCT 2017
http://dereksmart.com/forums/reply/5949/JUL 2017
http://dereksmart.com/forums/reply/5501/As I've written before, CIG is once again just making up bullshit names for standard tech so that it looks like they're actually inventing new things. And backers get to foolishly think they're paying for innovation.
Whatever it is CIG is wanting to do, here is a 2014 article that explains
Network Traffic Culling.
UPDATEClive has responded on SpectrumWe decided it was necessary to push Bind Culling back for the following reasons:
1) Progress has been slower than we had hoped, partly due to taking longer than anticipated to convert the last few places in the code that were using old-style Aspects and RMIs to Serialized Variables and Remote Methods, and then completely strip those legacy systems from the network code. That was a necessary step because we didn't want to have to implement Bind Culling for both the old and new systems. I'm not embarrassed to tell you there was some dancing and a few air-punches on my part when the last line of that old code was deleted.
2) There wouldn't have been enough time left before 3.1 for the network and gameplay programmers to deal with the issues we’re expecting the introduction of Bind Culling to cause.
3) Bind Culling would result in clients streaming entities in and out based on distance, but without asynchronous Object Container Streaming it was always a gamble whether the resulting synchronous loading stalls would be worse or better than what players experience now. The plan was to get Bind Culling working, see what the impact on player experience was and then make the call whether to turn it on for 3.1.
4) Range-based Serialized Variable Culling was our backup plan in case Bind Culling didn't make it into 3.1. You may remember that we were working on SV Culling for 3.0 but that it wasn't quite ready in time. Well, it was the first thing we tackled when we came back at the start of the year, and has been working in our development branch for several weeks now (not the branch 3.0.1 was taken from). SV Culling already gives us a lot of the performance gain we would expect from Bind Culling so the urgency for the later has dropped significantly.
5) The network team is needed for other tasks that have increased in priority since they were first added to our schedule.
