Nixian Raid Tracker

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

    • Nixian Raid Tracker

      My raid tracker I would like to get approved as legal to use:

      Info: Parses combat reports and harvest reports to keep track of your raids
      Author: Nixian
      Website: openuserjs.org/scripts/Nixian/Nixian_Raid_Tracker
      Support : Here and the .org boards as well as discord @Nixian#4074
      Download : openuserjs.org/install/Nixian/Nixian_Raid_Tracker.user.js
      Screenshot : See spoiler below.
      Browser : Chrome (potentially also firefox, but not tested)
      Compatibility : No incompatibility detected.
      Languages : EN, but also tested in FR uni
      Display Spoiler


      Everything is run locally - so no data is sent anywhere!

      Provides overview under planet list:

      Provides a table showing all raids / harvests

      Allows for parsing of CR and harvest reports via the messages area:



      Changelog:
      1.0.0.1:
      - Fixed loss calculations for deuterium
      - Minor performance improvement

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

    • chrome/firefox always had issues with memory handling
      i've run it myself for quite some time now while developing, and have yet to run into any problems though
      the ajax request is a required evil to make this work without external servers - as I can't process the API key directly (other scripts have gone to the tolerated list with this method though, so it should be fine)

      Why gameforge keeps the other API data available to the public but CR/harvest API key processing is behind a gate is beyond me

      You can do much more harmful things with the public API than you can with CR processing
    • Nixian wrote:

      the ajax request is a required evil to make this work without external servers - as I can't process the API key directly (other scripts have gone to the tolerated list with this method though, so it should be fine)
      I did not know that other script tolerated uses it, because OGSTeam (directed by @darknoon) consider that it's automate a task and this is prohibed X/

      If your script is authorized it's a very good news
    • Yes we got a POC to retrieved the data from an Ajax request, but as it marks the message as read. It could be a kind of automation.

      And as we have many tools, we don't want to take any blacklisting risks :)

      I will follow the approval of the script because this will allow us to do the same ;)

      OGSteam is a team that develops and tests Legal Tools for OGame.
      forum.ogsteam.fr
      Please help us to translate OGSteam Tools : transifex.com/ogsteam
    • Hi,

      we are currently reviewing this tool and will internally discuss its functionality in the coming days. Executing an AJAX-request to retrieve additional data seems a bit like something we should want to avoid when possible, also not to open Pandora's box.

      Maybe a solution would be to get the GF to implement additional data-attributes on the message-overview page, so that you have all relevant data already available there and don't need to execute an additional request. But I am not sure whether we could convince GF to do so, or in which timeframe that could happen. Stay tuned ;)
    • I agree @DeLord - that would be a much better solution, unfortunately there are no way to parse CR API keys or harvest API keys without an external server which I want to avoid to make sure the script doesn't break if I leave Ogame for a period of time or my server gets affected by DDoS etc - it is also a privacy concern to allow players to keep their API keys private and internal on their own device without my server acting as a proxy

      I still do not understand the reasoning for blocking CR parsing behind a register wall, while the server API data is publicly available, perhaps that would be another solution (making both APIs public)

      For the review I just want to point out that other approved scripts have been using the same method - so that this is not used as a reason for not accepting it
      board.origin.ogame.gameforge.c…kAttack-Anti-Bash-Script/
    • I think that a script that count how many attack you do is different that read any cr.

      When you talk about API public, about what are you talking ? API of cr or key to read API cr ? Because it is obvious that API cr cannot be public (if i don't want to share with other my cr, i have to be able to don't share).
      About key, probably it is to limited the access at ogame server ........... if key was public, maybe there was more tool, more request, etc, etc.

      PS: I hate the day GF created API data server ........... too many info to monitor the players, without any effort

    • New

      @TGWo not sure what you mean? checkattack also tracks raid profits so it doesn't just track number of attacks

      When talking about API I mean that you can send your CR API ID to gameforge and it returns you a data set - I do not mean a list of all CRs so your CRs would still be private and hidden

      Of course there is an antispam considerations with an open API - but why is that not a concern for the highscore API then?
    • New

      Hey @Nixian,

      it looks like your script calls your parseCR() method (which does the AJAX-stuff) for every CR on the current page, when the "Check messages" gets clicked. Inside of the parseCR() method at the end, you save every CR with its API-id into the localprofitDB.

      It seems kind of unneeded to call the parseCR() method for every CR on the page, because in normal cirumstances most of the CRs are already existant in the localprofitDB.

      Can you maybe add additional logic to your script, to only call the parseCR() method for those CRs, that are not known yet?

      Thanks!
    • New

      The idea was to make sure correct data was in the database in case something got messed up (my faith in ogame messages being consistent is a bit low - sorry)

      I have tried looking at parsing the CR api key from the messages itself to having the ajax request happen only when the CR is not already logged - but even without any addons they get messed up by how ogame is programmed.

      As soon as you hover over the API icon - the CR ID is removed from it's usual location, making it extremely difficult to check the messages for the CR ID consistently

      This is not made better by the fact that other addons can randomly trigger this behaviour making it even more unclear where to find the CR api key because you would need 3-4 checks to try and find out where the CR ID is located.

      If gameforge can commit to having the CR ID easily available in a parameter - I could implement this feature in 3 seconds

      Until then I will try to find a workaround to this mess - but it won't be pretty

      Edit to tag @DeLord

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

    • New

      Nixian wrote:

      This is not made better by the fact that other addons can randomly trigger this behaviour making it even more unclear where to find the CR api key because you would need 3-4 checks to try and find out where the CR ID is located.
      why don't search directly string, instead to search where is icon and then read info in icon ?

      Script know number of server and language, so you know that any api cr start with a particular string "cr-it-153-........"