Treat Unconfirmed Reports as normal threats

[kuhrusty]

When running with 5 players, I want Unconfirmed Reports to show up as normal threats; when running with fewer than 5 players, I want Unconfirmed Reports to not show up at all.

(I know there's an option for turning off Unconfirmed Reports in random missions, but that's not quite what I want; and, I want the standard missions to behave the same way too.)

I am imagining the following:

• some "number of players" SeekBarPreference
• some message which displays at the start of the mission saying how many players are selected (or some other way to keep from accidentally getting the wrong number of threats)
• the actual changes to ignore unconfirmed reports, or treat them as normal threats
• some CheckBoxPreference for disabling all of this behavior
• probably remove the existing unconfirmedReportsPreference

(I forked the tree to make these changes myself, but have not started on them yet.)

[nibuen]

Sounds like a good plan to me

[kuhrusty]

Hey, I don't know German; what do you want me to do for new strings in values-de/strings.xml?

• probably wrong: paste whatever Google Translate comes up with
• definitely wrong: copy English versions from values/strings.xml
• definitely wrong, but more obvious: use placeholders like "BROKEN BY RUSTY"

[nibuen]

Google translate and mark a comment... I don't know German either, but it allows other to come propose better translations

[mkalus]

I can translate the broken strings for you :smile:

Just give me a note when you are finished.

[nibuen]

@kuhrusty please check this when you get a chance https://github.com/nibuen/SpaceAlertMissionGenerator/pull/30 want to make sure not conflicting with your work too much

[nibuen]

see here for how I mark https://github.com/nibuen/SpaceAlertMissionGenerator/pull/30/files#diff-cdca861e65ab0caf0dac48368b3fa2a6R10 Google Translates

[kuhrusty]

@kuhrusty please check this when you get a chance #30 want to make sure not conflicting with your work too much

There's definitely some overlap (I didn't change minSdkVersion & targetSdkVersion, but I made some of the other same changes in AndroidManifest.xml and preferences.xml, and switched TestMissionImpl.java to JUnit before adding tests of my changes, etc.); should I merge circleci-project-setup into my fork, or just plow ahead & let you worry about the merge from circleci-project-setup later? Either way is fine with me.

[kuhrusty]

I'm done checking in my changes, but it looks like whitespace or line terminators in MissionType.java got changed unintentionally, making it hard to see what I did in there. (I think there was another file in an earlier commit where that happened, too.)

Note that, when I was first fiddling around with it, I think the wear module didn't build for me, so I commented it out in settings.gradle; you probably don't want that change. I also moved TestMissionImpl.java from app/src/androidtest/java/... to app/src/test/java/... before adding a pile of tests; I hope that doesn't complicate things.

Anyway, if you want me to merge circleci-project-setup into there before creating a pull request, let me know; I will be happy to do so.

[nibuen]

@kuhrusty yea let's merge circle-project-setup first as I agree not much was working due to how old the code base was... I can double check the formatter once you put PR up since we never formalized on one (think it was just default for Android Studio with the 1.0 release)