Re: [Freeciv-Dev] (PR#39859) Sliders in governor menu do not work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 Daniel Markstedt wrote: You're right - this is a regression between 2.1.0-rc1 and 2.1.0. Is this release 2.1.0? Or current source? What client? I looked at all the S2_1 commits between Oct 17 and Oct 27, and all I see are gui-sdl changes ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 - It ignores if unit hasn't its full moves left. For example, if your unit already did some move this turn, it check as your unit didn't make this moves. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39859) Sliders in governor menu do not work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 On 11/13/07, William Allen Simpson [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 Daniel Markstedt wrote: You're right - this is a regression between 2.1.0-rc1 and 2.1.0. Is this release 2.1.0? Or current source? What client? I looked at all the S2_1 commits between Oct 17 and Oct 27, and all I see are gui-sdl changes gui-sdl indeed - it's obvious from this ticket's queue. And the regression is between the two releases, not dev code. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 I'm using MacOS 10.3.9, standard iso Amplio (shouldn't make a difference), and standard GTK2 (shouldn't make a difference). We are talking about a fighter to the S of the continent, in the middle of the ocean. It has moves (7)7. Daniel Markstedt wrote: - Can issue goto to any unsafe tile within its current moves. The unit dies on EOT. Let's concentrate on this. This may be a difference of desired results. As I have deliberately re-written the code, it displays the unreachability of any tile more than it has enough fuel -- more than 7 away. * On the 7th tile, the cursor turn number changes from 0 to 1. This seems a little odd to me, but I didn't change it, as I presumed this was chosen for/by the gui designer. (I don't like it, slightly confusing.) * On the 8th tile, it displays a forbidden symbol. (This is part of the bug fix -- it used to display forbidden on the 7th tile.) It will not allow this distance to be selected. It will reach anywhere it has enough fuel, even places it will die. It has to work this way, or you would be unable to set waypoints on its way home. Waypoints was one of the bugs fixed. I'm presuming that the user is not so stupid that they dump the unit in the ocean. However, I didn't want the *code* to keep *me* from doing it But now, I'm thinking about what happens to an AI using this code. It probably *would* just dump it in the ocean. So, I could change the code to prevent it for AI (or allow it for users). The pseudonymous puppeteer also suggested (in his inimitable way) that the code also disallow being able to return to the current dangerous position. Not a goal for a human (it's obviously wrong), but maybe useful for an AI? - Can issue goto to city two turns away, e.g. PY. The unit does not refuel in city and dies on EOT. When I tested before, it automatically went into P5. Perhaps that was an accident of the path. Testing to PY, you are correct. It inexplicably runs out over the S ice continent. The code path chooser is flaky. This requires thought. I only fixed a particular callback, not the entire path chooser! That would be a different PR! - Can not issue goto to city more than two turns away, e.g. P1. If you set a waypoint in P5, you can go on to P1. That's one of the things that waypoints are for Perhaps the goto.c struct part code should keep a tally on a per waypoint basis about refueling. That would allow truly long term planning. But why? I certainly don't make moves for more than 2 turns, and I doubt the AI could cope!?!? And is this a 2.1 project goal? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39861) scrollbar on side and top doesnt work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39861 On 11/13/07, William Allen Simpson [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39861 Daniel Markstedt wrote: We get this question a lot so I suggest making a FAQ entry for it. If we get the question a lot, we should make the default *ON*. Those users that don't want them can turn them off Agreed. While we're on this topic - another few things that ought to have different defaults: - GTK fullscreen: OFF (to make PR#12119 less aggrevating) - Server setting 'aitoggle' OFF (workaround for PR#22082) And the default theme has them barely visible gray on light gray. Not easy on the eyes. Usability issue. Deserves a separate ticket. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Pepeto _ wrote: - It ignores if unit hasn't its full moves left. For example, if your unit already did some move this turn, it check as your unit didn't make this moves. Amazingly, you are actually correct. I tried moving the fighter one move, the display correctly shows (6)6 -- but the code passes in the value 7 to the callback function! Yet another annoying bug in the badly written pathfinding code. My guess is the entire thing needs to be reviewed -- some logic error elsewhere the fuel isn't being properly decremented. (All I can easily find are the places it's _correctly_ decremented.) But since the visual display is correct, this should not delay 2.1.1. I don't think we should be doing any more than fixing crashers. Code improvements are for *.minor.* releases, not *.*.trivial releases. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39861) scrollbar on side and top doesnt work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39861 Daniel Markstedt wrote: - GTK fullscreen: OFF (to make PR#12119 less aggrevating) It seems to be off here, I always have to click the green plus for fullscreen. You don't? - Server setting 'aitoggle' OFF (workaround for PR#22082) Sure. And the default theme has them barely visible gray on light gray. Not easy on the eyes. Usability issue. Deserves a separate ticket. OK. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [wsimpson - Mar. Nov. 13 10:51:44 2007]: Pepeto _ wrote: - It ignores if unit hasn't its full moves left. For example, if your unit already did some move this turn, it check as your unit didn't make this moves. Amazingly, you are actually correct. I tried moving the fighter one move, the display correctly shows (6)6 -- but the code passes in the value 7 to the callback function! Yet another annoying bug in the badly written pathfinding code. My guess is the entire thing needs to be reviewed -- some logic error elsewhere the fuel isn't being properly decremented. (All I can easily find are the places it's _correctly_ decremented.) But since the visual display is correct, this should not delay 2.1.1. I don't think we should be doing any more than fixing crashers. Code improvements are for *.minor.* releases, not *.*.trivial releases. For this bug, there is a very simple trick to change: - int fuel = param-move_rate * param-fuel_left_initially; + int fuel = param-moves_left_initially + param-move_rate * (param-fuel_left_initially - 1) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 On 11/13/07, William Allen Simpson [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 I'm using MacOS 10.3.9, standard iso Amplio (shouldn't make a difference), and standard GTK2 (shouldn't make a difference). I have the same setup, incidentally. We are talking about a fighter to the S of the continent, in the middle of the ocean. It has moves (7)7. Daniel Markstedt wrote: - Can issue goto to any unsafe tile within its current moves. The unit dies on EOT. Let's concentrate on this. This may be a difference of desired results. As I have deliberately re-written the code, it displays the unreachability of any tile more than it has enough fuel -- more than 7 away. * On the 7th tile, the cursor turn number changes from 0 to 1. This seems a little odd to me, but I didn't change it, as I presumed this was chosen for/by the gui designer. (I don't like it, slightly confusing.) * On the 8th tile, it displays a forbidden symbol. (This is part of the bug fix -- it used to display forbidden on the 7th tile.) It will not allow this distance to be selected. It will reach anywhere it has enough fuel, even places it will die. It has to work this way, or you would be unable to set waypoints on its way home. Waypoints was one of the bugs fixed. I'm presuming that the user is not so stupid that they dump the unit in the ocean. However, I didn't want the *code* to keep *me* from doing it But now, I'm thinking about what happens to an AI using this code. It probably *would* just dump it in the ocean. So, I could change the code to prevent it for AI (or allow it for users). The pseudonymous puppeteer also suggested (in his inimitable way) that the code also disallow being able to return to the current dangerous position. Not a goal for a human (it's obviously wrong), but maybe useful for an AI? I'm generally for freedom. If the player wants to goto their stealth fighter to certain death, the gui should allow them to do it. It's not uncommon to make suicide attacks with air units anyway. Let's leave this behavior as it is. - Can issue goto to city two turns away, e.g. PY. The unit does not refuel in city and dies on EOT. When I tested before, it automatically went into P5. Perhaps that was an accident of the path. Testing to PY, you are correct. It inexplicably runs out over the S ice continent. The code path chooser is flaky. This requires thought. I only fixed a particular callback, not the entire path chooser! That would be a different PR! The issue here is that the pathfinding code believes this goto can be completed, while the poor stealth fighter in fact only gets halfway and crashes. It must somehow believe the air unit will become refuled just because a friendly city is nearby. This is IMHO in the scope of this ticket. - Can not issue goto to city more than two turns away, e.g. P1. If you set a waypoint in P5, you can go on to P1. That's one of the things that waypoints are for Perhaps the goto.c struct part code should keep a tally on a per waypoint basis about refueling. That would allow truly long term planning. But why? I certainly don't make moves for more than 2 turns, and I doubt the AI could cope!?!? And is this a 2.1 project goal? Certainly not for 2.1. It would be a useful feature if city-hopping could be done automagically, but as you say it can be done with waypoints. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Forgot to mention, I also discovered that you could locate unseen units in the field by using goto to detect attack points. So, I added some checking to stop the cheat. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Very better. But still some problems: - You still cannot reach P1, and waypoints don't help me. Anyway, I don't think they should be needed to use air goto. For a land unit, you don't need to define a new way point for every turn, why should it be different for air goto. - You cannot move on all tiles you should be able to move to. For example, you cannot choose your path when the unit has only the half of its moves. - Helicopters still doesn't work. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [pepeto - Mar. Nov. 13 15:14:19 2007]: - You cannot move on all tiles you should be able to move to. For example, you cannot choose your path when the unit has only the half of its moves. Actually, it's when you are in a potential dangerous position. - Suicidal attack are supposed to be only for unit with the flag F_MISSILE only. Else, this is dangerous. - A unit with 2 turns of fuel (example AWACS or Bomber) always can move of it's half of it's moves, including when it's lost in the middle of the ocean. Then it dies. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39855) windows package and ggz client
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39855
[EMAIL PROTECTED] - Di 13. Nov 2007, 07:05:50]:
Daniel Markstedt wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39855
We ought to have a windows gtk package with embedded ggz client. Was
told
on #ggz that the code is portable, with win32 binaries available
from http://
ggzgamingzone.org/~oojah/
Maybe we could make a special test package for 2.1.0.
Yes, the windows package should absolutely have GGZ built-in.
-jason
Here's a package with GGZ support:
ftp://ftp.freeciv.org/freeciv/packages/windows/testing/Freeciv-2.1.0-win32-gtk2-ggz-setup.exe
but for some reason the Freeciv client doesn't connect to the Freeciv
server. With the internal GGZ-GTK client the client freezes when trying
to launch or join a Freeciv game and with the external GGZ-GTK client
the Freeciv client gets started and shows the start page, but no message
from the Freeciv server appears. According to the ggzd debug log
(DumpFile option in ggzd.conf), the GGZ server didn't even receive the
launch/join request from the client. Other GGZ games work fine, though,
and there's also no problem with a linux client connecting to the same
server, so I'm a little clueless about this problem at the moment.
The attached patch was necessary to get the Freeciv client running at
all with GGZ support on Windows. It sets the HOME environment variable
before GGZ-GTK initialization, because GGZ-GTK depends on HOME for its
configuration file (crashes otherwise).
Index: client/gui-gtk-2.0/gui_main.c
===
--- client/gui-gtk-2.0/gui_main.c (revision 13944)
+++ client/gui-gtk-2.0/gui_main.c (working copy)
@@ -1253,6 +1253,18 @@
void ui_init(void)
{
#ifdef GGZ_GTK
+
+ /* make sure the HOME variable is set on Windows, because
+ * ggz_gtk_initialize() uses it for the gtk-ggz configuration file */
+#ifdef WIN32_NATIVE
+ char *uhd = user_home_dir();
+ if (uhd) {
+char home_string[strlen(HOME=) + strlen(uhd) + 1];
+my_snprintf(home_string, sizeof(home_string), HOME=%s, uhd);
+putenv(home_string);
+ }
+#endif /* WIN32_NATIVE */
+
/* Engine and version match what is provided in civclient.dsc.in and
* civserver.dsc.in. */
ggz_gtk_initialize(FALSE,
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39611) BETA6 cannot find libggz
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39611 Christian Prochaska wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39611 [jordi - So 28. Okt 2007, 23:47:27]: [chrisk - Vie. Ago. 24 13:36:50 2007]: configure doesn't look for ggzlib in the standard path: On plain Debian Etch: ./configure --enable-client=no --with-ggz-server checking for GGZ library: libggz... no For Freeciv 2.1 Debian packages, I'm adding the following to the configure call: --with-libggz-libraries=/usr/lib \ --with-libggz-includes=/usr/include \ --with-ggzmod-libraries=/usr/lib \ --with-ggzmod-includes=/usr/include \ --with-ggzdmod-libraries=/usr/lib \ --with-ggzdmod-includes=/usr/include \ --with-ggzconfig=/usr/bin \ which it seems to like: the binaries are linked to the relevant ggz libs. just adding --with-ggz-dir=/usr works as well, but there are still two other problems: - Freeciv must be configured with --prefix=/usr (where GGZ is installed) or the configure check for ggz-config will fail with the message dismissed due to different prefix Ugh. - on Debian testing the GGZ server (ggzd) is installed in /usr/sbin which means that it must be run as root and thus will start the Freeciv server as root, which is disallowed ggzd should not be run as root. Ever. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39857) attempt to bribe barbarian causes crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39857 [guest - Mon Nov 12 11:30:43 2007]: If the diplomat in the city attempts to subvert the barbarian legion with a bribe of 100 gold the game will crash. #0 0x0812f8b2 in diplomat_bribe_yes_callback (pWidget=0x93ee968) at diplomat_dialog.c:1311 #1 0x0816e020 in widget_pressed_action (pWidget=0x93ee968) at widget.c:402 #2 0x081387e1 in main_mouse_button_down_handler (pButtonEvent=0x8298d9c, pData=0x0) at gui_main.c:331 #3 0x081392b8 in gui_event_loop (pData=0x0, loop_action=0, key_down_handler=0x813851f main_key_down_handler, key_up_handler=0x8138785 main_key_up_handler, mouse_button_down_handler=0x81387a0 main_mouse_button_down_handler, mouse_button_up_handler=0x8138856 main_mouse_button_up_handler, mouse_motion_handler=0x81388c7 main_mouse_motion_handler) at gui_main.c:700 #4 0x0813996e in ui_main (argc=1, argv=0xbfbd4bf4) at gui_main.c:1000 #5 0x08050945 in main (argc=1, argv=0xbfbd4bf4) at civclient.c:380 (gdb) p pIncite_Dlg $1 = (struct small_diplomat_dialog *) 0x0 Seems the dialog has already been destroyed when the callback is triggered. This is a gui-sdl problem. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39859) Sliders in governor menu do not work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 The sliders to set the values (gold, happy, etc.) do not work in the governor menu of the cities. It is possible to use the presets but you are not able to set the values yourself. what client? what version? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39855) windows package and ggz client
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39855 Christian Prochaska wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39855 [EMAIL PROTECTED] - Di 13. Nov 2007, 07:05:50]: Daniel Markstedt wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39855 We ought to have a windows gtk package with embedded ggz client. Was told on #ggz that the code is portable, with win32 binaries available from http:// ggzgamingzone.org/~oojah/ Maybe we could make a special test package for 2.1.0. Yes, the windows package should absolutely have GGZ built-in. -jason Here's a package with GGZ support: ftp://ftp.freeciv.org/freeciv/packages/windows/testing/Freeciv-2.1.0-win32-gtk2-ggz-setup.exe but for some reason the Freeciv client doesn't connect to the Freeciv server. With the internal GGZ-GTK client the client freezes when trying to launch or join a Freeciv game and with the external GGZ-GTK client the Freeciv client gets started and shows the start page, but no message from the Freeciv server appears. According to the ggzd debug log (DumpFile option in ggzd.conf), the GGZ server didn't even receive the launch/join request from the client. Other GGZ games work fine, though, and there's also no problem with a linux client connecting to the same server, so I'm a little clueless about this problem at the moment. Ouch. The attached patch was necessary to get the Freeciv client running at all with GGZ support on Windows. It sets the HOME environment variable before GGZ-GTK initialization, because GGZ-GTK depends on HOME for its configuration file (crashes otherwise). How would you find the configuration directory on windows? This is something that should be fixed within GGZ. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39859) Sliders in governor menu do not work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 On Nov 14, 2007 8:43 AM, Jason Dorje Short [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39859 The sliders to set the values (gold, happy, etc.) do not work in the governor menu of the cities. It is possible to use the presets but you are not able to set the values yourself. what client? what version? This has been answered already above. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39863) Client hangs my machine
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39863 I'm having major problems with a 2.1.0 install on Windows 2000 [Version 5.00.2195]. When I start the client, I can sometimes complete a couple of turns, But the client pegs my CPU out at 100% and then the machine hangs until I kill it from the Windows Task Manager. I tried starting the server first and then the client and automatically started the server by just starting the client. Both ways result in a hung machine. I have a gig of RAM and an AMD Athlon(tm)XP 2500+ cpu. (I installed binary Freeciv-2.1.0-win32-gtk2-setup.exe from http://freeciv.wikia.com/wiki/Main_Page) I'm running GTK+2.10.6-1 runtime environment (determined from the control Panel). I didn't see any GDK/GTK messages. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
