Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2005:
[Freeciv-Dev] Re: (PR#12530) CMA: Campos has changed multiple times due
Home

[Freeciv-Dev] Re: (PR#12530) CMA: Campos has changed multiple times due

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: nicolau.saldanha@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#12530) CMA: Campos has changed multiple times due to an error in Freeciv.
From: "Benoit Hudson" <bh@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Mar 2005 09:52:46 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12530 >

On Fri, Mar 18, 2005 at 03:01:04AM -0800, Christian Knoke wrote:
> 
> <URL: http://bugs.freeciv.org/Ticket/Display.html?id=12530 >
> 
> On Thu, Mar 17, 2005 at 08:48:20PM -0800, Benoit Hudson wrote:
> > 
> > Interestingly, I can't reproduce either of these on OSX with current CVS.
> 
> Here is another one. This is different, the CMA 'glitches' just after turn
> done, for 4 cities. I can reinstall it immediately.

Great!  This one I can reproduce.  Middlesborough is failing.

It starts off (client- and server-side both) at:

2: print_result:  workers at:
2: print_result:    ( 2, 2)
2: print_result:    ( 2, 3)
2: print_result:    ( 3, 2)
2: print_result:    ( 1, 1)
2: print_result:    ( 1, 3)
2: print_result:    ( 3, 1)
2: print_result:    ( 0, 2)
2: print_result: -...-
2: print_result: .w.w.
2: print_result: w.cw.
2: print_result: .ww..
2: print_result: -...-
2: print_result:  people: (workers/specialists) 6/0/2/0


It is aiming for:

2: print_result:  workers at:
2: print_result:    ( 2, 2)
2: print_result:    ( 2, 3)
2: print_result:    ( 3, 2)
2: print_result:    ( 0, 2)
2: print_result:    ( 1, 0)
2: print_result:    ( 3, 0)
2: print_result: -w.w-
2: print_result: .....
2: print_result: w.cw.
2: print_result: ..w..
2: print_result: -...-
2: print_result:  people: (workers/specialists) 5/0/3/0


Somehow, it doesn't get there.  The two workers in the second row --
(1,1) and (1,3) don't get turned off, which means we can't turn on
the workers in the top row at (0,1) and (0,3).  The worker at (3,1)
does, however, correctly get toggled off, and turned into a scientist.

2: print_result:  workers at:
2: print_result:    ( 2, 2)
2: print_result:    ( 2, 3)
2: print_result:    ( 3, 2)
2: print_result:    ( 1, 1)
2: print_result:    ( 3, 1)
2: print_result:    ( 0, 2)
2: print_result: -...-
2: print_result: .w.w.
2: print_result: w.cw.
2: print_result: ..w..
2: print_result: -...-
2: print_result:  people: (workers/specialists) 5/0/3/0

At the beginning, both client and server agree on what the city map and
specialists look like; at the end, they agree again.  The client appears
to be correctly making calls to create packets to toggle workers /
specialists.  What's left to debug are:
- whether the packets are actually being created correctly (I don't
  understand packets_gen.c ; I wouldn't know how to tell if it's caching
  them away)
- the server-side response to the packet: is it somehow screwing up
  unpacking the requests?





[Prev in Thread] Current Thread [Next in Thread]