"max. Players on Waitinglist-function" is not working on FTP since update!

[Placebo]

Though I have setted up that only tables are scanned with max. 1 Player on the waitinglist, this is not more working since the FTP-update.

any ideas?

best regards,
Placebo;)

[Zandry]

Yes, well the whole point of that filter is to make the scan faster, and skip tables with a waitinglist that exceeds your filter. But with the new FTP, we have no way of knowing how many people are on the waitinglist, until we have already selected the table, and waited for the player list to load.

So the way it's always worked is, TST tries to filter the table from the data in the table list in the lobby, then TST reads the players and scans the table.

But now there is no waitinglist # in the table list, so if I make the waitlist filter work again, it will have to try and filter the table again, after it has already been filtered and scanned from the lobby, then just not display the table in tablescan, even though all the work of scanning the table has already been done. The result would be that the scan would take the exact same amount of time as it does now, but it would just actually read in way less tables.

For example, it would appear to you that you've scanned 100 tables lets say, but in fact TableScan would only display 30-40 of them to you, and the amount of time it would take to scan would be the same.

So the question is should I implement that filter anyways? Would anyone still want to use it if it functions in the described way? Or would it cause confusion?

I think now people would be better served to create a "Table List" filter (Configure > List Filters) for # of Waiting (0-1). Because since you already have to scan all the tables anyways, you might as well just let it do the last step and add the table to TableScan, that way your # of Tables and # of Multi-Tablers will be more accurate

[Placebo]

Yes, well the whole point of that filter is to make the scan faster, and skip tables with a waitinglist that exceeds your filter. But with the new FTP, we have no way of knowing how many people are on the waitinglist, until we have already selected the table, and waited for the player list to load.

So the way it's always worked is, TST tries to filter the table from the data in the table list in the lobby, then TST reads the players and scans the table.

But now there is no waitinglist # in the table list, so if I make the waitlist filter work again, it will have to try and filter the table again, after it has already been filtered and scanned from the lobby, then just not display the table in tablescan, even though all the work of scanning the table has already been done. The result would be that the scan would take the exact same amount of time as it does now, but it would just actually read in way less tables.

For example, it would appear to you that you've scanned 100 tables lets say, but in fact TableScan would only display 30-40 of them to you, and the amount of time it would take to scan would be the same.

So the question is should I implement that filter anyways? Would anyone still want to use it if it functions in the described way? Or would it cause confusion?

I think now people would be better served to create a "Table List" filter (Configure > List Filters) for # of Waiting (0-1). Because since you already have to scan all the tables anyways, you might as well just let it do the last step and add the table to TableScan, that way your # of Tables and # of Multi-Tablers will be more accurate

Ok, cool - your last recommendation works for me good enough - thx;)