AntiGameOrigin

By Francolino Last update Oct 24, 2013 — Installed 590,585 times.

Clearing the coordinates buffer

in
Subscribe to Clearing the coordinates buffer 14 posts, 2 voices



Vess Scriptwright
FirefoxWindows

When you mark some text that looks like OGame coordinates on one of the pages supported by the script (e.g., in a Galaxytool report), the icon of Antigame's button ([***]) lights up to indicate that the coordinates have been remembered and will be used as the default target for any flight you try to send.

This coordinates buffer can be cleared by clicking on that icon.

Problem: it takes TWO clicks to clear the buffer.

Originally I thought that I wasn't hitting properly the icon with the mouse but today I spent some time testing this problem and it definitely takes two clicks. Also, in the original Antigame from Tarja (1.28.8), it definitely takes only ONE click.

Unfortunately, I could not determine the source of the problem. :-( While the relevant functions have been modified significantly and totally uselessly by the Origin team, as far as I could determine, the changes were only cosmetic - multi-line statement re-formatted into a single line, renamed variable, etc. I couldn't find any change that could cause this problem. Could somebody else please look into this problem?

 
LPuNKT Scriptwright
FirefoxWindows

i saw that a few days ago .. but i didnt supose that it was an error of ogame origin (i didnt check it before) .. i disabled it because fleets with recyclers werent send to debris, only to copied coordinates ..

 
Vess Scriptwright
FirefoxWindows

LPuNKT wrote:
i disabled it because fleets with recyclers werent send to debris, only to copied coordinates ..
That's why most of the time while you're playing, the coordinates buffer must be empty. But you don't have to disable it for it not to interfere with your normal fleet movements; you just click on the icon to clear the buffer. The feature is extremely useful when used in conjunction with game databases like Galaxytool. When you get a list of suitable targets by conducting a search in GT, you just mark the coordinates there and you don't need to remember them when sending the attack - AntiGame does it for you. (And you won't send any recyclers in the attack, hopefully, so the other AntiGame feature won't interfere with this.) As soon as you're finished sending the attacks, you clear the buffer and continue playing as usual.

But, back to the subject at hand - can anybody figure out why the problem occurs? Besides some (completely unnecessary) code re-formatting, the Origin morons have also done some (completely unnecessary) shuffling of the code around. They have renamed the function that draws this button, moved it into another object, call it from another place... But I couldn't find a reason why any of those cosmetic changes would cause this problem...

 
LPuNKT Scriptwright
FirefoxWindows

whaaat??? i tryed it ... and, yes, with the first click coordinates has been erased, but icon and tooltip are the same ... u need a second click to remove image and tooltip

 
LPuNKT Scriptwright
FirefoxWindows

its a refresh error ... if u click only one time in icon and then u go to another window, when u come back to ogame window the icon is normal, without coordinates, without highlight icon and without tooltip

 
LPuNKT Scriptwright
FirefoxWindows

.click(function(){ setTimeout( function(){  Coords.reset();  Coords.initImg(null,true); }, 0); })

may the call be false to onmouseover??

initImg: function(img,mouseover)
    {
      img = img || document.getElementById('btnCoords');
      if (!img) return;
      var saved = this.saved();

      if (mouseover) {
        img.setAttribute('rel', (saved?this.img_on:this.img_off) );

        if (!saved)
          img.setAttribute('src', this.img_off );
      }
      else {
        img.setAttribute('src', (saved?this.img_on:this.img_off) );
        img.setAttribute('rel', (saved?this.img_hl:this.img_off) );
      }
      img.setAttribute('title',(saved?Lang.Interface.resetCoords+this.get():''));
      img.parentNode.style.cursor = saved ? 'pointer': 'default';
    },

 
LPuNKT Scriptwright
FirefoxWindows

not, forget it ... i tryed it and its the same .. u need again 2 clicks to disable image

 
Vess Scriptwright
FirefoxWindows

As I said, it works correctly in Tarja's original code (1.28.8). Therefore, the problem must be in some change that the Origin team did to that code. Unfortunately, I still can't figure out what is so different about the handing of this icon that could be causing this problem... And debugging event handlers is a bitch. :-(

 
LPuNKT Scriptwright
FirefoxWindows

debugging something that really isnt happening ... if u go to console and back to ogame window the problem is fixed ... so really the code do that it must do ... but something mask it .. u must know which other functions are running at the same time in that window to check their events

 
LPuNKT Scriptwright
FirefoxWindows

crap, testversion variable doesnt make showing anything in error console ... only to know which functions are executed at that moment ... why they have a test version implementing into the code if it doesnt show anything in console? i must check for what is this variable ... what is doing?

 
LPuNKT Scriptwright
FirefoxWindows

crap ... morons ... crap ... it only shows errors in console ... if u want trace the script u cant because that variable isnt used for that .. only for errors .... if there isnt any error? and u need to find something that is wrong but it isnt an error??? crap twice

 
LPuNKT Scriptwright
FirefoxWindows

replacing try { with try { GM_log(arguments.callee); i found the functions that are called before and after initImg ... some of them must mask initImg result ...

at the loading of page ...

function () {
    try {
        GM_log(arguments.callee);
        var item = Utils.$("#menuTable li").eq(1).clone(true);
        var img = item.find(".menu_icon").find("a").attr({class: "", href: "javascript:void(0)"}).unbind("click").click(function () {setTimeout(function () {Coords.reset();Coords.initImg(null, true);}, 0);}).find("img").attr({id: "btnCoords", width: "27", height: "27"}).get(0);
        Coords.initImg(img);
        item.find(".menubutton").attr("href", "javascript:void(0)").attr("id", "btnAntiOptions").attr("target", "_self").removeClass("selected").bind("click", Menu.showWindow).find(".textlabel").html(Para.scriptName + " " + Para.version + (Para.testVersion ? "T" : ""));
        item.appendTo("#menuTableTools");
    } catch (e) {
        Utils.log(e);
    }
}

and after ..

function () {
    try {
        GM_log(arguments.callee);
        var spans = Utils.getElementsByClassName("reversalTime");
        for (var i = 0; i < spans.snapshotLength; i++) {
            var node = spans.snapshotItem(i);
            var date = new Date;
            var start = node.getAttribute("title");
            if (!start) {
                continue;
            }
            start = parseInt(start, 10);
            date.setTime((date.getTime() - DateTime.TimeDelta) * 2 - start);
            node.innerHTML = DateTime.formatDate2(date);
        }
    } catch (e) {
        Utils.log(e);
    }
}

cleaning the stored coords those functions can be the problem (may be, or something farer than them xD)

function (path, context, type) {
    try {
        GM_log(arguments.callee);
        if (!context) {
            context = document;
        }
        mydoc = context.ownerDocument || document;
        if (!type) {
            type = XPathResult.ORDERED_NODE_SNAPSHOT_TYPE;
        }
        return mydoc.evaluate(path, context, null, type, null);
    } catch (e) {
        Utils.log(e);
    }
}

and after ...

function () {
    try {
        GM_log(arguments.callee);
        var spans = Utils.getElementsByClassName("reversalTime");
        for (var i = 0; i < spans.snapshotLength; i++) {
            var node = spans.snapshotItem(i);
            var date = new Date;
            var start = node.getAttribute("title");
            if (!start) {
                continue;
            }
            start = parseInt(start, 10);
            date.setTime((date.getTime() - DateTime.TimeDelta) * 2 - start);
            node.innerHTML = DateTime.formatDate2(date);
        }
    } catch (e) {
        Utils.log(e);
    }
}

for a few seconds u can see and copy the console (later is crazy search anything) ... if morons inproves debuging script we can find the problematic function (with more than one type of debuging, basic: only function calls; iteractions: calls to recursive functions; extended: to check variable values during the script life ... as much types of debugging, better to find everything)

 
LPuNKT Scriptwright
FirefoxWindows

morons, try to make a debuging unit or something like that and add it to the functions (into all script code) ... u are able to find all u want and we can test it and help better ...
let tarja's code in peace ... inprove it with debugging functions ... and later u can continue making changes (but with a unit than can help us to find problems) ... let to be idiotic and let to change things than u dont understand ... first of all understand what is happening and why

 
Vess Scriptwright
FirefoxWindows

I know that it is too late to report this - the behavior of AntiGame's icon has changed completely anyway - but I finally figured out why the icon didn't turn off immediately after clicked. (Yes, I know. I'm slow.)

You see, the Origin morons have encountered some problem when saving a value with Utils.setValue on some pages (like, saving information of whether the fleet contains recyclers on the first fleet dispatch page, in order to select the debris field as the default target on the second fleet dispatch page). And, in order to "fix" that, they have told the setValue function to execute with a 0-second delay (which doesn't cause any actual delays; just makes sure that the code runs immediately after everything else).

Of course, that has screwed up a whole bunch of other things (surprise, eh?). Like, when you click on the lighted up icon, the scripts saves the information that the coordinates buffer has been cleared and then redraws the icon. However, the icon redrawing code checks whether the buffer is cleared or not. Ooops, because of the aforementioned pseudo-delay, the information that it is cleared hasn't been reflected yet. So, the icon redrawing code again draws the icon in "lighted" state. On the second click on it (or page switch or whatever), the buffer is already cleared (the pseudo-delay has passed) and the icon is drawn correctly.

Stupid, stupid, stupid. Trivial to fix, though. I'll fix it in "my" variant of the script that I am maintaining for myself; I don't like the new behavior of the icon in version 2.* anyway.