AA Upwell Fuel
Fuel planning for Upwell structures in Alliance Auth.
Answers one question for leadership: how much fuel do our structures need over the next N days, and how much of it still has to be bought?
Alerting is deliberately out of scope — aa-structures already notifies when a structure is running low. This is the planning view that sits next to it.
What it shows
- Every Upwell structure you can see, soonest to run dry first, or ordered by any other column you click
- The burn rate each structure is actually running at, in blocks per day
- Fuel blocks consumed over the planning period (default 30 days)
- What still has to be delivered, after the fuel already in the bay
- Volume in m³ to size the haul, and ISK at average market price
- Subtotals per corporation, and a CSV export for whoever runs the buy order
- Magmatic gas for Metenox drills, and liquid ozone stock for Ansiblexes
Where the numbers come from
Burn rates are measured, not modelled. Each structure's fuel bay contents
divided by the time until its fuel_expires_at gives the rate the game is
actually charging it, which already accounts for every hull bonus, rig and
service combination without this app modelling any of them.
That matters, because modelling it is genuinely error-prone. A hull's
structureServiceRoleBonus only applies to service modules matching the hull's
role: a Raitaru discounts manufacturing but not a clone bay, an Athanor
discounts reprocessing but not moon drilling. And citadels measurably burn
7.0 blocks/hour for a clone bay where the −25% in dogma predicts 7.5.
The modelled rates in upwellfuel/fuel/catalog.py are therefore only a
fallback, used for structures that are not currently burning fuel — where the
question is what refuelling one would cost. Those rows are marked as estimates
on the page. The catalog's discount rules were validated against measured rates
across a live 41-structure fleet.
Two figures on the page are estimates by necessity:
- Magmatic gas — the Metenox drill's gas rate is not in dogma and gas has no expiry date in ESI to measure against, so it uses a configurable constant.
- Liquid ozone — shown as stock only. Jump bridges burn ozone per jump rather than per hour, so projecting it over a period would be meaningless.
Requirements
- Alliance Auth >= 4.6
- aa-structures, installed, configured, and syncing assets
This app reads aa-structures' data and stores nothing of its own. It adds no models, no migrations, no ESI calls and no scheduled tasks — the report is computed per request and is exactly as fresh as aa-structures' last sync.
Installation
pip install aa-upwell-fuel
Add to INSTALLED_APPS in local.py:
INSTALLED_APPS += ["upwellfuel"]
There are no migrations to run. Restart Auth and the entry appears in the menu.
ISK estimates (optional)
The cost column needs market prices, which nothing loads by default. Add eveuniverse's price task to your schedule:
CELERYBEAT_SCHEDULE["eveuniverse_update_market_prices"] = {
"task": "eveuniverse.tasks.update_market_prices",
"schedule": crontab(minute=0, hour=3),
}
Until it runs, the page shows the fuel figures and hides the cost column.
Permissions
This app defines none of its own. It is a different view onto data aa-structures already owns, so it reuses that app's access model:
| Permission | Effect |
|---|---|
structures.basic_access |
Can reach the page |
structures.view_corporation_structures |
Sees their corporation's structures |
structures.view_alliance_structures |
Sees their alliance's structures |
structures.view_all_structures |
Sees everything |
A user with basic_access but no viewing permission gets an empty table
explaining why.
Settings
| Setting | Default | Description |
|---|---|---|
UPWELLFUEL_DEFAULT_PERIOD_DAYS |
30 |
Planning period selected on load |
UPWELLFUEL_PERIOD_CHOICES |
[7, 14, 30, 60, 90] |
Options in the period picker |
UPWELLFUEL_MAX_PERIOD_DAYS |
365 |
Upper clamp on a period from the URL |
UPWELLFUEL_MAGMATIC_GAS_PER_HOUR |
55.0 |
Gas burned per Metenox drill |
UPWELLFUEL_DEFAULT_FUEL_BLOCK_TYPE_ID |
4312 |
Block priced when the bay is empty |
License
MIT
Metadata
Release files for aa-upwell-fuel 0.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| aa_upwell_fuel-0.1.1.tar.gz | 25.9 kB | Without provenance | Details for aa_upwell_fuel-0.1.1.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| aa_upwell_fuel-0.1.1-py3-none-any.whl | Python 3 | none | any | Details for aa_upwell_fuel-0.1.1-py3-none-any.whl |
Total release size: 55.2 kB
Release files / aa_upwell_fuel-0.1.1.tar.gz
| Download URL | aa_upwell_fuel-0.1.1.tar.gz |
|---|---|
| Size | 25.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
2b34ca933917e0cea0e284b39a9181e8ca3ec5b8a6a45c211e989369752f2478
|
|
BLAKE2b-256 checksum How to use checksums |
33559c3a9f36256be0049f1885af12de23212c9b88fe9ea3fbb1f1e2b37d2af3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.3
|
Release files / aa_upwell_fuel-0.1.1-py3-none-any.whl
| Download URL | aa_upwell_fuel-0.1.1-py3-none-any.whl |
|---|---|
| Size | 29.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9482ae2a7d9d467d37ff6ba977a05f17c2bd41fc0c4fa2efc2e0d4dca2622e97
|
|
BLAKE2b-256 checksum How to use checksums |
51d53fc10246f50aa10737d6cbf03cc0268586ca30ff2b41ef3d4e7455a874ff
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.3
|
Security for aa-upwell-fuel 0.1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.