Search Results

I see. Actually I make it a rule to check to see if there are any ships / resources left sitting by mistake every time I FS, using the press-enter-to-go-to-fleet-I feature. Now it's gone but all I have to do is to go back to the original place manually. Not a big problem. Thx.

Follows are what happens: You launch a fleet on routine FS --> The browser proceeds from fleet III page to fleet movement view --> You hit [Enter] to go to fleet I --> The browser proceeds to fleet I page of the "next" planet/moon instead of where you were, where "next" is in the sense of "next planet / next moon" button in the right pane. As far as I have seen, this occurs only when you're in the fleet movement view after launching a routine FS mission. No "&cp=..." query string is contained in…

A small bug, just as stated in the subject. MkcHklA.png Looks like a wrong horizontal offset value is specified in the style. 3LxeZkZ.png

Just tried 5.9.5.1β and made sure it's working perfect. Thanks so much for the great work, as usual

Just made further tests and apparently it occurs when the newly joining fleet is made of probes only. Also, joining 1 probe and joining 2 or more probes cause different behaviors. * When joining 1 probe: rQWLxDe.png - Wrong mission type (attack) is selected after choosing ACS fleet to join, as shown by the wrong mission type marker - document.getElementsByName('mission')[0].value returns 1 - When proceeding to fleet dispatch III, the browser sends form data "...&mission=1&..." - After proceeding…

Sometimes it selects normal attack and sometimes espionage in fleet dispatch III page. (the latter started to occur after the new fleet dispatch I page was implemented) I'm guessing this occurs because fleet II page doesn't pass the form entry "mission=2" correctly to the next page (it passes a null value instead), unlike it does when AGO is off.

Just noticed one thing I should append: The timezone problem in fleet dispatch (ii) and (iii) mentioned above can also occur when you don't use target tab at all. The screenshot below shows slowing down of an attack by means of ACS. DKflm2z.png You can see the arrival time due (underlined portion) displayed in the user's local timezone, just the same way as the target tab case. It indicates that target tab entries and "a probe joining the ACS" both pass internally correct time to the fleet dispa…

My apologies first; I didn't notice the problem mentioned in the previous thread was marked as "done" and the thread was archived quite a while ago. I'm using AGO ver. 5.8.7 and the problem is still occurring. The point is: AGO passes the correct time to the target tab when doing this operation, but the target tab displays the time in a wrong timezone (i.e. it uses the user's local timezone unconditionally, even when the user is turning "Change all time values into local time-zone" feature off).…

Oh I see, I (or we) can wait until it's fixed then. Thanks for the reply and also thanks for your labor to move this thread to an appropriate section

Suppose you lanx a planet and have found a target fleet returning from elsewhere. yimf1wx.png When you put that mission into your "Target" panel by clicking on the mission in the sensor report, it comes with coords of where the target fleet is returning FROM (henceforth referred to as P) instead of the coords of the very planet you lanxed (i.e. where the target fleet is returning TO, henceforth referred to as Q), with automatic refresh of page to switch to the view of position P. 14jElhd.png I g…

Just tried 5.7.54.6 β and made sure it's working perfect (with the player/alliance coloring problem also resolved). Thanks a lot for the great job.

... and "increase/decrease range" buttons too. Similar buttons in 'detailed resource information' area of construction pages are working good. AGO ver. 5.7.52

i.e. the specified value of 'Maximum length of the "Current" lists' option is ignored. AGO ver. 5.7.52

AGO's built-in style pages_galaxy.css apparently doesn't apply in those cases (http://gf1.geo.gfsrv.net/cdnc4/a25f0962a239a7179c9131484e0503.css is used instead, just like when AGO is disabled) AGO ver. 5.7.50 Chrome ver. 34.0.1847.131 m

Quote from Francolino: “Do you still have this problem or not ?” Yes, it still occurs in 5.7.50. (Plus, the latest version doesn't focus on "target" panel when a mission is picked up from the event list, unlike the previous versions did.)

Quote from Francolino: “* Some timestamps are based on user's local time instead of server time, even if "Change all time values into local time-zone" feature is off (this was occurring in older versions of AGO too, not only in the latest version) Hmmm - do you want to create a detailed list where it does appear ?” When picking a fleet mission among the event list into "target" tab of the panel like this -> i.imgur.com/C3JTKuf.png it actually is added to the list like this -> i.imgur.com/7LKxuTP…

Quote from Francolino: “* Some timestamps are based on user's local time instead of server time, even if "Change all time values into local time-zone" feature is off (this was occurring in older versions of AGO too, not only in the latest version) Hmmm - do you want to create a detailed list where it does appear ?” When picking a fleet mission among the event list into "target" tab of the panel like this---> i.imgur.com/C3JTKuf.png it actually is added to the list like this--> i.imgur.com/7LKxuT…

Other problems I have encountered so far: * "Fix CR color" isn't working (as already pointed out elsewhere) * Player / Alliance coloring isn't working * Wrong background color for some planets / moons * OnMouseOver tooltip doesn't show up for planets and some moons * Grouping / ungrouping of player / alliance links in OnMouseOver tooltip doesn't work (also, "remove group" link shows up for players / alliances that don't belong to any group) * Some timestamps are based on user's local time instea…

Settings incompatibility problem again. Plus, some features (like standard targets, routine fleetsave, etc) seem to be broken.