Closed CosminPerRam closed 2 months ago
I have also emailed them regarding this matter.
The /server/search endpoint currently restricts additional query parameters directly at the route level, focusing solely on the name field. However, once the response is received, further filtering is possible using additional query params on the response instead of the route.
i have an example in my go code on how this done; https://github.com/xstar97/palworld-query-api/blob/main/internal/routes/api.go
Maybe they would be so kind to add IP filtering too.
It's also possible to get server information from the API via the world GUID, which is found in a file after the server runs for the first time. Not really ideal either but at least it doesn't require searching by name.
(This is WIP, not done)
Closes #555.
In 0.1.5, Palworld has seemingly stopped using EOS for the servers list, instead option for an in-house solution, api endpoint here.
As of writing this message, we don't have any documentation regarding this endpoint, although we know that:
/server/search?q=MyServer
) but it doesn't also look in the address/port fields.Our initial solution could be: As the user provides the ip and port, we can query for the first page of the list, look through it and return the data if present there, if not, just repeat until there is not pages left.
This is very bad to do as its an O(n) solution, where every operation is a HTTP request and takes a considerable amount of time and it comes down to luck whether your server is at the top or bottom of the list.
A potential thing that could help here is to also pass a
name
field that would be passed to the search endpoint, further narrowing down the list.Would be glad to hear opinions on this or possible improvements/news.