Skill stat is worthless as is. The fact that the calculation is done based on round performance on just three stats leads to huge swings in in skill gained or lost. It's painfully obvious that a stat meant to represent your skill as a player is unreliable if it is subject to huge fluctuations. Not to mention the fact that skill is measured based on pure K/D, SPM, and KPM without a game mode context. I mean, just try getting a high SPM from playing Defuse, it just isn't going to happen. Either needs to be reworked completely to reflect your competency as a player with relative stability within game mode specific contexts, or thrown out entirely.
Skill stat is worthless as is. The fact that the calculation is done based on round performance on just three stats leads to huge swings in in skill gained or lost. It's painfully obvious that a stat meant to represent your skill as a player is unreliable if it is subject to huge fluctuations. Not to mention the fact that skill is measured based on pure K/D, SPM, and KPM without a game mode context. I mean, just try getting a high SPM from playing Defuse, it just isn't going to happen. Either needs to be reworked completely to reflect your competency as a player with relative stability within game mode specific contexts, or thrown out entirely.
i dont think accuracy is a factor i have a 1.23 k/d with the m60 and 8% accuracy on 685 kills lol....instead there should be more of a highlight on team/squad based scoring maybe even how many teamkills? I cant count how many times i have been killed by blueberries being stupid with vehicles.....not counting the times i was being dumb and standing in the street =(
"I can't aim, so accuracy cant be a factor in skill".
accuracy should be a factor.
not saying we need a skill stat, but if you dont judge a player by his accuracy when determining what you think of him, you're missing a huge component of real skill.
Say P1 has a skill of 250 and P2 has a skill of 500. Depending on who killed who, the stat would increase or decrease accordingly. Larger gap in skill would mean a larger increase/decrease.
P1 kills P2. P1's skill increases a lot while P2's skill decreases a lot.
P2 Kills P1. P2's skill increases a little while P1's skill would decrease a little as well.
yes, this is how part of BF4's skill stat and all of BF3/BC2's skill stat worked.
Its a basic ELO system and is designed to measure head to head confrontations. something which doesnt often exist in a pure form in battlefield.
If EA/DICE wanted to build a statistical profile on every player they could do so with a degree of accuracy that it would make even Google jealous. From a flag capping/defending pattern for each map; what flags you prefer to cap and or defend, specific loadout you'll use for each map at start, down to how often you actually check a corner on op locker before sprinting past.
The data is there, so why not use a bit of it to provide more in depth statistics? What we've been given as stats for the last 5+ years is a very simplistic and shallow outline. Some of the stats are even flawed by approach and can be manipulated/bloated in certain situations without highlighting the situation clearly.
example: 150,000 scout heli kills, SPM (998), KDR (98.5), KPM (15.4) .... Only plays dawnbreaker and floodzone.
Anyway, I've taken an approach that calculates statistics from map to map for a specific player. In Battlelog you would have a stats page that offers a tab for each game mode (Conquest, Rush, Obliteration etc).
Under each tab there would be a list of maps with a thumbnail and basic stats for that game mode, grouped by DLC. Clicking a map thumbnail or map name would load the full stats for that particular map as shown below. I might do a mockup for the other layouts listed above at a later date.
I don't want to be rude as you've obviously put a good amount of work into that. But personally I think it might be a little overboard. Realistically although the player themselves might find some of it interesting to know, I doubt many people would bother scrolling through pages upon pages of statistics in order to formally review another player. This is why I think that the skill stat could potentially be a useful one. It's all about trying to represent how good a player is, in the most digestible format possible. It's not quite there yet but I think it would be far more interesting for them to properly review and tweak it, than to adopt a defeatist attitude and simply remove it.
not only is it overboard, its almost certainly far more than DICE is willing to invest server wise to accomplish. DICE limited us to 100 friends because they didnt want to invest in more server. They limited our battlereports and they stop archiving after a few months. you really think they're going to give every player a 20 map stat breakdown? hell no.
We dont need this. just give us the basic stats. Jesus, we dont need a thesis on a player's map to map performance.
we dont need a map breakdown that spm, accuracy, KD and weapon stats dont already tell us. objective related stats help too. but this is way more information than anyone needs and it would take a lot of effort and investment to pull off for a full playerbase.
All the data is already there in the battle reports. The cost and resources to do it are trivial and has no bearing on the way the friends system actually works. These new forums cost 100x more. I would know because this is what I do for a living. Web software and application development, database administration, bespoke platform development and so forth.
Depending on their DB layout you could simply add 6 new fields holding a json encoded array of the updated data.
Field type (TEXT | 65,535 max chars, 64 KiB max). This would never be maxed. even so it would only equal an additional 393.216 kb of data. That's less than this web page.
i dont think accuracy is a factor i have a 1.23 k/d with the m60 and 8% accuracy on 685 kills lol....instead there should be more of a highlight on team/squad based scoring maybe even how many teamkills? I cant count how many times i have been killed by blueberries being stupid with vehicles.....not counting the times i was being dumb and standing in the street =(
"I can't aim, so accuracy cant be a factor in skill".
accuracy should be a factor.
not saying we need a skill stat, but if you dont judge a player by his accuracy when determining what you think of him, you're missing a huge component of real skill.
Say P1 has a skill of 250 and P2 has a skill of 500. Depending on who killed who, the stat would increase or decrease accordingly. Larger gap in skill would mean a larger increase/decrease.
P1 kills P2. P1's skill increases a lot while P2's skill decreases a lot.
P2 Kills P1. P2's skill increases a little while P1's skill would decrease a little as well.
yes, this is how part of BF4's skill stat and all of BF3/BC2's skill stat worked.
Its a basic ELO system and is designed to measure head to head confrontations. something which doesnt often exist in a pure form in battlefield.
If EA/DICE wanted to build a statistical profile on every player they could do so with a degree of accuracy that it would make even Google jealous. From a flag capping/defending pattern for each map; what flags you prefer to cap and or defend, specific loadout you'll use for each map at start, down to how often you actually check a corner on op locker before sprinting past.
The data is there, so why not use a bit of it to provide more in depth statistics? What we've been given as stats for the last 5+ years is a very simplistic and shallow outline. Some of the stats are even flawed by approach and can be manipulated/bloated in certain situations without highlighting the situation clearly.
example: 150,000 scout heli kills, SPM (998), KDR (98.5), KPM (15.4) .... Only plays dawnbreaker and floodzone.
Anyway, I've taken an approach that calculates statistics from map to map for a specific player. In Battlelog you would have a stats page that offers a tab for each game mode (Conquest, Rush, Obliteration etc).
Under each tab there would be a list of maps with a thumbnail and basic stats for that game mode, grouped by DLC. Clicking a map thumbnail or map name would load the full stats for that particular map as shown below. I might do a mockup for the other layouts listed above at a later date.
I don't want to be rude as you've obviously put a good amount of work into that. But personally I think it might be a little overboard. Realistically although the player themselves might find some of it interesting to know, I doubt many people would bother scrolling through pages upon pages of statistics in order to formally review another player. This is why I think that the skill stat could potentially be a useful one. It's all about trying to represent how good a player is, in the most digestible format possible. It's not quite there yet but I think it would be far more interesting for them to properly review and tweak it, than to adopt a defeatist attitude and simply remove it.
not only is it overboard, its almost certainly far more than DICE is willing to invest server wise to accomplish. DICE limited us to 100 friends because they didnt want to invest in more server. They limited our battlereports and they stop archiving after a few months. you really think they're going to give every player a 20 map stat breakdown? hell no.
We dont need this. just give us the basic stats. Jesus, we dont need a thesis on a player's map to map performance.
we dont need a map breakdown that spm, accuracy, KD and weapon stats dont already tell us. objective related stats help too. but this is way more information than anyone needs and it would take a lot of effort and investment to pull off for a full playerbase.
All the data is already there in the battle reports. The cost and resources to do it are trivial and has no bearing on the way the friends system actually works. These new forums cost 100x more. I would know because this is what I do for a living. Web software and application development, database administration, bespoke platform development and so forth.
they still need to filter out the data and display it. frankly, that seems like far more effort than it's worth.
the fact that they dont save battlereports past a certain time is the what kills your argument. if they think its a waste of their resources to archive battlereports, why would they want to have continuously updated mega battlereports (which is what these are)?
Any measure of skill without a meaningful context is always going to be subject to criticism. Battlefield has been a game without any kind of ranked play so the skill stat inevitably becomes worthless in any way that truly matters. As such, it will always be subject to exploiting and not applicable to certain players and game modes.
Data mining all the stats BF has to offer will never really be beneficial in my eyes because it will never affect who you play with or against without any performance based or ranked matchmaking (unless badmin regulation). I highly doubt DICE/EA would offer such an experience any time soon, and it would be near impossible to develop and enforce for larger gamemodes.
As it is now, the skill stat can be somewhat useful sometimes in narrow applications. The few exceptions are when its really low or high, then its pretty accurate in describing what kind of player someone is.
Edit: Not sure why it's necessary to have it removed though. It literally has zero effect on anything (Except god awful team balancer.) But it's somewhat nice to see how you perform given your own averages.
they still need to filter out the data and display it. frankly, that seems like far more effort than it's worth.
the fact that they dont save battlereports past a certain time is the what kills your argument. if they think its a waste of their resources to archive battlereports, why would they want to have continuously updated mega battlereports (which is what these are)?
You have without a doubt above average intelligence in general. Which I highly respect. But, I'm quite surprised you stepped into this end of the argument without having a background or at least a strong grasp on the subject. Being the internet as it is you apparently just doubled down assuming I had no background or knowledge on the subject. With that I'm doubling down.
When a game ends and the BR is being inserted in the DB you update the maps/mode array entry. Updating 64p entries would take literally less than 0.00125ms on a LAMP platform under simple shared hosting. Even faster if the use C to run queries with the resources of a full dedicated stack.
For simplification and because there's quite a few here that OOP would just fly right over there head and make little to no sense. And the fact that this isn't a coding forum. I'll post a very brief example.
Data in the form of an array is very structured. It can hold thousands of independent values. Multidimensional transitional/associative arrays generally have a much more complex structure. For this example I will use a multidimensional associative array.
Here's 2 examples the latter will be used in the final snippet.
// Using a predefined key/value structure using text based key indexes is not required.
// Essentially saying we know exactly the position within the array for each value.
// [0][0][1] = 565200
// This approach lowers the storage overhead drastically.
// json decoded
array(
'0' => array(
'0' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
'1' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
'2' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
),
'1' => array(
'0' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
'1' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
'2' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
),
'2' => array(
'0' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
'1' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
'2' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'),
),
)
// Stored in the database as a json encoded string = 484 characters
[[["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"]],[["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"]],[["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"]]]
Retrieving and updating this data would be very simple with very little overhead. Updates would be done at the end of a round once the BR had been inserted. Having the BR's variables/arrays available from the previous insert it would just be a simple matter of passing them on to an update function. Basically saying the mode is Conquest and the map is Golmud and the playerid is 1234567.
Retrieving and displaying is as simple as the following. But of course in a live state this would all be done via object oriented programming using and MCV or other framework with templating. Even faster!
// query db. procedural non-prepared mysqli example
$query = "SELECT dlc_0 FROM sometable WHERE playerid='1234567' LIMIT 1";
$sql = mysqli_query($dblink, $query);
while ($r = $sql->fetch_array(MYSQLI_ASSOC)) {
$data = json_decode($r['dlc_0'], true); // json decode the result
}
$stats = $data['0']['0']; // array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH') for conquest / golmud
// extracting the array values for usage
$display = "<pre>Kills: ".number_format($stats['1'])."<br>Deaths: ".number_format($stats['2'])."<br>KDR: ".round($stats['1'] / $stats['2'], 2)."</pre>";
echo($display);
Outputs:
Kills: 10,456
Deaths: 2,912
KDR: 3.59
BR's past a certain time frame (I can back at least 6 months) are a waste if not used.
they still need to filter out the data and display it. frankly, that seems like far more effort than it's worth.
the fact that they dont save battlereports past a certain time is the what kills your argument. if they think its a waste of their resources to archive battlereports, why would they want to have continuously updated mega battlereports (which is what these are)?
You have without a doubt above average intelligence in general. Which I highly respect. But, I'm quite surprised you stepped into this end of the argument without having a background or at least a strong grasp on the subject. Being the internet as it is you apparently just doubled down assuming I had no background or knowledge on the subject. With that I'm doubling down.
When a game ends and the BR is being inserted in the DB you update the maps/mode array entry. Updating 64p entries would take literally less than 0.00125ms on a LAMP platform under simple shared hosting. Even faster if the use C to run queries with the resources of a full dedicated stack.
For simplification and because there's quite a few here that OOP would just fly right over there head and make little to no sense. And the fact that this isn't a coding forum. I'll post a very brief example.
Data in the form of an array is very structured. It can hold thousands of independent values. Multidimensional transitional/associative arrays generally have a much more complex structure. For this example I will use a multidimensional associative array.
(snipped for space)
ok, i get that it's easy. but is that how they're doing it? because what im going off of is that since they do not store battlereports, despite the fact that the data still obviously exists somewhere, then why? logically, whatever their reasons are, those would also apply to these map specific reports.
they still need to filter out the data and display it. frankly, that seems like far more effort than it's worth.
the fact that they dont save battlereports past a certain time is the what kills your argument. if they think its a waste of their resources to archive battlereports, why would they want to have continuously updated mega battlereports (which is what these are)?
You have without a doubt above average intelligence in general. Which I highly respect. But, I'm quite surprised you stepped into this end of the argument without having a background or at least a strong grasp on the subject. Being the internet as it is you apparently just doubled down assuming I had no background or knowledge on the subject. With that I'm doubling down.
When a game ends and the BR is being inserted in the DB you update the maps/mode array entry. Updating 64p entries would take literally less than 0.00125ms on a LAMP platform under simple shared hosting. Even faster if the use C to run queries with the resources of a full dedicated stack.
For simplification and because there's quite a few here that OOP would just fly right over there head and make little to no sense. And the fact that this isn't a coding forum. I'll post a very brief example.
Data in the form of an array is very structured. It can hold thousands of independent values. Multidimensional transitional/associative arrays generally have a much more complex structure. For this example I will use a multidimensional associative array.
(snipped for space)
ok, i get that it's easy. but is that how they're doing it? because what im going off of is that since they do not store battlereports, despite the fact that the data still obviously exists somewhere, then why? logically, whatever their reasons are, those would also apply to these map specific reports.
The example I gave takes a very simplistic approach. Using json encoded arrays is a very solid approach. Infact storing all the map stats under a single table field is actually feasible. Separating it into 6 actually speeds up the base select query and lowers the overall memory needed for the result.
How they actually do it I have no clue, because I don't have access to the db or code. 20 years experience says a single BR that contains everyone's round info is stored in a db table. One record per row. It would look similar to this...
record ID | Server ID | timestamp | report
============================
704114721178296448 | 43872838823 | 14949583 | json_econded array()
704114721178296449 | 45634534534 | 14949645 | json_econded array()
An example of what the report array "MAY" look like is as follows.
Same report but it doesn't highlight a specific player.
I mean I could talk code and approaches all day. My bottom line is it's definitely feasible at a very low financial and resource costs. If coded and managed correctly.
you dont need to demonstrate. at least with the statistics, i understand it, i've done similar things with matlab and fortran.
what i meant is that whatever EA is doing, they clearly dont want to handle the data. they dump battlereports after a couple of months. going off that it seems like whatever they do is a strain and this is basically the same thing.
Ok so you go hard in the pain with data mining and get MLB level amount of statistics. Now what? It serves no use for actual gameplay given the current system other than online trouser snake measuring. What application would you have in mind with all the data?
you dont need to demonstrate. at least with the statistics, i understand it, i've done similar things with matlab and fortran.
what i meant is that whatever EA is doing, they clearly dont want to handle the data. they dump battlereports after a couple of months. going off that it seems like whatever they do is a strain and this is basically the same thing.
too late already had it done.
Anyway, did you notice the BL forums are being removed? That's a good sign of an overhaul to come. This reduction frees up a lot of resources. Just saying.
you dont need to demonstrate. at least with the statistics, i understand it, i've done similar things with matlab and fortran.
what i meant is that whatever EA is doing, they clearly dont want to handle the data. they dump battlereports after a couple of months. going off that it seems like whatever they do is a strain and this is basically the same thing.
too late already had it done.
Anyway, did you notice the BL forums are being removed? That's a good sign of an overhaul to come. This reduction frees up a lot of resources. Just saying.
the forums are being moved but i already asked about it. they're basically removing them because the company that was running them got reassigned to something else. So i dunno. yeah, it frees up resources. but they really are just moving everything here because it's easier for the mods to manage and gives them more control because the battlelog forums were pretty makeshift from what i understand. ESN built the battlelog software and they had to shoehorn the forums in pretty late.
Comments
All the data is already there in the battle reports. The cost and resources to do it are trivial and has no bearing on the way the friends system actually works. These new forums cost 100x more. I would know because this is what I do for a living. Web software and application development, database administration, bespoke platform development and so forth.
Depending on their DB layout you could simply add 6 new fields holding a json encoded array of the updated data.
Field type (TEXT | 65,535 max chars, 64 KiB max). This would never be maxed. even so it would only equal an additional 393.216 kb of data. That's less than this web page.
the fact that they dont save battlereports past a certain time is the what kills your argument. if they think its a waste of their resources to archive battlereports, why would they want to have continuously updated mega battlereports (which is what these are)?
Data mining all the stats BF has to offer will never really be beneficial in my eyes because it will never affect who you play with or against without any performance based or ranked matchmaking (unless badmin regulation). I highly doubt DICE/EA would offer such an experience any time soon, and it would be near impossible to develop and enforce for larger gamemodes.
As it is now, the skill stat can be somewhat useful sometimes in narrow applications. The few exceptions are when its really low or high, then its pretty accurate in describing what kind of player someone is.
Edit: Not sure why it's necessary to have it removed though. It literally has zero effect on anything (Except god awful team balancer.) But it's somewhat nice to see how you perform given your own averages.
just saying
Oh that's true, forgot about that horrid update. Will edit. Cheers m8.
lol no probs
You have without a doubt above average intelligence in general. Which I highly respect. But, I'm quite surprised you stepped into this end of the argument without having a background or at least a strong grasp on the subject. Being the internet as it is you apparently just doubled down assuming I had no background or knowledge on the subject. With that I'm doubling down.
When a game ends and the BR is being inserted in the DB you update the maps/mode array entry. Updating 64p entries would take literally less than 0.00125ms on a LAMP platform under simple shared hosting. Even faster if the use C to run queries with the resources of a full dedicated stack.
For simplification and because there's quite a few here that OOP would just fly right over there head and make little to no sense. And the fact that this isn't a coding forum. I'll post a very brief example.
Data in the form of an array is very structured. It can hold thousands of independent values. Multidimensional transitional/associative arrays generally have a much more complex structure. For this example I will use a multidimensional associative array.
Here's 2 examples the latter will be used in the final snippet.
// Array() using text based key indexes // essentially saying playtime holds the value of 565200 // json decoded array( 'Conquest' => array( 'Golmud' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), 'Zavod' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), 'Lancang' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), ), 'Rush' => array( 'Golmud' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), 'Zavod' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), 'Lancang' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), ), 'TDM' => array( 'Golmud' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), 'Zavod' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), 'Lancang' => array('playtime' => '565200', 'kills' => '10456', 'deaths' => '2912', 'etc'=> 'value', 'etc'=> 'SO', 'ON'=> 'AND', 'SO'=> 'FORTH'), ), ) // Stored in the database as a json encoded string = 913 characters {"Conquest":{"Golmud":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"},"Zavod":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"},"Lancang":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"}},"Rush":{"Golmud":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"},"Zavod":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"},"Lancang":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"}},"TDM":{"Golmud":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"},"Zavod":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"},"Lancang":{"playtime":"565200","kills":"10456","deaths":"2912","etc":"SO","ON":"AND","SO":"FORTH"}}}// Using a predefined key/value structure using text based key indexes is not required. // Essentially saying we know exactly the position within the array for each value. // [0][0][1] = 565200 // This approach lowers the storage overhead drastically. // json decoded array( '0' => array( '0' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), '1' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), '2' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), ), '1' => array( '0' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), '1' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), '2' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), ), '2' => array( '0' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), '1' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), '2' => array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH'), ), ) // Stored in the database as a json encoded string = 484 characters [[["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"]],[["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"]],[["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"],["565200","10456","2912","value","SO","AND","FORTH"]]]Retrieving and updating this data would be very simple with very little overhead. Updates would be done at the end of a round once the BR had been inserted. Having the BR's variables/arrays available from the previous insert it would just be a simple matter of passing them on to an update function. Basically saying the mode is Conquest and the map is Golmud and the playerid is 1234567.Retrieving and displaying is as simple as the following. But of course in a live state this would all be done via object oriented programming using and MCV or other framework with templating. Even faster!
// query db. procedural non-prepared mysqli example $query = "SELECT dlc_0 FROM sometable WHERE playerid='1234567' LIMIT 1"; $sql = mysqli_query($dblink, $query); while ($r = $sql->fetch_array(MYSQLI_ASSOC)) { $data = json_decode($r['dlc_0'], true); // json decode the result } $stats = $data['0']['0']; // array('565200', '10456', '2912', 'value', 'SO', 'AND', 'FORTH') for conquest / golmud // extracting the array values for usage $display = "<pre>Kills: ".number_format($stats['1'])."<br>Deaths: ".number_format($stats['2'])."<br>KDR: ".round($stats['1'] / $stats['2'], 2)."</pre>"; echo($display);Outputs:
BR's past a certain time frame (I can back at least 6 months) are a waste if not used.
ok, i get that it's easy. but is that how they're doing it? because what im going off of is that since they do not store battlereports, despite the fact that the data still obviously exists somewhere, then why? logically, whatever their reasons are, those would also apply to these map specific reports.
The example I gave takes a very simplistic approach. Using json encoded arrays is a very solid approach. Infact storing all the map stats under a single table field is actually feasible. Separating it into 6 actually speeds up the base select query and lowers the overall memory needed for the result.
How they actually do it I have no clue, because I don't have access to the db or code. 20 years experience says a single BR that contains everyone's round info is stored in a db table. One record per row. It would look similar to this...
An example of what the report array "MAY" look like is as follows.
array( 'serverid' => '957d0481-f8c2-4c17-bd2f-9a74515ac847', 'timestamp' => '14232382', 'roundtime' => '2527', 'topfour' => array( '0' => array('playerid', 'CONSISTENT SCORER', '5819/spm'), '1' => array('playerid', 'KILLING MACHINE', '59/killing machine'), '2' => array('188850079', 'BEST ENGINEER', '20524/engineer score'), '3' => array('playerid', 'BEST RECON', '8725/recon score'), ), 'Players' => array( '188850079' => array('US', '565200', '10456', '2912', 'value', 'value', 'value', 'value'), '234234234' => array('US', '565200', '10456', '2912', 'value', 'value', 'value', 'value'), '153467433' => array('US', '565200', '10456', '2912', 'value', 'value', 'value', 'value'), '234234222' => array('CN', '565200', '10456', '2912', 'value', 'value', 'value', 'value'), '111143423' => array('CN', '565200', '10456', '2912', 'value', 'value', 'value', 'value'), '153467433' => array('CN', '565200', '10456', '2912', 'value', 'value', 'value', 'value'), ) )Now take the url from a BR
http://battlelog.battlefield.com/bf4/battlereport/show/1/704114721178296448/188850079/
Last number (188850079) references the player ID
The number before that (704114721178296448) references the Record ID
So when you view the full report it's actually telling the server:
SELECT * FROM reports WHERE report = '704114721178296448'
It displays the report highlighting player ID 188850079
Take the same url and drop the end number. http://battlelog.battlefield.com/bf4/battlereport/show/1/704114721178296448/
Same report but it doesn't highlight a specific player.
I mean I could talk code and approaches all day. My bottom line is it's definitely feasible at a very low financial and resource costs. If coded and managed correctly.
what i meant is that whatever EA is doing, they clearly dont want to handle the data. they dump battlereports after a couple of months. going off that it seems like whatever they do is a strain and this is basically the same thing.
too late already had it done.
Anyway, did you notice the BL forums are being removed? That's a good sign of an overhaul to come. This reduction frees up a lot of resources. Just saying.
the forums are being moved but i already asked about it. they're basically removing them because the company that was running them got reassigned to something else. So i dunno. yeah, it frees up resources. but they really are just moving everything here because it's easier for the mods to manage and gives them more control because the battlelog forums were pretty makeshift from what i understand. ESN built the battlelog software and they had to shoehorn the forums in pretty late.