Right now there are 2 areas that are getting a lot of development effort in fpdb: importing and HUD. The player stats and graphing are sort of first drafts that will be fleshed out some more later (no offense intended to the guys who worked on those areas ). I am not going to spend much effort on improving those areas until the importing effort is complete. For now, I am working to improve the HUD and adding a gui configuration function. I have an idea for a hand reviewer, but I'm not going to work on it while I have problems with the HUD and users have to edit the xml file to configure.

Speaking for myself, I think we (the fpdb team) are actually being pretty responsible and mature by taking a step back and working on infrastructure things, rather than just adding some more features. It demonstrates that we are interested in having a solid, reliable system and are willing to do the behind-the-scenes work required to do that. I think that it would be irresponsible of me to work on features when I have a problem like the misapplied pref seat stats that you see in some recent posts (now that I'm convinced that its not just a configuration problem).

One thing we have done, more or less accidentally, is work on multiple games and multiple sites and push them all along together, instead of focussing on one game and/or one site. I think this development model, plus the willingness to do the infrastructure stuff means that we will have really strong system when it comes together. The bad news is that it isn't going to come together in the next couple of weeks.

If you have coding skills and want to participate, you will be welcomed by the team. If you see something you want to work on you should probably speak up on the mailing list or the irc channel (#fpdb on freenode).

Once again, I didn't mean to come off as entitled or overly critical.

As far as joining the project, there are two problems with that:

1. I hate Python ("There's only one way to do it" = "You have to do it this way, and if you're not familiar with this particular idiom, you can't make up for it by being familiar with another idiom"; and the fact that there are so many keywords and builtins that can't, even in theory, be written in a small subset of the core language)

2. I hate Other People's Code (I don't even like to use libraries; sometimes I'd rather reinvent the wheel)

However, I did write a poker bot in C. It played like crap, but it understood the rules, arbitrated showdowns, guided the action, etc. Right now I'm learning Haskell, which kicks major ass. If you know of any open-source Haskell projects, I might be interested in joining one.

I think it's cool that you guys are taking a long-term approach. Just don't forget to add those features once the more important stuff is worked out!

One other thing: if anyone out there is using fpdb but wants something to review sessions with, I stumbled upon something called Popopop's Universal Hand Replayer (just google that) and it took two minutes to download and install and is stupid easy to use. This may be common knowledge already though.

Completely agree

I cant speak for the other devs, but one of the reasons I got involved was so I could work on these sort of features and make them work how i'd like to use them. They will come but probably not on a timescale you'll be happy with. Most of the required info is in the database, its just a matter of extracting and presenting it.

(A simple profit graph already exists fwiw)

Meh - get over it. Python is fine as is any other language. They all suck to some degree or another.
I'm sure your not, but this might be the stupidest thing i've ever read on the interwebs. This is one of the biggest strengths of python fwiw.
http://www.haskell.org/gtk2hs/

Write your features in Haskell + GTK. Theres nothing preventing this being a multi language project. If its useful we'll include it.

Sorrow (who shouldn't read forums while hung over.)

Was that necessary?

Nope, but your post was about the equivalent of a stupid "do not want" picture, and equally unnecessary.

Lets call it even

let's keep it civil, i tried to put a stop to the OS wars that I accidently started, so let's agree to disagree, that Discipline doesn't want to dev in Python, for whatever reason. (Frankly, I'm learning python specifically for this project, I intentionally stayed away from it as long as I could, I guess)



Primarily FPDB is mostly useful as a HUD right now. I know absolutely zilch about GUI stuff, and my very limited SQL knowledge is really not useful to a project that uses this much. Fortunatly, we have a few people that do know this kind of stuff. So, I'm sticking to areas that I do know currently, and that's pretty much trying to make improvements to the existing stuff wherever I can.

btw, we've recently got recursive HH folder reading in (at least for auto-import, i'm not sure if it works with Bulk or not), and the framework for the "universal" hand-history-converter that should, theoretically, make it relatively easy (to people who have a good knowledge of regex) to build a converter for most any site is mostly functional now. We're actually importing from a site that bears very little resemblence to FTP or PS format, with no third-party programs now, although the accuracy of the information is not completely tested.

¿

Oh boy!
I really like how the way people discuss here, because they keep it easy
and back to the relevant things! (E.g. it is MUCH better to skip the OS discussion
except you'd like to have a worthless discussion for the rest of the thread).

BUT...the QUOTE from "boy" just made my day!

Okay, this is the only post I'm going to make defending what I said. You can reply to this however you want, but I won't reply back on this topic because I don't want to totally derail this thread.

1. My post was not a "do not want" picture. I explained why I don't like Python, which was relevant since I was invited to contribute to a Python project, and my reasons are perfectly valid even if you think they're stupid.

2. Yes, it seems contradictory to say that I'd contribute to an open source Haskell project given that I like to work alone and don't like messing around with other people's code, but the difference is that I'm learning Haskell, so reading other people's code is less annoying and more educational. Also, I like Haskell so much more than Python that OPC becomes less of an issue.

3. There was still no reason to say that my post was "the dumbest thing ever" or whatever you said. So I don't like libraries. Obviously I use them if I have to, but I'm more interested in doing little niche projects that don't necessarily have massive libraries written for them. I don't like the fact that in Python you need to know 100 library functions just to get something done, and it's not necessarily straightforward to just implement them all yourself. Haskell uses a basic set of tools (recursion, list comprehensions, folds), and it's easy to see how the more complicated functions are written in the core language. If I came across a problem that could be solved with a library function, but I didn't want to wade through the libraries, I could probably write my own function in 10 minutes. Not necessarily the case with Python.

Anyway, that's all I have to say about that. Back to fpdb, please.

Agree

I think I have fixed the problem with scrambled stat windows when using preferred seating. The fix is in my public git repo. I tested by playing for a couple of hours with no problem--I rarely saw the problem, though. One side effect of my fix is that the HUD might not pop up until the second hand played at some tables. I also left some intermediate printing around the start of a new HUD, just in case and to help some of the other devs working on a different problem.

Please let me know how it works.

Ok I tried saving stats positions in the current version and it is working fine. Oh yeah, I wasn't playing heads up I just typed it wrong.

P.S. we need mucked cards for Holdem and Omaha - but especially Holdem.

I think pokertracker style is good but you guys may know better.

Edit: Oh crap, I noticed you are playing HU. I have never tested HU and there could be an edge case or something. I will give HU a try after lunch.[/QUOTE]

Glad to hear it is working for you.

I realize that a mucked card display for flop games is starting to be a pretty glaring need. The last time I saw PT3 it had the cards pop up for a sec after the hand. I think that is actually pretty annoying because you need to be looking right at that table when they pop up.

Putting the mucked cards in a separate window was fine for stud games because most stud players are playing 2-4 tables and screen real estate is not a big problem. There is no way that a 16 tabling holdem player can tolerate 16 mucked card windows scattered around his screen.

So I would be happy to hear suggestions for a mucked card display for flop games.

BTW, because of the way I have written the aux window thingie, it is possible to have multiple mucked card displays and users can pick the one they want in the config file. In fact you could have more than one going at once. One of the next things I'm going to do is to write a coherent tutorial on how to write an aux window, with the hopes of inspiring someone to write a brilliant mucked card display for flop games.

I've just played a test-session, but it really seems that you have
fixed the problem!
I had several tables open simultaneously, killed different HUDS, tables and so on and everything seems to run smoothly.
I also think that it works a lot more stable than the "normal" 0.10 version, at least for me! Nice work.

If any new (old ) problem occur I'll inform you.
Currently I can say it works like a charm, thank you very much!

Regarding the crashing problem in X-Windows:

I wrote that nearly a month ago but have allowed myself to be too distracted to report back till now.

The answer is: Yes; the HUD still consistently crashes when its parent table is closed (if new hands are subsequently imported, so that it tries to update the now-orphaned stat windows).

I haven't tested this on the very latest Git version, which Eratosthenes has just updated, by the way (but it's the same in this respect, I imagine).

This is a bit annoying, but I have got into the habit of closing the HUDs manually. Lately I have tried playing 20 tables (or sometimes more) at the micro-stakes, and my computer manages to keep up, in spite of my attempts to load it in this way with an intolerable burden. This is impressive.

I agree with Donkequity that a PT-style mucked card display would be very desirable. Eratosthenes: The way PT does it makes sense, I think, because one only cares what the mucked cards were if one was watching the action. Therefore one is already looking at the relevant table.

But this brings me to Eratosthenes' other point:

It depends on what the windows look like. I believe in PT there is nothing visible at all until just after a showdown, and no "window" in any real sense, just the cards.

But this raises a problem, related to a peeve I have.

I play with stacked tables. Whenever a new HUD is created (several seconds after the hand has been played) it jumps to the front of the stack, covering the HUD that belongs to the table actually being shown. This is not so bad in itself; what makes it annoying is that it steals the focus. If I happen to be in the lobby at the time, trying to open a new table, I can't use the keyboard to do it any more till I have put the focus back on the lobby window.

I suspect that this problem (which is not exactly important, as you can see) can't easily be solved; though it would be nice if it could. I mention the problem because it obviously applies to the behaviour of the mucked card display. This would have to respect the current visibility of the table it was attached to, otherwise it would make play with stacked tables impossible.

To add to my sudden loquaciousness (the fruit of insomnia), two things:

I keep up to date with this repository, but I am still having trouble with the preferred seat. When the preferred seat is set, not all the tables get their HUD. Sometimes it then works if I stop the HUD and start it again; but this does not seem to be reliable. I will try to test further.

Secondly, the HUD merges the statistics for 6-max and full ring games (in NLHE), i.e. it does not distinguish these as two games (but they are distinct in the database, I believe). This is wrong: a tight player in one would be quite loose in the other, so the statistics need to be kept apart.

The lastest version should be slightly more efficient. I am also working on the way that closed HUDs are handled, I think I see how to make the HUD behave better when the table window is closed. I have about half of that fix in.

I am pretty surprised that you can get 20 tables going on your pc, too (which is similar to the one I am on now). I am pretty impressed with how efficient python and gtk are on Linux machines.

I will put this on my things to do list. It will just be another set of (normally hidden) windows that are just unhidden when the mucked cards are being shown. The windows just be the card images. This will work nicely for both holdem and Omaha. If you are playing 20 tables x 9 max, this will be another 180 gtk windows. We should start really challenging you pc soon.
I think I know why the new HUD goes on top at first and steals focus. I will take a look at that today.

You are having this problem after the fix I pushed? It is date stamped in the repo as 2009/02/24 02:33 UTC. This is a fundamental problem with the db structure and how the HudCache stats are sliced and diced. The stats are not separated by max, but they are by number of active players. I agree that 6-max and 10-max stats should be separate because the games just play differently-this was a disagreement I had with Steffen back on day 1. I have been pretty successful at not thinking about this problem until just now. It might be possible to put in an ugly quick fix to display only stats from tables with 7-10 active player for 10-max and 1-6 for 6-max.

I've just played another testsession.
The stats-shifting problem seems to be solved at all.

1)
But when I kill a table HUD two times with only a few seconds in between at one
table, fpdb seems to stop working properly.
I think it works still with the opened HUDs but I can't end fpdb by klicking "Stop
Autoimport" but by killing its process.
It also stops to display new HUD on new tables.

2)
When I have several tables open (e.g. 7) and I am playing at one but still waiting
to participate at the other 6 it seems that fpdb doesn't like this either?!
I am really wondering because it doesn't seem to make any sense.

Well, I will observe both problems and if I can give more useful information I
am going to report about it.

p.s. The solved shifted-stats problem is awesome!

indeed

I think this is similar to the problem Eleatic Stranger mentioned a few posts above. I have an idea to pursue that might fix it. I will try it later tonight or in the morning. This is really odd. What site is this? You might check the HUD-error.txt file (same folder as fpdb) to see if there are any clues. Another thing to do would be to run fpdb from a terminal window to see if any clues get printed there.

Thanks for the feedback--it is very helpful.

I would like to see the HUD stats have an option to be seperable by Active Players, Max Players, and by Stakes. Or none of those, and have all the same games together, if you want.