Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect drop-ship reporting from AdmiralRoom #9

Closed
Acrone opened this issue Oct 8, 2016 · 2 comments
Closed

Incorrect drop-ship reporting from AdmiralRoom #9

Acrone opened this issue Oct 8, 2016 · 2 comments
Assignees

Comments

@Acrone
Copy link

Acrone commented Oct 8, 2016

Hello there,

The AdmiralRoom viewer appears to be incorrectly reporting ship-drop data.

Quick summary

Issues observed:

  • enemyShips array has 7 objects instead of 6. [SCREENSHOT1]/[SCREENSHOT2]
  • enemyFormation is not being correctly detected, left as empty string.
  • shipId not provided at all on some reports.

Details

I have been keeping an eye on the 6-5 ship drops and fleet formations encountered on each node. When I did a check tonight I had noticed reports for the boss node (6-5M mapId 65 cellId 13). It was strange to see 'enemyShips' reporting 7 ships instead of the usual 6. I am not aware of any viewers updated to deal with the new abyssal combined fleet mechanic so this appears to be incorrect [SCREENSHOT].

I've checked the origin and all the abnormal enemyShip reports appear to be coming from AdmiralRoom. I found evidence that it is this viewer as it uses the same origin string (HERE).

I've checked all reports from 'AdmiralRoom Reporter v1.0' and found the same enemyShips abnormality for every report [SCREENSHOT].

Reading through your Wiki where you describe how to formulate the JSON payload, for 'enemyShips' you say 'api_ship_ke.slice(1, 7), 0 is always -1 therefore useless'. I suspect they aren't stripping the first ship.

Aside from the the extra -1 value, the enemyShips array appears to be correct however, as you can see in the two screenshots posted above, enemyFormation is not correctly being obtained. It is left empty on submission (I substitute empty strings with '-1'). Also, on some entries there is no shipId provided at all. This can be observed at ObjectIds '57efbdb205d2b8bf6cc9e246', '57efbe4905d2b8bf6cc9e8cc', '57efbed305d2b8bf6cc9eec2' and many more.

I may be totally incorrect, and I apologise if I am, but I am just submitting my findings to you.

Kind regards,
Acrone

@Gizeta
Copy link

Gizeta commented Oct 9, 2016

I reported the bug to the AdmiralRoom, and it has been fixed.
The new UA string is AdmiralRoom Reporter v2. I think it is better to remove the old data sent by AdmiralRoom Reporter v1.0.

@hanzhao
Copy link
Contributor

hanzhao commented Oct 9, 2016

Hi all,
I've removed all wrong data that has been received yet

db.dropshiprecords.remove({ origin: 'AdmiralRoom Reporter v1.0' })
WriteResult({ "nRemoved" : 444 })

@hanzhao hanzhao closed this as completed Oct 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants