you’ve clearly never played in such a situation.
please, go play with 300 ping and tell me how it turns out.
It would be nice to see the skill stat but in a more meaningful way instead of just numbers.
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.
Hey ninja 
I like the way the moderators post in these threads, feels more like home.
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.
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.
‘’ it literally has zero effect on anything ‘’ … not quite true is it , as it has an effect on the team balancer
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:
- Kills: 10,456
- Deaths: 2,912
- KDR: 3.59
I always thought I wanted to know how skill worked thanks I now no longer care.
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.
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.
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.
Just don’t pay attention to it. That stat is completely irrelevant.
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?
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.