[Freeciv-Dev] (PR#39844) Re: Freeciv not working in Mac OS X 1.5 (Leopard)

http://bugs.freeciv.org/Ticket/Display.html?id=39844 >

Sorry, added to the wrong queue i think...

Too trigger happy with the enter key...

Can this be moved to general?

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39840) Re: 2.2/trunk changing production doesn't work

http://bugs.freeciv.org/Ticket/Display.html?id=39840 >

> [wsimpson - Wed Nov 07 20:27:40 2007]:
> 
>   wrote:
> > This transaction appears to have no content
> > 
> Really need more explanation.
> 
> And there's something wrong with the From: "" <> -- how did you submit
> this report?

I submitted as guest

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39844) Re: Freeciv not working in Mac OS X 1.5 (Leopard)

http://bugs.freeciv.org/Ticket/Display.html?id=39844 >

Thankyou!

I am just about to have a go, i'm pretty new to this aspect of Mac OS (I use 
the systems at work, 
textmate etc) so forgive me if i ask stupid questions!

I will update shortly.

Thanks.

:)

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39840) Re: 2.2/trunk changing production doesn't work

http://bugs.freeciv.org/Ticket/Display.html?id=39840 >

> [wsimpson - Wed Nov 07 21:41:39 2007]:
> 
> Looking at the code around your tiny patch, the return is very *much*
> wanted.  Otherwise, you'd try to add a bad entry to the worklist.  But,
> when I added error logging in PR#39827, I accidentally inserted the return
> one line too low.  Thanks, anyway!
> 
> Committed S2_2 revision 13922.
> Committed trunk revision 13923.

Ya, so this means there were 2 bugs :)

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39844) Re: Freeciv not working in Mac OS X 1.5 (Leopard)

http://bugs.freeciv.org/Ticket/Display.html?id=39844 >

Ok, it's taken me a little while, but i've got it working after using 
macports...
The first time I installed it the client said unable to connect/make server, 
but it seems to be 
working this time! woohoo!

I haven't figured out the tilesets and stuff yet, but i'll leave that for the 
time being...

I'll keep checking back for updates, but thanks for your response anyway :)

I only wanted something to play on while i'm sick in bed! lol

Good luck and thanks for your work on the project (that's to all who've 
contributed!)

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39840) Re: 2.2/trunk changing production doesn't work

[Daniel Markstedt]

http://bugs.freeciv.org/Ticket/Display.html?id=39840 >

On 11/8/07,  <> wrote:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=39840 >
>
> > [wsimpson - Wed Nov 07 20:27:40 2007]:
> >
> >   wrote:
> > > This transaction appears to have no content
> > >
> > Really need more explanation.
> >
> > And there's something wrong with the From: "" <> -- how did you submit
> > this report?
>
> I submitted as guest
>

If you want to be credited as bug reporter, please sign your reports. =)

 ~Daniel



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39844) Freeciv not working in Mac OS X 1.5 (Leopard)

http://bugs.freeciv.org/Ticket/Display.html?id=39844 >

Hi there,

I hope this hasn't been raised as a ticket already but when i try to run the 
binary of freeciv 
2.1.0 (or 2.0.9 for that matter) it comes up with the primary menu where you 
can select the 
tilesets and language) but when i click to start an xTerm is produced and the 
freeciv 
application exits.
Apologies if this has been fixed and I haven't found out where!

I have installed X11 and the Xcode add-ons from the CD but to no avail...
I have used your project on windows with no problems and would love to get it 
working on 
my new shiny mac :D

If there is anything i can do to help (more verbose errors, test new builds), 
please let me 
know.

Thanks in advance,

Dom

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39844) Re: Freeciv not working in Mac OS X 1.5 (Leopard)

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39844 >

> Can this be moved to general?
> 
Done.

Sadly, a number of things broke with Leopard.  Another example is that
libsdl won't compile with any QuickTime >7.0.3 -- and we're up to 7.3!

