Station search implementation

kenneaal commented 8 years ago

I'd like to suggest a few additions to pipsqueak to enable rats to search for a few vital points of information.

!scoopable [Jump range]

Returns the closest class KGBFOAM star to specified system, alternatively with a specified jump range.

Example output:

!scoopable COL 123 AB-C 1-33 Mechasqueak: Nearest fuel source is COL 123 AB-C 2-4 (11.6 LY, class M) !scoopable COL 123 AB-C 1-33 5.35 Mechasqueak: Nearest fuel source is COL 123 AB-C 2-4 (11.6 LY, Class M, 3 jumps)

!refuel [pad size] [jump range]

Returns the closest station with refuel capabilities and optionally specified minimum pad size.

Example output:

!refuel COL 123 AB-C 1-33 Mechasqueak: Nearest station is Happy Terminal, COL 123 AB-C 2-4 (11.6 LY, Size M pad) !refuel COL 123 AB-C 1-33 Large Mechasqueak: Nearest station is Bigpad Orbiter, COL 123 AB-C 2-4 (11.6 LY, Size L pad)

!rearm [pad size] [jump range]

Returns the closest station with rearm capabilities and optionally specified minimum pad size.

Example output:

!refuel COL 123 AB-C 1-33 Mechasqueak: Nearest station is Happy Terminal, COL 123 AB-C 2-4 (11.6 LY, Size M pad) !refuel COL 123 AB-C 1-33 Large Mechasqueak: Nearest station is Bigpad Orbiter, COL 123 AB-C 2-4 (11.6 LY, Size L pad)

Alot has already most of the groundwork that would be needed for this in his pathfinding Python, so this should be fairly easy to implement.

trezy commented 8 years ago

/cc @duk3luk3 && @tyrope

tyrope commented 8 years ago

Does EDSM have this capability? if so, we could add this to rat-search

trezy commented 8 years ago

For reference, here's @kenneaal's (Alot's) project.

tyrope commented 8 years ago

Since EDDB only has a .json download documentation. Here's an example of both the JSONs (using the first set of {})

systems.json:

[
    {
        "id":1,
        "name":"1 G. Caeli",
        "x":80.90625,
        "y":-83.53125,
        "z":-30.8125,
        "faction":"1 G. Caeli Empire League",
        "population":6544826,
        "government":"Patronage",
        "allegiance":"Empire",
        "state":"None",
        "security":"Medium",
        "primary_economy":"Industrial",
        "power":null,
        "power_state":null,
        "needs_permit":0,
        "updated_at":1444493764,
        "simbad_ref":""
    }
]

stations.json:

[
    {
        "id":1,
        "name":"Bain Colony",
        "system_id":18370,
        "max_landing_pad_size":"L",
        "distance_to_star":16253,
        "faction":"V492 Lyrae Co",
        "government":"Corporate",
        "allegiance":"Federation",
        "state":null,
        "type":"Unknown Starport",
        "has_blackmarket":0,
        "has_market":1,
        "has_refuel":1,
        "has_repair":1,
        "has_rearm":1,
        "has_outfitting":1,
        "has_shipyard":1,
        "has_commodities":1,
        "import_commodities":[],
        "export_commodities":[],
        "prohibited_commodities":[],
        "economies":[
            "Tourism"
        ],
        "updated_at":1444494520,
        "shipyard_updated_at":null,
        "outfitting_updated_at":null,
        "selling_ships":[],
        "selling_modules":[
            738,
            739,
            740,
            741,
            742,
            778,
            779,
            780,
            781,
            782,
            871,
            1085,
            1191,
            1207,
            1239,
            1242,
            1286,
            1306
        ]
    }
]

this information is technically enough for both !refuel and !rearm, but not !scoopable.

@kenneaal Do you have an API that has star class information? (Bonus points for being better documented and/or lower filesize.)

duk3luk3 commented 8 years ago

If someone can find a usable data source, we should implement this feature.

trezy commented 8 years ago

So I had a discussion with @themroc5 in IRC about making a REST API available. He made a pretty solid argument about system data since he's not actually the source of truth, he gets it from EDSM. He is, however, the source of truth for station data so we may be able to work together to create a better solution. As for star class data, I haven't been able to find any sources for that data. @Inhumierer, could we add support for it in EDSM? We'd need to talk to other tool creators about figuring out if we could capture that data as well.

Inhumierer commented 8 years ago

Sorry for late answer, didn't see the message...

Of course we can add some database structure for storing the star class

I assume the most important intel is "Scoopable - yes or no". My opinion: The better place to have this information is EDDB, since it stores way more detailed intel about the systems. Detailed star class intel won't fit properly into our database structure. A single bool to show "KGBFOAM confirmed", "no" or "unsure" would fit.

Since AnthorNet is doing most of the work regarding the API, the web FE & the database, I'd leave the decision up to him.

Two things to keep in mind: There are many systems with more than one star, and they may have different classes, so we need to store multiple star types per system, maybe including their names. Or we only store a boolean which tells if there is any scoopable star or not.

And where do we get the information? I don't have a client at hand to check, but I don't think this intel is spit out in the netlog files. So some brave CMDRs have to enter this by hand.

BTW: Nice to see Themroc alive... ;-)

