Jump to content


  • Content Count

  • Joined

Reputation Activity

  1. Upvote
    toohoola got a reaction from moisesolivar in Fully Automated | Script Decides the best combination for your balance   
    Same code, but fixed indentaion: https://gist.github.com/anonymous/a1d9b848044a2a0ebce8c04e982724aa
    @moisesolivar: what is f, fa, and ff ?
  2. Upvote
    toohoola got a reaction from Carollzinha in Sex Giveaway! 100k prize!   
    It took 5535 rolls and 10100 satoshis, but worth it!
    P.S.: Can I win multiple times, or only once?
  3. Upvote
    toohoola got a reaction from leftler in Can't get server seed to match server seed hash.   
    string input = "d8818b38a14e7461e87301ad4b9809b558bcbca816b650cd470452e018ada255"; Console.WriteLine(BitConverter.ToString(SHA256.Create().ComputeHash(Encoding.ASCII.GetBytes(input))).Replace("-", "").ToLower());  
  4. Upvote
    toohoola got a reaction from hui in Invalid payout values that misleads the players   
    When someone makes a high, but invalid payout bet, it stays like that!
    What is invalid?
    This dice game has 10000 possible outcomes and the payout ranges from 1.01202x to 9900x. 9900 and 1.01202 has much more values than 10000 inbetween, therefore some values can be invalid, because of the limit of the 10000 results. For example: when somone inputs a 6599x payout the winning chance changes to 0.02%. However if you input the 0.02% the payout changes to 4950. So players can incorrectly think, if they input such invalid payout they can win much more. The only way these invalid payout values could be valid is if the game has much more than 10000 outcomes.
    How to fix?
    I have 2 ideas:
    Since the payout-winchance changes at every key input, I suggest to implement a small algorithm that checks if the input is valid and if not, notify the user with a tooltip, like it does when it's either too high or too low. This algorithm should run only when the payout is changed and it's a high payout (bigger than 10 or 100), since that's where these kind of mis-calculations could be problematic, whereas at smaller payouts it can be annoying. I attached an example image of this. After the player rolled, the returned response (which contains the valid payout multiplier) should change the payout field value. This one is less user friendly, since it changes the payout after the player has rolled. Maybe there are other, better solutions that I could not think of.