Such things are out of our control, but this can track progress

Have you tried compiling with latest XCode?



___
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

[Per I. Mathisen]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

On 11/8/07, William Allen Simpson <[EMAIL PROTECTED]> wrote:
> One of the difficulties encountered trying to add vision to borders: the
> current algorithm for borders is non-deterministic and context based,
> relying on a history (the previous turn iteration).
>
> Instead, I propose a deterministic algorithm, based on static data such
> as city turn_founded and a (configurable) multiplier.

Any larger change to the borders code will have large repercussions on
other parts of the code, especially diplomacy and movement.

There is a lot of thought and debate behind the current design, and
not all of the constraints that shaped it may be immediately obvious.
I would suggest that before you change it, at least post the design
you have come up with here for discussion.

  - Per



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39841) Cleanup city, unit, and tile accessor functions for *_owner (and others)

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39841 >

Committed S2_1 revision 13925.
Committed S2_2 revision 13926.
Committed trunk revision 13927.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39846) FreeCiv RT account

[Tautvydas Andrikys]

http://bugs.freeciv.org/Ticket/Display.html?id=39846 >

Hi,

I would like to get FreeCiv bug tracker account with login: esminis

create password for me, ill change it later.

Thanks

-- 
Pagarbiai,
Tautvydas Andrikys aka esminis 
www.esminis.lt 
www.bajeriai.lt 



___
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

[Per I. Mathisen]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

I would suggest that you hunt down some of the old discussions and
read them before embarking on this. There are lots of constraints
involved here, and I may not remember them all.

The single most important reason why I rewrote the original borders
code and made the current one was so that it would run only on turn
end, instead of during the turn as did the previous code. This removes
a ton of complications, and I would strongly suggest that you do not
change this design parameter.

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. You can also
never take ownership of land underneath the feet of non-allied units.
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?

I suggest you change these rules only with great care and careful consideration.

  - 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

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

Per I. Mathisen wrote:
> I would suggest that before you change it, at least post the design
> you have come up with here for discussion.
> 
That's what this RFE thread is for  In pseudo-code:

iterate players
   iterate cities
 set cultural influence (probably game.turn - turn_built)
 iterate circle
   determine distance factors
   if factor(this) > factor(existing->source)
 replace owner and source

Simple.  No need to transfer ownership between closer cities.  That
happens automatically by distance factor.  Replaces loops 1, 2 & 4.

This algorithm will be much better at importing older versions and other
saved games.  It's easy to tailor to civ1/2/3 behavior.

Removing ownership should happen in the destroy city code at the same
place that vision is updated.  At turn end, this algorithm may replace
any unclaimed tiles with the next best owner.  One of the problems with
loop 3 is that there's no visual confirmation at the time of city owner
change -- it currently doesn't happen until the next turn!

Another idea is to use the same *vision_base and algorithm for fortresses
and airports (and future civ3-like radar outposts or what-have-you).

One constraint is the tile owner in handle_tile_info(); for compatibility
with existing clients, nothing more sophisticated is allowed.  This meets
that constraint.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39842) rulesetdir in already started game, gui-gtk-2.0 and nation_of_player/bounds_check_nation

[Egor Vyscrebentsov]

http://bugs.freeciv.org/Ticket/Display.html?id=39842 >

On Wed, 7 Nov 2007 12:56:25 -0800 Egor Vyscrebentsov wrote:

> Good daytime!
>
> branches/s2_1, r13919
>
> Start a game, say 'read civ2.serv' while game is already started and see
> gui-gtk segfault... Say 'quit' and see segfault of civserver...

Not gtk2-specific, but common client problem, of course.

> Reason: nations are already freed when nation_of_player() is called.
> And both nation_of_player() and bounds_check_nation() don't check for
> nation is NULL.

Attached patch makes civ{server,client} at least show an error rather
than segfaulting.