Fly safe, Inhumierer

Am 17.12.2015 16:30, schrieb Trezy:

So I had a discussion with @themroc5 https://github.com/themroc5 in IRC about making a REST API available. He made a pretty solid argument about system data since he's not actually the source of truth, he gets it from EDSM . He is, however, the source of truth for station data so we may be able to work together to create a better solution. As for star class data, I haven't been able to find any sources for that data. @Inhumierer https://github.com/Inhumierer, could we add support for it in EDSM? We'd need to talk to other tool creators about figuring out if we could capture that data as well.

— Reply to this email directly or view it on GitHub https://github.com/FuelRats/pipsqueak/issues/2#issuecomment-165484454.

Marenthyu commented 8 years ago

This is implemented in RatTracker - might want @kenneaal to give me the algorithm he uses and i can implement it into the bot as well. Additionally, if the Rat polls for it in RatTracker, give him the ability to post it into IRC through the API and bot.

T-om-X commented 8 years ago

@Inhumierer from a rat point of view the most important info would be whether the main star in the system (jump in point) was scoopable. It would be useful to know if there were other stars in the system that could be scooped but the information would be for 2 different scenarios. 1, At the start of a rescue - Usually on a LRR or difficult rescue where the client has some fuel - can they jump and refuel and save the rat a trip/hard work - really needs to be a primary. 2, At the end of a rescue - Refueled client at the end of a rescue who just needs directing to a star (but should have a reasonable amount of fuel or a rat that can give more close by.

So a return of scoopable primary or scoopable secondary, scoopable primary would be ideal.

Marenthyu commented 8 years ago

@T-om-X i do not think that this is possible as no current database that is up-to-date enough has the information about the star class. If a large enough database has the ability to search for these parameters we might think of adding it.

themroc5 commented 8 years ago

In case anybody missed this: EDDB now has body data and the nightly JSON dumps contain exactly that information: group_id/group_name, spectral_class and is_main_star derives the scoopable state. Of course, we don't have this for all the systems present at EDSM but it's a start :)

T-om-X commented 8 years ago

@themroc5 yep that's what I was thinking about:-)

Marenthyu commented 8 years ago

I wouldn't want to do it if it is not available for a good amount of stars, but we'll take a look at it maybe. Please be aware that this is not a high priority though.

tacocatcodes commented 8 years ago

Is this something to talk to the EDDN devs about storing, information-wise? If it's possible to convince them, it'd open up more information for everyone who relies on it and provide for a single source of truth. It might be a worthwhile venture to try and convince them. ...just my unsolicited 2 cents though.

themroc5 commented 8 years ago

EDDN is no storage system, it is a relay where apps can send and receive information in an N:N relation. Storage wise I guess that EDSM is the source of truth for system existance data and EDDB for every other data.

tacocatcodes commented 8 years ago

Consider me corrected. It still might be useful to get the EDDN folk to try and parse star data though.

themroc5 commented 8 years ago

We are just in the process of preparing a new EDDN schema for the Journal that FD announced for 2.2. Body data will be a part of that. So soon, that kind of data will pass EDDN and EDDB will publish this data in the nightly JSON.

Edit: To clarify one more thing: EDDN can't "parse". There always must be an application that does the part of data gathering. Like EDMC collects data from the Companion App API and sends it to the EDDN network. You can find a log here: https://ross.eddb.io/eddn/log

FuelRats / pipsqueak