So I have been thinking. Do you all think it would be beneficial to have someone on Discord to talk about Boundlexx? I am starting to get a decent number of people using and there is definitely some overlap in conversations?
Also note for “my” Discord server, it is not a Boundless specific server. It is just a generic Discord server where a bunch of people myself and my in real life friends hang out with and chat with. So there would be other non-Boundless related chatter and probably only a single Boundlexx channel.
Yes, official game Discord server
Yes, group message
Yes, other Discord server (will probably be “my” Discord server)
Yes, create a whole new Discord server for testing purposes
Having a “Support Server” for the API, bots dependent on it, etc … is a good choice. I wasn’t sure which option in your answers related to this (your server vs “official” Boundless server). Also a good place to track suggestions and such as well.
I added a new one specifically for a new server. I suppose there would be benefits to a separate server instead of just a group message. It could be a place I could give people admin control over parts of the server and test whatever they wanted for bots, etc.
Okay, ever one has spoken and the decision is to make a whole new server.
If you actually have interest in helping moderation or anything, please DM me. I certainly do not want sole ownership if a lot of people start using it.
There will be minor breaking changes in the next update. All of the World Block Color URLs will be changing slightly. The fields that “describe” the colors are completely being changed (currently: is_new_color, exist_on_perm, exist_via_transform, and days_since_last_exo). We are in the process of overhauling how we collect color so help track them better. This is unfortunately completely unavoidable because the way these are calculated are being completely overhauled to make it match how Sovereign world colors work (and to wonderfully simplify the whole process).
The update will hopefully be out tomorrow, but I wanted to post this ASAP in so people were aware before their apps broke.
Below are what the new values will be. Remember, all of these are calculated based on “when the world was created”. So a color that is “new” to a Exo world that appeared last year, may still be on a Sovereign world now.
"is_default", # is this the default color for the world (always True unless Sovereign)
"is_perm", # is this color on Perm worlds
"is_sovereign_only", # is this color on Sovereign worlds (and not Perm worlds)
"is_exo_only", # is this color _not_ on Perm or Sovereign worlds (Exo only)
"is_new", # is this a new color to non-Exo worlds
"is_new_exo", # is a new color for _any_ World
"is_new_transform", # is a new color to any world (including "by recipe")
"days_since_exo", # days since last Exo with this color (Exo only colors)
"days_since_transform_exo", # days since last Exo with this color "by recipe" (Exo only colors)
"first_world", # first non-Exo world that had this color
"last_exo", # last Exo to have this color
"transform_first_world", # first non-Exo world to have this color "by recipe"
"transform_last_exo", # last Exo to have this color "by recipe"
Various improvements to Discord Webhook format to match updates for the new Forum template generator
Adds average_per_chunk to all Resource Count endpoints to better understand how much of a resource really exists on a world relative to other worlds of different sizes. These will automatically be filled for all new Resource Count/World Polls going forward, but it will take some time to backfill older Resource Counts.
Major performance improvements for Polling Worlds. All worlds should be polled again at 10 minute intervals again.
Since this has not been posted yet, there are now Discords notifications (via Webhooks) for new Homeworlds, Sovereign worlds and Creative worlds in addition to Exoworlds. These are in use on at least 4 different Discord servers. DM me if you want want to set them up on yours.
WIP for uploading World Control data and new Sovereign colors Discord notifications
Since it looks like that color data is being collected at irregular intervals, and can change at irregular intervals, is it practical to get a timestamp the data was last verified? It would help apps filter out old data if a world isn’t seen for a while.
I already have that data, but I was not planning on exposing it. We already have 4 people running ProxyUI when they play to update colors more reliably. The more people that run it, the better the data will become. My next big task is probably to iterate on ProxyUI to help clean it up and make it more “user friendly” for non-technical folks.
Ah, okay. I was just thinking that with dozens to hundreds of these planets being in various states of availability, the limited number of people using the tool are likely to miss some worlds some months, but if you think it will be reliable, no worries.
Edit: In case I was ambiguous, I mean for /worlds/WORLD_ID/block-colors/ more than /items/ITEM_ID/sovereign-colors
Added msgpack serializer. You can now get any of the API responses back as a msgpack response by adding format=msgpack to the URL. While msgpack is not a human readable format (binary), it does make request sizes much smaller! JSON support is not going anywhere, just adding this as well for the new endpoint down below.
Some JS libraries for msgpack support (no particular order):
html_name is a fully resolved HTML name for colors/emojis. Comes with class attributes for easy styling!
text_name strips out Emojis and color formatting. Emojis are replaced with the Emoji name (otherwise some worlds would have empty strings for names).
Adds sorting by name to World API, add ordering=sort_name or ordering=-sort_name to the URL to sort by the sort_name for a world. sort_name is the same as text_name, but all lowercased and has a database index.
Adds is_public_edit and is_public_claim to Worlds API. This will be null (no data) in 99% of cases. You get a world to have this data, it has to be uploaded via ProxyUI.
Endpoints are defined as they are seen in the API Docs. Different variations of path parameters for a single endpoint (/api/v1/colors/1/ and /api/v1/colors/2/) are still in the same bucket for rate limiting.
I did not want to originally implement rate limiting, but making 800 requests in less then 1 minute is not cool.
He’s likely talking about me and the fact that http://portal-seekers.com/explorer.html originally made a request for each planet. It would cache these in browser storage for 4 hours but every time someone new would hit the site, it would make 1 request for every planet again. Guilty as charged.