> Questions:
> 1. Why 'rulesetdir' isn't disallowed in already started game?

Still need an answer. Since several settings with similar effect are
disallowed during the game, this command should be disallowed too.

And I think this is a core of current bug, but it will be nice if our
functions will work even with wrong parameters at input.

> 2. How to fix usage of nation_of_player()? [ie, what way is better?]

More hard question. Now this function call die() if bounds check
is not passed. I'm not sure that this is right reaction in all ways.
Maybe there could be a parameter, say 'allow_null_nation', that will
has default value FALSE? Or we are sure that there is no and will be
no variants when nation may absent? (I don't know yet how this work
with observers.)

Any thoughts?

> 3. Is there a reason not to have a check in bounds_check_nation()?

Ok, no reason, I guess. Added in patch, returns FALSE.

PS. Message "This setting can't be modified after the game has started."
looks badly than "Setting '%s' can't be modified ..." when loading
.serv file (since command doesn't shown).

-- 
Thanks, evyscr

Index: common/nation.c
===
--- common/nation.c	(revision 13921)
+++ common/nation.c	(working copy)
@@ -49,6 +49,10 @@
 freelog(loglevel, "%s before nations setup", func_name);
 return FALSE;
   }
+  if (!pnation) {
+freelog(loglevel, "%s error: nation is NULL", func_name);
+return FALSE;
+  }
   if (pnation->index < 0
   || pnation->index >= game.control.nation_count
   || &nations[pnation->index] != pnation) {
@@ -252,7 +256,11 @@
 {
   assert(plr != NULL);
   if (!bounds_check_nation(plr->nation, LOG_FATAL, "nation_of_player")) {
-die("wrong nation %d", plr->nation->index);
+if (plr->nation) {
+  die("wrong nation %d", plr->nation->index);
+} else {
+  die("wrong nation: null nation");
+}
   }
   return plr->nation;
 }
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39840) Re: 2.2/trunk changing production doesn't work

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39840 >

Daniel Markstedt wrote:
> If you want to be credited as bug reporter, please sign your reports. =)
> 
Heck -- if you want the reports to be seen, please sign your reports.
Otherwise, they are automatically classed as junk.  I try to clear out my
junk each day (I get about a thousand), but I'm sure I cannot notice every
one that should be saved



___
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

[Egor Vyscrebentsov]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

On Thu, 8 Nov 2007 William Allen Simpson wrote:

> iterate players
>iterate cities
>  set cultural influence (probably game.turn - turn_built)
>  iterate circle
>determine distance factors
>if factor(this) > factor(existing->source)
>  replace owner and source
>
> Simple.  No need to transfer ownership between closer cities.  That
> happens automatically by distance factor.  Replaces loops 1, 2 & 4.

