Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Dynamic fight_style with target_error results in inconsistent behavior?

Aperta
  • Qualcosa non va?
#4,447 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
cpp
Ambito
backend

Direzione di ricerca

Start by reading the fight_style logic for dynamic raid-event timing and the simulator's target_error iteration-length handling; the issue names no files or tests. Compare how HecticAddCleave schedules its last add spawn with and without target_error. Done would require deciding whether event timing should use mean or expected iteration time, and whether target_error should produce a uniform fight-length distribution.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

This is just a set of notes for myself, and I guess generic discussion on how we are currently doing the dynamic portion of fight_styles, and how it interacts with target_error. And perhaps more importantly, what we should do about this (if anything)?

Our fight_style system allows a certain amount of dynamic behaviour on the timing of the individual raid when using styles like HecticAddCleave. The dynamic values are calculated during simulator init, and are based on mean times.

Since the simulator iteration lengths are by default varied (+- 20%), and the raid events of the fight_styles are not accounting for fight length variance, we run into situations, where from iteration to iteration, the fight styles behave inconsistently. For example, with HecticAddCleave, no matter what length your fight is, the last add spawn will always be at t=225.

The above is further amplified by the fact that the simulator can be run in two different modes. When the simulator is run with no target error (i.e., fixed iterations), the simulator will run a close to uniform distribution of each fight length in the total range of fight length (max_time +- vary_combat_length). The uniformity is accomplished by adjusting the iteration combat length based on the proportion of work done. What follows is that the largest swings (from iteration to iteration) in combat time are also at the end of the simulation run.

With target_error option, the situation changes from above. As target_error has no fixed number of iterations (although it does converge towards some value), the system described above will result in the iteration fight length distribution to be such that the (vast) majority of iterations are concentrated at the extremes, and as such, the metric values will also be skewed towards the extremes. This leads to more iterations to converge to the wanted target_error value.

So, in total there are in my opinion two issues and/or discussion points:

  1. Should the dynamic nature of the raid events issued by fight styles follow the mean values, or should they be computed in relation to an expected iteration time?
  2. Should the fight length distribution of target_error converge to an uniform distribution with a range max_time +- vary_combat_length?
Lingua principale
C++
Stelle
1.6k
Fork
789
Merge medio
8h 18m
PR unite (30g)
63

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di simulationcraft/simc

Tutte le issue di simulationcraft/simc

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.