We’ve already covered the Americas Minor, next up is the Minor for the CIS region where the two tickets to Major will be hotly contested. The Counter-Strike played in the region has always been criminally underrated. Besides the powerhouse Natus Vincere and Gambit, who surprisingly won PGL Major Krakow last year, there really hasn’t been any CIS team that has garnered the respect of western audiences.
There were voices before the ELEAGUE Major Boston crying that the region had too many qualifying spots and that one of them should be transferred to the more competitive European region. However the doubters had to eat their words once the Major came around as the two sides that came out of the CIS Minor; Avangar and Quantum Bellator Fire shocked the eSports world alongside Russian Vega Squadron with several big scalps and upsets.
Quantum Bellator Fire, or QBF for short, even managed to reach the Champion’s Stage as a completely unknown team. That’s a feature almost unmatched in CS:GO Major history. The point to take from all this is that these CIS teams should not by any means be underestimated as there’s a lot of talent in the region waiting to reveal itself.
The Eastern European squad HellRaisers are participating in the CIS qualifier this time around and seems to be clear favourites to take the first place and move on the the Major itself. They had a different line-up going in to the ELEAGUE Boston Major earlier this year, which forced them to go through the European qualification system, and that is a completely different ball game. It’s riddled with talented teams and their journey ended even before the minor.
HellRaisers has always been a respected team within the Counter-Strike scene but they have not looked this good since late 2014 with their Markeloff and s1mple line-up. Their two new emerging stars ISSAA and Woxic have looked great under ANGE1’s leadership so far and they won’t settle for anything less than a win in London next week. 3/2 for HellRaisers as outright winners at Betway is worth considering.
Their group in the Minor is by far the easier of the two, they’ll face the Ukrainian Pro100, the relatively unknown team PLINK-TECH and Belarusian Nemiga. None of these teams should be able to take a map of HellRaisers if they play their own game. Recent form suggests that HellRaisers should cruise through the group stage.
As if HellRaisers weren’t lucky enough with the draw, news recently arrived that Nemiga will not be able to participate in the Minor due to visa issues. Unfortunately the appeal to British authorities did not change their decision.
The Kazakh Avangar team surely raised some eyebrows in Boston when they, as a team almost unheard of, beat FlipSid3, Misfits and Renegades. They were a few rounds away from knocking out Liquid to advance to the next stage but fell short in overtime. None of the players has been poached by the bigger teams of the region and many expect them to be able to qualify again.
However they’re in the tougher group with the Russian organization Team Spirit and it’s far from certain that they’ll end up as group winners, which means they’ll probably face HellRaisers in the first round of play-offs. Avangar is a better team than Team Spirit on paper, but it doesn’t show in the previous encounters between the two sides. The Russians have managed to win the last four, three of them in a very convincing manner, making them a solid pick at top eSports betting sites.
Much indicates that it’s mainly these three previously mentioned teams that will battle it out for the two qualification spots and it might very well be Avangar that receives the short end of the stick for this tournament.
Considering Team Spirit’s strong record against Avangar a place in the grand final looks very possible for the Russian team and a 2/1 bet on them reaching the finals at bet365 could be great bet. The CIS region always has strong teams that are relatively unknown. But in this tournament it’s hard to see how any team outside of the top three that I’ve mentioned would qualify. 9/4 for Team Spirit to win the group might also be worth considering at bet365.
Hi, Inexplicably, this error has started occuring in my directinput update() function: //This line.... result = m_mouse->GetDeviceState( sizeof( DIMOUSESTATE ), &m_mouseState ) // .. produces this result = 0x8007000c The access code is invalid. This happens for both mouse and keyboard. I traced this back to a problem during init, hr = m_keyboard->Acquire() produces E_ACCESSDENIED. The rest of the init code returns S_OK, like DirectInput8Create and CreateDevice. I thought maybe a previous error meant the devices has never been released, but it still occurs after a reboot. I've not been meddling with the input side of the app, so am surprised to see this error suddenly occur... ok, not that surprised :) Thanks for your help Simon
First, it would be wise to have your DI initialization routine return an error if anything fails in it, rather than continuing anyway and later find out the hard way in your "update" procedure. At any rate, I would try to run the keyboard sample which comes with the SDK. If that runs fine, then try to rewrite your code to more closely resemble the sample code. Hope this helps.
I have checked my DI init routine against the SDKs and its identical. I still get that E_ACCESSDENIED error on the acquire call!
Things like this dont tend to "just happen" - as hard as it might be, back-tracking through *ANY* recent changes to your code or system - however irrelevant is usually your best starting point. It's not happened recently, but I have killed my code via Windows Updates / Driver changes occasionally. Something I was doing is no longer valid with the updated system software = Kamboom!
You just need to put the acquire in a loop. Because some errors like this just happen. Usually because the device get lost or something like this.
as in the SDK sample, which seems to have recovered the error. The second format is for mouses with loads of buttons I believe.
This topic is 2181 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.
Try calling [font=courier new,courier,monospace]glGetError()[/font] after every OpenGL call to see if any of them are creating a problematic/erroneous state. I also came across this, which may be of some help.
thanks for the reply, but getting the errors didn't help (no errors), still crashes... however what you linked in gave me an idea, and I replaced the texture binding call with:
and this solved the problem. So I believe this is a driver bug. It shouldn't crash under any circumstances, right? Edited November 24, 2012 by Yours3!f
Well... not necessarily. For example, if you give it a garbage pointer or size and cause it to commit an access violation, it's free to crash.
if after calling glTexParameteri( GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE ); you did not get error with glGetError then it is a driver bug that it is not reporting error. Because you were binding 2D texture, but operating with cubemap texture.