[Freeciv-Dev] (PR#39867) freeciv 2.1.0 crashes when I conquer a city with paratroopers.
http://bugs.freeciv.org/Ticket/Display.html?id=39867 > Hi, When I conquer a city using the "Q" option of my paratrooper, freeciv crashes :/ It doesn't If I simply go into the city with my para. polytan [EMAIL PROTECTED] ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#12119) toggling fullscreen doesn't always work on windows
http://bugs.freeciv.org/Ticket/Display.html?id=12119 > I propose that fullscreen is off by default. Because of this bug, it's too hard to turn it off for a large population of users, i.e. Windows users. This patch ought to do it. ~Daniel no_default_fullscreen.diff Description: Binary data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#9347) Bug: buggy paratrooper message
http://bugs.freeciv.org/Ticket/Display.html?id=9347 > > [jdorje - Wed Jul 14 19:55:25 2004]: > > > [EMAIL PROTECTED] - Mon Jul 12 09:45:58 2004]: > > > So the message is buggy, it should read "You cannot paradrop a unit > > that is > > transporting other units." > > Here's a patch. > > jason > > Updated for S2_1. ~Daniel paradrop_transporter.diff Description: Binary data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39868) unit woken up from sentry not properly deselected
http://bugs.freeciv.org/Ticket/Display.html?id=39868 > S2_1 r13945: Put unit in sentry, then wake it up and move it somewhere using up all its moves. Expected behavior: Unit gets deselected and the next unit is selected. Actual behavior: Unit stays selected. If you try to move one more tile it will get a goto order to the tile and the next unit will finally be selected. ~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
http://bugs.freeciv.org/Ticket/Display.html?id=39852 >
After looking at airgoto code some more, found (more than one) function on
the server side that looks for an airbase. Copied part here.
Essentially no change for AI.
The user can run the aircraft any direction for 1/2 move, *and* another
1/2 move that takes it near a possible airbase. This allows setting
waypoints anywhere on a path (outgoing and incoming) near an airbase.
I ran many trials removing the restriction on single flight paths (that is,
letting it self-select a refueling base on the way to P1, as it did
initially). The code already exists. It works sometimes
As you may remember, in the early messages of this PR, it refueled at P5
for me, but not for you. After many boring tests (restart, test, quit, ...),
it has become clear that some code doesn't work consistently.
Sometimes it refuels at P5, other times P7, and sometimes, it just jogs
around P5 and dies. Trying to go to P3 or P8, it always makes a straight
path just past P5 over the engineer, never refuels, and dies.
There must be some kind of random path selection between equal paths, but
they didn't use a standard function, and I cannot find it! Or maybe it's
an uninitialized variable.
Therefore, for 2.1.1, I'm leaving in the restriction. If you need to
specify refueling on a long path, use waypoints. They always work.
For 2.2 (or 2.3), we can look at better combining the 4 different path
selection methods (with 2 different Dijkstra implementations)!
Committed S2_1 revision 13958.
Index: common/aicore/pf_tools.c
===
--- common/aicore/pf_tools.c(revision 13957)
+++ common/aicore/pf_tools.c(working copy)
@@ -550,8 +550,9 @@
{
int moves = SINGLE_MOVE * real_map_distance(param->start_tile, ptile);
int have = get_moves_left_initially(param);
+ int left = have - moves;
- if (have < moves) {
+ if (left < 0) {
/* not enough fuel. */
return TRUE;
}
@@ -576,6 +577,14 @@
return FALSE;
}
+ /* similar to find_nearest_airbase() */
+ iterate_outward(ptile, left / SINGLE_MOVE, atile) {
+if (TILE_UNKNOWN != tile_get_known(atile, param->owner)
+ && is_possible_base_fuel(atile, param)) {
+ return FALSE;
+}
+ } iterate_outward_end;
+
/* Carriers are ignored since they are likely to move. */
return TRUE;
}
___
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
http://bugs.freeciv.org/Ticket/Display.html?id=39852 > Committed S2_2 revision 13959. Committed trunk revision 13960. ___ 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
http://bugs.freeciv.org/Ticket/Display.html?id=39852 > Pepeto _ wrote: > * Units still can move of the half of their moves and die when they go > to dangerous positions. > By design. > * Way points don't work well since all far positions are considered as > dangerous. ... > Obviously, there is a language or comprehension problem. Please re-read the earlier discussion. Waypoints are working as designed. The pf "dangerous path" code does not, and will not be used, because it has been superceded by waypoints. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#20772) Bug: Air goto attack on unit or city not possible
http://bugs.freeciv.org/Ticket/Display.html?id=20772 > I have tested the excellent savegame provided by Fernando, and the AWACS moves with either G or cursors. Aircraft can attack cities and units. As to the patches proposed, after a cursory examination, the first didn't even begin to address the issues. The later ones all have crashing bugs, because they didn't test for < 0 before calling an iterator. And used the wrong iterator. And added unexplained return values without documentation. I think all related issues were resolved in PR#39852. ___ 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
http://bugs.freeciv.org/Ticket/Display.html?id=39852 > It is getting better. But... * Units still can move of the half of their moves and die when they go to dangerous positions. * Way points don't work well since all far positions are considered as dangerous. You must finish the turn (with 0 move only) to use them. For example, you cannot move to P1 if you move first to P7 and P8 before. To fix this, you have to make the all cities or airbases as safe places, then the pf code will make a "dangerous path". ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#20772) Bug: Air goto attack on unit or city not possible
http://bugs.freeciv.org/Ticket/Display.html?id=20772 > No, you didn't test my last request which point out a big problem. Waypoints don't work at well for air goto. It must must have 0 move only on the waypoint for seeing this feature working. So, it's still not resolved. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#20759) Crash on box select + mass goto
http://bugs.freeciv.org/Ticket/Display.html?id=20759 > I have not been able to reproduce this problem with 2.1.0. Could somebody please verify, or provide a savegame that crashes? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#20759) Crash on box select + mass goto
http://bugs.freeciv.org/Ticket/Display.html?id=20759 > It looks like PR#18010. ___ 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
http://bugs.freeciv.org/Ticket/Display.html?id=39852 > > [wsimpson - Jeu. Nov. 15 14:56:13 2007]: > > Pepeto _ wrote: > > * Units still can move of the half of their moves and die when they go > > to dangerous positions. > > > By design. > Sadly yes. > > * Way points don't work well since all far positions are considered as > > dangerous. ... > > > Obviously, there is a language or comprehension problem. Please re-read > the earlier discussion. Don't cut my comment. The explanation is written after. > Waypoints are working as designed. The pf "dangerous path" code does not, > and will not be used, because it has been superceded by waypoints. > I just said that Waypoints don't work well. ___ 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
http://bugs.freeciv.org/Ticket/Display.html?id=39852 > Try to move to P1... airgoto.sav.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39859) [gui-sdl][regression] Sliders in governor menu do not work
http://bugs.freeciv.org/Ticket/Display.html?id=39859 >
> [dmarks - Mi 14. Nov 2007, 11:25:24]:
>
> On 11/14/07, Christian Prochaska <[EMAIL PROTECTED]> wrote:
> >
> > http://bugs.freeciv.org/Ticket/Display.html?id=39859 >
> >
> > > [guest - Mo 12. Nov 2007, 12:26:51]:
> > >
> > > 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.
> > >
> >
> > Can you describe a testcase showing the problem? I've never used the
> > city governor so far and don't know exactly what's supposed to happen
> > when moving the sliders.
> >
>
> The idea is that when you move the sliders, the value to the left of
> it will change.
>
> Actually, I tried a little harder now and found out it's actually
> possible to move them - it's just very inconvenient. You have to grab
> the slider and then move the pointer far to the left to activate it.
> Then it's possible to adjust it in both directions as long as you hold
> down the mouse button; c.f. the behavior in 2.1.0-rc1.
>
> ~Daniel
>
Ah, it happens only with resolutions higher than 640x480 and I tested in
default 640x480 windowed mode where the sliders moved fine (though still
not 100% in sync with mouse movement) and thought about changed numbers
not being instantly told to the governor or something ;-) But I could
reproduce this with rc1 as well, so I guess you tried rc1 in default
windowed mode, too?
Index: client/gui-sdl/cma_fe.c
===
--- client/gui-sdl/cma_fe.c (revision 13945)
+++ client/gui-sdl/cma_fe.c (working copy)
@@ -91,6 +91,8 @@
struct hmove *pMotion = (struct hmove *)pData;
char cBuf[4];
+ pMotionEvent->x -= pMotion->pScrollBar->dst->dest_rect.x;
+
if (pMotion && pMotionEvent->xrel &&
(pMotionEvent->x >= pMotion->min) && (pMotionEvent->x <= pMotion->max)) {
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#23095) Goto with multiple units crash
http://bugs.freeciv.org/Ticket/Display.html?id=23095 > This 2.0 ticket is still listed in 2.1. The crash seems to be fixed in the current version. I could not reproduce it with this savegame. There remains a great deal to be done in path_finding, but this ticket is completed. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39858) middle click on unexplored territory causes SDL crash
http://bugs.freeciv.org/Ticket/Display.html?id=39858 > You're overreacting. > [wsimpson - Wed Nov 14 23:58:10 2007]: > > Jason Dorje Short wrote: > > SDL client, but it probably happens on any client. If the text.c > > function gets called for an unknown tile then ptile->terrain is NULL. > > > No, it doesn't!!! Which you would have known had you bothered to check!!! > That's a *BUG* in the SDL client!!! Perhaps, but fixing bugs like that should take second precedence to fixing crashes. And SDL client patches are in general outside of my scope, whereas the text.c code I am intimately familiar with. > Furthermore, I've been told for many months not to add new translated > strings to 2.1. That's a mixed bag. You should not add or change text that is going to be seen by users and confuse them. Adding an untranslated string to replace a crash is a different story - I'm quite sure users would rather see garbage text than see a crash. > Worse, this length of text is completely out of scale for the popup! Works for me. Text formatting is an issue however. > Worst, you stuck it before the debug data, instead of next to the rest of > the terrain text, ruining *all* existing clients to fix a bug in SDL. Other clients don't show the popup in the unknown-tile case so behavior is unchanged for them. > Finally, you did it to all branches, without waiting for review. This is justified for a simple crash-fix patch. > I'm immediately replacing your patch, to at least use an existing string, > and not screw up the entire project on a commonly seen tile just days > before another release. Naturally I have no objections to a better fix. > But fixing the SDL client bug itself would be best Yeah. I still don't think the text.c function should crash if given a bad tile though. And as a player I don't know if no popup is better than a semi-informative one that might be of (small) use to new players. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39867) freeciv 2.1.0 crashes when I conquer a city with paratroopers.
http://bugs.freeciv.org/Ticket/Display.html?id=39867 > > [guest - Thu Nov 15 10:24:17 2007]: > > Hi, > > When I conquer a city using the "Q" option of my paratrooper, freeciv > crashes :/ > > It doesn't If I simply go into the city with my para. What client are you using? Can you provide (attach) a savegame that lets us reproduce the crash? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39868) [regression] unit woken up from sentry not properly deselected
http://bugs.freeciv.org/Ticket/Display.html?id=39868 > > [dmarks - Thu Nov 15 12:26:01 2007]: > > S2_1 r13945: > > Put unit in sentry, then wake it up and move it somewhere using up all > its moves. > > Expected behavior: > Unit gets deselected and the next unit is selected. > > Actual behavior: > Unit stays selected. If you try to move one more tile it will get a > goto order to the tile and the next unit will finally be selected. > > > ~Daniel > > > Also, I'm pretty sure this is a regression between 2.1.0 and S2_1-devel. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#23095) Goto with multiple units crash
http://bugs.freeciv.org/Ticket/Display.html?id=23095 > > [wsimpson - Jeu. Nov. 15 15:45:08 2007]: > > This 2.0 ticket is still listed in 2.1. The crash seems to be fixed > in the current version. I could not reproduce it with this savegame. > This is not a 2.0 ticket, but resolved. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39859) [gui-sdl] Sliders in governor menu do not work
http://bugs.freeciv.org/Ticket/Display.html?id=39859 > > [cproc - Thu Nov 15 17:01:03 2007]: > > > [dmarks - Mi 14. Nov 2007, 11:25:24]: > > > > On 11/14/07, Christian Prochaska <[EMAIL PROTECTED]> wrote: > > > > > > http://bugs.freeciv.org/Ticket/Display.html?id=39859 > > > > > > > > [guest - Mo 12. Nov 2007, 12:26:51]: > > > > > > > > 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. > > > > > > > > > > Can you describe a testcase showing the problem? I've never used the > > > city governor so far and don't know exactly what's supposed to happen > > > when moving the sliders. > > > > > > > The idea is that when you move the sliders, the value to the left of > > it will change. > > > > Actually, I tried a little harder now and found out it's actually > > possible to move them - it's just very inconvenient. You have to grab > > the slider and then move the pointer far to the left to activate it. > > Then it's possible to adjust it in both directions as long as you hold > > down the mouse button; c.f. the behavior in 2.1.0-rc1. > > > > ~Daniel > > > > Ah, it happens only with resolutions higher than 640x480 and I tested in > default 640x480 windowed mode where the sliders moved fine (though still > not 100% in sync with mouse movement) and thought about changed numbers > not being instantly told to the governor or something ;-) But I could > reproduce this with rc1 as well, so I guess you tried rc1 in default > windowed mode, too? > > Yeah you're right. So this is not a regression after all. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
