Difference between revisions of "Talk:Realms API"

From wiki.vg
Jump to navigation Jump to search
(Created page with "When call API /worlds the "players" property is always empty")
 
(→‎New paths: new section)
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
== Tools that works with the Realms API ==
 +
 +
I wrote some simple scripts that work: https://github.com/air/minecraft-tools
 +
 +
There are amazing nodejs tools at https://github.com/zekesonxx/node-yggdrasil
 +
 +
--[[User:Air|Air]] ([[User talk:Air|talk]]) 21:40, 6 February 2017 (UTC)
 +
 +
== pc.realms.minecraft.net? ==
 +
I snooped my Minecraft process and observed it connects to <code>pc.realms.minecraft.net</code>, not <code>mcoapi.minecraft.net</code>. This also responds to Realms API requests. It resolves to a different IP. Anyone know if this is used by clients instead of <code>mcoapi</code>?
 +
 +
--[[User:Air|Air]] ([[User talk:Air|talk]]) 01:11, 7 January 2017 (UTC)
 +
 +
== Unknown edit ==
 
When call API /worlds the "players" property is always empty
 
When call API /worlds the "players" property is always empty
 +
 +
== Up to date IP ==
 +
 +
In order to get a world IP without calling the join endpoint, requests to worlds/{id} appear to have the current IP available instantly, whereas worlds/ alone does not. (Only the owner (or possibly an op?) can call worlds/{id}, however.)
 +
 +
--[[User:Ispillmydrink|Ispillmydrink]] ([[User talk:Ispillmydrink|talk]]) 21:39, 2 May 2015 (UTC)
 +
 +
== Join behavior ==
 +
 +
It appears that /worlds/$id/join calls actually prompt the service to start an instance of the server if it is not already running. This is why the first few calls to the join endpoint will return a 503 while the server is still starting. If no player actually signs on, the created server instance only stays alive for approx 10 minutes until it shuts back down.
 +
 +
--[[User:Ispillmydrink|Ispillmydrink]] ([[User talk:Ispillmydrink|talk]]) 17:41, 29 April 2015 (UTC)
 +
 +
== Some documentation here is out of date. ==
 +
 +
Some of the Realms protocol has changed as of 1.8.
 +
 +
The "handshake" process documented here no longer works, as well as various other things. I'm not exactly sure what is broken and what isn't, that'll require a bit more investigation than what I've done.
 +
 +
--[[User:Mitchfizz05|Mitchfizz05]] ([[User talk:Mitchfizz05|talk]]) 07:03, 15 April 2015 (UTC)
 +
 +
== Decompiling - Outdated Api ==
 +
 +
Has anyone actually decompiled the current (1.12.2) Realms Api? I'm using IntelliJ Idea to make a Forge mod,
 +
and was able to check the client jar, so I may update the documentation myself. (Even though anyone really could if they tried)
 +
 +
== Connect to local ==
 +
 +
You could technically connect Realms to a local server. You just have to set the "realms.environment" java property / environment variable to either "LOCAL" or "STAGE"
 +
 +
LOCAL connects the Realms Client to http://localhost:8080
 +
 +
STAGE connects the Realms Client to https://pc-stage.realms.minecraft.net
 +
 +
(Tested with realms 1.13.3)
 +
 +
== New paths ==
 +
 +
This should contains every paths which are present in realms-1.13.3.jar realms client : https://pastebin.com/R0Br85aE

Latest revision as of 15:55, 27 July 2018

Tools that works with the Realms API

I wrote some simple scripts that work: https://github.com/air/minecraft-tools

There are amazing nodejs tools at https://github.com/zekesonxx/node-yggdrasil

--Air (talk) 21:40, 6 February 2017 (UTC)

pc.realms.minecraft.net?

I snooped my Minecraft process and observed it connects to pc.realms.minecraft.net, not mcoapi.minecraft.net. This also responds to Realms API requests. It resolves to a different IP. Anyone know if this is used by clients instead of mcoapi?

--Air (talk) 01:11, 7 January 2017 (UTC)

Unknown edit

When call API /worlds the "players" property is always empty

Up to date IP

In order to get a world IP without calling the join endpoint, requests to worlds/{id} appear to have the current IP available instantly, whereas worlds/ alone does not. (Only the owner (or possibly an op?) can call worlds/{id}, however.)

--Ispillmydrink (talk) 21:39, 2 May 2015 (UTC)

Join behavior

It appears that /worlds/$id/join calls actually prompt the service to start an instance of the server if it is not already running. This is why the first few calls to the join endpoint will return a 503 while the server is still starting. If no player actually signs on, the created server instance only stays alive for approx 10 minutes until it shuts back down.

--Ispillmydrink (talk) 17:41, 29 April 2015 (UTC)

Some documentation here is out of date.

Some of the Realms protocol has changed as of 1.8.

The "handshake" process documented here no longer works, as well as various other things. I'm not exactly sure what is broken and what isn't, that'll require a bit more investigation than what I've done.

--Mitchfizz05 (talk) 07:03, 15 April 2015 (UTC)

Decompiling - Outdated Api

Has anyone actually decompiled the current (1.12.2) Realms Api? I'm using IntelliJ Idea to make a Forge mod, and was able to check the client jar, so I may update the documentation myself. (Even though anyone really could if they tried)

Connect to local

You could technically connect Realms to a local server. You just have to set the "realms.environment" java property / environment variable to either "LOCAL" or "STAGE"

LOCAL connects the Realms Client to http://localhost:8080

STAGE connects the Realms Client to https://pc-stage.realms.minecraft.net

(Tested with realms 1.13.3)

New paths

This should contains every paths which are present in realms-1.13.3.jar realms client : https://pastebin.com/R0Br85aE