On October 4th an update was released to SteamVR. It included changes in direct display driver component which is utilized by VRidge. The changes weren't documented/reflected in OpenVR interface. We've seen those changes in SteamVR's beta channel and after it started flickering there (few weeks ago) we posted the issue to SteamVR forums. An unfortunate series of events caused this changes to go into live SteamVR channel anyway.
The result was preeeeetty bad. Everyone experienced flickering in random intervals making VRidge totally unusable with SteamVR. Less than 1 hour after the changes went live we contacted SteamVR team through more channels to ask for help.
The SteamVR team was very responsive but it takes some time to update the live system. We were amazed that they pushed the update with a fix into their live stable channel on such short notice (everything was fixed in less than 24 hours). Some companies attempt to wall themselves off from 3rd party support and modding but Valve is doing the complete opposite with this kind of open attitude. We always recommended OpenVR/SteamVR for aspiring VR developers when they asked us how to start VR gamedev and we will continue to do so. It's nice that some companies care about VR's future overall.
What we learned
It's hard to have a system working 100% of the time when it relies on multiple 3rd party components (SteamVR, GPU drivers, Windows version, OS components, router config & rules, Android OS flavors, phone chipsets, Direct3D, etc). It is difficult, but there are still ways to mitigate the critical situations like this.
We will add some sort of emergency alert to the desktop client so we can notify about the possible compatibility issues. Sometimes all you need is to update some 3rd party components (like video driver) and everything starts working again. We can write this kind of important updates on our blog/facebook/twitter but over 90% of our users stay in client without checking the social media. A simple way to push a message to the client from our servers with a link to a detailed article can do wonders. Many other companies already have something like this (Battle.net or LoL launchers come to my mind).
We will also follow SteamVR's beta updates more closely now. If there's a chance of this kind of stuff happening again we'll start preparing alternative fallback ways. There is a way to capture SteamVR game surface with a slightly increased latency that could have worked even after the Oct 4th changes. Degraded performance while we are working to fix it "the right way" is better than app not working at all.
What we were doing in September
We've been working on behind-the-scenes modules and refactoring some code. This is in preparation for future Android 4.x version and iOS. This also allows to see clearer performance picture which is very helpful to locate Android performance problems (Samsung jitter mostly).
We were updating part of the platform so we can add more servers. Currently all our online service are running on single machine which works well enough but it sometimes need maintenance/updates or simply just fails due to some unforeseen event. Having one more gives us some more breathing space.
It's been a while without a feature update. There are a few unsolved problems that we are prioritizing now - Samsung jitter issue and motion controller black screen. Planned features are fake VR (playing regular flat games in VR), sound streaming and iOS version. We want to squeeze in an updated video encoder (H265/HEVC, double the performance of current one) somewhere in the meantime.
We know that some of you really want to know when we'll add those but giving ETAs often causes devs to go out of our way to meet the deadlines instead of doing things "the right way". This can work short time but over a longer period it leads to spaghetti code and long terms bugs that are hard to fix. All we can say is that our current short term priority is Samsung jitter & motion controller black screen and we really hope to see progress on these in October.