Chemlight Management
joebayles opened this issue · 20 comments
The only way to remove chemlights currently is to restart the application. There should be a way to remove/adjust chemlights from within the application.
Additionally, when Squad Leader is being used to demo (kiosk mode), it would be nice for the chemlites and other adjustments to wipe every time.
"it would be nice for the chemlites and other adjustments to wipe every time."
Can you explain what this statement means? Sorry but I don't get it.
The simulation runs it's course, and then resets automatically, so Squad Leader is running on a loop. I think that for the purposes of the demostration mode, like at a kiosk, that those chemlites should be removed every time the simulation restarts.
This would be a different function than the user purposefully removing them (say if the user placed it incorrectly in the first place).
So sounds like there might be 1 or 2 issues:
- Someone needs to add a "remove" message to the simulation file (this can be done & tested by anyone right now & it should work - though I don't know how much that has been tested)
- Add a way to remove a chemlight to the UI (is this still needed if item 1 works as it should?)
But as a workaround the chemlights should go away when the VC is reset.
@joebayles, Squad Leader isn't running the chem lights simulation. Chem lights can come from a message simulator, another instance of Squad Leader, a Vehicle Commander instance, or some other app or process that sends GeoMessages. That means the Squad Leader has no way of knowing that any sort of "loop" is ending or even happening, other than its own GPS simulation if simulated GPS is being used.
I have an idea: how about a new GeoMessage type that tells apps to clear all messages of a certain type, such as chem lights? That would let you add one message to the end of your simulation file that would erase all the undesired messages from the map. I think GeoEvent Extension would (and should) ignore such a messages since it would be an unrecognized type. Let me know what you think.
Related to Esri/vehicle-commander-java#41
I could have sworn I put this issue in VC originally... either way, sounds good to me. Basically, as long as every platform/device can:
- See chemlights
- Modify chemlights
- Delete chemlights
... and they reset with the rest of the simulation, that accomplishes the intent of the issue.
Okay, we will implement these:
- User can modify a chem light
- User can delete a chem light
- User can delete all chem lights
- App can process some sort of "remove" GeoMessage (described by me and by @csmoore on Nov. 6) that deletes all chem lights
I realize now we need to decide what happens on other users' displays when a user does any of the actions in the checklist above. In other words, if I modify or delete a chem light (or all chem lights) in Squad Leader, should messages go out to listening clients?
Here's what I think should happen.
- Modify a chem light: send an update message to listening clients. It would be silly to change a chem light just on the user's device.
- Delete a chem light: send a delete message to listening clients. The user intends to cancel that chem light for all users.
- Delete all chem lights: remove them just from the user's display but don't send out any messages. This capability is really for demo purposes. A Squad Leader user shouldn't be able to delete all chem lights for everyone using the platform. That would be done in a HQ or TOC if it ever needed to be done.
- Process "remove" GeoMessage: remove them just from the user's display but don't send out any messages. Our app just received the message and should not rebroadcast it.
If you disagree on any of this, please let me know soon.
Modify - I agree.
Delete - I agree.
Delete all - Depends on the use case for chem-lites. If they are intended for "single-mission" use, I'd say it would be great to add a "decay" feature where they just go away after a specified amount of time. This is also a feature that is currently in place in FBCB2 for old SPOTREPs (Spot Reports). For instance, when I spot the enemy and submit that report, it will decay over time. It's represented graphically by transparency (it shouldn't gray out since color is an important part of the symbology representation). The other way to do it is to allow a delete all only for chemlites authored by that user.
Process "remove" - I agree.
Hope that makes sense.
The decay feature is a good idea. Let's create a separate issue for it, since it would be automated and the current issue is about the user managing chem lights, and also because we'll have to do the symbology some other way since ArcGIS Runtime's MessageProcessor won't do transparent symbols off the shelf.
I will implement the ability to delete chem lights created by the current user, i.e. during the current run of the application.
👍
Update: I'm still working on this. Most of the code is done and I'm down to some minor bugs in my branch. I hope to finish this off today.
I guess this accidentally got auto-closed by one of the commit comments ("Fixes XXX" - since I didn't close this)...reopening so it can be verified
@csmoore, who would you like to close it then? It's assigned to you.
It should be probably assigned to whoever is able to actually test/verify the issue (usually the originator, but not sure who is testing these issues on an android device).
I cede my testing assignment to someone with more time this sprint... If there isn't anyone I'll figure it out.
@jrweakland is going to do it when the other issues for the upcoming release are addressed.
Reviewed and tested with Squad Leader 3.0.0 RC1
Thanks, @jrweakland. I removed the link to the file since it's internal and this repo is public. We will of course release the pre-built app on our downloads site once your testing is complete.