Discussion Ardent Industry API

[Flash Moonboots]

Pfft.. I'd say go for it if you've got updates.

I tried to use this but the details for commodities kept pushing me to ports that were farther than I wanted to go. I ended up scouting via Inara.

Hey thanks for the feedback!

Yeah the INARA UI has a lot more options - including tracking ship equipment - and I'm avoiding just trying to make a worse version of it, or I would be playing catchup for likely a couple of years worth of development and it would ultimately be a bit pointless, even if it was open data / open source, so trying to do unique take on fun-but-still-useful thing (but it's a bit of a journey to get there still...)

On the issue:

The data for both sites should be very similar, different processing obviously and maybe different downtime as require for essential maintenance as required but both sourced from EDDN, so would be helpful to understand if you think there is a driving factor was there.

I was wondering if the filtering options for jump distance / quantity being a bit too limiting was a problem, I didn't want too many options but I do feel it's not granular enough and that maybe it should be a combination dropdown/text input, so people can put in custom values. I'd be interested to hear if that would help or if other options, like landing pad size or something else feel particularly missing.

 

[Freyar]

I think it's more about what my objective is as a prospective user. I am doing heavy (mostly solo) construction in non-jump optimized cargo ships. I am (for the most part) price flexible so lowest price isn't what I am looking for.

If I were still operating with a trade-for-profit focus then the sorting/filtering today would be fine. I think in this case my goals don't align with your design objective.

 

[Flash Moonboots]

I think it's more about what my objective is as a prospective user. I am doing heavy (mostly solo) construction in non-jump optimized cargo ships. I am (for the most part) price flexible so lowest price isn't what I am looking for.

If I were still operating with a trade-for-profit focus then the sorting/filtering today would be fine. I think in this case my goals don't align with your design objective.

Thanks for the detail! Yeah I agree it feels misaligned with what most players - including myself - actually want at the moment.

I've intentionally avoided re-implementing the more powerful but also more complex UI options of INARA, so baked in assumptions to allow the interface to be simpler, automatically sorting by price (combined with filtering by distance) being one of those.

This was was pre-Trailblazers and so I'm also not finding that super helpful right now and will have to revisit some decisions there. It's working out okay for me, but would like it to be more streamlined - i.e. to automatically fetch and track my construction sites and to track their progress and highlight where to go next to stock up nearby.

 

[Flash Moonboots]

Status update​

I've been reasonably happy with the recent updates to the Trade Data UI and the homepage this week. I'm not done with them yet but it's good ground work for future improvements and having some some refactoring makes it easier to iterate on future improvements.

This weekend I rolled out a fix for a long standing issue that was causing data for stations with markets (the scope of which includes Starports, Outposts, Ports, Surface Settlements, Fleet Carriers, Megaships) whereby they were not being updated / refreshed when they were revisited later.

I had noticed there was maybe a bug a year ago or more but only dived into it given the recent updates, which have seen a lot of new stations and systems come online, and because I'm starting to look at improve the system map interface.

You can already search for system names on https://ardent-industry.com but I'm really looking forward to expanding on the site functionality. I'm considering maybe porting some functionality from ICARUS Terminal over, as well as improving on it.

As with ICARUS Terminal, I intend to leverage the EDSM.NET API at first, in particular for system body information as it does that really well and it has a great API, but will augment it with Ardent data and potentially expand the scope of data I'm tracking specifically for populated systems and/or power play.

Major bug fixes​

A fix for station information not updating was rolled out yesterday evening, station information should start to get a lot more accurate from here on in.

There are 322,774 stations in the database, which includes Fleet Carriers, and 99% of stations should get updated this week. I estimate getting enough data from EDDN for the longer tail of 2,898 CraterPort and SurfaceStations will likely take about 30 days or so to get enough data to consider the fix complete.

Upcoming API response change​

I wanted to give folks a heads up that I'm going to be making what could be considered a breaking change to the content of field returned by the API. This does not change the structure of the response object and so is not strictly breaking but it does change the values stored and what you will see returned for stationType.

I don't intend to bump the API endpoint version for this change.

Currently the service normalizes names for the stationType field and stores and returns them in a human readable form, like this:

• Asteroid Base
• Coriolis Starport
• Fleet Carrier
• Megaship
• Ocellus Starport
• Odyssey Settlement
• Orbis Starport
• Outpost
• Planetary Outpost
• Planetary Port
• NULL

