Étude de faisabilité : outil de suivi des revenus PvE (ratting) #60

New Issue

mcmuzzle · 2026-11-12T08:21:39Z

mcmuzzle commented

2026-11-12 08:21:39 +00:00

Objectif

Préparer un futur outil de suivi des revenus de ratting, sur le modèle du suivi d'exploration (Exploration/ExplorationSession.cs, Components/Exploration/) : des sessions, des sites, puis des statistiques.

Ce ticket est une étude de faisabilité : pour chaque statistique voulue, déterminer d'où viendrait la donnée (ESI, saisie manuelle, collage depuis le client…) et avec quelle fiabilité. L'implémentation fera l'objet de tickets séparés.

Statistiques souhaitées

ISK/h en bounties
ISK/h en ESS (part versée par l'Encounter Surveillance System)
Nombre de sites faits par session, par type de site si possible
Nombre d'escalations par type
Taux d'escalation par site (escalations obtenues / sites faits, par type de site)

Pistes à étudier (hypothèses, rien n'a été vérifié)

Bounties et ESS : journal du wallet ESI

L'application lit déjà le wallet (scope esi-wallet.read_character_wallet.v1, voir Stock/EsiMarketOrderService.cs). À vérifier : le journal (/characters/{id}/wallet/journal/) donne-t-il des lignes de type bounty_prizes et des lignes propres à l'ESS (types de lignes ESS exacts à identifier) ?
Les bounties semblent versées en paiements groupés à intervalle régulier, pas par NPC tué. Il faut savoir quelle précision temporelle on obtient pour un ISK/h, et comment rattacher un paiement à une session (paiement qui tombe après l'arrêt de la session, par exemple).
Le champ reason d'une ligne de bounty pourrait détailler les NPC tués (type et quantité). Si c'est le cas, on aurait un indice sur les sites faits.
ESS : le versement n'est pas immédiat (réserve, versement différé, risque de vol de la réserve). Il faut définir ce que veut dire « ISK/h ESS » : versé ou accumulé ?
Délai de cache ESI du journal : un affichage en direct est-il possible pendant la session, ou seulement après ?

Sites et escalations

À première vue, ESI ne donne ni les sites de combat faits ni les escalations (expeditions). À confirmer, notamment du côté des notifications du personnage (esi-characters.read_notifications.v1).
Repli possible, comme pour l'exploration : saisie manuelle du site (« entrer dans le site » / « site terminé », type de site) et d'une escalation obtenue (type).
À étudier : coller un extrait du client (journal des expeditions, fenêtre de l'agence…) pour réduire la saisie. Les logs du client (gamelogs) sont des fichiers locaux, que le portail web ne peut pas lire sans upload ou collage.
Peut-on déduire le type de site à partir des NPC indiqués dans le reason des bounties ? Ce serait un bonus, pas une base fiable.

Autres questions

Plusieurs personnages en même temps (multibox) : une session par compte qui regroupe les revenus de tous ses personnages ?
Loot et salvage : les compter (comme le butin d'exploration, au prix Jita) ou rester hors périmètre pour l'instant ?
Valeur d'une escalation : la suivre à part, ou l'intégrer à la session où elle a été faite ?
Statistiques sur la durée : ISK/h par système, par type de site, par personnage, par vaisseau ?

Livrables de l'étude

Pour chaque statistique 1 à 5 : source de la donnée, fiabilité, limites (cache, délai de versement), et verdict (faisable / partiel / saisie manuelle / non faisable).
Liste des scopes ESI à ajouter, le cas échéant.
Ce qui peut être repris du suivi d'exploration (sessions, sites, ExcludeFromStats, page de statistiques).
Proposition de découpage en tickets d'implémentation.

## Objectif Préparer un futur outil de suivi des revenus de ratting, sur le modèle du suivi d'exploration (`Exploration/ExplorationSession.cs`, `Components/Exploration/`) : des sessions, des sites, puis des statistiques. Ce ticket est une **étude de faisabilité** : pour chaque statistique voulue, déterminer d'où viendrait la donnée (ESI, saisie manuelle, collage depuis le client…) et avec quelle fiabilité. L'implémentation fera l'objet de tickets séparés. ## Statistiques souhaitées 1. **ISK/h en bounties** 2. **ISK/h en ESS** (part versée par l'Encounter Surveillance System) 3. **Nombre de sites faits** par session, par type de site si possible 4. **Nombre d'escalations par type** 5. **Taux d'escalation par site** (escalations obtenues / sites faits, par type de site) ## Pistes à étudier (hypothèses, rien n'a été vérifié) ### Bounties et ESS : journal du wallet ESI - L'application lit déjà le wallet (scope `esi-wallet.read_character_wallet.v1`, voir `Stock/EsiMarketOrderService.cs`). À vérifier : le journal (`/characters/{id}/wallet/journal/`) donne-t-il des lignes de type `bounty_prizes` et des lignes propres à l'ESS (types de lignes ESS exacts à identifier) ? - Les bounties semblent versées en paiements groupés à intervalle régulier, pas par NPC tué. Il faut savoir quelle précision temporelle on obtient pour un ISK/h, et comment rattacher un paiement à une session (paiement qui tombe après l'arrêt de la session, par exemple). - Le champ `reason` d'une ligne de bounty pourrait détailler les NPC tués (type et quantité). Si c'est le cas, on aurait un indice sur les sites faits. - ESS : le versement n'est pas immédiat (réserve, versement différé, risque de vol de la réserve). Il faut définir ce que veut dire « ISK/h ESS » : versé ou accumulé ? - Délai de cache ESI du journal : un affichage en direct est-il possible pendant la session, ou seulement après ? ### Sites et escalations - À première vue, ESI ne donne ni les sites de combat faits ni les escalations (expeditions). À confirmer, notamment du côté des notifications du personnage (`esi-characters.read_notifications.v1`). - Repli possible, comme pour l'exploration : saisie manuelle du site (« entrer dans le site » / « site terminé », type de site) et d'une escalation obtenue (type). - À étudier : coller un extrait du client (journal des expeditions, fenêtre de l'agence…) pour réduire la saisie. Les logs du client (gamelogs) sont des fichiers locaux, que le portail web ne peut pas lire sans upload ou collage. - Peut-on déduire le type de site à partir des NPC indiqués dans le `reason` des bounties ? Ce serait un bonus, pas une base fiable. ### Autres questions - Plusieurs personnages en même temps (multibox) : une session par compte qui regroupe les revenus de tous ses personnages ? - Loot et salvage : les compter (comme le butin d'exploration, au prix Jita) ou rester hors périmètre pour l'instant ? - Valeur d'une escalation : la suivre à part, ou l'intégrer à la session où elle a été faite ? - Statistiques sur la durée : ISK/h par système, par type de site, par personnage, par vaisseau ? ## Livrables de l'étude - [ ] Pour chaque statistique 1 à 5 : source de la donnée, fiabilité, limites (cache, délai de versement), et verdict (faisable / partiel / saisie manuelle / non faisable). - [ ] Liste des scopes ESI à ajouter, le cas échéant. - [ ] Ce qui peut être repris du suivi d'exploration (sessions, sites, ExcludeFromStats, page de statistiques). - [ ] Proposition de découpage en tickets d'implémentation.

mcmuzzle added the Kind/Feature label 2026-11-12 08:21:39 +00:00

mcmuzzle commented

2026-11-12 08:27:21 +00:00

si on démare et arrete une session en mode manuel, cela peut aider à déterminer pour un ESS donné, a quel session c'est rataché. Par contre, l'ESS tombe au 4h, si on a fait 2 sessions il faudra se basé sur les bountie pour savoir quel part d'ESS va a quelle session. Pour information, le % qui va dans l'ess est stable (environ 39% de mémoire) on ne gere que la main bank, pas la reserve bank

mcmuzzle added the

Status

Need More Info

2

label 2026-11-12 08:31:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mcmuzzle/EVEProd#60