I would like to request a function that will return a table with a list of locations (stations and wormholes) in a system. I'm requesting this because my previous method of compiling a local list of locations is no longer available to me.

I would like to see it have the following properties, if possible.
Arguments:
        systemid

Returns:
        table with sectorid as the key and the location description as the value.

{
            [575] = "Station: Geira Watch (Serco Barracks)|Wormhole: to Deneb", -- O4
            [586] = "Station: Balam Stronghold (Serco Commercial)", -- J5
            [634] = "Station: Geira Outpost (Serco Mining)", -- J8
            [748] = "Station: Geira Home Guard (Serco Barracks)|Wormhole: to Betheshee", -- L15
}

Could you describe some use cases, please? What you've historically been using it to do, etc?

My use is actually fairly new. I wrote a plugin that allows players to set quick NavRoutes to local Points-of-Interest (Wormholes, Stations, other defined sectors). Without this, all of these locations need to be hard-coded into the plugin.

Xeha also, apparently, has some use for it, which I'm not aware the details.

Incarnate said:
Given further expansion of the galaxy, exploration mechanics and so on...

With planned expansion, plugins like this would either need dynamic access to the local POIs or they would need to be hard-coded into the plugin. Access to hidden content need not be available. As plugins age and maintainers leave, something of this nature becomes even more important.

The plugin TradeAssistant (not mine) tracks goods sold at various stations. It does have the capability to set NavRoutes to individual stations, but I could see as a future feature the ability to set a route to the nearest station of a specific type.

In the screenshot below, from my plugin, you can see the list of POIs in the current system. Players can set a NavRoute to the individual locations by pressing the number on the left associated with that location.

Okay.. so all we really need here is a list of local (current-player-sector) data, which includes only those areas that are currently explored (like the fog-of-exploration in the Unknown System) or have current "awareness".

So, you don't really need to query something by system-ID, it can just be a "current-system" type call?

For my specific use-case, current-system, explored POIs would be sufficient.

I was basically shooting for the moon with my original request. :)

I was basically shooting for the moon with my original request. :)

The problem is that a cross-galaxy API taps into a lot of on-going development around what Star Systems are "known" versus "unknown" and how that will all work. Simplifying it to current-system-only certainly makes things easier, for now.

There's also some point where it becomes easier to just integrate the desired end-user functionality into the main game interface, than it is to make a really robust, powerful and flexible API that doesn't introduce other problems and concerns.

I found a way that fits my needs for now.

I found a way that fits my needs for now.

What method are you using now? It might bear on the rest of this discussion, in terms of what else is really needed.

What method are you using now? It might bear on the rest of this discussion, in terms of what else is really needed.

I've hardcoded the stations with their factions and the WHs in the plugin. For now this is sufficient, although not nicely done for future expansions.

There were 3 use cases for which i needed the full universe:

1) Navigation
Go to any station in system X (optionally of faction F)
Go to any WH in system X

2) Inventory management
You want to store X amount of cargo in system S, plugin tells you how to best store it in various stations with paying the least rent (or if its possible at all). I couldnt use the InvManager/Inventory, as empty stations wouldnt be listed or included as possible storage.

3) Manu plugin
Similiar to above with the "related stations" function

There's a GetPOI() function being released today. Documentation is forthcoming.

For the moment, it is local-system only, but down the road it could potentially be extended to allow queries to other systems.