Unknown symbols preserved, so there are also results for the following stationTypes in the stations database:

• GameplayPOI
• PlanetaryConstructionDepot
• SpaceConstructionDepot

The latter two ConstructionDepot types above are new with the Trailblazers update, the GameplayPOI is apparently unique to 3 stations.

In an upcoming update, the system will only store and return the in-game symbols, for example of the following:

• AsteroidBase
• Coriolis
• CraterOutpost
• CraterPort
• FleetCarrier
• MegaShip
• Ocellus
• OnFootSettlement
• Orbis
• Outpost
• PlanetaryConstructionDepot
• SpaceConstructionDepot
• SurfaceStation
• NULL

Any mapping of these into human readable names will move to the front end.

New station types that are added to the game will appear in the database automatically and I'll be adding an new endpoint - something like /stations/types - that returns a list of all known types and the number of each type in the database so we can track them. I may also add options to filter some types of queries by station type.

 

[Flash Moonboots]

Deployment of update now complete​

Following up confirm the update has now been deployed and the data being collected and stored, the API and the website are now all aligned with this change.

It didn't take as long as I thought for me to make and it all seems to be working fine.

There is a new API endpoint that lists the number of stations of each type so this can be monitored easily:

https://api.ardent-industry.com/v1/stats/stations/types

{
  "stationTypes": {
    "null": 42897,
    "AsteroidBase": 114,
    "Coriolis": 6878,
    "CraterOutpost": 27179,
    "CraterPort": 3407,
    "DockablePlanetStation": 1,
    "FleetCarrier": 34130,
    "GameplayPOI": 6,
    "Megaship": 344,
    "Ocellus": 1702,
    "OnFootSettlement": 245763,
    "Orbis": 3924,
    "Outpost": 28563,
    "PlanetaryConstructionDepot": 4480,
    "SpaceConstructionDepot": 600
  },
  "total": 399988,
  "timestamp": "2025-03-23T10:31:43.271Z"
}

There are a few oddities here like 1 entry for DockablePlanetStation and 6 stations that have the GameplayPOI type. I don't know if that is a data quality issue with the game or with a client reporting to EDDN or some other edge case. For the curious, those stations are:

marketId, stationName, distanceToArrival, stationType, allegiance, government, controllingFaction, primaryEconomy, secondaryEconomy, shipyard, outfitting, blackMarket, contacts, crewLounge, interstellarFactors, materialTrader, missions, refuel, repair, restock, searchAndRescue, technologyBroker, tuning, universalCartographics, systemAddress, systemName, systemX, systemY, systemZ, bodyId, bodyName, latitude, longitude, maxLandingPadSize, updatedAt
4207438595, Heck Vista, 664.958774, GameplayPOI, , Dictatorship, Close Encounters Corps, Refinery, , 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 9467047257457, Arietis Sector QS-T b3-4, 2.96875, -84.75, -134.15625, 14, Arietis Sector QS-T b3-4 A 6 a, -8.730869, 167.507721, 3, 2025-03-21T22:55:28.496Z
4208469251, Parnell Hub, 1039.693009, DockablePlanetStation, Empire, Corporate, ExDronPi Enterprise, Industrial, , 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 84120933098, HIP 59778, 167.0, -42.3125, 99.34375, 22, HIP 59778 A 3 c, -30.589317, 63.412651, 3, 2025-03-08T18:35:00.353Z
4208961027, Kerouac Cove, 1603.952094, GameplayPOI, Empire, Dictatorship, Party of Wally Berod, Refinery, , 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 1934656244091, HIP 114402, 156.375, -182.28125, 138.21875, 24, HIP 114402 3 b, -63.4249, 132.189407, 3, 2025-03-20T11:39:30.018Z
4209419267, Butler's Progress, 400.225353, GameplayPOI, Federation, Democracy, Jamush Republic Party, Refinery, , 0, 0, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 2871320126897, Hydrae Sector EQ-Y b1, 102.28125, 62.4375, 20.96875, 8, Hydrae Sector EQ-Y b1 1, -37.377544, 175.888763, 3, 2025-03-03T20:21:45.945Z
4212139779, Bohm's Folly, 539.713773, GameplayPOI, , Communism, Union of Kosche, Refinery, , 0, 0, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 9466510583257, Col 285 Sector JE-M b22-4, -43.625, -21.28125, 123.625, 4, Col 285 Sector JE-M b22-4 A 2, 13.712296, -72.776657, 3, 2025-03-16T18:27:15.161Z
4215131651, Aurelius Enterprise, 15.844018, GameplayPOI, Empire, Corporate, Narveti Company, Refinery, , 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 673101260193, Synuefe HO-W b48-0, 157.09375, -213.78125, -11.03125, 14, Synuefe HO-W b48-0 3, 45.21981, -32.767574, 3, 2025-03-10T14:56:42.840Z
4222704387, Kek Point, 1499.910166, GameplayPOI, Federation, Corporate, Bot Network, Refinery, , 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 93328028617744, Col 285 Sector SO-E -5, -1.1875, -26.125, 235.125, 3, Col 285 Sector SO-E -5 3, 52.069195, -177.806778, 3, 2025-03-21T22:53:21.902Z

