External jar Program Account and Amortisation by Lilith

    • External jar Program Account and Amortisation by Lilith

      Good evening,

      To be able to implement bugfixes and user suggestions/own ideas as fast as possible, I created my own tool for amortisation calculation and fancy graphs for an OGame account. The tools I really like to use for this purpose (Antigame Origin and Infocompte) lack depth in amortisation calculations and the "time to market" for improvement suggestions (be it theoretical or providing the new code) is too long for my liking. A slight problem might be that the program is currently in german (pending tasks include language selection for at least english).
      [Update: Nearly finished translation using localization. Link for english program added to end of this post. Still needing some things translated, but at least you can have a look and understand what's what for a large portion.]

      So, what does this (not yet that fancy ;) ) tool do?
      You enter your accounts buildings, defence, research, geologist into the respective table, and the program displays daily production and a list of next mines/astrotech/plasmatech in order of shortest amortisation time. To see how this looks like, take a look at the attached pictures:The program is divided into 5 tabs:
      1. Minen: Mines, resource storages, energy producers, planets maxtemperature.
      2. Anlagen (Facilities): From robotics to terraformer and the new building used to repair broken ships after an attack (in german: Raumdock)
      3. Verteidigung (Defence): All defence units
      4. Forschung (Research): All researches. Plasmatech and astrophysics levels need to be entered for a correct amortisation calculation
      5. Neuer Planet (New Planet): Here you can enter which buildings and what defense you plan to build on a new planet. The costs for these buildings will be considered when calculating the amortisation time of astrophysics. Mines are automatically considered to be equal to your current Metal/Crystal/Deuterium mine level. The costs from level 0 to current average level are also considered in astrophysics amortisation.

      Data management:
      The Program itself does only store values while it is running. To save all entries you need to click "Speichern" (Save). The program will create the file "account.txt" inside the folder where you started the jar file. When you click on "Laden" (Load) the program will search for a file with this name inside its folder and load all stored values, if it finds that file.

      What does it do that other tools (known to me to date) don't?
      The main thing for me is the flexibility of and the freedom of influence on the calculation of amortisation times. AntigameOrigin and Infocompte take the cost of astrophysics research and divide it by the production of the new planet (with the same mines as the other planets). The issue is that we still have to invest resources (and a bunch of them) into building these mines on a new planet before they really produce that amount of resources. We will also "need" (want!) a nice robotics factory, nanite, shipyard, defense to protect the daily production of our helpless new planet, etc. This has a huge effect on the cost of astrophysics up to a certain level (almost no effect for astrophysics 26 or higher unless you really put up large facilities and defense ;) ).


      So, the program is already finished, no work going into it anymore? NO! Pending tasks include:
      - english language (not complete yet and need to update column sizes)
      - research lab on new planet tab (don't know how I forgot that one..)
      - graphics (pie charts) for: Points in Mines/Research/Facilities/Energy production (for those fusionreactor/energytech users), production distribution(?) (how much % metal/crystal/deut)
      - editable exchange course (currency translation i guess). This is currently fixed to 3:2:1 Met:Crys:Deut, but easy to implement
      - extend the amortisation list by "how do I provide the newly needed energy most efficiently", or if temperature allows for solarsatellites: how much do they cost?
      - extend the amortisation list by "how long do I need until I can start the next mine?". Planned to calculate with daily production and editable amount of extra income (farming inactives/expo)

      I'm always happy about new ideas and critics as well. The program should not just be for me, so it should please other users as well. If someone is well versed in Java, I take programers advice and critics as well (e.g. "man did you implement that inefficiently! Should have taken this and that method...")

      But now, the afore mentioned screenshots of the different program parts. Seeing them now, I notice an unmentioned feature: "Invertieren" (invert colors), well not really invert..currently white text on black background instead of black on white/gray, but might be useful for the lightsensible part of the OGame community).

      Usage hints: Depending on your Java version you might have to allow creating and writing to the file "accounts.txt". Someone tested it and said you need to go to the files properties menu (rightclick).
      When entering numbers into the tables, leading zeroes are okay. Need to find out how to make entering replace the current value instead of appending, sorry. If you have negative temperatures however, a leading 0 is not okay.

      The file can currently be downloaded and tested from a dropbox link:
      dropbox.com/s/kxketubm393qs09/OgameAccount.jar?dl=0

      English version:
      dropbox.com/s/5njxm21lnu7pk83/OgameAccount_en.jar?dl=0

      If you do not trust a jar executable (which I would understand well), I can provide the program code, so you can have a look and create the jar file yourself from it.
      Update: The source code for this project is now available as zip file here:
      dropbox.com/s/4vcrsvllegoautx/OgameAccount_src.zip?dl=0
      Images
      • jOgame_afterLoad.PNG

        48.24 kB, 1,277×306, viewed 650 times
      • jOgame_Amortisation.PNG

        139.12 kB, 1,445×918, viewed 588 times
      • jOgame_AmortisationInvertiert.PNG

        143 kB, 1,421×964, viewed 596 times
      • jOgame_Anlagen.PNG

        24.02 kB, 341×321, viewed 559 times
      • jOgame_Forschung.PNG

        30.2 kB, 379×401, viewed 598 times
      • jOgame_initialState.PNG

        21.55 kB, 330×343, viewed 568 times
      • jOgame_neuerPlanet.PNG

        32.5 kB, 384×469, viewed 567 times
      • jOgame_Verteidigung.PNG

        24.35 kB, 344×318, viewed 538 times

      The post was edited 7 times, last by Lilith ().

    • @Shole What exactly could be illegal in an offline tool? I mean, I can't really imagine what can it be... it's like using Excel or using a calculator, and those can't be illegal. Just asking out of curiosity, nothing more.

      @Lilith I don't think that method is perfect for calculating the optimal way of upgrading mines (or plasma / astrophysics), there's more room for optimization. But I don't know where could we have a place where it could be discussed among the community (hopefully only people that have poured thought into the subject for years, and that knows an acceptable amount of math or are capable of calculating a bit more than usual) to advance a bit more about that “mine theory”. I'm not capable myself of calculating or deciding what to calculate correctly, but have a few ideas.

      In any case, I always thought that the method of InfoCompte does take in account buildings and such; IIRC there used to show two ways and one of them was pretty much similar to the result I obtained in my calculations, and after some time one of the two ways was removed, and thought that the one left there was the one that had in account defense and buildings. But never checked the code, just that InfoCompte was pretty similar (although not exact) to the results I got in an old Excel spreadsheet I had.
    • @Minion, you should not bother yourself about tool toleration, that is why we are here. Every tool what is for OGame, can be Excel or anything must be tolerated even if you don't like that fact. In this case it is java application, java application can also be online tool and if someone say its only offline tool not doing anything malicious, we still need to check.
    • Minion wrote:

      @Shole What exactly could be illegal in an offline tool? I mean, I can't really imagine what can it be... it's like using Excel or using a calculator, and those can't be illegal. Just asking out of curiosity, nothing more.

      @Lilith I don't think that method is perfect for calculating the optimal way of upgrading mines (or plasma / astrophysics), there's more room for optimization. But I don't know where could we have a place where it could be discussed among the community (hopefully only people that have poured thought into the subject for years, and that knows an acceptable amount of math or are capable of calculating a bit more than usual) to advance a bit more about that “mine theory”. I'm not capable myself of calculating or deciding what to calculate correctly, but have a few ideas.

      In any case, I always thought that the method of InfoCompte does take in account buildings and such; IIRC there used to show two ways and one of them was pretty much similar to the result I obtained in my calculations, and after some time one of the two ways was removed, and thought that the one left there was the one that had in account defense and buildings. But never checked the code, just that InfoCompte was pretty similar (although not exact) to the results I got in an old Excel spreadsheet I had.
      Java and Visual basic in Excel can be dangerous if they read out personal files for example. Browsercache with passphrases etc.. Not that I would do such a thing, but someone might.

      If you have further ideas for amortisation calculation, you might want to open a thread about it. If it's easily implementable, I could then add a choice for the user about how it should be calculated in the tool.

      Regarding infocompte, there is some code to include the cost of the mines of a new planet as far as I have seen (by benneb), but it is not used in the script.

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

    • Gonna clean up the code a bit this night or tomorrow. Too much production and costs code in the amortisation class..sorry if that makes it less well checkable, shole. Will cut it down to a helper class that takes an account object and can return production, daily production, and costs for building mines from {m, c, d} to {m+x, c+y, d+z}.

      Thinking about different optimizations as well to make the calculation of amortisation more readable.
    • Didn't find much time for clean up, sorry. Updated the files, to include:
      - fixed rounding issues of displayed daily production
      - added currency conversion on tab "Mines" (style: "3.0 2.0 1.0" means 1 deuterium equals 2 crystal or 3 metal)
      - a beginning of including "time until step is finished" in the amortisation list
      - created GitHub project "Account-and-Amortisation" by user "LilithOG". should be publicly viewable. is updated simultaneously with dropbox, and does not contain the jar executables
      - some clean up by means of a helper class that calculates costs and production, given mines-that-be or mines-to-be-build. planned style is to only have to call something like "helper.getcost(next mines to be build)" everytime this is needed for amortisation calculation or daily production calculation

      Hope I'll find more time soon for the toDo list
      If the Dropboxlinks time out, please inform me about it.