Description
Feature Request
Currently in-game if you store a fleet setup and then use it to create a new fleet then the ordering of the wings and squads in the fleet stays consistent.
However there is no way currently to figure out that ordering or easily change it via ESI.
If you are using a website to manage your fleet via ESI, the only way to ensure wings and squads are ordered the way you want them to be is to remove every wing and squad and create everything from scratch in the proper order.
So this feature request is specific to add the order of the wings and squads to the relevant GET endpoints, and then allow us to change them via the relevant PUT endpoints.
Use case
I manage one of the websites used by EVE Rookies to manage fleets, and currently I'm working on the ability for FCs to save fleet configs on the website, both for themselves and to be able to share with new FCs.
Given a lot of FCs will load their saved config with their fleet in-game when they create their fleet I wanted to cut down on the ESI calls I needed to make by only creating new wings/squads as needed instead of deleting everything already in the fleet and re-createing it per their saved config on the website.
However that means that sometimes wings/squads will not be in the position in the fleet in-game that the FC would expect them to be, and that ordering can be quite important for situational awareness.
Authentication
Existing esi-fleets.read_fleet.v1 and esi-fleets.write_fleet.v1 scopes
Example return
Propose what an example return might look like. E.g.:
GET /fleets/{fleet_id}/wings/
[
{
"id": 2073711261968,
"name": "Wing 1",
"order": 0
"squads": [
{
"id": 3129411261968,
"name": "Squad 1",
"order": 0
},
{
"id": 3129411261969,
"name": "Squad 2",
"order": 1
}
]
}
]
PUT /fleets/{fleet_id}/wings/{wing_id}
Update this endpoint to allow renaming of a wing and changing it's order
PUT /fleets/{fleet_id}/squads/{squad_id}/
Update this endpoint to allow renaming of a squad and changing it's order
Checklist
Check all boxes that apply to this issue:
- Feature request description is provided
- Use case exists
- Feature requires a new route
- Feature adds data to existing route
- Feature requires new auth scope
- Feature can reuse existing scope
- Feature does not require auth
- Meta feature, applies to all routes