Several Questions

[The Palimax]

I've been a registered TD customer for a couple years now - using it in our poker league and for charity tournaments (in simple mode) from time to time.

...but I've got a couple questions now that we're on our 11th season of our poker league.

• What mechanism allows me to take a player out to multiple hitmen?  We've had plenty of situations near the end of our games where there is a 3-way all-in where two players chop the pot, busting out a third player?  I certainly know how to take out multiple people to one hitman, but is the reverse possible?  Am I missing something obvious?
  I've now got about 70+ people in my database who are unlikely to return - they've been gone for a year plus.  Is there any way to do bulk removes of old players, or hide them?
  Finally, I'm still running on 2.5.8 since the upgrade from 2.4 left me recreating things because of the move of the stores (I now know the fix was simple, but at the time...).  Any caveats for doing the current upgrade without putting my data at risk?

[Stuart Murray]

at current multiple hitmen cannot be selected but it is included in 2.6 release.


there is no easy way to remove players from the database in the way you specified.

If you are on 2.5.8 all future updates were just that, we are still on version 2.5(.11) and even 2.6 will not require any movement of information, when you update to the most up to date version you will not loose any information or be required to make any changes, that was a one off situation from 2.4 to 2.5 as their were major changes introduced.

Stuart

[Corey Cooper]

stuamurr is right on all points.   

Let me see how hard it will be to add a delete mechanism to the Database tab.  I've done a lot of work rebuilding the dialogs, so it might be fairly easy in 2.6.

I'm always of the opinion that deleting players should be a last resort, which is why I never added a way to mass delete players (but then again I can always find reasons why it might be the best option).  One idea you might want to consider is placing all of your "active" players in a particular league, and then simply viewing that league on the Database tab.  This will have the effect of "filtering out" all of those other players that are inactive.  I'm going to see about having an option to mark one league as the "default" league.  Then that league would be selected automatically when you first visit the Database tab, and when you add new players to your database.

[The Palimax]

I did the current-version upgrade.  All went well.  After the last upgrade, I was scared.

Thanks for looking into the multiple hitmen issue, and I look forward to 2.6

I've got TWO database/player issues.  One in that I have duplicate players, and another in that I have old players who may never play again...

The prescribed method for fixing duplicate players isn't practical.  I've run 300+ tournaments, and I move them off the machine and back them up to gmail - or stats take forever to run on my comparably slow laptop.  Even if I did have them on the machine, it'd be unlikely for me to even FIND the game a single one-time player played in to edit and merge them.  I suppose I could create a dummy game and populate it with all players and then do some merges...  ...then just abandon/delete the game.

If I can throw out suggestions, you could implement a last-played field for players, and then include something as simple as a "Show players who haven't played in X days" checkbox.  Then for 95% of my sign-ins, I could select from a manageable list, and the rest I could uncheck the box and filter.  I need to keep everyone who plays in the league for stats filtering purposes, but when someone's cousin plays 1 or 2 games a season and won't be back for a year, their name clutters up my sign-in.

Thanks for the answers.

[Corey Cooper]

The "last played" info is interesting.  However, the disconnected nature of tournaments and the database, while intentional, also makes this type of information difficult to keep accurate.  I understand your interest in this kind of feature, but I'm just not sure it would be very practical from a coding standpoint.  And if it were as inaccurate as I think it would be, I would never implement it.  I'd rather omit the feature than give the user information that is that unreliable.