Report 基地防空戦 compositions?

[gakada]

That is, api_destruction_battle from api_req_map/next. Something like this after

plugin-report/index.es

Line 182 in 1458cf1

this.drop = drop

if (body.api_destruction_battle != null) {
  this.report('/api/report/v2/drop_ship', {
    // undefined quest, enemy, rank
    shipId: -1,
    itemId: -1,
    mapId: drop.mapId,
    cellId: -drop.cellId, // using -drop.cellId instead of drop.cellId to indicate that it's from api_destruction_battle, alternatively, can be an extra flag
    isBoss: drop.isBoss,
    teitokuLv: _teitokuLv,
    mapLv: drop.mapLv,
    enemyShips1: body.api_ship_ke,
    enemyShips2: body.api_ship_ke_combined, // just in case, normally undefined
    enemyFormation: body.api_formation[1]
  })
}

Also, should it be

enemyShips1: null,
enemyShips2: null,

instead of

plugin-report/index.es

Line 170 in 1458cf1

enemyShips: null,

[KagamiChan]

Land base raid happens randomly and does not let any ship drop, it is better to record in another collection

On enemyShips you're right, but it does not affect data collecting because we changed the model
https://github.com/poooi/poi-server/blob/master/models/report/drop-ship.es#L14

[KagamiChan]

Anyway the enemyShips1 and enemyShips2 initialization will be added

But what could air raid data collection serve for?

[gakada]

IIRC 長距離空襲戦 (ld_airbattle) also don't drop ships? So it's for enemy patterns only in this case. Like

[KagamiChan]

Using the same data collection will result in double drop reports in a single battle on certain cells and the drop rate on these cells will never be accurate

[gakada]

Yeah, if it's not filtered by an extra flag I mentioned, OR, if without changing the schema, can set cellId to a special value, like -1 or -cellId (that is, negative cellId), for the "AB node".

[gakada]

@KagamiChan would it be ok for another viewer to implement this? I.e., to report api_destruction_battle enemy compositions in drop_ship collection with a special negative cellId value. I think poi server won't filter those reports, so they will end up in the dump, available for wikis/etc.

[KagamiChan]

I still prefer creating a separate data collection for this, anyway staff at kcwiki should be informed and involved @Gizeta

[Gizeta]

I don't think it's a good idea to save land base air raid compositions in the DropShipRecord database table, although it doesn't affect the drop statistics. However, you can just post those negative cellId values but filter them on poi-server to save in a new table, such as

record = data.cellId < 0 ? new NewTableForLandBaseAirRaid(data) : new DropShipRecord(data)
record.save()

But, I think it's tricky. Why not create some new API on poi-server for the land base air raid?

[gakada]

Well, my argument was that there is already non-drop and composition-only data from corresponding (game) endpoints in DropShipRecord, so this is just another one of those endpoints. Then, it is probably easier to utilize existing code in drop-ship.es, the change is simple if it is the same table, so I made #13.

If it must be a different table, then yeah, extra class/schema/endpoint here and in poi-server (+ available dump, like dropshiprecords.gz).

[KagamiChan]

poi-server also accepts pull requests for creating new schema and endpoints, you may consider add a new report type, say, BaseAirRaidRecord, for both plugin-report and poi-server

and I'll add the dumping once the data set is available

P.S. Here's some instructions on how to locally test reporter and poi server: https://github.com/poooi/plugin-report/wiki

[gakada]

Looking at https://github.com/andanteyk/ElectronicObserver/blob/develop/ElectronicObserver/Other/Information/apilist.txt#L1517 there is more things in api_req_map/next that are kinda required for full info, for example

• node types, api_color_no/api_event_id/api_event_kind, currently only api_event_id is used for isBoss
• node events: api_itemget, api_happening
• various node rewards
• routing, that is current fleet (ships, stats, equipment) and route taken
• and then api_destruction_battle