FPHG (*** NO LONGER ALLOWED AT PARTY - PLEASE READ OP ***)
07-09-2009
, 10:14 AM
I can't say when I'll have time to work on it though or even if my idea will actually fix the problems (I have it about 50% written, but it still needs a couple of days to finish and test it), but I will try to add back the old method of memory scanning for people to fall back on if the crash bug isn't sorted out.
Juk
07-28-2009
, 02:41 AM
08-04-2009
, 03:18 PM
Quote:
Hey Juk,
I'm still having the (very annoying) issue I described here. And I've been thinking about a workaround that would help me out a lot. I came up with the following idea:
If I let FreePHG only write the observed handhistories, HEM will just pick up the handhistories of the Party client and I will not have this issue (OBSERVED_ONLY=1). I care much less about bugs in observed handhistories. The problem with this is that this setting applies to the .live files as well, so setting OBSERVED_ONLY to 1 won't allow me to use a BetPot script anymore.
Now what I would like to be able to do is let FreePHG output only observed handhistories but output .live handhistories of *all* tables. I did not see a way to create this scenario with the current options in freephg.ini. Is it possible for you to slightly tweak the FreePHG binary to exhibit this behavior? I'd be very grateful and am willing to compensate you for your time.
Let me know if anything isn't clear. Thanks!
I'm still having the (very annoying) issue I described here. And I've been thinking about a workaround that would help me out a lot. I came up with the following idea:
If I let FreePHG only write the observed handhistories, HEM will just pick up the handhistories of the Party client and I will not have this issue (OBSERVED_ONLY=1). I care much less about bugs in observed handhistories. The problem with this is that this setting applies to the .live files as well, so setting OBSERVED_ONLY to 1 won't allow me to use a BetPot script anymore.
Now what I would like to be able to do is let FreePHG output only observed handhistories but output .live handhistories of *all* tables. I did not see a way to create this scenario with the current options in freephg.ini. Is it possible for you to slightly tweak the FreePHG binary to exhibit this behavior? I'd be very grateful and am willing to compensate you for your time.
Let me know if anything isn't clear. Thanks!
Juk
08-04-2009
, 05:07 PM
08-05-2009
, 03:31 PM
OK, I need some people (who suffer from the crash bug and/or get occasional corrupted hands) to test this: http://www.jukofyork.com/FreePHG_v3a.exe
NOTE: This is only a (very basic and cut-down) test version so don't bother downloading it if your current FPHG runs without any problems... I'll be releasing the proper FPHG V3 installation/EXE later on.
Just download the EXE and run it: It will create the data-mined ".hhf" hands in the "C:\FreePHG_HandHistories" folder and put the ".live" hands in the "C:\FreePHG_HandHistories\live" folder (no way to change this in this test version atm).
The code will be quite CPU intensive as it grabs the hands from memory like the old FPHG v0.0x versions did. This is what I intend to use as a fallback in case the hooking-related crash bug isn't solved (the hooking code will just use a different method of acquiring the data - all the same data-handling functions in this code will still be called so any crashes or corruption will clearly be the fault of this code and not the hooking part).
There will be a small delay between the actions of the players and the hand being written (as there will be with the new asynchronous hooking code) so make sure you don't act too quickly or BetPot might miss a player's action before you (there is a way to tune this so as to react quicker using more CPU time, but unless this becomes a problem for the testers I'm just going to leave it at 1000ms delay - post if this is a problem and/or it's using too much CPU to test properly and I'll tell you how to edit the command line arguments).
Here are the questions I need answering from those who test this:
A) Does this work with HEM and/or any other HUD that uses it?
B) Does this work with BetPot and if so is the 1000ms scanning delay OK?
C) Does this use too much CPU time and cause your client/system to chug? If so what CPU are you using?
D) Do any odd corrupted hands appear? These might be hands with random junk in them or hands where actions have been missed or delayed until future lines get written. If so, please post them.
E) Overall is this satisfactory to use if I cannot fix the hooking crash bug for the people who get it?
If people can try this and answer these questions then the next step is to try acquiring the data via hooking again, but instead of doing all the work inside of Party's memory (like I did before) pass out the data as soon as possible to then be passed through this same set of (crash and corruption tested) functions (running within FPHG.exe rather than Party itself). If Party still crashes then then there is nothing I can do about it, but hopefully if it does the fallback code will still be adequate for those who can't use the hooking.
I have the IPC code on my netbook and it's just a case of gluing it all together to create FPHG V3 after I get some feedback on this test version (a few hours work at most).
Juk
NOTE: This is only a (very basic and cut-down) test version so don't bother downloading it if your current FPHG runs without any problems... I'll be releasing the proper FPHG V3 installation/EXE later on.
Just download the EXE and run it: It will create the data-mined ".hhf" hands in the "C:\FreePHG_HandHistories" folder and put the ".live" hands in the "C:\FreePHG_HandHistories\live" folder (no way to change this in this test version atm).
The code will be quite CPU intensive as it grabs the hands from memory like the old FPHG v0.0x versions did. This is what I intend to use as a fallback in case the hooking-related crash bug isn't solved (the hooking code will just use a different method of acquiring the data - all the same data-handling functions in this code will still be called so any crashes or corruption will clearly be the fault of this code and not the hooking part).
There will be a small delay between the actions of the players and the hand being written (as there will be with the new asynchronous hooking code) so make sure you don't act too quickly or BetPot might miss a player's action before you (there is a way to tune this so as to react quicker using more CPU time, but unless this becomes a problem for the testers I'm just going to leave it at 1000ms delay - post if this is a problem and/or it's using too much CPU to test properly and I'll tell you how to edit the command line arguments).
Here are the questions I need answering from those who test this:
A) Does this work with HEM and/or any other HUD that uses it?
B) Does this work with BetPot and if so is the 1000ms scanning delay OK?
C) Does this use too much CPU time and cause your client/system to chug? If so what CPU are you using?
D) Do any odd corrupted hands appear? These might be hands with random junk in them or hands where actions have been missed or delayed until future lines get written. If so, please post them.
E) Overall is this satisfactory to use if I cannot fix the hooking crash bug for the people who get it?
If people can try this and answer these questions then the next step is to try acquiring the data via hooking again, but instead of doing all the work inside of Party's memory (like I did before) pass out the data as soon as possible to then be passed through this same set of (crash and corruption tested) functions (running within FPHG.exe rather than Party itself). If Party still crashes then then there is nothing I can do about it, but hopefully if it does the fallback code will still be adequate for those who can't use the hooking.
I have the IPC code on my netbook and it's just a case of gluing it all together to create FPHG V3 after I get some feedback on this test version (a few hours work at most).
Juk
Last edited by jukofyork; 08-05-2009 at 03:37 PM.
08-05-2009
, 07:42 PM
Nobody? It would be nice if somebody could test this if possible I'm not at all sure how well it'll work for slower/single-core CPUs even though it seems to run fine on mine (nobody has used FPHG 0.0x for about 3 years afaik and most just had 1 core back then...).
I'm now at the stage where I have Party passing out the HH data to the FPHG executable and all seems to be working fine (I've had 18 tables open and mining using this for the last hour without any problems - and it's even working synchronously atm).
I still need to add a buffer at the receiver end, but that's all that needs to be done. It turns out that if I run the "deal with hand data" loop as a separate thread (which just reads from the buffer) then I'll be able to put HH data into the buffer from either memory scanning or hooked IPC seamlessly and for people with multi-core CPUs it'll mean that memory scanning can be speeded up slightly (ie: one thread scanning for hands while another deals with and writes them out, etc).
Anyway, gonna call it a night now, but it should be finished by tomorrow afternoon/evening.
Juk
I'm not at all sure how well it'll work for slower/single-core CPUs even though it seems to run fine on mine (nobody has used FPHG 0.0x for about 3 years afaik and most just had 1 core back then...).I'm now at the stage where I have Party passing out the HH data to the FPHG executable and all seems to be working fine (I've had 18 tables open and mining using this for the last hour without any problems - and it's even working synchronously atm).
I still need to add a buffer at the receiver end, but that's all that needs to be done. It turns out that if I run the "deal with hand data" loop as a separate thread (which just reads from the buffer) then I'll be able to put HH data into the buffer from either memory scanning or hooked IPC seamlessly and for people with multi-core CPUs it'll mean that memory scanning can be speeded up slightly (ie: one thread scanning for hands while another deals with and writes them out, etc).
Anyway, gonna call it a night now, but it should be finished by tomorrow afternoon/evening.
Juk
08-06-2009
, 04:04 AM
08-06-2009
, 06:04 AM
Quote:
I found a work-around for the freezing that works for me, when I notice party freezing I quickly kill hmhud.exe (the HEM hud process which seems to have gone into a busy loop), and then party starts responding again. Then I can start the hud again and it works ok until it happens again in 60 minutes or so. Could be a problem in the hud itself, but I'll still try the new version later today.
Basically the whole idea of the new code is to get all of the file writing stuff and all of the unnecessarily complex code out of Party's memory space so that HEM/BetPot file locking and/or a bug can't upset Party anymore.
I'll have the first version of FPHG v3 out in a few hours and hopefully I can fix any minor issues with the new code brought up here by the end of the weekend (I think I'm gonna be going away at the beginning of next week).
Juk
08-06-2009
, 12:17 PM
OK, here is the first BETA test version of FPHG v3.00: http://www.jukofyork.com/FreePHG_Install_BETA.exe
Just download and install as you did with FPHG v2.0x - The format of the 'FreePHG.ini' file is exactly the same as before, but there are a few small changes/improvements to the user functionality (see below).
I haven't added the memory scanning fallback code yet as I've not had any feedback on whether it is satisfactory or not yet and also if the changes in this version fix the crash bug there will be no need for it (ie: Hooking >>> Memory Scanning). If it does turn out that it's needed then it's trivial to add to the new code (will need a couple more options adding to the INI to tune it though).
SYSTEM FUNCTIONALITY CHANGES FROM FreePHG V2.0x
USER FUNCTIONALITY CHANGES FROM FreePHG V2.0x
Please report back how you get on with this. Does it still cause Party to crash? Is the OBSERVED_ONLY mode working better? Is it working as expected with the OUTPUT_LIVE flag on and off (see above). Is there anything else I've messed up (not playing poker atm so only tested briefly on play money tables)?
Juk
Just download and install as you did with FPHG v2.0x - The format of the 'FreePHG.ini' file is exactly the same as before, but there are a few small changes/improvements to the user functionality (see below).
I haven't added the memory scanning fallback code yet as I've not had any feedback on whether it is satisfactory or not yet and also if the changes in this version fix the crash bug there will be no need for it (ie: Hooking >>> Memory Scanning). If it does turn out that it's needed then it's trivial to add to the new code (will need a couple more options adding to the INI to tune it though).
SYSTEM FUNCTIONALITY CHANGES FROM FreePHG V2.0x
- The code injected into Party's memory space now does the absolute bare minimum processing and then sends the raw data (via 'WM_COPYDATA' IPC code) to the FPHG process for processing.
- No files are opened or written to from within Party's memory space now.
- The hand processing within then FPHG process runs in a separate thread so can take advantage of machines with multiple cores (hardly makes any difference to the hook-based code, but will make a big difference for the memory scanning version if needed).
USER FUNCTIONALITY CHANGES FROM FreePHG V2.0x
- The new default location for storing hands is now just below the folder where FPHG is installed to (ie: ".\HandHistories"). It will still read the old v2.0x FreePHG.ini file and store to "C:\FreePHG_HandHistories", etc if it finds it.
- If the OBSERVED_ONLY flag is set then FPHG should no longer write out erroneous "hand headers" (ie: text up to the "** Dealing down cards **" line) for non-observed hands. It now waits to see what gets written after the "** Dealing down cards **" line and only starts writting the hand out if it's not the "Dealt to" line.
- If the OUTPUT_LIVE flag is not set then FPHG will no longer bother to create the "live" subfolder and will also only write out fully complete hands (ie: it won't write them out in real-time after every action, etc). This saves thrashing the hard disk when we don't care about the hands being written in realtime. This should also fix the problem of trackers reading partial hands (there may still be a tiny problem with side-pots getting written as an extra bit "tacked on" - I'll try and fix this in a later version).
- If the OUTPUT_LIVE flag is set the live subfolder will be created and removed on the fly as FPHG starts up and shuts down. This will mean that the folder won't be visible to "browse to" in HEM until after you start FPHG with the flag set.
Please report back how you get on with this. Does it still cause Party to crash? Is the OBSERVED_ONLY mode working better? Is it working as expected with the OUTPUT_LIVE flag on and off (see above). Is there anything else I've messed up (not playing poker atm so only tested briefly on play money tables)?
Juk
Last edited by jukofyork; 08-06-2009 at 03:01 PM.
Reason: Clarified new "OBSERVED_ONLY" flag functionality and bolded other important changes in user functionality.
08-06-2009
, 03:10 PM
08-06-2009
, 03:21 PM
08-06-2009
, 03:41 PM
Quote:
Haven't really tested it yet, just got it installed, but now as you are already working on the program, could you make it possible to define additional process(es) in the .ini file where the data would also be sent? This would make a bit more "cleaner" design possible for any 3rd party bet pot tool, because they wouldn't have to poll and scan the fphg output files. What do you think?
The big problem with this idea is the fact that the HH data being sent hasn't been processed (as it's the FPHG process that does all the processing) and you would end up having to do all of the same book-keeping as FPHG does.
There is no reason why the FPHG process couldn't transmit the processed hand history data to other processes using the same method, but I'm not 100% sure it wouldn't actually end up harder than just reading the file when a decision is required (do any applications actually poll the FPHG files?).
Juk
08-06-2009
, 03:47 PM
Quote:
I'm still picking up some anomalies in the handhistories, some examples:
Code:
Game #8308415312 starts. #Game No : 8308415312 ***** Hand History for Game 8308415312 ***** $2 USD NL Texas Hold'em - Thursday, August 06, 15:04:57 EDT 2009 Table Table 169497 (Real Money) Seat 3 is the button Total number of players : 9 Seat 9: FerrumVS ( $1.54 USD ) Seat 4: Liliah ( $0.40 USD ) Seat 8: Lonlilokli1 ( $4.16 USD ) Seat 7: SlowBlues ( $1.88 USD ) Seat 6: The_Hague ( $1.74 USD ) Seat 1: boroka333 ( $2.45 USD ) Seat 2: jasiu82 ( $0.37 USD ) Seat 5: noddy101 ( $0.98 USD ) Seat 3: z22036th ( $2.19 USD ) noddy101 posts small blind [$0.01 USD]. The_Hague posts big blind [$0.02 USD]. ** Dealing down cards ** SlowBlues folds Lonlilokli1 folds FerrumVS folds jasiu82 folds z22036th folds noddy101 calls [$0.01 USD] The_Hague checks ** Dealing Flop ** [ 6h, 4d, 6d ] noddy101 checks The_Hague bets [$0.08 USD] noddy101 folds cards. ue does not show cards. The_Hague wins $0.12 USD Game #8308417917 starts. #Game No : 8308417917 ***** Hand History for Game 8308417917 ***** $2 USD NL Texas Hold'em - Thursday, August 06, 15:05:40 EDT 2009 Table Table 169497 (Real Money) Seat 5 is the button Total number of players : 9 Seat 9: FerrumVS ( $1.54 USD ) Seat 4: Liliah ( $0.40 USD ) Seat 8: Lonlilokli1 ( $4.16 USD ) Seat 7: SlowBlues ( $1.88 USD ) Seat 6: The_Hague ( $1.76 USD ) Seat 1: boroka333 ( $2.45 USD ) Seat 2: jasiu82 ( $0.37 USD ) Seat 5: noddy101 ( $0.96 USD ) Seat 3: z22036th ( $2.19 USD ) The_Hague posts small blind [$0.01 USD]. SlowBlues posts big blind [$0.02 USD]. ** Dealing down cards ** Lonlilokli1 raises [$0.08 USD] FerrumVS folds jasiu82 folds z22036th folds noddy101 folds The_Hague calls [$0.07 USD] SlowBlues folds ** Dealing Flop ** [ 2c, 2d, 7d ] The_Hague bets [$0.10 USD] Lonlilokli1 calls [$0.10 USD] ** Dealing Turn ** [ Ac ] The_Hague bets [$0.40 USD] Lonlilokli1 calls [$0.40 USD] ** Dealing River ** [ 6h ] The_Hague is all-In [$1.18 USD] d in time.(disconnected) pond in time.(disconnected) Lonlilokli1 folds he_Hague does not show cards. The_Hague wins $2.31 USD Game #8308382832 starts. #Game No : 8308382832 ***** Hand History for Game 8308382832 ***** $2 USD NL Texas Hold'em - Thursday, August 06, 14:54:37 EDT 2009 Table Table 169623 (Real Money) Seat 8 is the button Total number of players : 8 Seat 7: Orbas123 ( $1.96 USD ) Seat 2: PharoahG ( $1.36 USD ) Seat 9: Zembonator ( $2.75 USD ) Seat 4: joaoZa ( $2.67 USD ) Seat 1: kabil888 ( $0.83 USD ) Seat 3: napaalm ( $2 USD ) Seat 8: nuuunja ( $0.46 USD ) Seat 6: twaxxo ( $2 USD ) Zembonator posts small blind [$0.01 USD]. osts big blind [$0.02 USD]. .02 USD]. ** Dealing down cards ** PharoahG folds napaalm folds twaxxo calls [$0.02 USD] Orbas123 folds nuuunja folds Zembonator calls [$0.01 USD] kalambaha has joined the table. kabil888 checks ** Dealing Flop ** [ 5s, Qd, Ad ] Zembonator checks kabil888 bets [$0.02 USD] twaxxo calls [$0.02 USD] Zembonator calls [$0.02 USD] ** Dealing Turn ** [ 9c ] Zembonator checks kabil888 bets [$0.02 USD] twaxxo raises [$0.13 USD] Zembonator calls [$0.13 USD] kabil888 calls [$0.11 USD] ** Dealing River ** [ Ah ] Zembonator checks kabil888 checks twaxxo bets [$0.36 USD] Zembonator calls [$0.36 USD] kabil888 calls [$0.36 USD] twaxxo shows [ 9h, 9d ]a full house, Nines full of Aces. Zembonator doesn't show [ 4c, 5h ]two pairs, Aces and Fives. kabil888 doesn't show [ 7d, Qh ]two pairs, Aces and Queens. twaxxo wins $1.52 USD from the main pot with a full house, Nines full of Aces.
The problem is that you are fishing hands out of memory where new hands write over the top of old ones and bits of hands get copied about and they can end up "looking like" valid hand histories. The only surefire solution to this would be to parse every hand history you find and strictly reject any that don't pass the parser, but then you would get the opposite problem where any tiny change in the hand history format or addition of a new game would cause hands to get rejected (not to mention the added work of maintaining it all).
Juk
08-06-2009
, 04:25 PM
08-06-2009
, 04:32 PM
Juk
08-06-2009
, 07:09 PM
It's just struck me that the HEM HUD causing the Party client to freeze up probably isn't anything to do with FPHG. If the HEM HUD uses a trick like using SetParent() to attach it's HUD window(s) to the tables then when the HEM HUD process hangs it will also cause the Party process to freeze as all of the message queues will stop working.
I've actually seen this happen myself when I tested different methods of attaching HUD windows to the tables a few years ago and the fact you say that killing the HEM HUD process quickly stops the Party client from killing itself reminds me of this too (ie: you used to get about 4-5 seconds before the Party client would think it's frozen and try to restart itself).
It may still be that something is happening between FPHG's output files and HEM (ie: some "war" over locked files or something), but it's not really the fault of FPHG if the crash occurs inside of HEM and is caused by HEM reading the FPHG files. If this is the case them it might be a good idea for HEM to first make a temporary copy (using OS calls like C's system("copy xxx yyy") command) of a file it wants to read.
There is a different "crash bug" that is different to this HEM HUD one. The people who got this were the same people got strange graphical and UI "glitches" in the client after a certain update in Jan/Fen this year, but then the same problem seemed to turn into the "crash bug" later on in the year.
Peter who posted earlier reported that even FPHG on it's own could cause it and I'm pretty sure others who only use FPHG with BetPot have also had this.
Juk
I've actually seen this happen myself when I tested different methods of attaching HUD windows to the tables a few years ago and the fact you say that killing the HEM HUD process quickly stops the Party client from killing itself reminds me of this too (ie: you used to get about 4-5 seconds before the Party client would think it's frozen and try to restart itself).
It may still be that something is happening between FPHG's output files and HEM (ie: some "war" over locked files or something), but it's not really the fault of FPHG if the crash occurs inside of HEM and is caused by HEM reading the FPHG files. If this is the case them it might be a good idea for HEM to first make a temporary copy (using OS calls like C's system("copy xxx yyy") command) of a file it wants to read.
There is a different "crash bug" that is different to this HEM HUD one. The people who got this were the same people got strange graphical and UI "glitches" in the client after a certain update in Jan/Fen this year, but then the same problem seemed to turn into the "crash bug" later on in the year.
Peter who posted earlier reported that even FPHG on it's own could cause it and I'm pretty sure others who only use FPHG with BetPot have also had this.
Juk
08-06-2009
, 07:31 PM
I just had a quick hunt on the HEM forums and found a post in this thread about the HEM hanging issue:
So it looks like it's corrupted output from FPHG that is causing HEM HUD to lock up and that in turn is causing the Party client to freeze and then try to kill/restart itself (ie: in the way I mentioned above).
There is very little I can do to help fix this as the corrupted output is just a side effect of fishing hands out of memory (it must just be that a recent Party update caused HH data to corrupt in a way that really upsets HEM HUD when it reads it).
Another option is to fish about more inside of Party and see if I can find a better function to hook which is only called once per piece of hand data (the current function copies the same bits about quite a bit and sometimes even copies bits of random memory about that happen to have hands in).
I'm still interested in hearing from people who get the crash bug that is unrelated to the HEM HUD (ie: those who don't use HEM HUD or crashes that aren't preceded by HEM HUD locking up and freezing the Party client).
Juk
Quote:
There logs I got from Bezille seemed to indicate his problem was confined to live tracking. These problem happen because a recent Party update causes FPHG to output mangled lines to the live folder. Going back to 1.7 wouldnt fix this.
There is very little I can do to help fix this as the corrupted output is just a side effect of fishing hands out of memory (it must just be that a recent Party update caused HH data to corrupt in a way that really upsets HEM HUD when it reads it).
Another option is to fish about more inside of Party and see if I can find a better function to hook which is only called once per piece of hand data (the current function copies the same bits about quite a bit and sometimes even copies bits of random memory about that happen to have hands in).
I'm still interested in hearing from people who get the crash bug that is unrelated to the HEM HUD (ie: those who don't use HEM HUD or crashes that aren't preceded by HEM HUD locking up and freezing the Party client).
Juk
08-07-2009
, 07:28 AM
New BETA test version of FPHG v3.02: http://www.jukofyork.com/FreePHG_Install_BETA.exe
The changes in this version concentrate on trying to avoid writing corrupted hand data as much as possible. I think that at least some of the corrupted hands were to do with the "this player will use his time bank" and "this player has been disconnected" type message, but I'm not 100% sure sure.
Be on the lookout for (and post here) hands that still have corrupted data in them. If possible, please post the "real" hands history generated by Party to compare with (ie: for non-observed hands) as this helps me see any text that is getting delayed (ie: delayed output gives other stuff chance to write junk over the hand).
Also since I've made some of the matching even more strict there is a possibility that some valid hands will get rejected - be on the look out for any hands which just get totally ignored by FPHG (again try to post the "real" hands history when possible).
I still haven't heard from anybody who used to get the crash-bug whether the new method in V3.0x has actually fixed it or not so still interested in hearing about that (note though that the HEM HUD hanging thing is not the same as the crash-bug - see the above 2-3 posts).
NOTE: General info about the changes made in FPHG V3 can be found in this post.
Juk
The changes in this version concentrate on trying to avoid writing corrupted hand data as much as possible. I think that at least some of the corrupted hands were to do with the "this player will use his time bank" and "this player has been disconnected" type message, but I'm not 100% sure sure.
Be on the lookout for (and post here) hands that still have corrupted data in them. If possible, please post the "real" hands history generated by Party to compare with (ie: for non-observed hands) as this helps me see any text that is getting delayed (ie: delayed output gives other stuff chance to write junk over the hand).
Also since I've made some of the matching even more strict there is a possibility that some valid hands will get rejected - be on the look out for any hands which just get totally ignored by FPHG (again try to post the "real" hands history when possible).
I still haven't heard from anybody who used to get the crash-bug whether the new method in V3.0x has actually fixed it or not so still interested in hearing about that (note though that the HEM HUD hanging thing is not the same as the crash-bug - see the above 2-3 posts).
NOTE: General info about the changes made in FPHG V3 can be found in this post.
Juk
08-08-2009
, 09:24 AM
New BETA test version of FPHG v3.03: http://www.jukofyork.com/FreePHG_Install_BETA.exe
The main change in this version is the addition of a "fallback" memory scanning mode for those who still suffer from Party client crashes:
"Passive Mode" (default)
In this mode the code works just like it always did (ie: it will grab the hands from Party using an injected DLL). Unless you suffer from Party client crashes and/or Party client "glitches" then you should stick to using passive mode as it uses much less CPU time and writes the hands out almost instantaneously.
"Active Mode"
In this mode the code will actively scan Party's memory for hands (ie: no DLL is injected so there is no possibility of crashing the Party client). To enable active mode then you need to open up "FreePHG.ini" and set the USE_ACTIVE_MODE flag to 1. The default scanning delay and thread priority should be fine for most users, but if you wish to only use FPHG for background data-mining then setting the ACTIVE_DELAY value to 3000 or 5000 would mean it uses a lot less CPU time. On the other hand if you have a fast CPU and/or a multi-core CPU and use FPHG for BetPot (or anything else that needs the output updated very quickly after each player's action) then you might want to try setting the ACTIVE_DELAY value to 300 or 500.
NOTE: Custom settings in the "FreePHG.ini" will need to be re-set after installing this version as your old "FreePHG.ini" will be overwritten by the installer.
NOTE: General info about the changes made in FPHG V3 can be found in this post.
Juk
PS: I will update the main FPHG page and change the installer on that page as soon as I get some feedback on v3.03 (I'm not planning on any more major changes to FPHG now and just need to know if all the changes I have made are working OK and also if the default settings for the new "Active Mode" are OK for most people).
The main change in this version is the addition of a "fallback" memory scanning mode for those who still suffer from Party client crashes:
"Passive Mode" (default)
In this mode the code works just like it always did (ie: it will grab the hands from Party using an injected DLL). Unless you suffer from Party client crashes and/or Party client "glitches" then you should stick to using passive mode as it uses much less CPU time and writes the hands out almost instantaneously.
"Active Mode"
In this mode the code will actively scan Party's memory for hands (ie: no DLL is injected so there is no possibility of crashing the Party client). To enable active mode then you need to open up "FreePHG.ini" and set the USE_ACTIVE_MODE flag to 1. The default scanning delay and thread priority should be fine for most users, but if you wish to only use FPHG for background data-mining then setting the ACTIVE_DELAY value to 3000 or 5000 would mean it uses a lot less CPU time. On the other hand if you have a fast CPU and/or a multi-core CPU and use FPHG for BetPot (or anything else that needs the output updated very quickly after each player's action) then you might want to try setting the ACTIVE_DELAY value to 300 or 500.
NOTE: Custom settings in the "FreePHG.ini" will need to be re-set after installing this version as your old "FreePHG.ini" will be overwritten by the installer.
NOTE: General info about the changes made in FPHG V3 can be found in this post.
Juk
PS: I will update the main FPHG page and change the installer on that page as soon as I get some feedback on v3.03 (I'm not planning on any more major changes to FPHG now and just need to know if all the changes I have made are working OK and also if the default settings for the new "Active Mode" are OK for most people).
Last edited by jukofyork; 08-08-2009 at 09:35 AM.
08-08-2009
, 10:15 AM
Quote:
New BETA test version of FPHG v3.03: http://www.jukofyork.com/FreePHG_Install_BETA.exe
Juk
08-09-2009
, 05:35 AM
08-09-2009
, 06:29 AM
Quote:
Played for awhile with the FreePHG_v3a version. Has the same problem and solution as has been mentioned before. The first two times it froze I killed HM Hud immediately and it was solved. The third time I waited for about half a minute, nothing happened and then when I killed HM Hud everything was fine again, except I had missing buttons on one table.
Playing without HM Hud seemed to give no problems and it also seemed to react better. With the Hud it was kind of slow with pot sized bets, UTG it even often just made it 0.00 and if I then waited and tried again it still didn't work. Without HM Hud I didn't seem to have this problem.
Playing without HM Hud seemed to give no problems and it also seemed to react better. With the Hud it was kind of slow with pot sized bets, UTG it even often just made it 0.00 and if I then waited and tried again it still didn't work. Without HM Hud I didn't seem to have this problem.
Can you try FPHG v3.03 (see above) to see if that works any better? It does more strict sanity checks than earlier versions so should be less likely to pass through corrupted data which HEM HUD doesn't like.
If possible try the first session with USE_ACTIVE_MODE left at 0 as this will work much better overall (but only if the crash bug has been fixed).
If this still causes the crash bug (ie: the one unrelated to HEM HUD) on your PC then you'll have to set USE_ACTIVE_MODE to 1 which will mean it scans memory like FreePHG_v3a did (except it has more strict sanity checking).
If this proves to be unresponsive you can then try to tune the ACTIVE_DELAY value down to say 500 and also try setting the ACTIVE_PRIORITY value to 0 or 1.
Juk