Some of the systems currently being returned as 'CraterPort' stations should be 'SurfaceStation' types as previously this distinction was not being recorded as it used to be a bit of a distinction without a difference for most players - both ports and stations support large landing pads, the conspicuous difference was cosmetic. However, the distinction has become more relevant with the Trailblazers update, as the type of station can have an impact on system population and the system economy and on the specific economy of nearby stations.

The station type for surface stations will auto-correct over time - i.e. anytime someone lands at one who is running a client that reports back to EDDN. This goes for all stations, including some of the edge cases above. Anytime someone docks at a station the latest information about what facilities are available, who is in control of the station, what the economy type is (etc). should all be updated.

Note: Separate to the stations database, which stores only dockable locations, there is a locations database which logs thousands of instances of in-game POIs but it is not currently exposed by the API - but I hope to use it to surface interesting data and surface POIs flagged by the community in the future.

Like the rest of the data Ardent collects and stores, raw location data can be downloaded from https://www.ardent-industry.com/downloads

 

[gazelle]

First, I really like the UI of the web site, very clean and simple.
Second, some thoughts about Stations and their types:

The StationType Bernal is only used in the Location event, otherwise it is now Ocellus.

SurfaceStation was used for planetary ports in the old days and was replaced with CraterPort or CraterOutpost. It is now wrongly reported for special types of stations, (eg. Stronghold Carriers, System Colonisation Ship, ...). I'm ignoring it and use some self defined types.

I have some corrections I do first to the stationname before I determine a type:

^\$ShipName_StrongholdCarrier\b.*	Stronghold Carrier
Hochburg-Carrier	Stronghold Carrier
Portanaves bastión	Stronghold Carrier
Porte-vaisseaux de forteresse	Stronghold Carrier
Transportadora da potência	Stronghold Carrier
Носитель-база	Stronghold Carrier
^\$EXT_PANEL_ColonisationShip\b.*	System Colonisation Ship

if stationname in {"Stronghold Carrier", "System Colonisation Ship"}:
    stationtype = "MegaShip"
    # I really use "StrongholdCarrier" or "SystemColonisationShip" defined by me, not fdev.

I also have some special checks if I don't know the stationtype but have a marketid:

if 3700000000 <= market_id < 3720000000:
    stationtype = "FleetCarrier"
elif 3800000000 <= market_id < 3930000000:
    stationtype = "OnFootSettlement"

DockablePlanetStation is a interim type for the transition from PlanetaryConstructionDepot to CraterOutpost (so far, maybe also to CraterPort or OnFootSettlement).

GameplayPOI (I observed) is a interim type for the transition from PlanetaryConstructionDepot to an undockable station (eg. installation).

 

[Flash Moonboots]

Thank you, that's incredibly helpful!

I had seen some of the values like $EXT_PANEL_ColonisationShip and am ignoring them but had only noticed Stronghold Carriers coming though as NULL before, but comparing the database with the above list I can see they come through with other incorrect station types (like CraterPort...).

That's great, I'll implement something similar using that logic - agree that it seems like having a built-in type for Strongholds is going to be useful if Fdev are not implementing something explicit.

Now that you mention it I'm recalling the mess around old types like SurfaceStation is why I think I started maintaining my own list originally, but I started doing that so long ago I had mostly erased that from memory, I just cargo-culted some of the logic over from my old code in ICARUS Terminal and I forgot to write WHY I was doing it in the comments.

if 3700000000 <= market_id < 3720000000:
stationtype = "FleetCarrier"
elif 3800000000 <= market_id < 3930000000:
stationtype = "OnFootSettlement"

