Re: [Freeciv-Dev] (PR#39848) SDL client city_owner() compile error
http://bugs.freeciv.org/Ticket/Display.html?id=39848 >
Jason Dorje Short wrote:
> If I'm not mistaken the city_owner field was removed a few days ago.
No, it is a long-time existing access function. The problem here is that
my (PR#39841) string search and replace was confused by the annoying
camelcase and multiple levels of pointers, and my eyeballing misread it --
probably should be:
- if (pCityDlg->city_owner(pCity) != game.player_ptr) {
+ if (city_owner(pCityDlg->pCity) != game.player_ptr) {
> But nobody has compiled the SDL client since apparently.
>
While I do my best to make the appropriate changes to each gui, the coding
standards require that GTK be tested, and each other gui be addressed in a
separate patch as necessary.
Thank you for testing! MacOS Panther/Leopard users cannot compile sdl.
I'm working with the MacPorts developer on it
> Not sure if this affects other branches.
>
Blindly patching, untested.
Committed S2_1 revision 13928.
Committed S2_2 revision 13929.
Committed trunk revision 13930.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39849) strcasestr warning
http://bugs.freeciv.org/Ticket/Display.html?id=39849 > Jason Dorje Short wrote: > But, strcasestr is a nonstandard glibc extension. To be portable we > need to use mystrcasestr and have a configure-time check or just > implement it ourselves. Or avoid using it, of course. > Actually a standard BSD libc function, and in the standard required Linux glibc since time immemorial. But apparently not in cygwin. But since that's the only place used, I'll write a replacement later today, assuming you don't beat me to it. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > On Friday 09 November 2007 12:47 am, Jason Dorje Short wrote: > I have to agree with per that changing the borders system is an > unfortunately tricky problem. Having consistent/realistic/logical/fair > behavior in all cases may not really even be possible - I know that civ3 > and smac had just as many if not more border "goofs" than our current > system. If this is a step toward making freeciv more civ3-ish, I'd like to request that a means be kept to continue to have civ1 and civ2 like play. Randy Kramer ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > Jason Dorje Short wrote: > A triple-loop is also rather tedious (possibly too slow with a very > large number of old cities in the game). A simpler loop is possible if > we make border assignment context-based and impose the restraint that > borders can expand only one tile per turn. > Four (4) passes over the number of tiles, instead of one (1) pass over the cities? That's tedious? This is some new use of the word "tedious". What I found tedious was trying to read 900+ ->owner uses (in two branches simultaneously) to find the ones that were assignments instead of references In the computing point of view, by definition the number of cities is always less than the number of tiles, by orders of magnitude. The context-based borders are not "simpler" in any computational sense, because the execution is data dependent and therefore harder to debug! > iterate all tiles >iterate adjacent tiles > look at the owner source >mark tile for reassignment based on the highest factor > iterate all tiles >assign/reassign tile as marked > Wow, that's both slow *and* data intensive (another temporary variable per tile per player). But not as bad as the current code doing the adjacent tile search twice! > The hard question is what to do to a unit/fortress/city when the tile > under it gets reassigned. This part will end up being more coding > (though less argument) than the borders changes themselves. > No new code necessary. A unit reassigned converts to the new owner, attacks, or leaves. An occupied fortress cannot be reassigned. An unoccupied fortress has no border/vision of its own. A city cannot be reassigned. It *should* be able to be "converted", by proximity to a superior civilization, at which time it self-reassigns. > As a side note, I do think context-dependent borders are more stable > than context-independent ones. For instance with the above algorithm if > the factor (culture) formula was changed when you loaded an old game you > would find that borders changed to match the new formula, but did so > over several turns. > The context save first occurred in 2.1.0 two weeks ago, so there's not much in the way of "old" games that change over several turns. Any other savegame has to start from scratch. Vision in fits and starts with little carved out discontiguous blocks (see the picture) just isn't workable (and is annoying in practice). And I actively dislike the idea that buggy savegames won't be fixed until some gradual and unpredictable evolution That's what I'm trying to redesign. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > Randy Kramer wrote: > If this is a step toward making freeciv more civ3-ish, I'd like to request > that a means be kept to continue to have civ1 and civ2 like play. > That's part of the idea. The current code is not parameterized. (Per preferred one-size fits all -- "long wanted the game to leave its origins as a clone, emulator, and multiplayer hack of the commercial games it drew its inspiration from, and instead streamline the rules and interface to make it one, good single-player game.") ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > On 11/9/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: > I also examined the 467+ "->owner" [and 10 tile_get_owner] references in > 70 files. [Why, oh why, do folks not use the accessor functions?] And > fixed them! Not using accessor functions is not a bug, it is a feature. I would rather get rid of the pointless accessors than make them mandatory. But why are we discussion that in this thread? > with deterministic borders, the algorithm can be run on loading games, and not > be dependent on saving large tables. The size of the tile owner table in the savegame is not a problem. > > Another important constraint is that the border code should never take > > a tile from one player and give it to another. Once a tile is taken, > > it is *not* reassigned automatically by the borders code. > > Of course, this is one of the things I've already said I disagreed. One > of the excellent features of civ3 (for those of us who think this is more > than a shoot-em-up) is the cultural expansion of temple, library, etc. > Peaceful conversion! So the reason you want to change the current borders rules is because you want to turn this game into civ3? I think that is a really bad idea. > > ... You can also > > never take ownership of land underneath the feet of non-allied units. > > Seems reasonable. A novel way of preventing border expansion, until the > units move Saw that in the code. This is of course not compatible with civ3-like cultural borders. > > This removes a lot of complications that tie in with the diplomacy and > > unit rules. For example, what happens if you are in a peace treaty, > > and suddenly the borders shift underneath your carefully built > > defensive line of units? > > > That's a feature! In civ3, you are sent a message, and allowed a turn to > move without an implied declaration of war. Then you run into another constraint that the new borders/diplomacy code is based on: Never assume that the user reads messages. The way that messages are implemented in Freeciv, and perhaps must be implemented in order to have a semblance of real-time multiplayer, you cannot make such an assumption, because you cannot throw a modal click-me-to-remove dialog at the player with the message. I think that in order to do what you want to accomplish with the borders code, you also need to change how diplomacy works, and how messaging works. If you intend to make carbon copies from civ3 in these areas too, I think you will be removing most of what is original about Freeciv's rules. And I think that would be really sad. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > On Friday 09 November 2007 07:44 am, William Allen Simpson wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39845 > > Randy Kramer wrote: > > If this is a step toward making freeciv more civ3-ish, I'd like to request > > that a means be kept to continue to have civ1 and civ2 like play. > > > That's part of the idea. Good--thanks! Randy Kramer ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > On Thu, 8 Nov 2007 William Allen Simpson wrote: > Egor Vyscrebentsov wrote: > > Does this mean that there will never be other source than city? > > (I can't see place for fortresses in this algorithm.) > > Even in the current code, the test for cities and fortresses et alia is > in the same place. To me the main difference (in results) of your algorithm is that it doesn't fill all tiles (all border sources, if be more accurate.) Current code doesn't require city to be the source of border in tile where the fortress stays. Maybe there can be other iterator than city, say border_sources_iterator. (where border_source is union, for example.) [I understand that this has its own contras.] > > Can influence function be scriptable? > > Probably. But since that would slow it down to a crawl, I'm not sure > anybody would desire it. I know that I want too much :) But what I really want is that the code will support idea that this function _may_ become scriptable _someday_ and will not require massive rewriting when/if this day will come. -- Thanks, evyscr ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39849) strcasestr warning
http://bugs.freeciv.org/Ticket/Display.html?id=39849 >
Naive trunk implementation:
Index: utility/support.c
===
--- utility/support.c (revision 13930)
+++ utility/support.c (working copy)
@@ -156,6 +156,40 @@
}
/***
+ Return the needle in the haystack (or NULL).
+ Naive implementation.
+***/
+char *mystrcasestr(const char *haystack, const char *needle)
+{
+#ifdef HAVE_STRCASESTR
+ return strcasestr(haystack, needle);
+#else
+ size_t haystacks;
+ size_t needles;
+ const char *p;
+
+ if (NULL == needle || '\0' == *needle) {
+return (char *)haystack;
+ }
+ if (NULL == haystack || '\0' == *haystack) {
+return NULL;
+ }
+ haystacks = strlen(haystack);
+ needles = strlen(needle);
+ if (haystacks < needles) {
+return NULL;
+ }
+
+ for (p = haystack; p <= &haystack[haystacks - needles]; p++) {
+if (0 == mystrncasecmp(p, needle, needles)) {
+ return (char *)p;
+}
+ }
+ return NULL;
+#endif
+}
+
+/***
Return a string which describes a given error (errno-style.)
***/
const char *mystrerror(void)
Index: utility/support.h
===
--- utility/support.h (revision 13930)
+++ utility/support.h (working copy)
@@ -74,6 +74,8 @@
int mystrncasecmp(const char *str0, const char *str1, size_t n);
int mystrncasequotecmp(const char *str0, const char *str1, size_t n);
+char *mystrcasestr(const char *haystack, const char *needle);
+
const char *mystrerror(void);
void myusleep(unsigned long usec);
Index: server/ruleset.c
===
--- server/ruleset.c(revision 13930)
+++ server/ruleset.c(working copy)
@@ -2286,7 +2286,7 @@
* Note that the section name is unique (by definition).
* The sub-strings are carefully crafted for this function.
*/
- if (NULL != strcasestr(isection, name)) {
+ if (NULL != mystrcasestr(isection, name)) {
city_names[j].terrain[i] = setting;
handled = TRUE;
break;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > William Allen Simpson wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39845 > > > Jason Dorje Short wrote: >> A triple-loop is also rather tedious (possibly too slow with a very >> large number of old cities in the game). A simpler loop is possible if >> we make border assignment context-based and impose the restraint that >> borders can expand only one tile per turn. >> > Four (4) passes over the number of tiles, instead of one (1) pass over > the cities? That's tedious? > > This is some new use of the word "tedious". What I found tedious was > trying to read 900+ ->owner uses (in two branches simultaneously) to find > the ones that were assignments instead of references > > In the computing point of view, by definition the number of cities is > always less than the number of tiles, by orders of magnitude. Perhaps. But consider the worst case, where there are a large number of high-culture that are spaced closely together (is there a limit to how far city influence can extend?). In this case you could end up iterating over every tile many, many times. And this case, rare as it is, is exactly the one that we should be concerned about since maps with no cities have no problem with computation time anyway. Oh and by "tedious" I meant for the CPU, not the coder. Bad choice of word perhaps. > The context-based borders are not "simpler" in any computational sense, > because the execution is data dependent and therefore harder to debug! Ya. >> The hard question is what to do to a unit/fortress/city when the tile >> under it gets reassigned. This part will end up being more coding >> (though less argument) than the borders changes themselves. >> > No new code necessary. > > A unit reassigned converts to the new owner, attacks, or leaves. So you give the unit one turn to attack or leave or it gets converted on the following turn? What if it is entirely surrounded by the newly-claimed non-allied tiles and cannot get away in time? Is that going to be a common scenario? > An occupied fortress cannot be reassigned. An unoccupied fortress has > no border/vision of its own. > > A city cannot be reassigned. It *should* be able to be "converted", by > proximity to a superior civilization, at which time it self-reassigns. Can a fortress be converted? > Vision in fits and starts with little carved out discontiguous blocks > (see the picture) just isn't workable (and is annoying in practice). Somehow I missed seeing the picture. But if you're talking about granting vision to everything within borders, it follows that you want contiguous borders, yes. How will your system deal with ocean? Is that just included in the factor() function that assigns tile influence based on the city's culture? > And I actively dislike the idea that buggy savegames won't be fixed until > some gradual and unpredictable evolution > > That's what I'm trying to redesign. Okay. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > Egor Vyscrebentsov wrote: > Maybe there can be other iterator than city, say border_sources_iterator. > (where border_source is union, for example.) [I understand that this has > its own contras.] > I've not been sufficiently clear. The code that I already checked in has cities (positive identity), fortresses, airports, etc. (negative identity). Same stub structure (vision_base). Probably same iterator! > I know that I want too much :) But what I really want is that the code > will support idea that this function _may_ become scriptable _someday_ > and will not require massive rewriting when/if this day will come. > Sure. Good design criteria. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
http://bugs.freeciv.org/Ticket/Display.html?id=39845 > William Allen Simpson wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39845 > > > Randy Kramer wrote: >> If this is a step toward making freeciv more civ3-ish, I'd like to request >> that a means be kept to continue to have civ1 and civ2 like play. >> > That's part of the idea. The current code is not parameterized. > > (Per preferred one-size fits all -- "long wanted the game to leave its > origins as a clone, emulator, and multiplayer hack of the commercial > games it drew its inspiration from, and instead streamline the rules > and interface to make it one, good single-player game.") Some sort of balance is needed that gives decent rule flexibility without the huge proliferation of options that is overwhelming for users and never get tested enough for coders to keep them current. For borders you don't have to worry though: the option of just turning off borders should always be present and is what civ1/civ2 do. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39849) strcasestr warning
http://bugs.freeciv.org/Ticket/Display.html?id=39849 >
William Allen Simpson wrote:
> http://bugs.freeciv.org/Ticket/Display.html?id=39849 >
>
> Naive trunk implementation:
Naive is fine but you forgot to add the check to configure.ac. Attached
patch does that.
But now it still won't compile, and I don't understand why.
if gcc -DHAVE_CONFIG_H -I. -I. -I..
-DLOCALEDIR="\"/usr/local/share/locale\""
-DDEFAULT_DATA_PATH="\".:data:~/.freeciv:/usr/local/share/freeciv\"" -g
-O0 -Wall -Werror -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -MT support.o -MD -MP -MF ".deps/support.Tpo" -c
-o support.o support.c; \
then mv -f ".deps/support.Tpo" ".deps/support.Po"; else rm -f
".deps/support.Tpo"; exit 1; fi
cc1: warnings being treated as errors
support.c: In function 'mystrcasestr':
support.c:167: warning: implicit declaration of function 'strcasestr'
support.c:167: warning: return makes pointer from integer without a cast
Of course I have strcasestr, it's detected properly so HAVE_STRCASESTR
is defined. The function is in string.h which is properly included.
Yet in compiling the prototype is apparently not being included.
This is on debian testing.
-jason
Index: utility/support.c
===
--- utility/support.c (revision 13930)
+++ utility/support.c (working copy)
@@ -156,6 +156,40 @@
}
/***
+ Return the needle in the haystack (or NULL).
+ Naive implementation.
+***/
+char *mystrcasestr(const char *haystack, const char *needle)
+{
+#ifdef HAVE_STRCASESTR
+ return strcasestr(haystack, needle);
+#else
+ size_t haystacks;
+ size_t needles;
+ const char *p;
+
+ if (NULL == needle || '\0' == *needle) {
+return (char *)haystack;
+ }
+ if (NULL == haystack || '\0' == *haystack) {
+return NULL;
+ }
+ haystacks = strlen(haystack);
+ needles = strlen(needle);
+ if (haystacks < needles) {
+return NULL;
+ }
+
+ for (p = haystack; p <= &haystack[haystacks - needles]; p++) {
+if (0 == mystrncasecmp(p, needle, needles)) {
+ return (char *)p;
+}
+ }
+ return NULL;
+#endif
+}
+
+/***
Return a string which describes a given error (errno-style.)
***/
const char *mystrerror(void)
Index: utility/support.h
===
--- utility/support.h (revision 13930)
+++ utility/support.h (working copy)
@@ -74,6 +74,8 @@
int mystrncasecmp(const char *str0, const char *str1, size_t n);
int mystrncasequotecmp(const char *str0, const char *str1, size_t n);
+char *mystrcasestr(const char *haystack, const char *needle);
+
const char *mystrerror(void);
void myusleep(unsigned long usec);
Index: configure.ac
===
--- configure.ac (revision 13930)
+++ configure.ac (working copy)
@@ -607,7 +607,7 @@
AC_CHECK_FUNCS([fileno ftime gethostname getpwuid inet_aton \
select snooze strerror strcasecmp strncasecmp \
- strlcat strlcpy strstr usleep uname flock \
+ strcasestr strlcat strlcpy strstr usleep uname flock \
gethostbyname connect bind])
AC_MSG_CHECKING(for working gettimeofday)
Index: server/ruleset.c
===
--- server/ruleset.c (revision 13930)
+++ server/ruleset.c (working copy)
@@ -2286,7 +2286,7 @@
* Note that the section name is unique (by definition).
* The sub-strings are carefully crafted for this function.
*/
- if (NULL != strcasestr(isection, name)) {
+ if (NULL != mystrcasestr(isection, name)) {
city_names[j].terrain[i] = setting;
handled = TRUE;
break;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39850) Huts cause crash on 1st turn of second game
http://bugs.freeciv.org/Ticket/Display.html?id=39850 > On Windows Vista (fully updated), latest SDL client of Freeciv, Freeciv will dependably crash if the follow steps are taken: 1. Install Freeciv 2. Run civclient.exe 3. Select "Start New Game" 4. Hit "Start" 5. When the game starts, move a unit in the same territory as a hut. 6. Hit Esc, then select "Leave game" 7. Repeat steps 3 and 4 7. End the turn Freeciv crashes. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39849) strcasestr warning
http://bugs.freeciv.org/Ticket/Display.html?id=39849 > Jason Dorje Short wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39849 > > > William Allen Simpson wrote: >> http://bugs.freeciv.org/Ticket/Display.html?id=39849 > >> >> Naive trunk implementation: > > Naive is fine but you forgot to add the check to configure.ac. Attached > patch does that. > > But now it still won't compile, and I don't understand why. Still strange. Delving into the preprocessor, if I just throw a -E on to the above line the resulting file has no prototype for the function at all. Yet it is clearly present in the header, surrounded by #ifdef __USE_GNU which is presumably being left undefined somehow in compilation while it was defined properly during the configure check. I suppose I could upload my string.h if anyone has any bright ideas. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39849) strcasestr warning
http://bugs.freeciv.org/Ticket/Display.html?id=39849 > Jason Dorje Short wrote: >> Naive is fine but you forgot to add the check to configure.ac. Attached >> patch does that. >> I didn't forget; that ensured my new code was compiled and tested > ... Yet it is > clearly present in the header, surrounded by #ifdef __USE_GNU which is > presumably being left undefined somehow in compilation while it was > defined properly during the configure check. > My guess is that the wrong string.h (or strings.h) is included. We've been having problems with includes for some time. I have posted various reports about it (PR#39403 still open, though I haven't tested it recently). Like you, I was having similar problems with the faculty present during configure check, but not during compile. Marko was poking at them last. Since your original report turns out to be fixed by my patch, and it will fix cygwin systems, and we've both verified it works correctly without the configure.ac check, I'll commit it. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
