adding columns to tables

[pasita]

When I create a column with PT3, it should go to cache automatically? Well, now that I once again recreated, they went to cache, no idea what changed. Is there a property in a column that makes PT3 determine whether it'll be cached or not?

All of this is in section HCPS.

I have two columns created in PT3:
a: player.a
b: player.b

Neither is grouped by.

I have two columns I've created outside PT3 to table player, player.a and player.b. I've inserted numeric data into both.

I can make a stat
mystat: (a / b) * 100

Now this stat can't be used in a report (complains about group by) but when I either change my columns to group by or change a: avg(player.a), I get good values in my report. (I can use avg or max or similar, as it's only one value per player, regardless of the cache groupings.)

I can add the stat to HUD. Result is that the HUD group where I have the stat in isn't shown*. Sometimes also another HUD group disappers (I have 3). This is regardless of whether I use avg (see above) or not; if using "group by" for my columns the stat isn't usable in hud (as expected).

* But I have seen this stat work in my HUD when setting things up. This is probably during a time when I didn't have all the selfmade fields in table player populated, but had only 1 or two players have their player.a and player.b columns filled with a value. Can this have something to do with the cache groupings?

[kraada]

If you use avg(player.a) do you still get the same results in the HUD?

[pasita]

Yes, avg doesn't change the results or the behaviour.

Ok followed this further. Getting weirder all the way.

In my HUD options I have Refresh rates set up for 1 for 0...25, 5 for 25...100 and so on.
When I step through the first hands (on replayer) I have on a person, the group that has my own stat hangs on just fine. Then after I hit hand 26, only one group of three remains. Having stepped up to 30, they all pop up again (and the hand count -which is in the group that stays visible-updates). Two groups promptly disappear when I step further but show up every fifth hand.

If I remove my culprit of a stat from one of the groups, none of the groups disappear when I hit 26, hand count just stops updating (as expected) till I hit 5 more.

[kraada]

That is definitely odd, however as I said originally at the start of this thread, PT3 was not designed to be accommodating of extra data so it is not entirely surprising that there are strange behaviors associated with this sort of setup.

I'm curious though - if you use player.val_icon in a stat, do you see the same behavior (player.val_icon is an integer that is linked to a player's icon status - so it defaults to values between 0 and 16)?

[pasita]

I tried val_icon and id_player from table player. No disappering groups but the HUD displays nothing except one empty space (rest of the stats in the group on the same line move one char right- I don't have grid on). No tooltip or anything.
BTW, I built a column in PT3 (mycol3: player.id_player), the editor didn't say anything about "you have to update cache to use this in hud", nor did the new columm apper in holdem_cache (checked via pgadmin).
When I changed it to mycol3: avg(alayer.id_player), the cache promt came up. Column shows up in cache. No change in behaviour any way.

[pasita]

player_real is the real player name with original case and not the main alias name (which is used when you have linked screennames with aliases).

Actually, I meant the table player_real that pops up sometimes when working with stats... What's this about, couldn't find anything relevant with search.

[kraada]

I'm not certain exactly how player_real works but I'll see what I can find out for you - it's not an actual table in the database.

[Lythande71]

Hey pasita,

probably can jump in here to help.
You asked me in viewtopic.php?f=18&t=34111 to report my findings regarding the HUD working not properly.

I did something similar. I manually added columns to player table to create a totally self customized player rating --- but that's not of interest here.

Unfortunately after 2 years of successfully using these new fields suddenly the HUD stopped working. It stopped showing hero's stats.
All i did was creating new stats from built in columns.

After days of research supported by WhiteRider and others (Mike) we found the reason:

Sry, bad news: The root cause of all HUD problems were those manually added fields.
They seem to do no harm as long as you do not try to use them with complex built in functionality. Since those customized fields are only considered in some but not all built in SQLs.
I.e. Simply displaying their values in HUD or reports may work, or may not work. But they are definitely causing errors that you can find in one of the two logfiles.
Just check your logfiles, and if you are somewhat familiar with SQL you will find that your columns are not properly included. (Either they reference to a wrong alias used in FROM clause or completely jam the Group By clause.
As I said mine worked properly for more than 2 years without doing any obvious harm. But since they are not considered correctly from built in functions they definitely caused errors all the time. Most common error for example is that they prevent the HUD from using the cache or (as in my example) stop displaying Hero's stat.

To solve that you dont have to delete the colums in the table itself hence you keep all your data stored in them. But you have to remove any reference to them in "custom stats", i.e. remove them from any column, any variable and any stat including expressions, formatting and color conditions.

I am almost certain that anything you wanted to achieve with them can be done with another approach only using already existing fields. e.g. since I don't use 'auto rate' and dont give much for the icons I stored all my custom data in player.val_icon instead of using my manually added fields. Perhaps you can think of something similar.

If you can describe what you are trying to achieve with your fields I can try to help you how to store this data in and retrieve it from player.val_icon.

HTH

[Lythande71]

I'm not certain exactly how player_real works but I'll see what I can find out for you - it's not an actual table in the database.

As far as I understood in that context it's just an alias for table player used in some SQLs.

[pasita]

Hey, thanks for the info.

Basically what I'm trying to overcome here is the PT3 bug of really slow queries to table holdem_hand_player_combinations, which makes it impossible to use those in hud (1 I can do with, 2 renders my hud update speed totally useless). So I'm guerying some data from there offline (thanks Gatech !!) and storing it in table player, to be used in some custom stats in my hud.

I originally put the data in the players notes, but since the notes box is also an unfortunate mess in PT3 -to put this in a kind way- I decided to try making extra columns in table player.

I guess I'll try putting my extras in another table that gets queried always... hhpd would seem a likely hit.