^ Oh this is very cool, thank you. I didn't know that distinction based on Market ID range was possible.

DockablePlanetStation is a interim type for the transition from PlanetaryConstructionDepot to CraterOutpost (so far, maybe also to CraterPort or OnFootSettlement).

GameplayPOI (I observed) is a interim type for the transition from PlanetaryConstructionDepot to an undockable station (eg. installation).

Thank you also for this! Something like that was my hunch but I didn't really have anything to go on. I wonder why they have done that...

 

[gazelle]

^ Oh this is very cool, thank you. I didn't know that distinction based on Market ID range was possible.

It's not official but based on my database:

marketID	group_concat(distinct fdev_name ORDER BY fdev_name, ', ')	count(*)	min(market_id)	max(market_id)
NULL	FleetCarrier, StrongholdCarrier	6876
128xxxxxx	AsteroidBase, Coriolis, CraterOutpost, CraterPort, MegaShip, NULL, Ocellus, OnFootSettlement, Orbis, Outpost	1269	128000000	128999873
129xxxxxx	Coriolis, MegaShip, Ocellus, Orbis, SurfaceStation	65	129000129	129033463
32xxxxxxxx	Coriolis, Ocellus, Orbis, Outpost	40122	3221225472	3240326656
35xxxxxxxx	CraterOutpost, CraterPort, NULL	21804	3500000000	3546895360
36xxxxxxxx	MegaShip	9	3600001792	3600010762
370xxxxxxx	FleetCarrier	36459	3700000256	3709999872
371xxxxxxx	FleetCarrier	3999	3710000128	3711579648
378xxxxxxx	CraterOutpost, CraterPort	1553	3789600000	3789999872
379xxxxxxx	CraterOutpost, CraterPort, NULL	6556	3790000128	3791970304
38xxxxxxxx	OnFootSettlement	196232	3802400000	3899999744
390xxxxxxx	OnFootSettlement	17706	3900000000	3909999872
391xxxxxxx	OnFootSettlement	17970	3910000128	3919479552
392xxxxxxx	OnFootSettlement	15142	3920160000	3929145088
393xxxxxxx	StrongholdCarrier	289	3930399745	3930478081
395xxxxxxx	SpaceConstructionDepot, SystemColonisationShip	6582	3950881026	3959998722
396xxxxxxx	SpaceConstructionDepot, SystemColonisationShip	257	3960008706	3960628226
42xxxxxxxx	AsteroidBase, Coriolis, CraterOutpost, CraterPort, NULL, Ocellus, OnFootSettlement, Orbis, Outpost, PlanetaryConstructionDepot, SpaceConstructionDepot, SurfaceStation	19657	4206880003	4225147907

I also think that 35xxxxxxxx are the horizon planetary stations and 37[89]xxxxxxx are the odyssey ones but I don't need that distinction. Stronghold carriers have their own range but I use the station name for them.

 

[Flash Moonboots]

Follow-on changes to data returned by the API​

1. I've use the helpful information above to also implement checks for Stronghold Carriers and have also implemented an explicit "StrongholdCarrier" type, because it was either coming through as NULL or CraterPort on messages via EDDN.

I don't know if that's purely a data quality issue with the game or if some clients are trying to work with missing data and guessing what it should be and getting it wrong, but either way it's very useful for Power Play to be able to explicitly query for Stronghold Carriers (that should be coming soon!).

Note: This is the only specific custom type I anticipate supporting at the moment, I'd otherwise like to keep in closer alignment with the official types, but this really feels like a special case where the game is missing something (with Recue Ships arguably being another...).

2. I have added some data retention caps.

2.a) Rescue Ships - Rescue ships that have not been active in the last 7 days will be removed automatically (this accounted for a number of old, incorrect megaships)
2.b) Invalid Stations - Stations that have transitioned from being dockable to not dockable will be purged automatically each day
2.c) Trade Orders - The database and the website now only support commodity trade orders added / updated in the last 90 days

Until a few weeks ago I had been storing trade data with no limit on how old it was. The last change to this policy capped the age of trade orders at 356 days, but I anticipated then I might have to reduce this cap to 90 days at some point - I didn't expect it to be so soon though!

With x2-3 as much player activity this year, which is wonderful to see, the cost / benefit of keeping older data means it's not worth it to keep hold of much older trade data. INARA retains trade data for 180 days (~6 months), which I also considered as a limit, but I ultimately decided on 90 days / ~3 months so that I don't end up having to do this again anyway, if player activity levels keep up.

