Outline the plan for troubleshooter
This commit is contained in:
26
test/mod_list_troubleshooter_test.dart
Normal file
26
test/mod_list_troubleshooter_test.dart
Normal file
@@ -0,0 +1,26 @@
|
||||
// Here's the plan:
|
||||
// This class will take an instance of ModList and manipulate it in various ways
|
||||
// What we want to achieve is two things:
|
||||
// A) a binary search / bisect algorithm to find the minimum set of mods
|
||||
// that exhibit a bug
|
||||
// B) a linear search / batching algorithm for the same purpose
|
||||
// Why both? I think B will be most useful most often but A theoretically
|
||||
// should be faster
|
||||
// Why I think A might not always be faster is because it takes us a very long
|
||||
// time to load a lot of mods
|
||||
// So say it takes us 30 minutes to load 300 mods
|
||||
// Via bisect we would be loading 30 + 15 + 7.5 + ... = some 50 minutes
|
||||
// Via linear search we would be loading say 30 mods at a time
|
||||
// Which would be 3 minutes per batch for 10 batches
|
||||
// ie. 30 minutes
|
||||
// Reality is a little bit more complicated than that but that is the theory
|
||||
|
||||
// Now - how should this class do what I detailed it to do
|
||||
// Keep the original ModList and copy it for every iteration
|
||||
// Whether that be an iteration of bisect or a batch of linear search
|
||||
// For every new batch make sure all its dependencies are loaded (ModList.loadRequired())
|
||||
// Then try run game and proceed to next batch (or don't)
|
||||
// Progressively our ModList will shrink (or not, regardless)
|
||||
// And we should keep a registry of tested (say Good) mods and ones we haven't gotten to yet
|
||||
// Maybe even make sure each batch contains N untested mods
|
||||
// And that we don't test the same mod twice (unless it's a library)
|
Reference in New Issue
Block a user