(I’m from a country where we spell things more or less than same as they do in England. Therefore, throughout this post, I use colour instead of color.)
The most important change in this update is the HUD colour settings:
You can now make all HUD statistics use a default colour based on simple formulas.
You now have fine-tuned control over the colours used for each statistic, regardless of whether it is percentage-based or not.
You can now customise HUD colours used for M-ratio and for BB remaining.
We’ve replaced “full brightness threshold” with two separate settings: “color threshold” and “icon threshold”
Some other changes:
Added support for gioco digitale poker (aka GD Poker), which recently changed from Ongame Network to PartyPoker network.
Added support for bwin.it, which recently changed from Ongame Network to PartyPoker network.
Fixes to 888poker support, especially for their unique definition of ” raises” actions
All-in equity is now calculated for 888poker network
I hate it when an app I use every day changes things for no apparent reason. Or for an apparent reason, but not something that was an issue for me. And so I’m aware that some of you will be bothered by the changes in this update. Others won’t notice. And some people will be very pleased. Let me explain further why we did this:
Problem 1: Confusion
Until this update, Poker Copilot’s HUD colours were configured via three different places:
the “HUD colour threshold” setting in Preferences -> HUD -> General (which also controlled when icons appeared)
Preferences -> HUD -> Colours
Preferences -> SharkScope, if you have a SharkScope account attached to Poker Copilot
All three sets of settings were combined to choose the correct colours to use.
This was probably confusing for some customers; it certainly was confusing for us here at Poker Copilot global headquarters.
Problem 2: Limitations
A long-standing and common request for Poker Copilot was to be able to change the colour settings for M-ratio and other non-percentage based stats. A quite recent but common request from our SharkScope users is to be able to colour statistics according to SharkScope statistics, which are often neither percentage-based, nor inaccurate until a certain number of hands for the player are in your local Poker Copilot database.
Problem 3: Keep it Simple
Making a simple user interface is hard. Well, it is easy if there are few choices and features to offer. But when there are subtle differences between features that seem alike from a user perspective, hiding that difference behind a simple user interface is hard. I tried to concoct an alternative to our multi-colour sliders that are used to control HUD colours. I talked to smart people who know Poker Copilot well; I sought external help. But alas, it seemed that the multi-colour sliders were not practical for statistics like M-Ratio or Times Played. For the sake of simplicity we needed an approach that would work for all statistics, no matter what their range of allowed values.
Our Approach
Over the last month, I’ve used the brilliant Balsamiq Mockups to make drafts of potential approaches to remove the confusion, remove the limitations, and yet keep it simple. I’ve bounced ideas around with others. I’ve coded up test solutions. It was hard. But we got it done. Perhaps the solution we’ve got is ideal; we hope it is. But if not, we’ll be listening to customer feedback to tweak the approach in the coming weeks.
Here’s the new HUD Colours preferences panel:
I hope you enjoy the extra flexibility these settings give you.
From the “about time” category: the next update of Poker Copilot lets you create your own colour settings for M-ratio in the HUD.
You can change any colour and change the values at which any colour is used. You can add many more colour settings.
Why has this taken so long? It required a substantial change to the way Poker Copilot colours statistics. The amount of work required always pushed this down in the priorities of things to change in Poker Copilot.
There’s more to this new feature. You can now set the colours of any of Poker Copilot’s HUD statistics. Until now, only stats that showed a percentage value could have custom colours that are used at different values. Now you can colour any statistic. For example, here’s how you could change the colour of “hands played” so that for players you played often it shows in green:
We’ve changed the statistic colouring system substantially; an upcoming blog post will demonstrate the changes.
Coming in the next Poker Copilot update: When relevant, Poker Copilot will show your all-in equity % for the previous hand. So now when you lose with Pocket Jacks to a villain who hit his flush draw, you can immediately see if, despite the loss, you made the correct decision in terms of equity.
With the help of loyal but frustrated Poker Copilot customer Artem, I’ve been able to tune up Poker Copilot’s HUD to make it faster and more responsive for people with extremely large databases. The next update will have these improvements.
A brief overview of the improvements:
Imagine you’ve got 500,000 hands of 6-max PokerStars No Limit Hold’em tournament hands in your database. For each hand, Poker Copilot records roughly 60 statistic data points. When you are playing, and the HUD is showing, your own HUD stats are calculated by aggregating 500,000 hands times 60 data points = 30 million data points. That’s a lot of data to recalculate after each hand on each table. The database that Poker Copilot stores this data in is optimised to handle such cases quickly, using database indexes and pre-rolled-up summary tables.
A new database index
Except, that Poker Copilot has stopped using the optimisations, if you had “HUD stat weighting” turned on. Somewhere over the development of Poker Copilot 5, as we changed things around to facilitate the addition of HUD statistic weighting, the database index setup stopped helping for tournament live play. So Poker Copilot was doing more work than necessary to calculate your own statistics. (HUD statistic weighting is a Poker Copilot 5 feature where more recent hands count more towards calculating statistics than older hands do.) We added a new database index designed for optimising fetching the right hands for calculating tournament HUD stats.
HUD stat weighting for opponents only
But there was another improvement waiting for us: the idea of HUD statistic weighting is not so useful for your own stats. And yet HUD statistic weighting was part of the performance problems. It is intended to make sure your opponents’ stats are more weighted by recent hands. Your opponents’ stats are what you typically use for making decisions on the poker tables. Your own stats are not used so much at the tables during live play for decision making. So we’ve turned off HUD statistic weighting for your own stats. It now only affects opponent stats. You will typically only have a fraction of data for any specific opponent, so it is much quicker to weight newer statistics for opponents than it is to weight your own statistics.
Don’t calculate what you don’t need
Poker Copilot was calculating hero stats even if hero HUD stats were set to “Don’t show”. That was rather pointless. The quickest database query is the one that isn’t performed. So we’ve made Poker Copilot be smarter in choosing what data it fetches during live play.
Hopefully these three changes will make Poker Copilot quicker for you when using the HUD with a massive database.
This update has many small tweaks and fixes. The most important changes are:
Fix: The HUD works again on Merge Network rooms, including CarbonPoker, Players Only, and Sportsbook Poker. Due to changes to their software, we can no longer automatically detect your preferred seat on these rooms. You’ll need to set your preferred seat in Poker Copilot’s preferences -> “Poker Room” -> “Merge Network” -> “Preferred Seat”.
Fix: 888poker.es now supported.
Fix: 888 poker hands no longer crash the hand replayer.
Fix: 888 poker hands no longer crash the HUD.
Fix: Fetching seat info from SharkScope for Winamax now works on multi-table tournaments.
Change: Revised “fold to 3-bet” statistic so that it only includes the situations where you made the initial raise.
Fix: Revolution Network 10-max tables were sometimes identified as 9-max, breaking the HUD
Fix: Winamax tournament wins that have both a cash component AND a ticket are now correctly imported
This update introduces a new service for customers who have a SharkScope account linked to Poker Copilot. On tournaments on PokerStars and Winamax, player names are automatically fetched from SharkScope’s website before play starts, already showing player info before the first hand.
You’ll see SharkScope stats for each player, and – if you already have data for a player – you’ll see Poker Copilot stats too.
This is also handy when changing tables in a tournament. Within a few seconds of being moved, Poker Copilot will fetch enough info from SharkScope to be able to show you stats for each player. You shouldn’t need to wait for a hand to be completed.
We’ve been getting occasional reports from Poker Copilot 5 users that the HUD is not updating for long periods. Until now we’ve been unable to reproduce it.
Then two days ago, a set of coincidences let me experience the bug. The HUD would show after one hand but then it wouldn’t update. The hardest part of fixing bugs is reproducing them. Once you’ve reproduced a bug, fixing it is usually straight forward. Time consuming possibly, but straight forward.
Here’s the bug: if you have a recently created or modified file in one of your hand history folders that ISN’T recognized by Poker Copilot as a valid hand history file, then any live hand history file subsequently detected by Poker Copilot only gets handled once. Future updates are ignored until you restart Poker Copilot, or one hour has passed since the file causing the problem was last changed.
So yesterday I fixed the bug. There will be a Poker Copilot release later today that includes the fix.
I wanted to know how this critical bug got into Poker Copilot. It turns out that I added it in May, 2014, in the early days of creating Poker Copilot 5. It was a small optimisation needed for our work in making Poker Copilot capable of running on Windows.
May, 2014…and I’m writing in March, 2015. In that period I’ve had a dedicated part-time QA assistant working for months testing Poker Copilot thoroughly, many other bugs have been discovered and fixed, we’ve gone through a long beta period, we released Poker Copilot 5 two months ago, and this critical bug managed to keep hiding.
This makes me ask myself: what could have prevented this?
Unit testing? I don’t think so. Poker Copilot already has hundreds of unit tests. The component where this bug occurred is not a natural candidate for unit testing. It is not good to make unit tests complicated and slow. When unit tests run slowly it becomes tempting not to use them frequently. I think that adding a unit test that would pick up this bug would be too convoluted. Unit tests, in my opinion, are best used to test black boxes, and this critical bug was in code that doesn’t easily lend itself to be a black box.
Code reviews? In a code review session, another developer would have looked at my change back in May, 2014, and would have quickly spotted the bug. It was an egregious bug. But as the sole developer in my company, I don’t have the luxury of code reviews. I wish I did.
Shorter release cycles? Many months passed between me creating the bug and fully releasing the code. I believe that if I had released a Poker Copilot a week or two after adding the bug, I would have been able to connect the “my poker copilot is broken!” feedback to guilty code changes much quicker. Customers would soon report the problem started with the latest minor update, I’d look at what changed in the latest minor update, and would have been able to narrow down the problem with too much trouble.
This bug isn’t alone. A month ago I discovered another long-hidden performance problem. Despite accurate reports from customers, I only managed to reproduce it by getting a helpful customer to supply both his Poker Copilot database and his Poker Copilot preferences file. That helped me spot the problem – again, the offending code had been part of Poker Copilot 5 for many months, making it through near daily testing for months, through the beta period, and into our actual release of Poker Copilot 5.
Software with infrequent major updates
The more I experience problems with major updates, the more I believe it is time to end for good the 12- to 24-month major upgrade cycle that desktop software traditionally uses. Releasing many small upgrades frequently is much safer than releasing a huge upgrade seldomly.
This is is no remarkable observation; since 2010, Google Chrome has six-week release cycles. Mozilla Firefox switched to six-week release cycles in 2011. Only three years ago, Facebook announced a four-to-eight week release cycle for its mobile apps. Now it seems to be every two weeks. From their iOS app description: “To make our app better for you, we bring updates to the App Store every 2 weeks.”
On the other hand, Apple releases OS X yearly. As a developer I’m always amongst the first to update to the new release, and it is always initially a painful process. Things that used to work stop working. (For some months OS X Yosemite turned my lovely Sennheiser wireless headphones into expensive dust collectors; and my Apple TV became more trouble than it was worth to use from a Mac with Yosemite. Apple rectified these issues over some months.) Parallels Desktop, software I rely on for running virtual machines – an important part of modern cross-platform, cross-version software development and testing – released an update some months ago that worked worse than the previous version – but required me to pay an upgrade fee. I had to pay money to have what seemed an inferior product. Parallels Desktop 10 did have some helpful new features, but all I could see at first was that the new update was worse for me than the old one. Eventually they released a couple of minor updates and the problems were solved.
The difference between Chrome, Firefox, and Facebook on one hand, and Poker Copilot on the other, is, well, a lot. Two major ones for the sake of this article: they have many more resources; and their products are free. So their release cycle doesn’t have to take into account how frequent free releases rather than an annual or twice-yearly paid update affect sales and profitability.
Poker Copilot is a paid product. After a few years on the market, upgrade fees become a significant source of revenue for desktop apps. This is why having a occasional major upgrade of Poker Copilot is important for my business.
Yet customers expect significant extra value for the hassle and expense of major upgrades. So it is tempting to develop for many months, and then release a major upgrade. At release time, we can say, “Look at these new features if you pay to upgrade!” But, as my experience has shown, this leads to software that has more defects than is the case with many minor updates. As I noted with Parallel Desktops, some Poker Copilot 5 customers could say at first: I had to pay money to have what seemed an inferior product. I believe Poker Copilot 5 to be a big step forward, but for customers who were affected by initial bugs, and who didn’t need or care for the new changes, all they could see is that it brought them problems. This is a stressful situation for me; it isn’t pleasant to be trying to deal with this. The bugs causing customers grief are hard to find. While finding them, I’m not able to work on new features nor on other products. Nor rest on a sunny beach, which is always a pleasant alternative.
One way to solve this is to create subscription-based services, either for desktop software, or for online web applications. People pay a monthly- or annual- fee. While they keep paying, they get to keep using the software. When they stop paying, they can no longer use the software. Instead of major updates to get customers to pay upgrade fees, the company releases frequent small updates, to keep the customers subscribing. That is not a path I intend to follow at this stage, although it certainly is an option worth investigating.
Another way is to state clearly that a purchase of desktop software entitles the customer to the current version and all upgrades for a time period, say one year. After that time, the customer can still use the version they have, but they can no longer update to new versions without buying an upgrade license. I believe this to be more customer-friendly; the customer doesn’t feel they are forced to buy upgrades. They only do so if they believe there is value for them in the new major upgrade.
A friend of mine reckons that it is inevitable that one day Poker Copilot – and indeed most desktop software – will become an “in-the-cloud” pay-by-month service. If that is the case, I think we are still a long way from that day. Due to the massive databases that some Poker Copilot customers have, and the processor demands a database-heavy product places on a computer, I’d like to avoid that change for as long as possible.
For now, after the headaches in the last 2 months of fixing the critical problems introduced in Poker Copilot 5, all I can think is: No more major Poker Copilot updates ever; frequent minor updates from here on. The end product is the same; the path to get there is more pleasant for me and for my customers.
We recently changed the maximum spots available in Poker Copilot’s HUD for showing statistics. It used to be a 4×4 grid; it is now a 5×5 grid. This gives you up to 25 statistics.
We hope to soon increase the choice of statistics you can put into those 25 spots.
I’m in a hotel room in Laos; the Chinese New Year starts in a couple of hours. That seemed like a perfect time and place to answer a question nobody had asked until yesterday: what email companies do Poker Copilot customers use?
Why is this a question? It’s because customers who use hotmail.fr often don’t receive the email we send with license key info. Hotmail.fr enthusatiatically decides that our messages are spam and often our French customers who use hotmail.fr are denied the chance to receive their license key. While talking about this with Alex, our QA guy, we asked ourselves how many people actually use hotmail.fr, whether the number is dropping, and whether we should spend much time working out what exactly is causing this problem.
Gmail dominates, being used by more people than hotmail and yahoo combined.
But 3% for me.com and 2% for mac.com? Those numbers look odd. Because me.com and mac.com are two obsolete attempts from apple to do what’s now called cloud computing for consumers. Both have been replaced with iCloud. Clearly this data is unduly influenced by an older state of affairs. Nothing stays still on the Internet; what’s relevant information for five years ago is misleading for today.
So let’s only look at data for the last twelve months. Let me work out the syntax in MySql for date comparisons…I never recall the specific way to do this for a particular SQL engine. Ah, here it is.
So gmail.com has gained, but hotmail.fr together still have a significant 6%. So, it seems it is worthwhile making the changes that will make hotmail co-operate better with our license key emails.
(Aside: it makes me kind of sad that gmail.com keeps moving ahead. It is getting dangerously close to monopoly status, and who can compete against a massive company that offers an excellent email service for free? I use gmail myself, but still feel something is not good with this market domination.)
—
Postscript: I asked Margherita, our customer support agent if this problem was still happening: were hotmail.fr addresses still filtering our license key emails as spam? It turns out this is no longer happening. Well, there was a bunch of investigation and writing that turned out to be unnecessary!
