This topic contains 36 replies, has 0 voices, and was last updated by  imported_gcamp 13 years ago.

  • Author
    Posts
  • #11643

    Bobirov
    Participant

    I beleive it should work on mysql version 4.0.0 or higher, it works just fine with my host. It was the easiest way I could find to count up the number of results when using a LIMIT in the query. Did you replace it with some other mechanism to count up the results of the query on stathistory.php? I guess the query could be sent twice, once with the limit and then another without the limit. This was the way I found to do it but you probably know of another way seeing as how I am still really new to php and mysql.

    Anyways it isn’t necessary to count the results on the index page (that was just a cosmetic thing) but it is required on the stathistory page in order to calculate how many pages to split the results into. You can’t just count up the total number of playerids like you did with allplayers because the list is supposed to only show players who have played during the designated time period.

    I am sorry for any inconvieniance this has caused you. I am sure you are a very busy man and I hate to do anything that causes you to waste your valuable time.

    #11644

    imported_gcamp
    Participant

    No worries, I’ll have a look at it soon. I am not sure what version of MySQL sourceforge is running I’ll check that too.

    I am sorry for any inconvieniance this has caused you. I am sure you are a very busy man and I hate to do anything that causes you to waste your valuable time.

    Don’t be silly your time is just as valuable as mine I am sure, and you spent the time making the changes. Any contributions are always very welcome, if everyone put it the time you put in we would be flying 🙂

    #11645

    Bobirov
    Participant

    There seems to be another problem with one of my alterations but its only occuring on the official Scorched 3D pages that I am aware of. I suspect this again has something to do with either what version of MySQL is on the host or maybe PhP even. My host is running mysql Ver 12.22 Distrib 4.0.18 and PHP 4.3.4. Anyways, here’s the problem…

    First off, check out the allplayers page at ApocHQ. After the page loads click on the “Kill Ratio” link at the top of the list to sort the list by kill ratio. The stats list should reload and be sorted by kill ratio in descending order. If you click on the link again, it will resort the entire list in ascending order. This is how the page is intended to work.

    Ok now head on over to the allplayers page at Scorched3D. If you try to repeat the process that you did at ApocHQ, you will find that the list will not properly sort by Kill Ratio. The rest of the sorts work just fine but not the kill ratio sort.

    I suspect that it has to do with the fact that killratio isn’t stored in the database but rather calculated in the query off of other values. I really have no idea here though, and this is just my best guess. I don’t know what to do about this one. I was hoping that the new sort function I use in the latest set might somehow fix the problem but it did not.. 😥

    Any ideas??

    #11646

    Ebonite
    Participant

    forgive me for barging in, especially when I’m essentially nitpicking, but would it be possible for tracer-class weapons (smoke and regular) to be omitted from the tally of shots made by a player? not total shots or the tally used for shots per kill, but the tally used for determining hit percentage could greatly affect a players percieved hit percentage. the tracer weapon class has no chance of damaging or killing an enemy, and subsequently, any shots made with a tracer shouldn’t be counted as an attempt to hit, though they should count towards shots for kills.

    Additionally, the dirt weapons could be discounted as well, as they “shouldn’t” do any damage, much less kill. I am aware that “Ton of Dirt”s have accounted for 4 player deaths, although no one will explain to me how to do this. if this is a bug, then once it is resolved, could the dirt classes be removed from the hit tally as well?

    Random thought, what about keeping track of dirt inflicted suicides/resignations/skipped turns? well nigh impossible i would guess, but wouldn’t that be an interesting stat table? 😛 Players who cause most suicides with dirt

    Would it be possible to modify the player’s personal stat page to show the current ranking on each of the relevant stats? for example, player has 600 kills, rank is 61; 22 resignations, rank is 104; 98 round wins, rank is 72; etc.

    and while you’re all at it, I’ll take the moon on a silver platter. 😉

    #11647

    Bobirov
    Participant

    @[PDX]Ebonite² wrote:

    would it be possible for tracer-class weapons (smoke and regular) to be omitted from the tally of shots made by a player? not total shots or the tally used for shots per kill, but the tally used for determining hit percentage could greatly affect a players percieved hit percentage. the tracer weapon class has no chance of damaging or killing an enemy, and subsequently, any shots made with a tracer shouldn’t be counted as an attempt to hit, though they should count towards shots for kills.

    I don’t think that tracers should be removed from the counts because it is still you firing a shot to get lined up for the next shot which will probably be the lethal one. If you didn’t count the tracers and non-lethal shots then the kill ratios could easily go over 100% if farmed properly and I think that would be kinda silly. I am saying this because there is only one count for shots in the database and there would be no way to destinguish between the count for kill ratio and for total shot count, etc. This is just my opinion, of course, and I would be curious to see what Gavin says on the subject.

    I think at the core of what you’re saying here is that there needs to be a “hit percentage” of some sort. On the current pages, “Kill Ratio” is definately NOT hit percentage, it is simply your shots/kill displayed as kills/shot instead. Or, in other words, the raw percentage of shots that you make that results in a kill. I preferred to display it on the lists this way because a higher number is better where as shots/kill would be the other way. I then wrote it both ways on the individual stats page so you could see it both ways.

    Currently, there is no way to tell when one of your shots “hits” a target (but doesn’t kill it) or to distinguish between which weapons the player fires each shot that I am aware of. This might sound strange as you see quite a bit on the lovely events pages but those are only shots that result in deaths, obviously. Perhaps something along the lines of scorched3d_players.ShotsThatHit could be added, that might be cool. In that particular count, non-lethal weapons might not be counted if that is possible. But, that whole not counting your shot business still seems odd to me though :P.

    @[PDX]Ebonite² wrote:

    Would it be possible to modify the player’s personal stat page to show the current ranking on each of the relevant stats? for example, player has 600 kills, rank is 61; 22 resignations, rank is 104; 98 round wins, rank is 72; etc.

    Okay, I am sure there is an easy way to do this quickly and I’ve actually had something similar on my little list of things to add for a while but I just haven’t figured it out yet.. 😳 I am no pro here though, and I’ll keep looking at it. I am sure someone else who knows what they are doing could look at it and do it without a problem ;).

    #11648

    hobbesme
    Participant

    @bobirov wrote:

    There seems to be another problem … only occuring on the official Scorched 3D pages …

    The “Kill Ratio” … should … be sorted … in descending order … [or] ascending order.

    [However] the list will not properly sort by Kill Ratio. The rest of the sorts work just fine but not the kill ratio sort.

    As you may remember, I too discovered this flaw (feature?) with the Kill Ratio column last month & sent you & Gavin my observations :

    @hobbesme wrote:

    “The Kill Ratio column DOES display rankings from lowest to highest or highest to lowest Kill Ratio if that column is selected to re-sort the player rankings.

    HOWEVER, for some reason, it ALWAYS displays all players that have NO kills, NO kill ratio, & NO wins — i.e. players that probably have not played at all — before the sorted Kill Ratio listing!

    In other words, regardless of whether it sorts from highest to lowest or lowest to highest, it displays players whose stats are all 0’s (which on the main Scorched3D site is several hundreds of players with all 0 stats).

    And these do NOT seem to be valid Kill Ratio 0%’s because the actual sorted Kill Ratio rankings start with negative Kill Ratio’s then transition to seemingly valid 0% Kill Ratio’s then transition to positive Kill Ratio’s.

    Therefore, the sort on the Kill Ratio column DOES sort the players based on Kill Ratio. But for some reason the listing prepends all players who have NULL or all-zero stats before the actual Kill Ratio sorted listing.”

    @bobirov wrote:

    I suspect that it has to do with the fact that killratio isn’t stored in the database but rather calculated in the query off of other values. I really have no idea here though, and this is just my best guess.

    I think that’s a VERY reasonable guess. Clearly, there is some logic in the sort function that is allowing players with all-zero stats to be prepended in the sort instead of just sorting all-zero-stats players by their zero Kill Ratio stat.

    Actually, it would be best if these all-zero-stats players were APPENDED to any sort, rather than prepended OR sorted. Thus, whatever logic is prepending these players to the front of the list should be reversed so that these players are appended at the end of the list.

    #11649

    Ebonite
    Participant

    yeah, “hit percentage” was what I was leading up with those requests, something to reflect the relative accuracy of a player. I certainly endorse counting non-lethal shots into the shots-to-kill and total-shots catagories.l I know I was asking for quite a bit, particularly in the complexity department, so if it can’t be done, or it is simply to difficult to implement, don’t bother. I’ll live (and get blowed up) as normal without it.

    It is nice that you think the ranings can be included on the personal stat page. I was kinda thinking the entire post was stretching the realm of vitual reality. What about my request for the moon? 😉

    #11650

    Bobirov
    Participant

    Okay, I found a helpful little function called COALESCE that returns the first non-null value in a series. When inserted into the query itself, you wind up not getting any null values and it seems to help. This may solve the problem with the kill ratio sort as it solved a similar problem I was having with a rating system I am messing with. Just for kicks, I also removed lastconnect from the list and replaced it with suicides, resigns and teamkills.

    #11651

    imported_gcamp
    Participant

    Nice 1 I will upload as soon as I have had a shower :), ah lazy weekends. I hope this works on my outdated mysql version.

    I was having with a rating system I am messing with

    Intrieging, I was wondering if people would want something other than kill based stats.

    #11652

    Bobirov
    Participant

    Note: in looking at the all players list, I would say the COALESCE function solved the problem with the kill ratio sort. HOORAY!! 🙂 Now my next question is, should I remove the the penalties for suicides/teamkills from the kill ratio calculation? It works great for users who actually play a little bit, but for people who log in and suicide once and never play again it looks silly with all the negative numbers. Maybe if I implement the system described below there would be no need to penalize the kill ratio count. Lemme know what you guys think.

    @gcamp wrote:

    Intrieging, I was wondering if people would want something other than kill based stats.

    Well it is still kill based, but kill ratio plays a roll in how much your rating goes up per kill. Currently everyone starts out at 100 pts for a “combat rating”. At the moment, the numbers are basically any kill at 10% kill ratio or better will increase your combat rating. At 30% kill ratio, 2 kills gets you one combat rating point, at 50% kill ratio, 1 kill gets you 1 rating point. For every teamkill/suicide/resign the player has, they are deducted 1 rating point.

    Its basically just a way to compare eachother based on how lethal you have proven yourself to be with respect to killing yourself/teamates and resigning. Users who are accurate and take care to not kill themselves and their teamates and do not resign a lot can overtake other users with higher kill counts but who are less accurate or more careless. I have the system up on a test page if you want to have a look.

    The system isn’t perfect, if people were to continually stay below 10% kill ratio or kill themself/teamates and resign a lot they will wind up with negative ratings. Perhaps I could start the ratings at 1000 instead of 100 but I thought it looked a bit odd. I can’t decide if the numbers are ok as they are now or if they should be readjusted. I was thinking if I could get the numbers right I could sort the deadliest players query on the index with the rating system instead of just a weighted kill ratio. Anyone who wants to give me some input here is welcome.

    #11653

    imported_gcamp
    Participant

    Sounds good. I wouldn’t worry about the negative stats thing, just shows a person is really bad.

    I also play Counter Strike (Half life based) and there are lots of stats programs for this game. They use a similar method, here is a commonly used one :-
    http://www.psychostats.com/faq.php?faqid=1
    Others use the weapon used to do the killing in the rating as well. I think hlstats does this.

    #11654

    Ebonite
    Participant

    Alright, more complex and hypothetical ideas from your friendly neighborhood Ebo.

    Idea, likelihood: impossible. Comparative rating ratings. A player’s rating is based on the rating of the people he kills and is killed by. Like a ladder system, but rather harder to implement, I would think, due to the matches not being one vs. one. But, for the sake of arguement, a player’s rating will go up proportionate to the rating of the player he killed and down proportionate to the player who kills him. Only players with more than, say, 10 kills will have a rating, their 11th kill with put them on the rating list. This will keep the ladder managable and prevent “ladder spamming” by killing a bunch of newbies over and over. For example, of the 4113 unique users as of this posting, only 848 have 10 kills or more, and only 796 have more than 10 kills. Apologies, but StarCraft was my only experience with ladders, and I never made it. 🙁

    The basic idea of the first idea is that a player’s rating improves fastest when playing against and beating better players. Presumtion: the more players in a game, the greater the likelihood of better players in that game. Suposition: kills made in higher populated games should weigh more than kills in sparse games. This would require some kind of “# of players played against” tracker, and then, how do you wiegh the kills? But wait, what if round wins and game wins are factored into the rating somehow? These stats could and should be weighted by the number of players in a round or game respectively. This would still require the “# of players played against” tracker A good player doesn’t just kill a lot of people, he kills the right people to ensure his survival. By surviving, a player gives themselves a better chance for more kills, money, and wins.

    Of course, any rating system will depend on the creator’s defintion of a “player” and their impression of the purpose of the game. Is the purpose to kill as many other tanks as possible? Then stay with the current “total kills” system. What about killing effectively? Try “kills per round”. Killing efficiently? “kill ratio”. What if there is more than just killing? Managing the budget seems rather important. Could the kill be rated based on the weapon used? Aside from the money awarded, isn’t it harder to kill with a baby missile as oppsed to a nuke or deathhead? Someone who kills with “lighter” weapons should be rated higher than someone with the same number of kills but uses more “heavy” weapons.(On a side note, I have noticed that rollers actually award more money for a kill than baby rollers. One roller will kill a tank for an award of $6000, while it takes at least 2 babies to kill the same tank, resulting in multiple awards totaling less than $6000. The normal rollers costing more, I would have thought they would rank in a different weapon scale.)

    Does being a good player mean surviving? Then a rating of rounds won over rounds played. Again, I would like to see rounds versus more people weigh more than rounds against less people. I admit that many of my round and game wins came from beating newer players in 1 vs 1 rounds through all 10 rounds of a game in the early weeks of this release. A rounds rating would also be more representative than a games rating, since many people can’t or don’t participate for a whole game, entering or leaving somewhere in the middle.

    I like Bob’s idea for penalties for suicides and teamkills, but I hesitate on endorsing penalties for resigning. I, personally, find resigning to be strategically advantageous, particularly in the first round where only baby missiles are used, as staying in after being wounded only gives the opponent more money to spend in subseqeunt rounds. I do not believe this to be condusive to my long term survival. As I already cannot win that round, why provide another player with the means to kill me more effectively throughout the rest of the game and lessen or even prevent the possibility of myself winning later rounds? Like that one quote, “Lose the battle to win the war.”

    In case anyone is interested, my perceived purpose of the game is to win games. One needs to win rounds to win games, make kills to win rounds, earn money to make kills, and shoot well to earn money.

    Also, I think that the Team stats should be kept separate from the regular stats. My current understanding is that players do not get round or game win credit on a Teams server, so any rating taking those two factors into account will be skewed by the amount of time a player spends on Teams as a portion of his gaming time. Also, the gameplay is different in Teams as only half of the players are valid targets, as oppsed to all of them in regular, and you must take care not to hit friendlies, which is not an issue in regular. Possible ratings on a teams server could be “total kills”, “kills per round played”, “rounds survived”, “team wins”, and “rounds survived that contributed to a team win”.

    As an alternative to the straight ranking of players on a Team server, what about the formation of a league for teams to compete as teams? This can be readily laddered (is that a word?), but would involve a huge time investment involving scheduling matches on the usually open server, managing disputes, player tracking, etc.

    Just some stuff for consideration. Disregard at your leisure. 😆

    #11655

    Bobirov
    Participant

    I took the time to hopefully fix the problem with stathistory.php on the official hosted stats and to fix some sorting errors that were on the page as well. I also removed some of the charts from the index and replaced them with links to the respectful sorted allplayers and stathistory page. Some people might not like it, but the index is now FAR less cluttered. It is now much more like a portal to the information you are looking for than a place to find it. Let me know what you think.

    #11656

    Bobirov
    Participant

    I see you’ve got the changes up that I posted. Stathistory.php is indeed working properly now so you can see stats for ALL players who have played over the designated time period. It really is one sweet page when it works right. Of course I think I am a little biased because I wrote it.. 😛

    #11657

    imported_gcamp
    Participant

    Yeah it looks nice 😀

    I can’t remember if you were asking but I have also added in a stats prefix that allows multiple servers to have different stats in the same database. The prefix changes the tables scorched uses to scorched3d_table (e.g. scorched3d_players). Except for the main table (scorched3d_main) which contains the prefix for each server. The default prefix is nothing (“”) so all the previous stats will work.

Viewing 15 posts - 16 through 30 (of 38 total)

You must be logged in to reply to this topic.