[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [pepeto - Mon Dec 01 22:45:49 2008]: > > > [book - Mon Dec 01 22:15:19 2008]: > > > > > [pepeto - Mon Dec 01 07:17:09 2008]: > > > > > > > [book - Mon Dec 01 03:54:35 2008]: > > > > > > > > I also made some minor style changes (but I tested the > > > > above both with and without them, to make sure it was > > > > not caused by them), and I will post the modified > > > > airgoto patch when I cannot find any more oddities. :) > > > > > > Minor changes ? Did you remove it completly or just forgot > > > to post the patch ? :P > > > > I didn't post it yet in case the above needed a lot of > > changes to fix. Anyway, it is mostly formatting fixes > > and some other minor improvements. Here I have attached > > the diff from your final airgoto patch (so apply this > > one on top of yours to compile, or just read it to see > > what I have changed). > > This looks all ok. Here then is the final version I will commit in a few days, unless someone can think of a good reason why not. --- 荷造りして用意が出来た！ airgoto_final.patch.bz2 Description: application/bzip2 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Mon Dec 01 22:15:19 2008]: > > > [pepeto - Mon Dec 01 07:17:09 2008]: > > > > > [book - Mon Dec 01 03:54:35 2008]: > > > > > > This time when testing I found that bombers when they > > > have to wait at a tile before doing an attack (i.e. > > > the attack destination is farther than the bomber's > > > immediate range), when the bomber does get to the > > > target instead of attacking it stops with the message > > > "Orders for bomber aborted as there are units in the > > > way". > > > > I suppose AI player unit moved on the bomber way. > > I am pretty sure this is not the case. Try it with the > airtest savegame or just use the editor to create the > situation. If a fighter or bomber needs more than one > turn to attack an enemy unit or a non-empty enemy city, > when it does get to the target it just stops in front > of it instead of attacking. > > I looked at the code, and perhaps it is the case that > this is a "feature"? There doesn't seem to exist an > ORDER_ATTACK... > > Well it is a minor thing, and if it would require big > changes to the order/goto system it should be left for > another ticket. The message "Orders for bomber aborted as there are units in the way" is displayed when the bomber check a new visible unit, in its vision range and not only in its own path. This should linked with the vigilant flag of the path, so it's certainly the part of an another ticket (client problem or feature). A similar thing also occurs for refueling. Sometimes, the unit stops before reaching the refuel point when it meets a unit. This is especially annoying for AWACS with 5 tiles of vision range. This may constitute a third ticket (server problem). > > > I also made some minor style changes (but I tested the > > > above both with and without them, to make sure it was > > > not caused by them), and I will post the modified > > > airgoto patch when I cannot find any more oddities. :) > > > > Minor changes ? Did you remove it completly or just forgot to post the > > patch ? :P > > I didn't post it yet in case the above needed a lot of > changes to fix. Anyway, it is mostly formatting fixes > and some other minor improvements. Here I have attached > the diff from your final airgoto patch (so apply this > one on top of yours to compile, or just read it to see > what I have changed). This looks all ok. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Mon Dec 01 03:54:35 2008]: > > This time when testing I found that bombers when they > have to wait at a tile before doing an attack (i.e. > the attack destination is farther than the bomber's > immediate range), when the bomber does get to the > target instead of attacking it stops with the message > "Orders for bomber aborted as there are units in the > way". I suppose AI player unit moved on the bomber way. > I also made some minor style changes (but I tested the > above both with and without them, to make sure it was > not caused by them), and I will post the modified > airgoto patch when I cannot find any more oddities. :) Minor changes ? Did you remove it completly or just forgot to post the patch ? :P ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [pepeto - Sat Nov 15 13:39:13 2008]: > > Feel free to modify the patch. Alright, finally I have time to get back to this. This time when testing I found that bombers when they have to wait at a tile before doing an attack (i.e. the attack destination is farther than the bomber's immediate range), when the bomber does get to the target instead of attacking it stops with the message "Orders for bomber aborted as there are units in the way". I also made some minor style changes (but I tested the above both with and without them, to make sure it was not caused by them), and I will post the modified airgoto patch when I cannot find any more oddities. :) --- もう少しだけ！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > Feel free to modify the patch. airgoto.diff.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Sat Nov 15 04:56:43 2008]: > > All I could find is a minor display annoyance in that if > a fighter or bomber type unit has only 1 move left, then > the "turns to target" label shows 1 turn instead of 0 when > the user does a 1 tile goto. This is probably a bug in > the gui and can be left for another ticket. > It is the same for classic goto. It is a part of the pf code. It always has calculated this like that. If it should be modified, it would require an other ticket. > Since you already did the hardest part of the work, > if you don't feel like doing this kind of "cleanup", > I can do it myself later after committing this patch > (in a few days, to give more people time to look at > it and discuss). > I will try to finish this work. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 >
Alright, with the patch in 40563 this new goto code works
great, even better than the old warmap code.
All I could find is a minor display annoyance in that if
a fighter or bomber type unit has only 1 move left, then
the "turns to target" label shows 1 turn instead of 0 when
the user does a 1 tile goto. This is probably a bug in
the gui and can be left for another ticket.
Now we can discuss style/implementation improvements. :)
There are a few places with really long function names making
formatting kind of ugly. The style guide doesn't say anything
about this case, but I have been using this convention: to
have the extern/static and return type on a separate line
above the function name. So for example:
static enum tile_behavior no_fights_or_unknown_goto(
const struct tile *ptile,
enum known_type known,
const struct pf_parameter *p)
would become
static enum tile_behavior
no_fights_or_unknown_goto(const struct tile *ptile,
enum known_type known,
const struct pf_parameter *p)
I think this is a little better than having a line end in (
and the parameters floating in an arbitrary place. :)
I like the use of polymorphism for pf_map. Using enums
and switch statements is a nice way to implement this;
it is useful when there are a great number of very similar
"classes" and their overridden functions differ only
very slightly in their respective implementations (cf.
objprop in client/gui-gtk-2.0/editprop.c).
In this case I think a better design pattern would be
to have pf_map emulate a c++ abstract base class (or an
"interface" in the java terminology) and the 3 "derived"
pf_map classes use a vtable (a bunch of function pointers)
to emulate c++ virtual functions.
So the public interface for pf_map would look like
(obvious stuff left as "..." for brevity):
struct pf_map; /* Abstract base class. */
struct pf_map *pf_create_map(...); /* Factory function. */
/* Public function interface. */
void pf_destroy_map(struct pf_map *pfm);
struct pf_path *pf_get_path(struct pf_map *pfm, ...);
bool pf_get_position(struct pf_map *pfm, ...);
bool pf_next(struct pf_map *pfm);
void pf_next_get_position(const struct pf_map *pfm, ...);
struct pf_path *pf_next_get_path)(...);
struct pf_parameter *pf_get_parameter)(...);
(Maybe these should be renamed so that they all start
with "pf_map_", so that the object oriented style
is emphasized. Not strictly necessary for now; it can
be left as cleanup for later so that it does not clutter
up the patch needlessly.)
Internally (visible only to pf_map and derived classes)
we would have:
/* Abstract base class. */
struct pf_map {
void (*destroy)(...);
struct pf_path *(*get_path)(...);
bool (*get_position)(...);
bool (*next)(...);
void (*next_get_position)(...);
struct pf_path *(*next_get_path)(...);
struct pf_parameter *(*get_parameter)(...);
};
/* Down-cast macro. */
#define PF_MAP(p) ((struct pf_map *)(p))
void pf_destroy_map(struct pf_map *pfm)
{
pfm->destroy(pfm);
}
...
Or even struct pf_map could be made public so that
pf_destroy_map and friends could be inline functions
or macros (personally I would go for inline functions).
Now a derived class would look like:
struct pf_normal_map {
struct pf_map vtable; /* As before, must be first. */
... /* pf_normal_map specific stuff */
};
/* Up-cast macro. */
#define PF_NORMAL_MAP(p) ((struct pf_normal_map *)(p))
/* NB: The "constructor" returns a pf_map. */
struct pf_map *pf_normal_map_create(...)
{
struct pf_normal_map *pfm;
struct pf_map *vtable;
pfm = fc_calloc(...);
vtable = &pfm->vtable;
/* Initialize virtual function table. */
vtable->destroy = pf_normal_map_destroy;
...
return PF_MAP(pfm);
}
void pf_normal_map_destory(struct pf_map *p)
{
struct pf_normal_map *pfm = PF_NORMAL_MAP(p);
...
}
...
An ugly aspect of this kind of implementation is
the up-casting in every derived method, though it
is only 1 extra line per function.
Though not necessary for this relatively small
inheritance hierachy, type checking could be added
in the cast macros for example by keeping the
mode enum in struct pf_map (it wouldn't be a pure
"vtable" then, so some stuff would be renamed),
setting it correctly in each of the derived classes'
constructors, and checking it in the macro.
Since you already did the hardest part of the work,
if you don't feel like doing this kind of "cleanup",
I can do it myself later after committing this patch
(in a few days, to give more people time to look at
it and discuss).
---
そこでもう一度飛べて全世界のどこでも旅行ができる。
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Thu Nov 13 03:20:35 2008]: > > Hmm perhaps I spoke too soon about fighters in my last reply. > Now it sometimes happens that a fighter with 2 or 3 moves > left will wait in a city if the user does a goto 1 tile out > of the city. It is very odd in that it appears to happen > only some of the time :?. In fact, once I must have done the > test with twenty fighters before I gave up thinking I was > crazy. But having reloaded the airtest savegame it happened > again soon afterwards. I was also able to make a bomber with > two moves and zero fuel wait in a city by making a goto to a > tile beside the city. > I observed this too in a particular case. It occurs when you set 2 gotos for the same unit in a same turn. When a unit is waiting and you select it, it seems that the client doesn't reset the focus status or something like this. I didn't check more for the moment. I think this is an other bug, not directly linked with this change. If this is not the case, I would like to know a reproducible example. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > Hmm perhaps I spoke too soon about fighters in my last reply. Now it sometimes happens that a fighter with 2 or 3 moves left will wait in a city if the user does a goto 1 tile out of the city. It is very odd in that it appears to happen only some of the time :?. In fact, once I must have done the test with twenty fighters before I gave up thinking I was crazy. But having reloaded the airtest savegame it happened again soon afterwards. I was also able to make a bomber with two moves and zero fuel wait in a city by making a goto to a tile beside the city. --- すごく奇妙ですね！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Wed Nov 12 21:20:16 2008]: > > Fighter type units now pass all my tests, however there seems to > be a problem with bomber type units. In certain situations the > path finding code appears to get into an infinite loop (or take > very very long; I left it for several minutes with no change). > This can be seen with the airtest savegame if you take a bomber > in Amsterdam and try to hover a goto beyond its possible range > (e.g. near Kocevje or near the unknown tiles beside Ormoz). What > is strange is that a bomber starting in Rotterdam does not make > the pf code go into the loop; it correctly stops and shows that > the destination is unreachable in less than a second. > My mistake, I messed up the two queues. It was a infinite loop, assuming that the best way reach the tile A was from B, and the B from A. Now, it shouldn't freeze anymore, at least I hope so. :-) trunk_airgoto.diff.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > Fighter type units now pass all my tests, however there seems to be a problem with bomber type units. In certain situations the path finding code appears to get into an infinite loop (or take very very long; I left it for several minutes with no change). This can be seen with the airtest savegame if you take a bomber in Amsterdam and try to hover a goto beyond its possible range (e.g. near Kocevje or near the unknown tiles beside Ormoz). What is strange is that a bomber starting in Rotterdam does not make the pf code go into the loop; it correctly stops and shows that the destination is unreachable in less than a second. --- ブラックホールが出たかも。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Wed Nov 12 05:03:58 2008]: > > I found one strange behaviour while testing: if a fighter > is at a refuelling point and has one move left, doing a > goto with it will make it move this turn instead of waiting. > Hopefully that won't be too hard to fix. > Fixed. trunk_airgoto.diff.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [pepeto - Tue Nov 11 13:20:18 2008]: > > I changed completely my initial mind to fix the last strange > behaviour I observed. I rewrote the nearly-whole path_finding.c > file. Ah, the worst case scenario I was afraid of... but seems you managed it without too much trouble. :) I found one strange behaviour while testing: if a fighter is at a refuelling point and has one move left, doing a goto with it will make it move this turn instead of waiting. Hopefully that won't be too hard to fix. > I made this patch for trunk only. I think it's too important > changes for 2.1. I agree. At least this way it will be a nice "new" feature for 2.2 when it is released. ;) --- 無理をしないでね。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > I changed completely my initial mind to fix the last strange behaviour I observed. I rewrote the nearly-whole path_finding.c file. Some words about this new code: * struct pf_map is a base structure, containing only the mode it is used. There are 3 modes: PF_NORMAL (in the most of the cases), PF_DANGER (like old danger code) and PF_FUEL (for fueled units which returns automatically to refuel. The real derived structures are named pf_normal_map, pf_danger_map and pf_fuel_map. The classical pf functions are keep and just wrap to the specific functions of the mode. All specific function have the pf_normal_*, pf_danger_* and pf_fuel_* prefixes. * The mode PF_FUEL is different of PF_DANGER because it doesn't say if a tile is dangerous or not. It tries to find the closest refuel point and deduce the minimum moves left a unit needs to reach this position. * The function pf_fuel_map_iterate takes care of refueling, including the case the unit with 2 fuel turns, for example, could refuel in the odd turns. * For attacking, the found path should be the one which requires the less of moves, also for retreat after attacking. * Added some 'const' flag to some callbacks. I made this patch for trunk only. I think it's too important changes for 2.1. Thank you for testing and finding new bugs. trunk_airgoto.diff.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [pepeto - Wed Nov 05 17:14:11 2008]: > > I hope this version should work very better. This version is the best so far. I did find one strange thing though: take for example a fighter from Arnsberg and make a goto attack on Kranj. The path finding code correctly recognizes that it can attack that city and be able to come back to Novo Mesto, but the route it calculates is wrong (fighter ends up running out of fuel). It is almost as if it assumes the attack will make the fighter go through the city. Maybe this can be easily fixed by making the path finding code know when an attack will result in the unit occupying the the tile and when not? Of course most of the time an attack will not cause the unit to occupy the defender's tile, especially for air units. --- 毎度ごめんね〜 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [pepeto - Wed Oct 29 09:03:33 2008]: > > > [book - Wed Oct 29 01:45:22 2008]: > > > > Good stuff. There remains only one weird thing that I > > could find: now when a figher or bomber is made to > > attack an enemy city or unit via goto, it first tries > > to go to a closer "safe" tile and only then make the > > attack approach. For example, this can be seen when a > > fighter or bomber in city A tries to attack Radovljica, > > which results in the unit running out of fuel and dying. :/ > > Seems this is harder to fix. It is annoying, so I think I will > have to rewrite all the stuff. Sorry it was my mistake then; if this was present before and will take much more work to fix I will leave it for another ticket and commit your latest patch so that we have a decently working air goto in the meantime. Incidentally, waypoints can be used to work around this: you just need to set a waypoint beside your target then make the attack click. And I also found another oddity that may or may not be related: a fighter doesn't wait at a refuel point if it doesn't have enough moves to complete the route. For example, take a fighter from Gelsenkirchen and hover a goto 2 or 3 tiles from Radovljica: the goto turn counter says 1 turn (meaning immediately) and allows you to send the fighter past the refuel point making it end up with zero moves. It should wait at the refuel point (with status icon 'G') and only next turn go to destination (so it has moves left over to come back). --- 九日だけにここの喫茶店の特別なサービスです。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > Hi, Pepeto wrote on Oct 29, 01:04 (-0800): > > [chrisk - Wed Oct 29 07:29:07 2008]: > > Madeline Book wrote on Oct 28, 17:45 (-0800): > > > > > Good stuff. There remains only one weird thing that I > > > could find: now when a figher or bomber is made to > > > attack an enemy city or unit via goto, it first tries > > > to go to a closer "safe" tile and only then make the > > > attack approach. For example, this can be seen when a > > > fighter or bomber in city A tries to attack Radovljica, > > > which results in the unit running out of fuel and dying. :/ > > > > FWIW, you see a similar thing with land unit goto: a unit next to an enemy > > unit doesn't necessarily attack it, but makes a move before using > > rivers or > > roads sometimes. Too silly. > It is the classic behaviour or with using this patch? This bug is in the source now for many month. I didn't test the air goto patch. I guess there is an old bug report from me somewhere. Christian -- Christian Knoke* * *http://cknoke.de * * * * * * * * * Ceterum censeo Microsoft esse dividendum. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [book - Wed Oct 29 01:45:22 2008]: > > Good stuff. There remains only one weird thing that I > could find: now when a figher or bomber is made to > attack an enemy city or unit via goto, it first tries > to go to a closer "safe" tile and only then make the > attack approach. For example, this can be seen when a > fighter or bomber in city A tries to attack Radovljica, > which results in the unit running out of fuel and dying. :/ Seems this is harder to fix. It is annoying, so I think I will have to rewrite all the stuff. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [chrisk - Wed Oct 29 07:29:07 2008]: > > Madeline Book wrote on Oct 28, 17:45 (-0800): > > > Good stuff. There remains only one weird thing that I > > could find: now when a figher or bomber is made to > > attack an enemy city or unit via goto, it first tries > > to go to a closer "safe" tile and only then make the > > attack approach. For example, this can be seen when a > > fighter or bomber in city A tries to attack Radovljica, > > which results in the unit running out of fuel and dying. :/ > > FWIW, you see a similar thing with land unit goto: a unit next to an enemy > unit doesn't necessarily attack it, but makes a move before using rivers or > roads sometimes. Too silly. > > Christian > It is the classic behaviour or with using this patch? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > Madeline Book wrote on Oct 28, 17:45 (-0800): > Good stuff. There remains only one weird thing that I > could find: now when a figher or bomber is made to > attack an enemy city or unit via goto, it first tries > to go to a closer "safe" tile and only then make the > attack approach. For example, this can be seen when a > fighter or bomber in city A tries to attack Radovljica, > which results in the unit running out of fuel and dying. :/ FWIW, you see a similar thing with land unit goto: a unit next to an enemy unit doesn't necessarily attack it, but makes a move before using rivers or roads sometimes. Too silly. Christian -- Christian Knoke* * *http://cknoke.de * * * * * * * * * Ceterum censeo Microsoft esse dividendum. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > Good stuff. There remains only one weird thing that I could find: now when a figher or bomber is made to attack an enemy city or unit via goto, it first tries to go to a closer "safe" tile and only then make the attack approach. For example, this can be seen when a fighter or bomber in city A tries to attack Radovljica, which results in the unit running out of fuel and dying. :/ --- 六日後に無意味な言葉しか話せなかった。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > I tested the patch and it works fairly well. It is a big improvement over the current broken goto for air units, so I will test it some more and commit it soon if I do not find anything obviously bad. I found some strange things while testing which I will describe below and perhaps leave for future tickets if they cannot be easily fixed as part of this patch. I have attached a savegame for ease of testing which I will refer to below. Helicopters seem to work only in S2_1. In trunk they still can only go to "safe" tiles. The path finding code seems to be unable to find a route where it has to wait at an intermediate location with more than 1 move left. For example try making a fighter go from city A to city C and it finds a very long route totally in the wrong direction (it should just go via city B). Using waypoints did not help: setting a waypoint at city B makes any further route impossible. It is still impossible to use fighters to attack a target knowing that they may possibly have no moves to come back, or a target that is unseen. This occurs frequently in games and should be made possible somehow. I could not get patrol to crash, but I could not make it do anything sensible either. For fighters it seems to do nothing and for awacs I kept getting the error message "Orders for AWACS aborted as there are units nearby" (?). When I finally did make the awacs patrol (it went to a tile and had the patrol icon), it just returned to refuel the next turn and did not go out again. > Maybe carrier should be considered as refuel point, it > was written in the code that they could move so don't be > considered as it. However, other paths can be also wrong > (e.g. land unit going to a transporter, which can have > been moves). Moreover, a fighter able to reach a carrier > directly in the turn should be able to use it. I think carriers should be considered to be a refuel point (unless they are fully loaded perhaps). It should be the player's responsibility to not move the carrier before the fighters have arrived, or to recall the fighters if the carrier is destroyed. > Maybe add an option to ignore the dangerous positions > path in the client. It could be quite annoying sometimes > to don't move where you want, especially from carriers. That could be good. Also, it could draw the goto line in green for "safe" routes, and red for potentially suicidal gotos. --- いつものごとく我々は密会を三日三晩探さなければならなかった。 airtest.sav.gz Description: Unix tar archive ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40536) [Patch] Working air goto
http://bugs.freeciv.org/Ticket/Display.html?id=40536 > > [EMAIL PROTECTED] - Mon Oct 27 02:12:31 2008]: > > Is there way to reproduce these with old code? Both 2.1 and TRUNK? > > - Air patrol doesn't crash any more. Move a fighter ouside a city and choose a far point to patrol on. The client dies with: 0: Detected fatal error in goto.c line 1085: 0: No return path found! civclient: shared.c:754: real_die: Assertion `0' failed. Aborted > > - Way points works as expected. Far way points couldn't be chosen except if you could arrive there with 0 moves left only. Also long path couldn't use intermediate cities to refuel. > > - Client's goto command forbid to move to dangerous tiles (like it > > already does for triremes). Using numeric pad can be used instead to > > reach dangerous positions. The only things that the old code allowed is that a unit could move to the half of its moves, ignoring totally its position and the position of the potential refuel points. If you have a nuke, you could move to 8 tiles then 4, 2, 1, and impossible to move anymore :), whereas there was 1 single moves left. This patch allow all safe moves, where the unit can finish its turn on a known refuel point (except carriers unfortunately). Long paths are possible, using automatically some refuel points. What could be again improved: - Maybe carrier should be considered as refuel point, it was written in the code that they could move so don't be considered as it. However, other paths can be also wrong (e.g. land unit going to a transporter, which can have been moves). Moreover, a fighter able to reach a carrier directly in the turn should be able to use it. - Maybe add an option to ignore the dangerous positions path in the client. It could be quite annoying sometimes to don't move where you want, especially from carriers. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
