[Freeciv-Dev] (PR#40022) Diplomacy with dead AIs?
http://bugs.freeciv.org/Ticket/Display.html?id=40022 > Hello: I was just informed that my cease-fire with the Phoenicians had expired, and that I was now at war with them - not a problem, they've been dead since the turn after I met them. Could you please look into this, and perhaps disable changes to the diplomatic state for dead players (at least AIs), since there's no way to negotiate with them? Thanx and Regards, VJSchiavoni -- "I may detest what you say, but I will defend to the death your right to say it." EB Hall, "Friends of Voltaire", 1906 Hello: I was just informed that my cease-fire with the Phoenicians had expired, and that I was now at war with them - not a problem, they've been dead since the turn after I met them. Could you please look into this, and perhaps disable changes to the diplomatic state for dead players (at least AIs), since there's no way to negotiate with them? Thanx and Regards, VJSchiavoni -- "I may detest what you say, but I will defend to the death your right to say it." EB Hall, "Friends of Voltaire", 1906 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39792) explore server assert
http://bugs.freeciv.org/Ticket/Display.html?id=39792 > > [wsimpson - Tue Jan 15 17:28:03 2008]: > > Jason Short wrote: > > I'd really like a savegame from which this can be reproduced. > > > What's wrong with the two existing savegames they've already provided? Indeed, I missed the first savegame. For some reason I thought it was the same as the second savegame which directly implies that it cannot be used to reproduce the problem. > Yes, it is triggered for ground units. Apparently, you're the one who > added the bad assert() because you didn't properly study the code. > > [I just didn't say so publicly until now. I was trying to be polite.] Obviously I'm the one who added the assert. It was intended to catch the situation where the invariant is broken. Which it has done. Nonetheless it was probably added by mistake as such checks are normally done with a CHECK_* macro (though that may not have been around back then) and it wasn't included in the last patch from RT. > I'm using the two savegames to test my work, and I'll post the patch > after they've been tested on both 2.1 and 2.2! Great, I'll leave you to it then. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40016) 2.1.2 assert - message pane after turn done
http://bugs.freeciv.org/Ticket/Display.html?id=40016 > On Jan 15, 2008 12:30 PM, William Allen Simpson <[EMAIL PROTECTED]> wrote: > > http://bugs.freeciv.org/Ticket/Display.html?id=40016 > > > Jason Short wrote: > > This is the same as 39991 which explains the cause. > > And had you actually read the ticket, you'd have seen the link. It's not > exactly the same, but they are related. Seriously man, I am getting incredibly frustrated at your snide remarks "go read the ticket" for every reply to a bug report. Yes, this bug is *exactly* the same as the first one reported in 39991. How else would I have known that except by reading the tickets? On a more constructive note, this can probably be solved by processing the GUI event queue right before clearing the messages list. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40020) AutoReply: Segfault in server code.
http://bugs.freeciv.org/Ticket/Display.html?id=40020 > You should probably kill stack of warriors with archer to trigger error. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40001) Update to catalan.ruleset for 2.1
http://bugs.freeciv.org/Ticket/Display.html?id=40001 > Perfect. :-) On Jan 14, 2008 10:46 PM, Joan Creus <[EMAIL PROTECTED]> wrote: > You're right. There you go. > > Joan > > 2008/1/15, [EMAIL PROTECTED] <[EMAIL PROTECTED] >: > > > > http://bugs.freeciv.org/Ticket/Display.html?id=40001 > > > > > On Jan 14, 2008 9:33 PM, Joan Creus <[EMAIL PROTECTED]> wrote: > > > So, last patch (for now) for catalan.ruleset in 2.1. > > > > > > Basically, it's the same as the current ruleset, with no translatable > > > strings changed, and: > > >[...] > > > > It's almost perfect. You forgot to add " (ocean)" to both Guardamar > cities. :-) > > > > > > -- > > Miguel Farah > > [EMAIL PROTECTED] > > > > > > > > -- Miguel Farah [EMAIL PROTECTED] ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40007) Crash when upgrading unit using Japanese language
http://bugs.freeciv.org/Ticket/Display.html?id=40007 > Jason Short wrote: > That means that the GTK library is using japanese correctly, but freeciv > is still using the untranslated strings. I have trouble with this > myself and aside from making sure you have gettext installed and linked > (use --enable-nls in your configure I believe) I'm not sure what else > needs to be done. > Yes. Glad to know I'm not the only one. I have. Perhaps Marko's recent undocumented changes (r14238) to configure.ac for 2.2 and trunk will fix the problem, but since he didn't make the change to 2.1, I've no way to test ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40016) 2.1.2 assert - message pane after turn done
http://bugs.freeciv.org/Ticket/Display.html?id=40016 > Jason Short wrote: > This is the same as 39991 which explains the cause. And had you actually read the ticket, you'd have seen the link. It's not exactly the same, but they are related. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39792) explore server assert
http://bugs.freeciv.org/Ticket/Display.html?id=39792 > Jason Short wrote: > I'd really like a savegame from which this can be reproduced. > What's wrong with the two existing savegames they've already provided? Perhaps you didn't actually read the report(s) Next time, please re-read the whole thread before replying to the last message. Yes, it is triggered for ground units. Apparently, you're the one who added the bad assert() because you didn't properly study the code. [I just didn't say so publicly until now. I was trying to be polite.] I'm using the two savegames to test my work, and I'll post the patch after they've been tested on both 2.1 and 2.2! Thank you (the bug reporters) for your patience. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40016) 2.1.2 assert - message pane after turn done
http://bugs.freeciv.org/Ticket/Display.html?id=40016 > This is the same as 39991 which explains the cause. The message click is being dequeued after the next turn has started, meaning the message list was already reset. So it tries to activate message 5 (say) but the message list is of length 0. There needs to either be a check for this case (including the turn # in the queued event, assuming the turn is incremented at the same time the message queue is cleared, and assuming that's even possible which in the GTK case it may not be), or we could allow it by tracking old messages (keeping a message queue for each turn, say, which could then be flipped through...and on the same note the message queue should be saved and stored at the server end then so it will come back after a game is reloaded). Although 3991 says this is a problem under GTK and SDL on further thought I'm dubious it could happen in the GTK event system. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40019) Feature Request: adjustable road movement multiplier
http://bugs.freeciv.org/Ticket/Display.html?id=40019 > Hello: REF: http://forum.freeciv.org/viewtopic.php?t=4113. Please consider making the road movement multiplier to be a ruleset-adjustable value, rather than hardcoded. This multiplier should probably affect river movement as well. I know that in Civ2, it could be changed in the rules.txt file. That was very convenient - it allowed finer tuning of unit movement rates for modpacks. For example, reducing the road movement multiplier to 2x or even 1x, and increasing terrain movement costs accordingly, you could have very slow units with only one move point, while still retaining the advantages of reduced movement for paved tiles (all movement between two tiles, both having roads, is reduced to 1/2 or 1, regardless of the underlying terrain move cost) and units with multiple movement points. And "rugged" terrain would still slow down most units. Or, you could speed things up by increasing the road movement multiplier to, say, 4x. Example: ruleset (effects.ruleset? game.ruleset? terrain.ruleset?) value of road movement multiplier (default 3) is changed to 1x for a modpack; terrain.ruleset is modified: flat terrain (grassland, plains, desert) move cost set to two, forest to 3-4, hills to 4, mountains/swamp/jungle to 5-6; units.ruleset is modified: slow units (slaves/workers, catapults) have one move point, standard units (most land units) have two move points, fast units have more (chariots and light/skirmishers 3, horsemen 4-5, etc.); across flat open terrain, then, any unit could move one tile, some two, others three (same as now); "rugged" terrain (forest, hills, etc.), however, would still slow down even fast-moving units (same as now) such that any land unit could only advance into only one mountain tile (same as now); on paved tiles however, some slow units would still only go one tile, most standard land units would now go two paved tiles, some fast units 3-4-5 or even more, as long as they stay on a road, and all regardless of the terrain type underlying the roads. As the rules stand, some units might be able to attack more than once - if they're very lucky and don't suffer much damage, and haven't moved yet. Now, they would have a much better chance of having one or more move points left after the first maneuver or attack to actually get in an extra attack at full strength (and therefore a reasonable chance of success), rather than being crippled by damage after the first charge (as is often now the case) or faced with only fractional move points remaining with which to attack, withdraw, or fortify. It is easy to see that the current movement scheme could be exactly duplicated by setting road multiplier to 1x, and simply increasing all unit move rates and terrain move costs by a factor of 3x; the only difference would then be that all units would automatically gain multiple-attack capability. In any case, it would be up to the modpack author to ensure that some units are flagged as "one attack per turn only" as desired (most standard land units currently fit this class, but do not require a flag to specify them as such). The game engine currently allows any unit with even a fractional movement point remaining, to move into another tile; it may be necessary to add a check to ensure that any unit, that can move at all, is allowed to move at least one tile per turn, regardless of the tile move cost. This change would have no direct effect on sea or air unit movement. Thanx and Regards, VJSchiavoni -- "I may detest what you say, but I will defend to the death your right to say it." EB Hall, "Friends of Voltaire", 1906 Hello: REF: http://forum.freeciv.org/viewtopic.php?t=4113. Please consider making the road movement multiplier to be a ruleset-adjustable value, rather than hardcoded. This multiplier should probably affect river movement as well. I know that in Civ2, it could be changed in the rules.txt file. That was very convenient - it allowed finer tuning of unit movement rates for modpacks. For example, reducing the road movement multiplier to 2x or even 1x, and increasing terrain movement costs accordingly, you could have very slow units with only one move point, while still retaining the advantages of reduced movement for paved tiles (all movement between two tiles, both having roads, is reduced to 1/2 or 1, regardless of the underlying terrain move cost) and units with multiple movement points. And "rugged" terrain would still slow down most units. Or, you could speed things up by increasing the road movement multiplier to, say, 4x. Example: ruleset (effects.ruleset? game.ruleset? terrain.ruleset?) value of road movement multiplier (default 3) is changed to 1x for a modpack; terrain.ruleset is modified: flat terrain (grassland, plains, desert) move cost set to two, forest to 3-4, hills to 4, mountains/swamp/jungle to 5-6; units.ruleset is modified: slow units (slaves/workers, catap
[Freeciv-Dev] (PR#39991) 2.1.1 GTK assert message pane after turn done + SDL future tech
http://bugs.freeciv.org/Ticket/Display.html?id=39991 >
I think neither of these bugs may be easy to solve.
> [EMAIL PROTECTED] - Sat Dec 29 03:13:49 2007]:
>
> Version: Freeciv 2.1.1
>
> Client crash bug 1: (SDL AND GTK)
>During the end-of-turn processing, you can still click on things on
> the
> screen. Have a long list on the message window from the last turn.
> Before
> this list is refreshed at the beginning of the next turn, double-click
> one of
> the messages near the bottom, which would normally take you to a city
> or unit.
> If the message list on the next turn is shorter, this will trigger an
> assertion
> failure. I think messages in the queue should be quietly discarded
> when the
> message window is cleared.
The queue is stored in the gtk events and I think there is no simple way
to discard it. A first step is to see what the assertion is and fix or
remove that. Long-term the solution may be to save all old messages
(previous turn's messages are useful to scroll back to...).
Can you tell us the assertion that is failing? Or even better, send a
backtrace after the crash?
> Client reporting bug 1: (SDL) - This appears to work as expected for
> GTK
>I have researched all tech and I am working on Future Tech. One of
> my units
> encounters a hut and the report is:
> Learned Future Tech 2. Researching Future Tech 3.
> You found Future Tech 3 in ancient scrolls of wisdom.
>I had been researching Future Tech 2. The research is now Future
> Tech 3.
> It looks like the second line is reporting one tech level too high.
>
> I have not tested these with version 2.1.2 yet.
This one is also not easy to fix properly, because giving a random tech
is an atomic function and because of the hackish way future techs work.
The function call is give_random_free_tech which picks and assigns the
text. On its return the tech name can be determined. But because the
future tech count has already been incremented by this time the name for
the tech will be wrong.
There are a couple not-as-easy ways this could be fixed. The attached
patch breaks up give_random_free_tech, removing it completely and
integrating its parts into the 2 callers. We can therefore get the name
before the tech is assigned.
An alternative would be passing a string pointer (char**) parameter to
give_random_free_tech. This could then fill in the tech name. This
doesn't lend itself to future techs as "Future tech %d" is not a string
already allocated. A second problem is with translation if multiple
translations are to be sent to the clients, or if they are to receive a
pre-translated version.
Yet a third alternative is to redesign the future-tech system to be more
sane. But I don't know what form this would take.
-jason
Index: server/unittools.c
===
--- server/unittools.c (revision 14241)
+++ server/unittools.c (working copy)
@@ -2152,22 +2152,26 @@
struct player *pplayer = unit_owner(punit);
Tech_type_id new_tech;
const char* tech_name;
-
- new_tech = give_random_free_tech(pplayer);
-
+
+ new_tech = pick_random_tech(pplayer);
+
tech_name = advance_name_for_player(pplayer, new_tech);
notify_player(pplayer, punit->tile, E_HUT_TECH,
_("You found %s in ancient scrolls of wisdom."),
tech_name);
- script_signal_emit("tech_researched", 3,
- API_TYPE_TECH_TYPE, &advances[new_tech],
- API_TYPE_PLAYER, pplayer,
- API_TYPE_STRING, "hut");
notify_embassies(pplayer, NULL, NULL, E_TECH_GAIN,
_("The %s have acquired %s"
" from ancient scrolls of wisdom."),
nation_plural_for_player(pplayer),
tech_name);
+
+ do_free_cost(pplayer, new_tech);
+ found_new_tech(pplayer, new_tech, FALSE, TRUE);
+
+ script_signal_emit("tech_researched", 3,
+ API_TYPE_TECH_TYPE, &advances[new_tech],
+ API_TYPE_PLAYER, pplayer,
+ API_TYPE_STRING, "hut");
}
/**
Index: server/techtools.c
===
--- server/techtools.c (revision 14241)
+++ server/techtools.c (working copy)
@@ -622,7 +622,7 @@
/
Gives a player random tech, which he hasn't researched yet.
- Returns the tech. This differs from give_random_free_tech - it doesn't
+ Returns the tech. This differs from give_immediate_free_tech - it doesn't
apply free cost
/
Tech_type_id give_random_initial_tech(struct player* pplayer)
@@ -784,27 +784,16 @@
}
/
- Gives a player random tech, which he hasn't researched yet. Applies freecost
- Returns the tech.
-/
-Tech_type_id give_
[Freeciv-Dev] (PR#40006) Placeholder strings like %d for gold amount isn't replaced
http://bugs.freeciv.org/Ticket/Display.html?id=40006 >
#: server/unittools.c:2143
#, c-format
msgid "You found %d gold."
msgstr "金%dを見つけました。"
static void hut_get_gold(struct unit *punit, int cred)
{
struct player *pplayer = unit_owner(punit);
notify_player(pplayer, punit->tile, E_HUT_GOLD,
_("You found %d gold."), cred);
pplayer->economic.gold += cred;
}
This is very bizarre and almost certainly the same as PR#40007. The
strings look fine (in PR#40007 also) and the code looks fine. There's a
very good chance it's caused by windows printf problems in combination
with utf-8. If that is the case, then there is a very good chance using
libutf8 (which has its own printf) would fix it. Use of libutf8 was
added in PR#12932 but removed in PR#36496, afaict. So if someone on
windows has the time, apply this patch and re-compile with
--with-libutf8=yes on your configure. If anyone can test this on other
platforms (or walk me through setting up locales, which have
mysteriously stopped working again) that would also be good.
-jason
Index: configure.ac
===
--- configure.ac (revision 14241)
+++ configure.ac (working copy)
@@ -372,6 +372,18 @@
AC_DEFINE_UNQUOTED(LOCALEDIR, "./share/locale", [Locale directory (windows)])
fi
+dnl Check libUTF8
+AC_ARG_WITH(libutf8,
+AC_HELP_STRING([--with-libutf8],
+ [Use the libutf8 library (needed for some systems)]),
+[with_libutf8=$withval], [with_libutf8=no])
+if test "$MINGW32" = yes || test "$with_libutf8" = yes; then
+ AC_CHECK_HEADER(libutf8.h, [],
+ AC_MSG_ERROR([Could not find libutf8 library (libutf8.h)]))
+ AC_DEFINE(HAVE_LIBUTF8_H, 1, [Use libutf8's stdio functions])
+ LIBS="$LIBS -lutf8"
+fi
+
dnl Check for zlib (needed for libpng)
AC_CHECK_LIB(z, gzgets, ,
AC_MSG_ERROR([Could not find zlib library.]), )
Index: utility/support.h
===
--- utility/support.h (revision 14241)
+++ utility/support.h (working copy)
@@ -26,6 +26,9 @@
#ifdef HAVE_SYS_TYPES_H
#include
#endif
+#ifdef HAVE_LIBUTF8_H
+#include
+#endif
#ifdef TRUE
#undef TRUE
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40007) Crash when upgrading unit using Japanese language
http://bugs.freeciv.org/Ticket/Display.html?id=40007 > On Jan 11, 2008 1:11 PM, William Allen Simpson <[EMAIL PROTECTED]> wrote: > > http://bugs.freeciv.org/Ticket/Display.html?id=40007 > > > Sounds like a fuzzy string translation that doesn't have the correct > number of c-format parameters, causing a memory access for a non-existent > pointer. I've already reported the general problem in PR#39970, and there > are other reported specific problems. > > Today, the 2.1.2+ ja.po has 121 fuzzy strings that need to be checked, 51 of > them are c-format, and another 210 untranslated strings. On a related note, has anyone used the po/check_po.pl program lately? It's not even set as executable in subversion. I can't recall ever using it before but I believe it was supposed to check c-format parameters. However running it now on even the most up-to-date po files gives massive errors. ./check_po.pl < de.po Oh and one other note, it is indeed possible that windows printf will crash with bad parameters while glibc or macos printf do not. Windows printf certainly crash if you try to %s a null string, while glibc printf will just insert "(null)" and keep on going. But I don't see how anyone can crash on a %d parameter no matter how bad it is. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
