Why is data of some events send json encoded?

Seems like some of the info contains data that has been json encoded from the object:

for example the kill_feed event:

{"name":"kill_feed","data":"{\r\n  \"local_player_name\": \"mutschler\",\r\n  \"attackerName\": \"0Mandragor0\",\r\n  \"victimName\": \"Zenxss\",\r\n  \"weaponName\": \"alternator\",\r\n  \"action\": \"kill\"\r\n}"}

damage:

{"name":"damage","data":"{\r\n  \"targetName\": \"Gibersider\",\r\n  \"damageAmount\": \"11.000000\",\r\n  \"armor\": \"false\",\r\n  \"headshot\": \"false\"\r\n}"}

info updates as well

{"info":{"match_info":{"roster_13":"{\"name\":\"Hoxdolum\",\"isTeammate\":false}"}}
{"info":{"me":{"inventory_0":"{\"name\":\"unknown_41\",\"amount\":\"8\"}"}},"feature":"inventory"}
{"info":{"match_info":{"teammate_0":"{\"name\":\"d4rkpsych0_ttv\",\"state\":\"knockedout\"}"}},"feature":"team"}

and a few others.

Wouldn’t it make sense to send this as object as well?

@mutschler hi,

Can you please clarify what exactly is the issue? can you please tell us how whould you expect to get these data?

@eransharv sure i’ll try to explain it a little bit better with the kill_feed event:

so currently the data object which get’s passed to me when a event/info update happens looks like this:
(json encoded for readability)

{ 
   "name":"kill_feed",
   "data":"{\r\n  \"local_player_name\": \"mutschler\",\r\n  \"attackerName\": \"0Mandragor0\",\r\n  \"victimName\": \"Zenxss\",\r\n  \"weaponName\": \"alternator\",\r\n  \"action\": \"kill\"\r\n}"
}

as you can see everything in the data property is one string which i have to parse to get access to the properties. i was more expecting something like this:

{ 
   "name":"kill_feed",
   "data":{ 
      "local_player_name":"mutschler",
      "attackerName":"0Mandragor0",
      "victimName":"Zenxss",
      "weaponName":"alternator",
      "action":"kill"
   }
}

So basically i’ll have to JSON.parse the data attribute as well as some other attributes on some info updates in order to be able to access the needed information. I was just curious if there is a special reason for this as i thought it would make more sense to keep this consistent.

@mutschler you should do JSON.parse() only on the data part:

JSON.parse("{\r\n  \"local_player_name\": \"mutschler\",\r\n  \"attackerName\": \"0Mandragor0\",\r\n  \"victimName\": \"Zenxss\",\r\n  \"weaponName\": \"alternator\",\r\n  \"action\": \"kill\"\r\n}")

That will work.

@eransharv of course it does! That’s what i currently do… but it seems a little bit awkward since it’s not really consistent. sometimes i need to parse additional data and sometimes i don’t…

I’ll give you another example here:

{ 
   "info":{ 
      "me":{ 
         "totalDamageDealt":"1303"
      }
   },
   "feature":"damage"
}

vs:

{ 
   "info":{ 
      "me":{ 
         "inventory_0":"{\"name\":\"unknown_39\",\"amount\":\"80\"}"
      }
   },
   "feature":"inventory"
}

in the example above i’ll have to parse info.me.inventory_X but don’t have to do it for info.me. totalDamageDealt. This is not really an issue i was just wondering why it’s returned in different ways.

@mutschler, In general, you are right. An ideal API should be consistent. Unfortunately, it’s quite complicated as there is a lot of apps that expect to get the data in specific ways, so we have to think about backward compatibility here; Besides, the event data come from different sources in different structures.

Bottom line - we are working to normalize and enhance the API all the time, so thanks for the feedback!

BTW, we are working to improve the game events simulator, and add to it sample data. Means - for every event, you will be able to see the expected return value. I hope that will help in some way.

1 Like

@eransharv Thanks for the answer! Don’t worry i know the struggles of creation consistent API’s. Especially when the requirement’s and sources change more often.

i’ve wrote a small function which handles the parsing on data that needs to be parsed again. just thought i’d ask if there’s a reason behind this all.

Data from different sources/structures and backwards compatibility are understandable reasons :wink: Thanks for clearing that up.

1 Like