Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Dynamic fight_style with target_error results in inconsistent behavior?

Abierto
  • ¿Algo no está bien?
#4,447 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?
Lenguaje dominante
C++
Estrellas
1.6k
Forks
789
Merge medio
8 h 18 min
PR fusionados (30 d)
63

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de simulationcraft/simc

Todos los issues de simulationcraft/simc

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.