Reporting a bug¶
Where¶
- Bugs: GitHub Issues on
Horizon-36596/simloop. Use the bug form, or the "Sim doesn't match my robot" form when the sim runs but its numbers differ from your robot's. - Questions and ideas: GitHub Discussions.
There is no Discord, no mailing list and no support address. Issues and Discussions are also the only routes that leave a record the next person with the same problem can find.
What to put in it¶
A simulator bug report is unusually easy to make complete, because the run is reproducible by construction. Four things, and the first two matter most:
- The scenario, or enough of it to run — the config values, the tick count, the time step. Numbers, not descriptions.
- What you expected and what you got, as the actual assertion and the actual failure message.
- The SimLoop version, from your build file, and your FTC SDK version.
- The RLOG, if the failure is about what was logged rather than about a compile error.
If two runs of the same scenario disagree, say so explicitly and include both logs — that is a determinism bug, which is a different and more serious thing than a wrong number.
What is a bug and what is a boundary¶
Before filing, check What it does not do. Several reasonable-sounding requests, such as an intake that really grips, a rendered camera image, a shipped field or an auto-tuner, are deliberate boundaries rather than gaps, and the page says why for each. A request to cross one is still worth making; it is just a different conversation from "this is broken".
Contributing a fix¶
The module is built to be read: every public class, method and field carries javadoc with units and frame
on every number, and that is enforced — ./gradlew :SimLoop:apiDocs runs with doclint on and warnings
fatal, so a new public method without a comment fails the build.
Run the tests before you propose anything:
(Run it from the repository root. The :SimLoop prefix is always correct: the library is a Gradle
subproject and never the root project.)