Does this mean that there will never be other source than city?
(I can't see place for fortresses in this algorithm.)
Can influence function be scriptable?

On Thu, 8 Nov 2007 Per I. Mathisen wrote:

> I would suggest that you hunt down some of the old discussions and
> read them before embarking on this. There are lots of constraints
> involved here, and I may not remember them all.

Are they from RT time or earlier? (If first, it would be nice if there
will be META: ticket about borders (I can't find one now) with linking
to them.)

Am I right that most information about current behavior is in #13718?

> The single most important reason why I rewrote the original borders
> code and made the current one was so that it would run only on turn
> end, instead of during the turn as did the previous code. This removes
> a ton of complications, and I would strongly suggest that you do not
> change this design parameter.

Can you suggest some words to search original messages (with problems
descriptions)? Mine were ineffective and gave ~nothing...

> 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. You can also
> never take ownership of land underneath the feet of non-allied units.
> 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?

Good question. But I'm not sure that the only answer to it is "should
never take." However, with our current diplomacy this solution seems to
be one of the best (if not the only.)

> I suggest you change these rules only with great care and careful
> consideration.

Agree, of course.

-- 
Thanks, evyscr



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39817) goto interrupted by sentry

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39817 >

Apparently, I forgot to attach the patch  Here's S2_2 at the
current revision:

Index: client/control.c
===
--- client/control.c(revision 13927)
+++ client/control.c(working copy)
@@ -50,14 +50,17 @@
 /* gui-dep code may adjust depending on tile size etc: */
 int num_units_below = MAX_NUM_UNITS_BELOW;
 
-/* unit_focus points to the current unit in focus */
-static struct unit_list *pfocus_units;
+/* current_focus points to the current unit(s) in focus */
+static struct unit_list *current_focus;
 
-/* The previously focused unit.  Focus can generally be recalled on this
- * unit with keypad 5.  FIXME: this is not reset when the client
- * disconnects. */
+/* The previously focused unit(s).  Focus can generally be recalled
+ * with keypad 5 (or the equivalent). 
+ * FIXME: this is not reset when the client disconnects. */
 static struct unit_list *previous_focus;
 
+/* The priority focused unit(s). */
+static struct unit_list *priority_focus;
+
 /* These should be set via set_hover_state() */
 enum cursor_hover_state hover_state = HOVER_NONE;
 struct tile *hover_tile = NULL;
@@ -83,9 +86,8 @@
 /*/
 
 static struct unit *find_best_focus_candidate(bool accept_current);
-static void store_focus(void);
 static struct unit *quickselect(struct tile *ptile,
-enum quickselect_type qtype);
+enum quickselect_type qtype);
 
 /**
   Called only by main() in client/civclient.c.
@@ -96,8 +98,11 @@
 
   caravan_arrival_queue = genlist_new();
   diplomat_arrival_queue = genlist_new();
-  pfocus_units = unit_list_new();
+
+  current_focus = unit_list_new();
   previous_focus = unit_list_new();
+  priority_focus = unit_list_new();
+
   for (i = 0; i < MAX_NUM_BATTLEGROUPS; i++) {
 battlegroups[i] = unit_list_new();
   }
@@ -112,14 +117,55 @@
 
   genlist_free(caravan_arrival_queue);
   genlist_free(diplomat_arrival_queue);
-  unit_list_free(pfocus_units);
+
+  unit_list_free(current_focus);
   unit_list_free(previous_focus);
+  unit_list_free(priority_focus);
+
   for (i = 0; i < MAX_NUM_BATTLEGROUPS; i++) {
 unit_list_free(battlegroups[i]);
   }
 }
 
 /**
+...
+**/
+struct unit_list *get_units_in_focus(void)
+{
+  return current_focus;
+}
+
+/
+  Return the number of units currently in focus (0 or more).
+/
+int get_num_units_in_focus(void)
+{
+  return unit_list_size(current_focus);
+}
+
+/**
+  Store the focus unit(s).  This is used so that we can return to the
+  previously focused unit with an appropriate keypress.
+**/
+static void store_previous_focus(void)
+{
+  if (get_num_units_in_focus() > 0) {
+unit_list_unlink_all(previous_focus);
+unit_list_iterate(get_units_in_focus(), punit) {
+  unit_list_append(previous_focus, punit);
+} unit_list_iterate_end;
+  }
+}
+
+/
+  Store a priority focus unit.
+/
+void urgent_unit_focus(struct unit *punit)
+{
+  unit_list_append(priority_focus, punit);
+}
+
+/**
   Called when a unit is killed; this removes it from the control lists.
 **/
 void control_unit_killed(struct unit *punit)
@@ -127,12 +173,16 @@
   int i;
 
   goto_unit_killed(punit);
+
   unit_list_unlink(get_units_in_focus(), punit);
   if (get_num_units_in_focus() < 1) {
 set_hover_state(NULL, HOVER_NONE, ACTIVITY_LAST, ORDER_LAST);
   }
   update_unit_info_label(get_units_in_focus());
+
   unit_list_unlink(previous_focus, punit);
+  unit_list_unlink(priority_focus, punit);
+
   for (i = 0; i < MAX_NUM_BATTLEGROUPS; i++) {
 unit_list_unlink(battlegroups[i], punit);
   }
@@ -216,7 +266,7 @@
 /
 struct unit *head_of_units_in_focus(void)
 {
-  return unit_list_get(pfocus_units, 0);
+  return unit_list_get(current_focus, 0);
 }
 
 /
@@ -249,6 +299,28 @@
 }
 
 /**
+  ...
+

Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

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.


> Can influence function be scriptable?
> 
Probably.  But since that would slow it down to a crawl, I'm not sure
anybody would desire it.


> Can you suggest some words to search original messages (with problems
> descriptions)? Mine were ineffective and gave ~nothing...
> 
Yeah, I wasn't very successful with RT, I searched the mail archives.

I'll stick some "refers to" in the ticket tomorrow.  G'night!



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39847) Crash on build new city

http://bugs.freeciv.org/Ticket/Display.html?id=39847 >

I downloaded the latest version win32 package, installed it, started a
game with all defaults, and ended up playing as Sweden.  When i built my
third city (Stockholm, i think it was), the client crashed right after i
clicked the button.

I run Windows XP with all updates on a centrino laptop with 1.5 GB RAM
and Radeon 9600 Mobility graphics.

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39847) Crash on build new city

[Daniel Markstedt]

http://bugs.freeciv.org/Ticket/Display.html?id=39847 >

On 11/9/07,  <> wrote:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=39847 >
>
> I downloaded the latest version win32 package, installed it, started a
> game with all defaults, and ended up playing as Sweden.  When i built my
> third city (Stockholm, i think it was), the client crashed right after i
> clicked the button.
>
> I run Windows XP with all updates on a centrino laptop with 1.5 GB RAM
> and Radeon 9600 Mobility graphics.
>

Is that the win32-gtk2, win32-sdl, or just plain win32?

Oh, and if you post as guest, please sign your reports. Otherwise we
don't know who to credit for a bug report and it also risks getting
ignored as junk mail.

 ~Daniel



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39846) FreeCiv RT account

[Daniel Markstedt]

http://bugs.freeciv.org/Ticket/Display.html?id=39846 >

On 11/9/07, Tautvydas Andrikys <[EMAIL PROTECTED]> wrote:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=39846 >
>
> Hi,
>
> I would like to get FreeCiv bug tracker account with login: esminis
>
> create password for me, ill change it later.
>
> Thanks
>
> --
> Pagarbiai,
> Tautvydas Andrikys aka esminis 
> www.esminis.lt 
> www.bajeriai.lt 
>
>

Hi Tautvydas,

Thanks for your interest in Freeciv! The preferred way to use RT is
through the email interface. If you want a personal account, you'd
have to give a good reason why one is absolutely neccessary for you.

Kind regards,
Daniel



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39848) S2_1 SDL client compile error

[Jason Dorje Short]

http://bugs.freeciv.org/Ticket/Display.html?id=39848 >

citydlg.c: In function 'create_present_supported_units_widget_list':
citydlg.c:745: error: 'struct city_dialog' has no member named 'city_owner'
citydlg.c:745: error: 'pCity' undeclared (first use in this function)
citydlg.c:745: error: (Each undeclared identifier is reported only once
citydlg.c:745: error: for each function it appears in.)
citydlg.c: In function 'next_prev_city_dlg_callback':
citydlg.c:1608: error: 'struct city_dialog' has no member named 'city_owner'
citydlg.c:1608: error: 'pCity' undeclared (first use in this function)
citydlg.c: In function 'redraw_supported_units_city_dialog':
citydlg.c:1765: error: 'struct city_dialog' has no member named 'city_owner'
citydlg.c: In function 'redraw_army_city_dialog':
citydlg.c:1823: error: 'struct city_dialog' has no member named 'city_owner'

If I'm not mistaken the city_owner field was removed a few days ago.
But nobody has compiled the SDL client since apparently.

Not sure if this affects other branches.

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39849) strcasestr warning

[Jason Dorje Short]

http://bugs.freeciv.org/Ticket/Display.html?id=39849 >

ruleset.c: In function 'load_city_name_list':
ruleset.c:2289: warning: implicit declaration of function 'strcasestr'
ruleset.c:2289: warning: comparison between pointer and integer

Now I'm not sure why I get this warning, since string.h is included and 
that should contain strcasestr.  Perhaps I have some -pedantic parameter 
or something.

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.

-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

[William Allen Simpson]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

Per I. Mathisen wrote:
> I would suggest that you hunt down some of the old discussions and
> read them before embarking on this. There are lots of constraints
> involved here, and I may not remember them all.
> 
Thank you, as part of my research, I looked at all 300+ list messages
over the past 2 years (since I joined) with the word "border" in them.
Such as PR#13718, PR#14548, PR#14589, PR#14982, PR#15169, PR#17163, and
others that carried over

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!


> The single most important reason why I rewrote the original borders
> code and made the current one was so that it would run only on turn
> end, instead of during the turn as did the previous code. This removes
> a ton of complications, and I would strongly suggest that you do not
> change this design parameter.
> 
Wasn't planning on it, but with deterministic borders, the algorithm can
be run on loading games, and not be dependent on saving large tables.


> 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!

And of course, civ4 rather celebrated the use of the "culture bomb"
(using special leaders).


> ... 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 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.


> I suggest you change these rules only with great care and careful 
> consideration.
> 
Sure.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39846) FreeCiv RT account

[Tautvydas Andrikys]

http://bugs.freeciv.org/Ticket/Display.html?id=39846 >

I want account couse i have already reported some bugs as guest and will 
report some bugs or features later, ussually with patches.

Maybe later I will join dev team as ocasional developer.

One more thing i have to say that code is really hard to read, maybe 
couse I ussually do OO, not functional way.

Daniel Markstedt wrote:
>
> Hi Tautvydas,
>
> Thanks for your interest in Freeciv! The preferred way to use RT is
> through the email interface. If you want a personal account, you'd
> have to give a good reason why one is absolutely neccessary for you.
>
> Kind regards,
> Daniel
>
>   
-- 
Pagarbiai,
Tautvydas Andrikys aka esminis 
www.esminis.lt 
www.bajeriai.lt 



___
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

[Jason Dorje Short]

http://bugs.freeciv.org/Ticket/Display.html?id=39845 >

William Allen Simpson wrote:
> http://bugs.freeciv.org/Ticket/Display.html?id=39845 >
> 
> Per I. Mathisen wrote:
>> I would suggest that before you change it, at least post the design
>> you have come up with here for discussion.

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.

Specifically, one of your complaints is that the current system is 
context-based.  But the reason for this is that having tiles change 
hands between peaceful nations is majorly problematic when peace 
treaties are designed to prevent invasions.  Having cities or fortresses 
change hands based on cultural influence (or whatever you call the 
engine behind border generation) is militarily or socially imbalancing.

In general I don't see a problem with context-based borders - if nothing 
else it makes backward-compatibility easier when border algorithms are 
changed since the old border setup will always be factored in when 
things change.  That said, the current border system is certainly not 
perfect itself (as I said a "perfect" system is likely impossible.)

> That's what this RFE thread is for  In pseudo-code:
> 
> iterate players
>iterate cities
>  set cultural influence (probably game.turn - turn_built)
>  iterate circle
>determine distance factors
>if factor(this) > factor(existing->source)
>  replace owner and source

You have to be careful that the order of player iteration doesn't 
matter.  If "set cultural influence" is an actual step that must be done 
for all players before any reassigning is done.  Also in turn-based mode 
it should be done separately for each player during (at the start of?) 
their turn.

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.

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

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.

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.

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev