New Stats unavailable to HUD

[andyco]

I've created a handful of new stats and got them working properly in the reports.

Unfortunately, when i try to add them to the HUD, via the HUD Configurator/Profile Editor, the new stats are not listed
in the list of stats to add to the profiles. I noticed that if i create the same Stat passing the Column info through
variables, that the Stat now becomes available to the HUD Config.... :?: :?:

[*]Is this a know limitation of how the HUD or cache works?
[*](if so) Can anyone explain this limitation, so i can anticipate what data/calculations i should be doing where (columns vs. variables vs stats)?
[*]Is this a known bug

Thanx

ps -- have already updated/rebuilt/... cache several times, tried on both 3.08 and 3.09 versions, made sure i was entering in
playersstatistics section, and everything else i can think of. ...

[WhiteRider]

It might depend on exactly what your stat and column expressions are. What kind of stats have you added? Were they based on existing stats?

If you make a Backup of just the default Optional Files and attach it to a Support ticket and tell us the names of the stats that you're having problems with we'll check them out.

[andyco]

I was hoping that i'd run into some known limitation or subtlety that would easily explain what i've run into.... didn't want you guys to have to
respond, track and manage a "ticket", so let me explain the scenario a bit more... (hoping to trigger some known/existing knowledge)

Here's 2 specific stats: (one which is available to HUD Profile Editor (Hand Group 1%), one which is not (Hand Group 3%)
They are effectively the same stat -- referencing the same columns and using the same calculations.

Columns:
name: id_hc_led_grp
expression:
if[ id_holecard = 1 OR id_holecard = 2 OR id_holecard = 26, 1 ,
if[ id_holecard = 49 OR id_holecard = 70 OR id_holecard = 89 OR id_holecard = 3, 2 ,
if[ id_holecard = 106 OR id_holecard = 121 OR id_holecard = 4 OR id_holecard = 6 OR id_holecard = 5, 3 ,
if[ id_holecard = 134 OR id_holecard = 145 OR id_holecard = 154 OR id_holecard = 8 OR id_holecard = 27 OR id_holecard = 7, 4 ,
if[ id_holecard = 161 OR id_holecard = 165 OR id_holecard = 169 OR id_holecard = 29 OR id_holecard = 50 OR id_holecard = 9 OR id_holecard = 28, 5 ,
if[ id_holecard = 31 OR id_holecard = 52 OR id_holecard = 73 OR id_holecard = 90 OR id_holecard = 107 OR id_holecard = 30 OR id_holecard = 71, 6 , 9 ] ] ] ] ] ]
(this is used to identify/assign a "starting hand grouping" value/id of 1-6 & 9. the resultant column/value is used in the following/below Columns to
count the # of hands which fall into each of the 7 groups. This equation/expression seems to work properly -- as it produces the correct output in all reports
and is used in BOTH Stats - the one which is showing available to the HUD and the stat which does not show available)

name: cnt_hc_grp_led_1
expression: sum( if[ id_hand_led_grp = 1 , 1 , 0 ] )
name: cnt_hc_grp_led_3
expression: sum( if[ id_hand_led_grp = 3 , 1 , 0 ] )

Variables:
name: var_cnt_led_1
expression: cnt_hc_grp_led_1

(Custom) Stats:
name: Hand Group 1%
expression: ((var_cnt_led_1 / cnt_hands) * 100)
format exp: format_number( (var_cnt_led_1 / cnt_hands) * 100, 1, false, false)

name: Hand Group 3%
expression: ((cnt_hc_grp_led_3 / cnt_hands) * 100)
format exp: format_number( ((cnt_hc_grp_led_3 / cnt_hands) * 100), 1, false, false)
cnt_hands and id_holecard are both default columns.

The stat (Hand Group 1%) with the data "passed thru" the variable is available to the HUD Profile editor,
yet the second stat (Hand Group 3%) is not. The only difference which i can discern is that one
is calling the Column (cnt_hc_grp_led_3) directly, while the other "launders" the value through a variable
(var_cnt_led_1).

Please tell me that "you've seen this before", or that "it rings some bell", .... I'm baffled....

[kraada]

Grouped by statistics should not be available in the HUD. This is the first I've heard of one being available using a variable as a pass through. Your stat will work just fine in reports, but won't work in the HUD because the HUD isn't designed to handle grouping by. I'm curious though - what actually does happen when you add the stat with the variable to your HUD? Do you get meaningful data or does everything fall apart?

[andyco]

Kraada - thanx for the answer.

1st -- make sure we're on the same page: when you say

Grouped by statistics should not be available in the HUD

id_holecard is the only column i'm using which is "grouped by"...
I'm using it to so as to "count the number of hands which have specific holecards (id_holecard = ##)". Is this not legal for stats used within HUD?
Unless I'm completely mis-understanding something, i'd expect that this is not unusual: PT3 seemingly has existing default Stats which are available to
the HUD and reference "group by" columns.
Player (str_player_name), Position (position), Days Played (date_played), etc...

I suspect that this may be more of an artifact of SQL, than it is of PT3... and i'm NOT a db/sql guru, so can you tell me if:
2) Is there more documentation on exactly how/where the "group by" data can be used for other columns, variables and stats?
3) Is there an simple explanation for why/how the 'group by' data is used in reports (successfully) and in the HUD/cache (unsuccessfully)?
4) Are there workarounds which allow the transformation of 'group by' data to an alternate format or structure, which would then allow
that info to be processed for Stats within the HUD?
a) is there examples for ways of working around this?
b) is it simply fixed by moving the calculations/references further downstream ( to Variables or Stats directly, instead of within columns)?
(that sounds too easy ;-)


btw -- the stat does not crash or hang anything. Both stats work fine on reports. The "variable based"
stat shows up on the HUD, but frankly i haven't checked to see if it's producing the correct data yet (since i
was trying to complete the rest of the set before cycling the # of hands needed to validate the actual counts & % ...
which brings me to my next question:

is there an easier way of testing/debugging the HUD layout & stats, other than having to fire up a live Session on
a Site and actively play multiple hands of poker? Is there any sort of debug environment which can simulate playing
a few hands to see how the new HUD/Stat improvements look? Playing against a dummy client, or software (ala Poker Academy or simulated
game s/w...)..

a lot of questions, i know, would like to get as much info as possible before heading back down to the cave....
thanx in advance,

[kraada]

I believe the only statistics that will work properly when grouped by in the HUD are those which the cache also groups by.

A little explanation on grouping by:

When PostgreSQL groups results by a certain value, the resulting rows are combined together according to the grouped value. So for example, if you have a table which has a person's name, their age and the city they live in, you can select for average age grouping by city - then you'll see one row output per city with the average age for each group. Or you could select for the count of each city grouping by age and see that 3 people who are 29 live in Los Angeles. I'm aware this is a little fast, so a more in depth treatment of grouping by with further examples can be found here.

The reason we cannot use grouped by results in the HUD is that we want to see one individual number for each statistic shown on the table.

Imagine we're looking at data for a tournament and you built a column to group a player's hands by blind level. If you add that to your query and then want his VP$IP you'll get one answer per blind level that's in the database - which PT3's HUD is not designed to display. In reports we can display the results of any PostgreSQL queries - you'll just see more rows. But on the HUD each stat needs to return exactly one value and grouping by breaks that dynamic. We do have some groupings built into the cache so that we can get certain data - for example by position. But that required extra complexity and in turn creates a slower cache. Breaking the data down into further and further subsections in the cache will quickly defeat the purpose of a cache entirely.

You won't be able to work around these limitations as far as I'm aware, and I'm fairly certain that with the exception of a few hard coded stats which are allowed through (e.g. player name), grouped by stats in general are disallowed from the HUD (and btw - Days Played does not group by).

With regards to generally editing your HUD you can see your HUD on the Replayer so long as you have Auto Import not running. You'll see the data on the replayer that you would have seen at the time of the hand in question.

[andyco]

thanx for the quick reply, kraada....

i do understand your explanation of "group by" functionality in principal.
however, i don't understand where my implementation is breaking these rules.

Let's take your example in the Adv HUD FAQ/example of "Creating Hand Range Popups",
http://www.pokertracker.com/forums/viewtopic.php?f=45&t=11188&p=86924#p148871

Now we can start building. We can build cnt_limp_show_aa: sum( if[holdem_hand_player_statistics.flg_p_limp AND
holdem_hand_player_statistics.id_holecard = 1, 1, 0]) then cnt_limp_show_aks: sum( if[holdem_hand_player_statistics.flg_p_limp AND
holdem_hand_player_statistics.id_holecard = 2, 1, 0]) ...
We also need to build cnt_limp_known: sum( if[holdem_hand_player_statistics.flg_p_limp AND holdem_hand_player_statistics.flg_showdown, 1, 0]) ...
... we can build the statistics: (cnt_limp_show_aa / cnt_limp_known) * 100 will be the percentage of hands that he player limped and showed that were AA...

you're creating columns which reference the same "group by" data/columns which i'm referencing (id_holecard or HTTPS.id_holecard)
for the same purpose of comparing and counting instances of a holdings occurance.
This is exactly what i'm doing (or trying to do) - but instead of 169 groups (1 for each hand), i've reduced it to a handful (6 total).
This example is largely what i was basing my approach upon:
a) test if holecard matched any of 6 cases (your example has 169 cases)
b) count the number times a) happens
c) produce a % stat of this cnt b) / all cases...

The only difference i can see is that I've created an intermediate column (id_hc_led_grp) to store the integer group/case# of each hand,
so as to keep the definition and code for the 6 cases in the 1 place and not in each of the 6 columns (cnt_ ...) I have NOT selected "group by" when creating this column...

starting to bleed a bit from the serious head scratching....
thanx again!!

(additionally - thanx for the HUD-replayer point.... i was not aware of that !?!?
It will be HUGELY helpful -- until now, i'd been playing, very poorly & distracted, cheap games while debugging the HUD :lol: )

[kraada]

Columns cannot be referenced effectively in other columns for addition the way you want to do it - it just doesn't work with the way the queries and the cache are currently generated.

I agree it would certainly be nice and I've talked to the development team in the past about working in these features, but I don't know if or when they'd be added.

[pasita]

When I do the following it works fine in the HUD.

Or is this something you want to avoid because of

so as to keep the definition and code for the 6 cases in the 1 place and not in each of the 6 columns

Code: Select all

columns:
cnt_hc_grp_led_1:
sum( if[ holdem_hand_player_statistics.id_holecard = 1 OR holdem_hand_player_statistics.id_holecard = 2 OR holdem_hand_player_statistics.id_holecard = 26, 1,0])

cnt_hc_grp_led_3:
sum( if[holdem_hand_player_statistics.id_holecard = 49 OR holdem_hand_player_statistics.id_holecard = 70 OR  holdem_hand_player_statistics.id_holecard = 89 OR holdem_hand_player_statistics.id_holecard = 3, 1,0])

stats:
Hand Group 1%:
(cnt_hc_grp_led_1 / cnt_hands ) * 100
Hand Group 3%:
(cnt_hc_grp_led_3 / cnt_hands ) * 100

[kraada]

Yes that approach works, but it gets very tedious to write stats that way.