SourceMod provides a GetPlayerIQ function. Would that work? I do see a minor problem with it though. The IQ return value is hard coded to (9.5 x 10 ^ 99) * -1 Back on topic: Reef made the KM ATB. Apparently, there was a faulty formula in it. If someone could fix it, we could have a ready made solution.
seraph: i have no idea, I only remember that I was stuck at debugging it for some reason. The exact same plugin worked perfectly fine on KM server and on my workstation where I had set up the mysql+srcds, so I thought it has to be fault on the server box side We had joins, many of them actually, but on very short tables, so queries went like in 10ms. No performance problems on mysql. It was something else. Dunno what. Doesn't look like a balancer plugin developer problem anyway... Theowningone: if You have some skill in complex mysql queries, PM me. You are always welcome to write a plugin that works better than mine My plugin was meant to be a proof of concept. Everyone was like 'THIS CANNOT POSSIBLY WORK BECAUSE ...' and they elaborated about why this cannot work. I decided to try it myself and it appears that writing a ATB plugin that would make the players less stressed than without ATM is HARD but POSSIBLE. And then it failed by a lack of mysql queries and a lot of bad luck. Here is the query that failed: DB schematics: So it was meant to be 0.2 * (sum_of_Skill_Points/ (300 + 30*sum_of_deaths + time_played_in_seconds) )^0.2 but the join part seems to be bad 0.2 is for making it all close to 1 (needed for 1/5) 1/5 is for making it non-linear (to prevent Mkoll being 100 times better than emp_recriuts)
Reef, Which part was getting messed up? Did the MySQL versions match? Did you log the results of the query to a log file to troubleshoot? And what did you use to make the DB diagram? It doesn't look like MySQL Workbench.
Like I said, joins are wrong, it produces too few or too much rows and the sum() fails horribly. It was 5.1... As far as I know, the syntax of this query is not version dependent for mysql 4.0, 5.0, 5.1 No, it'd be an int anyway. You would have to have a locked database state with all the data to debug it and as KM was shutdown We lost it. I talked to trickster about maybe enabling only the data gathering functions so We would fill the database with entries and then it would be possible to debug it, but it'll take at least a week to gather enough data. Does it really matter? http://ondras.zarovi.cz/sql/demo/?keyword=empires_atb (please don't change) Maybe it would be easier to just split the large query into few simple ones. It would sacrifice some performance, but it'd be easier to do.
I had the idea a while ago to deal with a number stacks (9 vs 5, etc) You may only have X number of players "alive" at one time. X = Size of smallest team. So if you are on a larger team, when you die, you enter a queue. However, If you have > X players alive, they will stay in the game until they are killed. You do not enter the spawn queue until you die.
I clicked on one of the tables, but it didn't change anything. Get MySQL WB. It's safer. Neat DB design system though
Ok, I drew it on paper and scanned. The way DB schemes are provided doesn't change the database layout or the query problem we are facing. If You want to rewrite the thing into some database design tool - be my guest, but thats not the problem We need to solve, really.
