I would actually understand if skill is never implemented into the vanilla ns2 scoreboard, even if I would prefer it to happen eventually. Force even teams can always be used to balance a game. And mods can always be created for server operators who prefer these skill values to be visible.
Individual skill levels on the scoreboard would be horrible from a social standpoint. But it would be nice to see the teams' average skill levels displayed. These should only be shown as soon as that team has a minimum number of players, though - otherwise, it's the same as showing individual levels.
(Yes, I know you can get these values from Hive, too. But there's some effort in fetching them, which prevents the "lazy blaming" which will happen if they are on the scoreboard.)
This might have been answered already, but are the games being played at the moment going to contribute to the skill system when it's finally fixed or will there have to be another skill reset/ will we be effectively starting over?
The search works for me... As long as I put in their exact name, as it appears in NS2 :P
Agreed, it could stand to be slightly better.
That's the issue, you have to write the exact nickname of the guy you're looking for. Should be better if searches needed a bit less details. For instance, you typed the start of the nickname, you gonna find all relative users with these letters or something.
It depends on the collation of your column (or database). If it is case sensitive, then LIKE is case sensitive, if it's not, then LIKE is not. Apparently the hive database is case sensitive, so either change the collation or use UPPPER / LOWER.
PSA: You should really use prepared statements instead - it's both safer & faster.
mysql_real_escape_string() is making it save against SQL-Injection and because we're only excecuting one statement, "prepared statements" are slower because of the additional round-trip to the server.
B2T: Skill system seems to be fixed, but it feels like the "time" part has not been included yet I can join a nearly finished game or have another of those crashes but hive subtracts a full lot even if I was only a minute on a server.
It depends on the collation of your column (or database). If it is case sensitive, then LIKE is case sensitive, if it's not, then LIKE is not. Apparently the hive database is case sensitive, so either change the collation or use UPPPER / LOWER.
PSA: You should really use prepared statements instead - it's both safer & faster.
mysql_real_escape_string() is making it save against SQL-Injection and because we're only excecuting one statement, "prepared statements" are slower because of the additional round-trip to the server.
B2T: Skill system seems to be fixed, but it feels like the "time" part has not been included yet I can join a nearly finished game or have another of those crashes but hive subtracts a full lot even if I was only a minute on a server.
In this case yes, but not entirely true.
It can save time when sub-parts of the query computing are always the same. Meaning, dealing with some tables the same way every time. For a query that deals with millions of lines, you can see the change.
Usually it's rather difficult to get this to work efficiently as it requires a compatible data model, and / or the query that can be a good candidate. We don't deal with millions of line every morning is it ?
PSA: You should really use prepared statements instead - it's both safer & faster.
mysql_real_escape_string() is making it save against SQL-Injection [...]
Yes, of course. But the real reason why manual input escaping is unsafe is because it's easily messed up in maintenance. Somewhere along the line, another developer will add a new feature (sorting, for example), and he may forget to add escaping. One instance of this is enough to compromise the whole application. That's the long-term security risk that is completely eliminated by prepared statements.
If the query is as trivial as this one, it's still manageable. But if developers get the idea that manual escaping was proper practice, they *will* use it on bigger queries. Hence the PSA.
[...] and because we're only excecuting one statement, "prepared statements" are slower because of the additional round-trip to the server.
When I said that they are faster, I meant faster in general. But even in this single-statement case, I suspect that caching the prepared statement will save more time than the additional round-trip costs. In small setups (like a LAMP stack), the database will be on the same machine anyway, so the network overhead is very low.
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
I think there are still some issues with it. Not enough to require a reset of the skills, but it's not quite working properly yet. I'm talking to Acedude, and we'll hopefully have it sorted out soon.
Comments
(Yes, I know you can get these values from Hive, too. But there's some effort in fetching them, which prevents the "lazy blaming" which will happen if they are on the scoreboard.)
It has been doing that since long before CDT was a thing.
I've also wondered why.
I do prefer @IronHorse's answer. don't take it too bad.
Edit: MrFangs linked it already. Nvm my post
I can't find this guy ingame then?
Agreed, it could stand to be slightly better.
That's the issue, you have to write the exact nickname of the guy you're looking for. Should be better if searches needed a bit less details. For instance, you typed the start of the nickname, you gonna find all relative users with these letters or something.
How about something to ignore case, like:
SELECT * FROM hive WHERE UPPER(playername) LIKE UPPER('%" . mysql_real_escape_string($searchbox) . "%')
ctrl+f
You're welcome.
And with that, I think we should get this thread back on topic
mysql_real_escape_string() is making it save against SQL-Injection and because we're only excecuting one statement, "prepared statements" are slower because of the additional round-trip to the server.
B2T: Skill system seems to be fixed, but it feels like the "time" part has not been included yet
In this case yes, but not entirely true.
It can save time when sub-parts of the query computing are always the same. Meaning, dealing with some tables the same way every time. For a query that deals with millions of lines, you can see the change.
Usually it's rather difficult to get this to work efficiently as it requires a compatible data model, and / or the query that can be a good candidate. We don't deal with millions of line every morning is it ?
If the query is as trivial as this one, it's still manageable. But if developers get the idea that manual escaping was proper practice, they *will* use it on bigger queries. Hence the PSA.
When I said that they are faster, I meant faster in general. But even in this single-statement case, I suspect that caching the prepared statement will save more time than the additional round-trip costs. In small setups (like a LAMP stack), the database will be on the same machine anyway, so the network overhead is very low.
I'm confident he knows his stuff