hi,

do most of you,who datamine,only open up to 4 tables without logging in on party or open up to 10 tables and being logged in?do you think it doesnt matter at all being logged in because party will detect who is mining anyway through your ip-adress even if you dont log in?
but hopefully it isnt against their t&c to mine

thx
asteroid

I just open up, log in and mine 10, but I don't open up other clients on other WinXP accounts (partly bc my PC is a bit crappy and I do other stuff while mining, and partly bc I don't want to overdo the mining and make party mad from it...).

Lots have asked this already and the honest answer is "I really don't know, but don't think it is atm...".

If you read their T&C it seems like the thing they get most mad about is commercial data sharing of hand histories. FPHG is neither commercial nor anything to do with sharing the gathered hand histories. Also FPHG wont write in real time (it waits for the hand to finish), so this also makes it pretty much useless for writing bots (if you notice Party now themselves don't write the HHF in real time to stop this kind of "real time analysis"...).

Juk

Main changes for v0.03:

(1) Have totally fixed the so called 'side pot bug', so now hands with side pots don't get the 'main pot' part missed off the end anymore (was causing problems for NL players...).

(2) Have fixed another bug which was making the 'side pot bug' much more extreme than it should have been. The code which should have added on extra data to the end of a hand had something wrong with it, and this meant that most times when it saw the extra data it wasn't actually writing it to the file! This was why the side pot bug was causing so many problems for NL players all along (even split pots and players leaving the table at the end of a hand should all be written to the HH files correctly now).

(3) I have managed to speed up the code quite a lot also (maybe 200-250% speedup). FPHG has gone from about 30-40 memory passes per minute to 100-150 on my system (using no delay option of '-d 0' - only useful for testing...). It now only uses about 20% CPU time when watching 10 tables and was using about 80-100% before v0.03 had the speedups added.

People should now be able to mine many more table using FPHG and also people with slow/old systems should find that it uses much less CPU time than before (and also misses a lot less hands).

I have also added an extra option (probably only useful for me though) which is '-p'. This option will display profiling information such as the number of memory passes per minute, and some extra info about where in memory the hands are being grabbed from.

The new version can be downloaded from here.

Any feedback would be helpful (NL miners, multi XP account miners and people with slow systems are most likely to benefit from v0.03 I think though).


As far as adding an interface goes, then I have decided to run a poll. This is what I said in another post when asked about why FPHG didn't have an interface:

Please think about this, and then decide if you think adding a nice interface to FPHG is a good or bad idea.

Juk

Thanks Juk. It's much faster - now I can actually mine while I'm doing other stuff which is great.
FWIW I voted "Don't care"... only thing I'd like to see is minimize to tray.

I just use TrayIt. It's nice for Juk's DollarToBB app as well.

So, I don't need you to minimize to tray, I just need a snazzy icon!
-Sam

P.S. I added TrayIt to the FAQ.

Thanks - that's great.

I thought about it, and I think that making the interface nicer really won't make much of a difference. Party likely knows about mining; we've had blunt threads on hand-grabbers on 2+2 and the lunking crowd haven't been subtle about PMs. If interface matters, the other hand-grabbers have interfaces already.

I say you make a tiny window showing the recognized tables and gooey buttons for .hhf/.txt and log-folder. That would already be enough to put you ahead of the other interfaces, and shouldn't be tough at all.
-Sam

Thanks jukofyork -- a much better performance on my P4 1.8GHZ!

I voted "don't care". I think performance outweighs the asthetics of the application. If you can invest that time into improving its functionality rather than convenience than it's a big bonus for us. But then again, GUI would be even a bigger bonus.

v3 has fixed NLHE issues.juk great work ..man that was fast..awesome

Juk,

you are a badass.


I vote no GUI.
The less sophisticated it appears, the better for it's lifespan.

Besides, the people who have to spend a great deal of time figuring it out would be much better served at the tables

Great work!!!
I think a graphic interface would be nice but it´s more important with speed and configurability. I think speed was the major issue in version 0.1 but this was a dramatic change in 0.3. Thanks!

May I suggest a possibility to mine only tables with a certain amount of players. Statistics are not that interesting from a table with 3-4 players if you normally play full tables. This feature was used by PokerTracker and this feature is also available in Lunker.

/Swedebubba

I'm surprised by the requests for this feature. First, don't you already have it set in PokerTracker? What's the difference if FPHG writes the hhf if PT isn't gonna read it?

Second, if you're using iWitness, you never even WATCH a table with fewer than <min> players, much less write it to the .hhf. Is there a reason you guys don't use iWitness?
-Sam

An old engineering principle comes to mind about the FPHG interface..."keep it simple, stupid"...a nice interface just slows things down w/o adding any real value

After spending a couple of days evaluating FPGH vs. LunkerTracker I have switched my opinion...FPHG is the way to go...LunkerTracker gobbles machine resources and may attract PP since it is a commercial product and not underground...although underground software is a relative term these days

Updated for v0.04:

(1) Added two more small optimizations which resulted in about a 40-50% speedup over version 0.03's code (now only using about 10% of CPU on my system scanning 10 tables).

(2) Due to the rest of the optimizations, have increased the default sleep time to 1000ms.

(3) Have added a "realtime" write option, so that hands will be written in realtime if asked. Only use this option if you need to as it does use more CPU time and may also cause the end of some hands to not get written properly. Also use a smaller delay if you use this option (-d 300 or less is probably best to try).

(4) Added minor bugfix in that we could in theory mine over 1000 tables and wasn't checking for an overrun.

(5) Have made it so that it can have the priorities set from the command line. Also profiling mode changed from "-p" to "-prof" bc of this ("-p" is now for priorities, so: "FPHG -p -2" will run in 'Low' priority mode, just like the old batch file used to do).

(6) Prints the options that we are using when FPHG starts up(bc getting too many and was starting to get confusing).

Version 0.04 can be downloaded from here.

Please read the readme.txt file for further information about the new options (better explained in their). Also I left the run.bat file in the zip so as to have an example of how to set command line parameters. If you look in run.bat you will see how to run FPHG in "Low Priority" mode (eg: exactly the same as what the old batch file did).

Juk

PS: Still waiting to see the votes on if an interface is really wanted (please keep voting in this sub-thread).

Amazing. Thanks. I definitely appreciate all the processor tweaks. (Now please get to work on lowering the load of the damn Party client. )

I've switched from my paid copy of PHT to FPHG. Just letting you know.
-Sam

Cool, there was acatully two "bugs" causing the problems!

One was the bug which I expected to only kick in on overloaded systems: what I called the "side pot bug". It now has extra code to check no hands will ever be written which finish with "wins from side pot" and all hands must always finish with a "wins from main pot" line if their was a side pot.

But it baffled me why so many ends of hands were being missed... It turned out their was a another (unknown) bug in the code which was supposed to write extra bits on the end of hands and about 99% of the time it wasn't writing the extra bits! (all fixed now). You should notice now that even people saying "nh" or leaving the table at the end of a hand get written properly now and split pots working fine again too...

This fix should also means W$SD stats are correct, but this bug effected NL players much more than limit...

Juk

Holy crap I'm gonna start running FPHG while playing only to use it with SmartNotes. Awesome, very awesome.

I been trying to tell people about TrayIt soooo many times! Maybe now it's in the FAQ people might start to use it, but it is a great free util and I been using it for ages (hence why I didn't have "minimize to tray" support in most of my apps until people asked - TrayIt can do this for anything!).

