For an unknown reason, ARK occasionally submits "-nan" as a JSON property value for the location of a dinosaur. It consistently happens on the same dinosaur, but I don't know how to replicate it. Here is what the raw JSON data sent from ARK looks like when it is invalid:
Notice how the x and y values are both listed as "-nan", instead of a normal value. The dinosaur triggering this error consistently produces the same invalid JSON data, and has for at least two days. Because "-nan" is not valid JSON, my server will throw an exception and fail to update any dinosaurs in that batch.
I was thinking that it's perhaps a stasis problem, but I don't understand how the z location float, let alone everything else here, is still available if that were the case. I don't believe this is the problem. All other dinosaurs submitted in this chunk have correct data, and all of the data for this dinosaur other than these location properties are valid. This dinosaur used to update correctly, but now produces these invalid location coordinates. I don't know why.
I don't have any solutions that would fix the invalid data being sent. I don't even know how to reproduce it happening. However, there are a few approaches that could be taken to mitigate the problem:
- Assume "-nan" is 0. This would place the dinosaur at 0,0 on the map but would allow the data to be imported correctly.
- Don't update the location if it's invalid. I don't know if the location will ever be fixed however, and it could cause confusion for end users.
- Don't update any data for this dino at all if there is invalid data. This would make the "updated" time not update, but it would still likely cause confusion for end users.
- Remove the dino from the map if the location data is invalid. This would cause a lot of confusion because users would assume the dino had died.
I believe I'm going to go with option 1 and replace the location to 0, 0. Forking Newtonsoft JSON to implement custom behavior when the value is "-nan" is out of the question however. Instead, I'm going to replace any instances of "nan," in the JSON string with "0," instead. This is an easy solution, but would replace any strings typed containing "nan," with "0,". The likelihood of this happening accidentally is incredibly low, and it would only be checked if the data is being received from the ARK ingest endpoints. I see it as the best solution.
For an unknown reason, ARK occasionally submits "-nan" as a JSON property value for the location of a dinosaur. It consistently happens on the same dinosaur, but I don't know how to replicate it. Here is what the raw JSON data sent from ARK looks like when it is invalid:
Notice how the
xandyvalues are both listed as "-nan", instead of a normal value. The dinosaur triggering this error consistently produces the same invalid JSON data, and has for at least two days. Because "-nan" is not valid JSON, my server will throw an exception and fail to update any dinosaurs in that batch.I was thinking that it's perhaps a stasis problem, but I don't understand how the
zlocation float, let alone everything else here, is still available if that were the case. I don't believe this is the problem. All other dinosaurs submitted in this chunk have correct data, and all of the data for this dinosaur other than these location properties are valid. This dinosaur used to update correctly, but now produces these invalid location coordinates. I don't know why.I don't have any solutions that would fix the invalid data being sent. I don't even know how to reproduce it happening. However, there are a few approaches that could be taken to mitigate the problem:
I believe I'm going to go with option 1 and replace the location to 0, 0. Forking Newtonsoft JSON to implement custom behavior when the value is "-nan" is out of the question however. Instead, I'm going to replace any instances of "nan," in the JSON string with "0," instead. This is an easy solution, but would replace any strings typed containing "nan," with "0,". The likelihood of this happening accidentally is incredibly low, and it would only be checked if the data is being received from the ARK ingest endpoints. I see it as the best solution.