adding columns to tables

[Lythande71]

How many extra fields to you use.
How does the data they hold looks like? Only integer values or even strings?

[pasita]

I've got about 20 so far. Integer data but planning to go strings also.

BTW, when you were figuring out the problem: was it because there were some added colums to begin with, or the fact that you were also using table player which doesn't get queried everywhere one might expect? If the latter, using another table might help... if the former, please give more details if you found some.

[Lythande71]

....or the fact that you were also using table player which doesn't get queried everywhere one might expect?...

The latter.
But I wouldn't conclude that its the fact that player table doesnt get queried everywhere one might expect. Its more the fact that the extra columns are not considered within those queries correctly. Hence these queries fail...hence it looks like they don't exist where you expect them....
One more thing: You mentioned that playing around with refresh rates didn't show much effect. This doesn't surprise me: Your extra columns are likely preventing that HUD uses the cache table at all. Probably thats the cause for the slow performance u are experiencing.


Hm, 20 fields is too much, i.e. abusing player.val_icon would not work for you. Sry.

[WhiteRider]

Just reference – as I understand it "player_real" is the ID of the original site-specific player, and is used when screen names aliased together if we need access to the original player rather than the alias.

[pasita]

Not following,sry.

When I build a column to section HCPS, I can click insert and get Available database fields:
player_winner
player_lo_winner
player_real
(and a bunch of other stuff).

I know table player holds the unique name and doesn't group aliases. I don't know what player_real (and the two others) hold as I can't query them directly from the database as such tables don't exist. They all do seem to hold the columns I've added (directly, outside PT3) to table player.

[pasita]

One more thing: You mentioned that playing around with refresh rates didn't show much effect. This doesn't surprise me: Your extra columns are likely preventing that HUD uses the cache table at all. Probably thats the cause for the slow performance u are experiencing.

The situation with stats appearing only when the refresh was due was with replayer... which shouldn't use cache at all. Or maybe it does store something in the cache between refreshes?

Any way, as all of this seems to be because we both were unlucky enough to use table player for the extra data, I guess this is becoming a bit useless, other than academic point of view:) I'll be going for another table when I have the time, I'll keep you all posted if that works better.

[Lythande71]

Ya, your are right it has become a bit academical discussion. Its always hard to blindly guess how an individual setup really looks like. Good luck with your approach using a new table.

[kraada]

Ah I see now - imagine we are player with id 1 and we have an alias as well, and that alias was created from id 17. player_real.id_player is 1 if we're playing at our primary site, and player_real.id_player is 17 if we are playing as our alias.

[pasita]

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

Note to self (and any one interested): I didn't have anything in my hud groups that referers table player, other than my self made stats using self made columns in table players. When I added stat Player Icon to one of my hud groups, the selfmade stats (in all of my groups) stopped misbehaving, i.e no blinking in the replayer hud. So once there's a query to a PT3 default stat in table player, it would seem the (very) custom columns can be used too.

[kraada]

That's good to know - thanks for following up!