PS: Just make sure you don't block it's hooks using PG or SnoopFree - it needs the hooks to work properly.

Juk

Try v0.04 and see if this helps even more (about 40%-50% speed increase). I only have a 1.4GHz and its down to about 10% CPU usage now...

Juk

Try v0.04 as I have optimized it a little more and now CPU usage has become fairly insignificant (even on my crappy system!)

Yes, I can add this and will add this and the ability to re-add the 6max tags in a later version. Thanks for the suggestion (I always thought PT had some kind of option to import only if > N players, but this much have been taken out...)

Juk

Nope. It's still there. That's why I'm confused.
-Sam

Tell us how you get one with it - any feedback helps

Juk

Just to say sorry it took me a while to optimize it (v0.01 and v0.2 had no optimization effort put into them at all).

Alot of (experienced) coders will know though: their is never much point in optimizing stuff for the sake of it (ie: optimizing every line, using fancy data structures for the sake of it, jamming your code full of pointers, etc), as usually about 1% of your code uses 99% of CPU. Best plan is to wait and then try to optimize that 1% as much as possible, this way you get the biggest gains for the least effort and can keep 99% of the code nice and simple...

Sadly though, I think I have hit the point of diminishing returns now and only very small increases possible from now on unless I rethink the whole architecture and start to use dual-threaded string scanning system (which I might do if FPHG stays alive indefinitely, but its alot of work if it eventually gets banned or the method nullified via a client update...)

Juk

Hey, I'm not going to give you flak for optimization. I'm the guy who spent hours and hours this week writing in a SCRIPTING LANGUAGE. We don't even have a compiler!
-Sam