This change has involved some service interruption this evening - the API has been slow over the last hour or so and it will be like that for a little while yet.

Note: Data for Star Ports, Surface Ports, Outposts, Settlements, Megaships (other than Rescue Ships) etc. does not expire and will remain even if a system is not visited indefinitely and that will not be changing - this limit only applies to trade orders, where stale data is less useful and there is much more of it. Fleet Carriers that haven't been reported in don't currently expire either, but I might review that at some point, if only because carriers can be abandoned and so it's probably useful to purge them too, at some point (e.g. if it's been more than 1-3 months since they were last known to be active).

3. I have not attempted to go back and update data for NULL (unknown) station types using the approach documented above yet, but I do plan to. Some of the information above seems pretty safe to act on and should help backfill data for a lot of incomplete settlements and stations.

{
  "stationTypes": {
    "null": 50428,
    "AsteroidBase": 126,
    "Coriolis": 6023,
    "CraterOutpost": 26488,
    "CraterPort": 3004,
    "DockablePlanetStation": 1,
    "FleetCarrier": 34106,
    "Megaship": 194,
    "Ocellus": 1461,
    "OnFootSettlement": 245247,
    "Orbis": 3421,
    "Outpost": 27640,
    "PlanetaryConstructionDepot": 4427,
    "SpaceConstructionDepot": 800,
    "StrongholdCarrier": 162,
    "SurfaceStation": 506
  },
  "total": 404034,
  "timestamp": "2025-03-24T19:33:15.369Z"
}

4. There are some other data quality issues, I'm hoping many of these will get shaken out over the next few weeks. I might have to start getting more strict about what data I accept from EDDN clients as I think some of the data coming through being iffy is making things harder than they need to be.

 

[Flash Moonboots]

Final update in this saga to say that the database update is complete and performance is back to normal now, or better.

It took a couple of hours to complete in the end, it's can be a bit of a slog having to wait for operations on a large database optimized for fast / cheap reading to complete. I'd do them offline and sync, if my internet wasn't so limited!

I might not post back for a couple of weeks now, I might do some improvements quietly in the background, but the next time you hear from me I should have new features to talk about again!

 

[Flash Moonboots]

It's only been a few days, but I said the next time I would post, it would be about an update with actual features!

Added API endpoint to find nearest station services​

You can now query to find the nearest station providing a specific type of service and get back information about the station and system they are in.

The location of 20 nearest matching stations will be returned, in order of distance (nearest first).

A minimum landing pad size for the station can be specified.

• https://api.ardent-industry.com/v1/system/name/{systemName}/nearest/{service}

You can query for any of these services:

• https://api.ardent-industry.com/v1/system/name/Sol/nearest/interstellar-factors
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/material-trader
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/technology-broker
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/black-market
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/universal-cartographics
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/refuel
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/repair
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/shipyard
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/outfitting
• https://api.ardent-industry.com/v1/system/name/Sol/nearest/search-and-rescue

Supported query parameters​

• minLandingPadSize (int); default 1 (1 = small, 2 = medium, 3 = large)

Feedback and suggestions on improvements to this are very welcome!

Future plans include the option to specify raw XYZ galactic co-ordinates to the API.

---

Added sign-in to ardent-industry.com​

I've also added the ability to sign to the homepage on ardent-industry.com, securely using the existing Frontier account for your CMDR.

It uses the official Frontier OAuth API, this means you don't need to actually create a new account or share your login details with anyone except directly with Frontier. You can sign in from multiple devices, and you should stay signed in on any devices for up to 30 days - after that you will need to sign in again to confirm with Frontier if you want the site to continue to be able to access and display your CMDR information.

This is the first time I've exposed this feature on the site and the functionality is still limited, but it's still hopefully somewhat useful. It should at least be working enough for me to shakeout any issues with the implementation. There are few rough edges but would love your feedback if you have any.

In addition to a summary of your current status, it uses the new endpoints to display information about nearby services. It does not (yet!) live update your stats the way ICARUS Terminal does, but future updates should enhance this functionality and the trade functionality to make use of things like your current location, current cargo capacity, etc. to automatically surface relevant information, including some of the hundreds of interesting unique POIs in the game (logs, voice recordings, crash sites, abandoned bases, etc).

 

[Flash Moonboots]

Primary domain name change​

