You need to be logged in to your Sky Poker account above to post discussions and comments.
You might need to refresh your page afterwards.
Sky Poker forums will be temporarily unavailable from 11pm Wednesday July 25th.
Sky Poker Forums is upgrading its look! Stay tuned for the big reveal!
One for the Area51ers to investigate/debate
*other opticians are available
Comments
Whilst playing tonight in a tournament I noticed the following...
I was short stacked so was looking for a spot to get my chips in and d/u. The hands are irrelevant (even though I was I massive fav v a big stack and we never win those races blah blah blah). What is strange is the lobby update. I had the table open to the left and the lobby open to the right. I shoved aipf and after a call by another player, the flop was dealt. When the turn card came down (took ages while the RNG made sure I was a gonna blah blah blah), the lobby updated with my exit position BEFORE the river card!! I still had outs on the river btw.
Please guys, before I am blasted by the normal crew, try it for yourselves and see if it happens to you aswell...........
Still voted the top option though as ya need some support
I dont have the lobby open now when im all-in because of this.
any chance that this could happen in the lobby..before u go all in
Evidence of potential foul play? It could of course just be latency in the system response - it takes longer to process the graphics on your PC than numbers in a table. However, perhaps it's sufficient grounds for the AGC to examine the matter in detail to satisfy themselves that nothing untoward is going on . . . . silly me, that'll cost a fair bit to engage an independent software house to examine the underlying code and write a report outlining their findings.
It does, of course, show that although the shuffle may be completely random (I know for a lot of people the jury's out on this one), other resultant actions within the overall software are not, and are pre-determined, ie something happens because the system knows the outcome of a hand before it's played out.
A not unreasonable concern to expect SkyPoker to issue a statement over?
Last week I was playing a sat and we were down to the last 7 players. I had both my table (obv) and the other open. On my table 2 players were still playing out the hand whilst at the same time, we had all been moved to the other ''final'' table. For a few seconds 3 of us were on both tables at the same time. Spooky but nothing untoward as the outcome was known before the last card was dealt.
The course of play isn't pre-determined - it can't be. The only known factor are the cards to come. If an all-in situation between 2 players occurs then the outcome is at that point known regardless of the displayed cards. If two players go all-in after the flop then the outcome is known before the turn and river cards are dealt. The software can perform the functions of dealing the turn and river cards whilst at the same time moving the remaining players (including the eventual winner of the hand) to the next table and updating the lobby.
If this game had side bets, ie you could bet on who knocked who out, the arrangement described by posters above, where the results were known and reported before the hands had been played out, could be a real problem.
The situation of seeing the result before the deal is completed is not ideal but it's not suspect in any way.
Yep fixed once the shuffle is completed.
Only experience I have had like this is in dyms, where the chat box tells me the bubble has burst prior to the board running. Which I used to see frequently.
I always assumed this was lag between visual board and chat box i.e money and points awarded.
This thread does add another interesting layer however.
Not saying this is the case obv as this would be IMPOSSIBLE to prove.
So as far as im concerned all is well and im happy xx
"I got my money in as an 80/20 dog on two occasions and the most statistically probable event occurred."
To be honest, even if it had been the other way around, and you lost 2,3... even 4 all ins having started as an 80% favourite...well...I'd have to say &*%~ happens! You're looking at a small sample size, it's happened us all and it hurts... it really hurts.
However, you have to be able to look at it without emotion and place it in the context of all your all-in hands from the last 1000 games. Read up on G-bucks/Sklansky dollars. This is a way of calculating the difference between your expected gains (or losses) and your actual gains based on the equity you had in a particular hand. To simplify it, just calculate the Sklansky dollars based on the hand you held and the hand your opponent held (calculating G-bucks uses ranges, difficult on skypoker without tracking software) when all the chips went in. Over time, all the heaters, all the beats, should eventually converge in line with statistical expectations.
I went through a couple of weekends where I just "knew" that JJ, QQ or KK on the bubble of a DYM spelled disaster for me. I lost 7/8 all-ins with KK pre flop, only one of which was against a favourite (AA), and the majority were underpairs or suited connectors - not even rag aces. It hurt, and I was down about 8 buy ins, but on the other side my graph started to go up again and along the way I had A9 suck out on AK etc.
I've yet to notice the "pre river card exit" but it would rub salt in the wound and raises questions on server side latency issues and possible vulnerabilites.
Lets say for instance we have 3 computers networked togeter.
PC1 sends a time stamped signal to PC2 & PC3 it then calculates the round trip of the signal. If it takes 3 seconds to send and receive a signal from PC2 but takes 4 seconds to send and receive the signal from PC3, it will time stamp it with a difference of 1 second.
"If it did not calculate and adjust the time between PC2 & PC3, then PC2 would see the information 1 second before PC3. So by calculating and adjusting the time delay both PC's are essentially able to see the information at the same time. Although in theory it did not happen that way.
These time stamps are adjusted periodically to enable them to be as accurate to real time as possible.
In the real world of computing and software this is much much more complex than the explaination I have used above and I have really stripped it to its bare bones just to give you an understanding of how it works.
So please don't shoot me.
Here is an Extracts Taken from D.L. Mills
The routing algorithm uses a table called the Host Table, which contains for each host in the network the computed roundtrip delay and clock offset, in milliseconds. In order to separately identify each reference clock, if there is more than one in the network, a separate entry is used for each clock, as well as each host. The delay and offset fields of the host itself are set to zero, as is the delay field of each attached reference clock. The offset field of each attached reference clock is recomputed periodically.
Hello messages containing a copy of the Host Table are sent periodically to each neighbor host via the individual links connecting them. In the case of broadcast networks the Hello message is broadcast to all hosts sharing the same cable. The Hello message also contains a timestamp inserted at the time of transmission, as well as information used to accurately compute the roundtrip delay on point-to-point links.
A host receiving a Hello message processes the message for each host in turn, including those corresponding to the reference clocks. It adds the delay field in the message to the previously determined roundtrip link delay and compares this with the entry already in its Host Table. If the sum is greater than the delay field in the Host Table, nothing further is done. If the sum is less, an update procedure is executed. The update procedure, causes the new delay to replace the old and the routing to be amended accordingly."