wonderful

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Hello

      I've just seen your announcement concerning Ogame API.
      Making left a developer of the OGSteam (developing mainly OGSpy), it's true that the appearance of "planet_id " and " moon_id" is an additional help for us.

      However, because of the low frequency of the updates of the API, it doesn't seem sufficient for a very active player.
      Where from my question:

      In a future, GameForge envisages you she to make these identifiers ingame, quite apparaitre as are it at present "player_id " and " ally_id" in the source code?
      Below, a detail of the problem met during the development of tools :

      At present, for tools, when we establish a link between a player and its planets, we can make better only " player_id <-> coordinates ".
      Concerns since the movings, the coordinates of a planet are not fixed any more in the time. And as soon as a planet moves, the links are broken.

      It's difficult to pick up the pieces: even if we find the new coordinates of planets, we cannot know with certainty if it is good it (especially if the player moves several planets just like that, changes name at the same time, etc.).
      Too much uncertainty for something that we wish reliable.

      You will say to me that the API is an answer to this problem; certainly, but not completely, because of its frequency of update, it is difficult to maintain something in real time.
      ( I suppose that these weak frequencies are not only made to relieve the server, but also to avoid that it becomes too easy, because we could then detect any movement without making anything )

      However, for a player who takes time to go through the solar systems one by one, he deserves well to be able to connaitre the movements of planets, etc. (it is at present the case but as of explained it higher, with some relational concerns)

      It is for it that with the id visible ingame, the problem would be really solved.
      It would change nothing the gameplay (an average player laughs at connaitre the identifiers of planets), he would only be the work facilitating in the developers of tools diverse and varied for Ogame

      Nb: by " ingame ", I listen in can loan everywhere where it is useful: in the view galaxy, at the level of every planet and the moon, but also in the reports of espionages (if we spy on the moon, id of the moon, ie for the planet) + the identifier of the player which is aimed by this espionage, or which is the source, but also in the messages of transport of fleet, expeditions, and in the reports of fights (at present, in a report of fight, even player_id is not visible)


      I am only transmitting :)
    • the update frequency is already too high. 2 times a week you get the coordinates of a player in real time!

      btw the update time is in the xml as well... show your users that and if they think its too old they can search for themselves if they wish so.
    • they are updated every 7 days at most
      if nobody request them they will never be updated
      when you send a request the api checks the last update time and updates data before sending the response if it's more than 7 days ago
    • Black Cat wrote:

      they are updated every 7 days at most
      if nobody request them they will never be updated
      when you send a request the api checks the last update time and updates data before sending the response if it's more than 7 days ago


      Exactly correct.



      Hello

      I've just seen your announcement concerning Ogame API.
      Making left a developer of the OGSteam (developing mainly OGSpy), it's true that the appearance of "planet_id " and " moon_id" is an additional help for us.


      However, because of the low frequency of the updates of the API, it doesn't seem sufficient for a very active player.


      Where from my question:

      In a future, GameForge envisages you she to make these identifiers ingame, quite apparaitre as are it at present "player_id " and " ally_id" in the source code?
      Below, a detail of the problem met during the development of tools :

      At present, for tools, when we establish a link between a player and its planets, we can make better only " player_id <-> coordinates ".
      Concerns since the movings, the coordinates of a planet are not fixed any more in the time. And as soon as a planet moves, the links are broken.

      It's difficult to pick up the pieces: even if we find the new coordinates of planets, we cannot know with certainty if it is good it (especially if the player moves several planets just like that, changes name at the same time, etc.).
      Too much uncertainty for something that we wish reliable.

      You will say to me that the API is an answer to this problem; certainly, but not completely, because of its frequency of update, it is difficult to maintain something in real time.
      ( I suppose that these weak frequencies are not only made to relieve the server, but also to avoid that it becomes too easy, because we could then detect any movement without making anything )

      However, for a player who takes time to go through the solar systems one by one, he deserves well to be able to connaitre the movements of planets, etc. (it is at present the case but as of explained it higher, with some relational concerns)

      It is for it that with the id visible ingame, the problem would be really solved.
      It would change nothing the gameplay (an average player laughs at connaitre the identifiers of planets), he would only be the work facilitating in the developers of tools diverse and varied for Ogame

      Nb: by " ingame ", I listen in can loan everywhere where it is useful: in the view galaxy, at the level of every planet and the moon, but also in the reports of espionages (if we spy on the moon, id of the moon, ie for the planet) + the identifier of the player which is aimed by this espionage, or which is the source, but also in the messages of transport of fleet, expeditions, and in the reports of fights (at present, in a report of fight, even player_id is not visible)



      Where should it appear ? I think to mean adding them in the galaxy view. We'll request it.
      The API should NOT replace the user projects like war riders or galaxytool - Someone who wanna have newest details have still to work for them.
    • The API should NOT replace the user projects like war riders or galaxytool - Someone who wanna have newest details have still to work for them.


      I fully agree. THE API would not change.
      But the information which appear in the API (the identifiers of the various "objects" composing Ogame: player, planet, moon) could as well apparaitre also in Ogame he even

      Somebody who uses the API can establish relational plans correct to identifiers.
      While somebody wishing details at time - reality thus takes time to update by crossing the view galaxy, or by sounding, etc.) finds himself in the incapacity to be able to make these relations in a correct way (for the storage in database).

      Where should it appear ? I think to mean adding them in the galaxy view. We'll request it.

      Yes, that the various identifiers also appear in Ogame, in real time, but not only in the view galaxy: in messages, reports of fights, in the view of the events, etc....

      Example
      Tools of storage of the reports of espionage.

      A report of espionage of 1:1:1.
      1 week later, the colony moved there 2:2:2 = > all the reports corresponding to the planet 1:1:1 are lost

      Even if we find the new position, we cannot be sure that it is about the same planet.
      Because if the player moves 2 planets at the same time (for example, another colony 3:3:3 which goes 4:4:4 there), how know, simply by crossing the solar systems, if (1:1:1 - > 2:2:2 and 3:3:3 - > 4:4:4) Or (1:1:1 - > 3:3:3 and 2:2:2 - > 4:4:4)?
      50 % of luck to make a mistake

      If we had access to the identifiers of the target planet of the report of espionage, it would be simpler, and surer.
      In broad outline, in database, that would be translated by:

      A table for planets: [planet_id, galaxy, system, row, name, player_id]
      A table for the reports of espionages: [planet_id, date, levels of appearances(mines), etc.] (planet_id in foreign key towards the table of planets)

      So, even if the planet moves and what the player changes name, it is possible to know that our report of espionage concerns the same colony, that it moved, and that furthermore, the player in changed name! 3 in 1

      At present, with the absence of identifiers, it is impossible, because the only possible key is the triplet [galaxy, system, row], which is only but not unchanging.
      Similar for the name of a player on a report of espionage (or of fight): the name is not unchanging, any relation based on that could be broken.
      While identifiers, them, are unchanging.

      And it is the same problem with the reports of fights, the sudden espionages, etc. etc....

      I hope that my example will have allowed to clear up.

      Nothing changes for the API or the player; only a help for the developers of tools to have correct relational plans, for tools time - reality.
    • First of all, great job on publishing and releasing APIs.

      I have a little comment tho. I think it would be better to include timestamps of each element in global xmls (like players.xml and universe.xml).

      For example:

      Source Code

      1. <players xsi:schemaLocation="http://uni670.ogame.org/api/xsd/players.xsd" timestamp="1344431225" serverId="en670">
      2. <player id="1" name="Legor" status="a" timestamp="1344431225"/>


      This way, people won't have to loop around in each entry of playersData, in order to synchronize them with a local database.
      It would directly show that "hey yeah this id has been updated" or "this one is still same, don't bother searching playersData". :P
      I mean, i believe this is better either for reducing server's bandwidth to minimum, or an application's synchronization delay.

      (ps: my english are terrible, pardon me for any typos or misunderstandings)
    • Bahamut wrote:

      First of all, great job on publishing and releasing APIs.

      I have a little comment tho. I think it would be better to include timestamps of each element in global xmls (like players.xml and universe.xml).

      For example:

      Source Code

      1. <players xsi:schemaLocation="http://uni670.ogame.org/api/xsd/players.xsd" timestamp="1344431225" serverId="en670">
      2. <player id="1" name="Legor" status="a" timestamp="1344431225"/>


      This way, people won't have to loop around in each entry of playersData, in order to synchronize them with a local database.
      It would directly show that "hey yeah this id has been updated" or "this one is still same, don't bother searching playersData". :P
      I mean, i believe this is better either for reducing server's bandwidth to minimum, or an application's synchronization delay.

      (ps: my english are terrible, pardon me for any typos or misunderstandings)


      Thanks, i'll forward it to the responsible people :)

      The timestamp is also in the header, it's pretty simple to it in all programming languages. I'll use only those one.


      Source Code

      1. var request = new XMLHttpRequest();
      2. request.open('HEAD', url, true);
      3. request.onload = function() {
      4. var time = request.getResponseHeader('Last-Modified');
      5. if (time && request.status == 200) { }
      6. };
      7. request.send(null);
    • Good evening.

      I'm currently working on a site that uses the new Ogame API (bandwidth friendly, it loads the XML data only if needed/required).

      I was wondering if you are planning to use the JSON format besides XML, since JSON data is smaller and easier to read/generate.
      You would save a lot of traffic in comparison to XML.

      Best regards.
    • New API with Ogame 5.2.2

      Translation API for all details with a techid

      uni670.ogame.org/api/techNames.xml (coming tomorrow )


      <tech id="1">Metallmine</tech>
      <tech id="2">Kristallmine</tech>
      <tech id="3">Deuterium-Synthetisierer</tech>
      <tech id="4">Solarkraftwerk</tech>
      <tech id="12">Fusionskraftwerk</tech>
      <tech id="14">Roboterfabrik</tech>

      The post was edited 1 time, last by marshen: fixed link ().

    • Good evening. Nice to see new features of the Ogame API.

      Well, I have a suggestion: A new document, similar to playerData.xml:

      http://[unidomain]/api/allianceData.xml?id=

      Both would be useful when the players.xml and alliances.xml documents have already been cached by the server, and there's no info available for a new player/alliance.

      Best regards.
    • NeoArc wrote:

      Good evening. Nice to see new features of the Ogame API.

      Well, I have a suggestion: A new document, similar to playerData.xml:

      http://[unidomain]/api/allianceData.xml?id=

      Both would be useful when the players.xml and alliances.xml documents have already been cached by the server, and there's no info available for a new player/alliance.

      Best regards.

      What would allianceData contain ?

      Because i don't see a problem.
      alliances.xml containts the player id's, i think that's enough.
      also the alliances.xml file is not a big compared to players.xml and universe.xml.
    • allianceData.xml would contain the info of one alliance, referenced by their id (if the visitor doesn't provide an id, there will be an error message). Also, some information about the alliance position (ranking).
      This behaviour is similar to playerData.xml

      Why this should be implemented? Well, I can think of 2 reasons:

      - In a big universe you don't need the info of another 900 alliances, just the one that interest you. Good speed/good internet bandwidth usage/less programming and skipping/less monitor scrolling.
      - Let's say the alliance.xml file was generated this morning, and will be cached until tomorrow. Then, a new alliance is created by popular players. If somebody wants to get the info of this alliance will have to wait another day, since it is not available in the current list of alliances from the API

      The post was edited 1 time, last by NeoArc ().