When I started this project I'd intended only to fill in an API gap for Trade Data and maybe some other related things, like station services - nothing as comprehensive as INARA but useful for developers, including myself, working on their own tools who would find a central database with an API (and/or database dumps) useful.

I've really enjoyed working on this site and have started to branch out the functionality. It has taken a while because there is always some foundational work to do, some maintenance which takes away from development time - in particular in response to recent surges in player activity, and the new game mechanics with new materials, new station and megaship types, etc. - and I like to take a break from time to time, not least to actually play the game!, but I'm very happy working on it and am starting to get into the interesting functionality and extending beyond just trade data.

With that in mind, I've gone ahead with something I've been mulling over for a few months now and changed the default domain, and name displayed on the website, to Ardent Insight to reflect the wider remit of functionality, that is growing beyond just trade data.

The new primary domain is ardent-insight.com

As with the previous domain (ardent-industry.com) it also works without the hyphen. The old domain will continue to work for the website and the API but the website will now redirect to URLs that use this new domain to help avoid confusion. The URLs in the documentation have already been changed.

The only really conspicuous change is that if you have signed in, you will be prompted to again because the domain for the authentication cookie has changed.

Given I can't change Forum Topics I MIGHT create a new topic on here and redirect to it from this thread, but I'll post back here if I do that.

Minor update / upcoming improvements​

To give an idea of where I'm going with future improvements, I've added some improvements to the System view: https://ardent-insight.com/system/Sol

It's a bit crude right now but I'm going to be working on the System view, and on new views for Engineering, Fleet Carrier management, and Trade that leverage the Frontier APIs for CMDR data.

Feedback​

If anything seems really broken I'd really appreciate feedback about it!

 

[Flash Moonboots]

System Upgrade​

On Thursday, the service was migrated to a new hardware platform.

This system has increased RAM to support additional functionality, with a trade off for disk space, which I wasn't using anyway.

It took a few hours to get everything migrated and the DNS updated to point to the new service. This was a good fire drill which confirmed it doesn't take long for me to get it up and running on an entirely new system and in the end it all went well.

Performance has been pretty good recently but should be further improved as there is additional free capacity for disk caching - almost everything, except the system data, fits entirely in RAM all of the time - which will also enable support for new features down the line.

The migration is complete now and the old server will be turned off over the weekend. If you DNS is being cached by your device / network and you are accessing the older version of the site / service and it stops working after tomorrow you will need to flush your DNS. This shouldn't happen for anyone, but mentioning this for awareness.

If you can can see "Ardent OS 1.13.1" (or newer) in the top right of the homepage at https://ardent-insight.com you are already on the new system! If not, try refreshing and then try restarting your device if you have had it running for a while.

Note: As a side effect if this migration, you were signed in, you may have been signed out (possibly more than once) as authentication service was active on both old and new systems for a time, sorry about that - frankly it didn't seem worth the effort to make that more seamless given it's a very early stage feature with limited value, but it should be stable again now; you should only need to confirm your identity again once every 30 days (as required by FDev).

Minor Improvements​

I've made a lot of small quality of life improvements to improve front end performance, address minor UI bugs added small features. Nothing major, there are still a lot of things not yet at the level I want them to be at, but it's better.

I'm probably going to focus on improving the functionality of the system view next - e.g. https://ardent-insight.com/system/Sol - to leverage the EDSM API and to bring it closer to par with some of the features already in ICARUS Terminal. That should be easy, because I can port over over a lot of the code.

After that I want to turn to CMDR specific functionality, like Fleet Carrier overviews and inventory management and to colonisation data, specifically to make it easier to track construction progress.

I'm not sure yet how distracted I will get with things like Power Play or system information related features, or things like Engineering, I expect to get round to both later but I might dabble in them - again I have a lot of code I could port over.

 

[Flash Moonboots]

UPDATE: New Thread for Ardent Insight Created!​

PLEASE SEE THE NEW THREAD FOR FUTURE UPDATES

I'm leaving the original post intact for future reference, but to avoid confusion caused by the change of name - which I think was necessary given the evolution of the site, as well as the new name being better - all updates relating to Ardent will be on the new thread!

Thank you so much everyone for all the comments, feedback and reactions to posts! <3

PS: I've also added some new features this week, including a new local area system map and system list view - and I've improved how the searching works; you can now use the arrow keys to navigate auto-suggestions, and it will attempt to auto-match what you have typed if you just press return.