![\"\"](\"https:\/\/woolstrand.art\/blog\/wp-content\/uploads\/2022\/11\/Screenshot-2022-11-19-at-22.10.11.png\")
![\"\"](\"https:\/\/woolstrand.art\/blog\/wp-content\/uploads\/2022\/11\/Screenshot-2022-11-19-at-22.11.50.png\")
<\/p>\n\n\n\nA short story about how perfect bug report should look like.<\/p>\n\n\n\n
A couple of months ago a bug was reported: ruins were not appearing. Not for everyone. Not always. I knew about this bug, but couldn’t do anything, logs were not helpful and I was not able to replicate the issue by myself. Also all reporters had way too much mods to use it as a reference. So the bug lived until I got those two posts:<\/p>\n\n\n\n
And you know what? I would like to have each and every bugreport like those two. Because those have enough information to replicate the bug for me, so I was able to find the issue in VE core and report it to Vanilla Expanded maintainers (and thanks to them, they fixed the issue just in a couple of hours).<\/p>\n\n\n\n
The bug is gone, ruins are generating fine. Time to get back to development.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
Bonus part: how to search for faulty mod quickly<\/p>\n\n\n\n
You can use approach called “binary search”. If you have 200 mods, you don’t need to do 200 relaunches, removing mods one by one and running tests. You remove a half: 100 mods at once and see what happens. If the game still fails, you remove another half: another 50 mods and so on. If the game runs fine, then it means the incompatible mod was just removed, so you re-add mods you just deleted and remove everything else.
Using this approach you can narrow down 200 mods to 6 in just five checks. And since many mods go in groups (like Core + parts) you can make number of steps even less. <\/p>\n","protected":false},"excerpt":{"rendered":"