feature ideas

[cforcomputer]

• make the entire row highlight color changes red/green

• Add up and down arrow at the far left next to type to show if the probability has been increasing or decreasing.

• Make sure api is retrieving the latest type ids: TypeID 90854×2
  TypeID 90842×1
  TypeID 90843×1
  TypeID 90850×1
  TypeID 90853

• Explain the ch, co, and p comps. Is the greyed out for p representing the two party sizes fighting each other?

• ability to filter activities by region, with a search to quickly look up a region.

• adding sort by value for all columns (numbers, and alphabetical for letters)

• When adding the route calculation, "route for content", it uses the current active gangs and systems most likely to give a good fight based on the last 60 days of historical battles and roam routes.

• Also add a "safest route - fastest" that avoids all the current activities, and safest route "historical" which adds all active, but also routes for least active systems, which can be far longer.

[cforcomputer]

• Remove the regions view. (just using it for debugging). Replace with the salvage fields page.
• Add back the solar system preview, this time make it show multiple kill id locations for each system when clicking back through the list, so you can visualize where it happened on the gate.
• add a page for the galaxy map, this time just make it be highly optimized 2d map that clearly splits everything into region blocks far away from the other region systems.
• So 3 pages. Live activities, salvage fields, and map view

[cforcomputer]

• before adding all map stuff back in, train the ml model and make sure it can recognize the different activities.
• The part of the app that recognizes when camps are about to happen can be time series, separate from ML? Maybe when scheduling a route it will give a warning to the user that "warning: x gate camp will likely within the next 15 minutes"
• Add the TTS activity system and region activity alerts module back in once activities and ml are fully working.

[cforcomputer]

There can only ever be one camp on each gate. If a new group appears to be camping a gate, the old one is removed. Example, there has to be logic that handles when all the players in a camp are killed, but the group may respawn and keep roaming. But the activity in their last system before the majority of them died is "reset" and if the surviving players keep roaming it creates a new activity.

if activity.at_system.at_gate > 1 then check.if_alive: if dead: activity -1: activity_system.at_gate = survivor?

it would actually be much more simple just to improve the dead check in this scenario, that would be sufficient.

However, if there is no fight, and the old group has simply moved on or logged off, the duplicate activity will expire after 30 minutes (the current system, which leads to duplicates at the same gate). There needs to be a check that recognizes that the new group is now camping the gate, and there was an old group camping the gate, and they are not in the new killmail or any other killmail, then that group must be deactivated until a new killmail appears or they expire according to the new logic, but only one will therefore appear at the gate in this case.

[cforcomputer]

• Add a filter to exclude abyssal systems again

[cforcomputer]

• Issue: Still creating massive activities that show over 1000 players counting as a Battle, when the most recent activity only involves about 20 players participating in a gatecamp. At some point there may have been a large battle, but it did not recognize that the battle ended and the players have moved on to other activities and split into groups. Now all the different activities in different systems are being clumped together into a battle that happened a while ago in a specific system with 79+ systems visited over 3.5 hours. This is not intended behavior.