[Freeciv-Dev] [bug #20498] Pirate archers alone in the water

[Marko Lindqvist]

Follow-up Comment #1, bug #20498 (project freeciv):

I don't see how it could explain sanity check failures with rules in use, but
barbarian creation just creates a ferry and then units inside, without
checking if they are suitable cargo for the ferry. Creation of the units try
to load them to ferry with 'force' being FALSE, so they would end failing the
loading to ferry.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20498] Pirate archers alone in the water

[Marko Lindqvist]

URL:
  

 Summary: Pirate archers alone in the water
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 11 Feb 2013 06:22:42 AM EET
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

I've lately got "ptrans != NULL" sanity failures. One time I managed to debug
it down to the fact it was Pirate Archer in Deep Ocean tile. The unit was
already several turns old when sanity check first failed, so it was not just
spawned there without ferry.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3693] Worker food upkeep less important factor

[Marko Lindqvist]

URL:
  

 Summary: Worker food upkeep less important factor
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 11 Feb 2013 05:33:16 AM EET
Category: ai
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.5.0

___

Details:

As I said in patch #3692:
"As value of the improver unit is taken from single tile, and further possible
actions ignored, settler consuming one food is considered zero value when it
could only improve tiles to produce +1 food (no matter how many)"

Further, food is considered most valuable output, so settler producing +1
shield or +1 trade would have negative value (food upkeep bigger loss than
tile improvements gain)

Attached patch just divides unit food upkeep by 2 in want calculation. That's
about equivalent of expecting it to improve 2 tiles during its lifetime
instead of just one.

Needless to say, this patch require rebalancing of _WEIGHTING constants in
patch #3692 once again. Otherwise AI builds far too many workers.



___

File Attachments:


---
Date: Mon 11 Feb 2013 05:33:16 AM EET  Name: WantSettlerForFoodImpr.patch 
Size: 1kB   By: cazfi



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3692] Reduce SHIELD_WEIGHTING

[Marko Lindqvist]

Follow-up Comment #1, patch #3692 (project freeciv):

Simply reducing SHIELD_WEIGHTING to get correcte relative weight to FOOD and
TRADE means that average tile improvement value goes down. This in turn means
that default AI does not value Workers/Settlers as much as before -> doesn't
build, doesn't research tech enabling them.

So, my next attempt
FOOD:  19 -> 21
SHIELD:17 -> 15
TRADE: 13 -> 14
POLLUTION: 12 -> 13


AI buglet noticed:
- As value of the improver unit is taken from single tile, and further
possible actions ignored, settler consuming one food is considered zero value
when it could only improve tiles to produce +1 food (no matter how many)

Autosettler buglet:
- It prefers to have at least one of each of food/shield/trade in every tile.
Comment says this is to take advantage of _INC effects. Comment is wrong in
that _INC effects are already included in the calculation (+1 food with _INC
effect is +2 food).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3692] Reduce SHIELD_WEIGHTING

[Marko Lindqvist]

URL:
  

 Summary: Reduce SHIELD_WEIGHTING
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 11 Feb 2013 04:05:17 AM EET
Category: ai
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.5.0

___

Details:

It might be specific to the rules I play with so that changing this would
break the more important supplied rulesets, but in the serious (as opposed to
quick tests) games I've played lately, AI autosettlers (and city worker
placement?) seem to value production far too much. AI cities are generally
left rather small as instead of producing food in the fields, all the tiles
are transformed to forests.

Autosettler production want value is SHIELD_WEIGHTING in
server/advisors/citytools.h. Maybe unfortunately it controls more than
autosettlers in the default AI code. From the architecture perspective it
belongs to autosettlers, and if changing it breaks parts of actual AI code,
that should be fixed in the AI code and not to try to kludge autosettlers code
to use values suitable for current AI code. So I'm simply changing value from
17 to 13 for my testing. It would be good if other people tested similar
change with other rulesets so we get data to decide if the change should be
made to freeciv.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3672] Select "CanFortify"defender

[Marko Lindqvist]

Update of patch #3672 (project freeciv):

  Status:  Ready For Test => Done   
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20489] Explorers shouldn't stop exploring

[Marko Lindqvist]

Follow-up Comment #4, bug #20489 (project freeciv):

> If we're going to have such a mode, possibly the unit should
> stop and wait for orders the first time it runs out of unknown
> territory to explore, and pressing X again will instruct it to
> go into this new mode (which will never terminate).

I were considering that too, but from my own autoexplorer using experience I
think it's not good enough. I often press 'x' just to see if autoexplorer
would still find some work. With it automatically determining mode, it could
end to new mode when I wanted old one. Such situations arise as new units are
acquired by any means (could this new unit explore?) or enemy units move to
open passage to new areas for autoexplorers already finished with old areas.


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3691] Handle lookup_req_list errors

[Marko Lindqvist]

URL:
  

 Summary: Handle lookup_req_list errors
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 11 Feb 2013 02:31:45 AM EET
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0, 2.5.0

___

Details:

Handle all errors in lookup_req_list() gracefully.

S2_4 goes the opposite direction. There is no way to handle errors gracefully,
but ignoring the errors as the old code does is not good either. It was just
ignoring illegal requirements. It's better to make errors known to ruleset
author by aborting upon them than silently running with broken ruleset
(missing requirement that author meant to be there, maybe simply because typo
in name).



___

File Attachments:


---
Date: Mon 11 Feb 2013 02:31:45 AM EET  Name:
HandleLookupReqListErrors.patch.bz2  Size: 6kB   By: cazfi


---
Date: Mon 11 Feb 2013 02:31:45 AM EET  Name: FatalReqListErrors-S2_4.patch 
Size: 2kB   By: cazfi



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20489] Explorers shouldn't stop exploring

[Jacob Nevins]

Follow-up Comment #3, bug #20489 (project freeciv):

Re patrol: remember that you can force a particular route by typing Q extra
times. But, yeah, micromanagement.

As long as auto-explore is implemented on the server, we could steer
auto-explore toward areas we haven't seen recently, since this is tracked in
(struct player_tile).last_updated.

If we're going to have such a mode, possibly the unit should stop and wait for
orders the first time it runs out of unknown territory to explore, and
pressing X again will instruct it to go into this new mode (which will never
terminate).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

Re: [Freeciv-Dev] [bug #20489] Explorers shouldn't stop exploring

[Imhotep]

Please excuse that I am fairly new to the code and may well ignore some 
details but,
this request is asking for somethings that could be done by the real 
player that operates the client instance.


So this, like auto-settler and city management, "only" a goody, not an 
essential part of the code.


Instead of giving in to such requests, I would rather advocate an 
interface for the client where everyone can put any unit or types of 
units under the control of some client-side script.


The community could develop such scripts for all and every kind of 
purpose, and the best could be incorporated into the trunk.


This would also open a way to improve AI performance without much need 
of hardcoding.


My vision is that I could have a complete set of scripts for every 
occasion, running these against other players (with other scripts),
just laying back and looking what my scripts will do, possibly 
interfering personally when they run bad,

analyzing what went wrong, and later improving them for the next encounter.

Yea, that would really be great!
Imhotep

David Lowe wrote:

Follow-up Comment #2, bug #20489 (project freeciv):

"Patrol" requires far too much micromanagement to be useful.  The primary
issue is that the pathfinder keeps steering the unit onto any available
road/river/etc and the unit never gets close to areas that aren't adjacent to
such.  I second the original poster in that it would be better if we had a
mode that would 'pull' units towards tiles that currently aren't seen.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

  



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

[Freeciv-Dev] [patch #3677] Handle load_xxx_names() errors

[Marko Lindqvist]

Update of patch #3677 (project freeciv):

  Status:  Ready For Test => Done   
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3676] fcintl.h mentions of config.h -> fc_config.h

[Marko Lindqvist]

Update of patch #3676 (project freeciv):

  Status:  Ready For Test => Done   
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20489] Explorers shouldn't stop exploring

[David Lowe]

Follow-up Comment #2, bug #20489 (project freeciv):

"Patrol" requires far too much micromanagement to be useful.  The primary
issue is that the pathfinder keeps steering the unit onto any available
road/river/etc and the unit never gets close to areas that aren't adjacent to
such.  I second the original poster in that it would be better if we had a
mode that would 'pull' units towards tiles that currently aren't seen.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20476] netdb.h conflict

[Marko Lindqvist]

Follow-up Comment #4, bug #20476 (project freeciv):

So the question is if we should drop that -lbind in general, or do we need
some magic to sometimes include it and sometimes not (I have no good ideas
what what we should be testing to make the decision)

> I suspect that the libbind4 package is my main problem, and I
> plan to remove it (but I'll wait in case there's more you'd like
> me to test);

In case this takes some time (I have higher priorities elsewhere at the
moment), it should be sufficient for you to list important bits of your system
here (Lucid, libbind4-package installed, anything else?) so I can setup it to
virtual machine for testing later.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

Re: [Freeciv-Dev] Mystery of Tilesets

[Marko Lindqvist]

On 10 February 2013 20:55, Imhotep  wrote:
>
> Am I guessin correct that
>
>  10, 12, "t.l0.floor1"
>
> is short for
>
>  10, 12, "t.l0.floor_n1e1s1w1"
 ...

 No. I think you are comparing two different sprite types here (See
README.graphics "layerN_sprite_type") Former is terrain drawn with
single sprite, in the latter set you have multiple "corner" sprites.

> and that is that all those sprites are taken from the 10th row, 12th column
> (starting count with 0)?

 Yes, those numbers are location of the sprite in gfx file.

> Why then, in trident/tile.spec does this
>
> ; Rivers (as special type), and whether north, south, east, west
> ; also has river or is ocean:

 Note that river is not an generic terrain, so it has drawing rules of
its own (to be changed in trunk really soon now)


 - ML

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

Re: [Freeciv-Dev] Mystery of Tilesets

[Imhotep]

Am I guessin correct that

 10, 12, "t.l0.floor1"

is short for

 10, 12, "t.l0.floor_n1e1s1w1"
 10, 12, "t.l0.floor_n0e1s1w1"
 10, 12, "t.l0.floor_n1e0s1w1"
 10, 12, "t.l0.floor_n0e0s1w1"
 10, 12, "t.l0.floor_n1e1s0w1"
 10, 12, "t.l0.floor_n0e1s0w1"
 10, 12, "t.l0.floor_n1e0s0w1"
 10, 12, "t.l0.floor_n0e0s0w1"
 10, 12, "t.l0.floor_n1e1s1w0"
 10, 12, "t.l0.floor_n0e1s1w0"
 10, 12, "t.l0.floor_n1e0s1w0"
 10, 12, "t.l0.floor_n0e0s1w0"
 10, 12, "t.l0.floor_n1e1s0w0"
 10, 12, "t.l0.floor_n0e1s0w0"
 10, 12, "t.l0.floor_n1e0s0w0"
 10, 12, "t.l0.floor_n0e0s0w0"

and that is that all those sprites are taken from the 10th row, 12th
column (starting count with 0)?

Why then, in trident/tile.spec does this

; Rivers (as special type), and whether north, south, east, west 
; also has river or is ocean:

 19,  0, "tx.s_river_n0e0s0w0"
 19,  1, "tx.s_river_n1e0s0w0"
 19,  2, "tx.s_river_n0e1s0w0"
 19,  3, "tx.s_river_n1e1s0w0"
 19,  4, "tx.s_river_n0e0s1w0"
 19,  5, "tx.s_river_n1e0s1w0"
 19,  6, "tx.s_river_n0e1s1w0"
 19,  7, "tx.s_river_n1e1s1w0"
 19,  8, "tx.s_river_n0e0s0w1"
 19,  9, "tx.s_river_n1e0s0w1"
 19, 10, "tx.s_river_n0e1s0w1"
 19, 11, "tx.s_river_n1e1s0w1"
 19, 12, "tx.s_river_n0e0s1w1"
 19, 13, "tx.s_river_n1e0s1w1"
 19, 14, "tx.s_river_n0e1s1w1"
 19, 15, "tx.s_river_n1e1s1w1"

work (note the 19 instead of 8)

(I have 2.4.99-dev, revision 22213).

Greetings from Imhotep

Marko Lindqvist wrote:

  On 10 February 2013 19:20, Imhotep  wrote:
  
  
I would like to know about the mystery of tilesets.

I have a modpack of my own, derived from Ancients, and heavily modified via
blind copy&paste to make it work with 2.4.99-dev.

Now I don't see any differences between deep and shallow ocean.
By a look in the save-file I can see that the generator distinguishes all
right, (":" for deep ocean and " " for shallow).
But the tile for floor is not found, alt_graph is used instead. When setting
alt_graph="-", an error occurs.

Comparing with amplio2.tilespec and modifying, hoping for good luck didn't
work.

Where can I get an understanding of the anatomy of *.tilespec?

  
  
 I don't know if there's better documentation in wiki or somewhere,
but doc/README.graphics tries to document it. Unfortunately one person
who reworked tilespec handling significantly didn't update any
documtentation, so most of the information in that doc is what I
figured out by reading the source files - it might have somewhat weird
approach to issues that would have more sane explanation from another
angle.
 If you have modified ancients.tilespec and related .spec and gfx
files, note that it's based on trident tileset. You would probably do
better by comparing changes to trident than to amplio.

 Unfortunate naming of ocean tiles ("coast" for deep ocean!) comes
from halfway cleanup of another mess, this time with
not-really-working and unnecessary additional terrain types that lived
in our version control for a while. That's something that should be
properly addressed, but I've forgotten it over the years.


 - ML

  





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

Re: [Freeciv-Dev] Mystery of Tilesets

[Marko Lindqvist]

On 10 February 2013 19:20, Imhotep  wrote:
> I would like to know about the mystery of tilesets.
>
> I have a modpack of my own, derived from Ancients, and heavily modified via
> blind copy&paste to make it work with 2.4.99-dev.
>
> Now I don't see any differences between deep and shallow ocean.
> By a look in the save-file I can see that the generator distinguishes all
> right, (":" for deep ocean and " " for shallow).
> But the tile for floor is not found, alt_graph is used instead. When setting
> alt_graph="-", an error occurs.
>
> Comparing with amplio2.tilespec and modifying, hoping for good luck didn't
> work.
>
> Where can I get an understanding of the anatomy of *.tilespec?

 I don't know if there's better documentation in wiki or somewhere,
but doc/README.graphics tries to document it. Unfortunately one person
who reworked tilespec handling significantly didn't update any
documtentation, so most of the information in that doc is what I
figured out by reading the source files - it might have somewhat weird
approach to issues that would have more sane explanation from another
angle.
 If you have modified ancients.tilespec and related .spec and gfx
files, note that it's based on trident tileset. You would probably do
better by comparing changes to trident than to amplio.

 Unfortunate naming of ocean tiles ("coast" for deep ocean!) comes
from halfway cleanup of another mess, this time with
not-really-working and unnecessary additional terrain types that lived
in our version control for a while. That's something that should be
properly addressed, but I've forgotten it over the years.


 - ML

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

[Freeciv-Dev] Mystery of Tilesets

[Imhotep]

I would like to know about the mystery of tilesets.

I have a modpack of my own, derived from Ancients, and heavily modified 
via blind copy&paste to make it work with 2.4.99-dev.


Now I don't see any differences between deep and shallow ocean.
By a look in the save-file I can see that the generator distinguishes 
all right, (":" for deep ocean and " " for shallow).
But the tile for floor is not found, alt_graph is used instead. When 
setting alt_graph="-", an error occurs.


Comparing with amplio2.tilespec and modifying, hoping for good luck 
didn't work.


Where can I get an understanding of the anatomy of *.tilespec?

Thanks
Imhotep

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

[Freeciv-Dev] [bug #20495] punit->activity_count overflow

[pepeto]

URL:
  

 Summary: punit->activity_count overflow
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 17:25:46 CET
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

Noticed that units fortifying have a increasing activity count. You can read
in the savegame posted in bug #20361 pikemen with a counter of 1200!

The problem is that this info is sent to the clients using a 8-bit integer...





___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20361] Pathfinding may prefer move+attack to simply attacking adjacent target

[pepeto]

Update of bug #20361 (project freeciv):

  Status:None => Ready For Test 

___

Follow-up Comment #6:

This patch should solve your problem.


(file #17180)
___

Additional Item Attachment:

File name: attack_last_part_problem.diff  Size:4 KB


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20494] Uninitialized PACKET_UNIT_ORDERS

[Marko Lindqvist]

Follow-up Comment #1, bug #20494 (project freeciv):

I vaguely remember thinking this is finally deciding to leave it as it is.
Should have added comment at least to remind why exactly so. Probably I were
afraid of masking some erronous use *before* actual send.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #19943] Initial protocol between trunk and S2_4-or-earlier broken

[pepeto]

Update of bug #19943 (project freeciv):

  Status:None => Ready For Test 

___

Follow-up Comment #9:

Fix attached. It needs to apply patch #3690.


(file #17179)
___

Additional Item Attachment:

File name: trunk_network_protocol.diffSize:14 KB


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3690] dio__uintx()

[pepeto]

Update of patch #3690 (project freeciv):

  Depends on: => patch #3688


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3690] dio__uintx()

[pepeto]

URL:
  

 Summary: dio__uintx()
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 16:23:39 CET
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Tools for repairing trunk login protocol.




___

File Attachments:


---
Date: dim. 10 févr. 2013 16:23:39 CET  Name: dio_put_get_uintx.diff  Size: 4
ko   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20494] Uninitialized PACKET_UNIT_ORDERS

[pepeto]

URL:
  

 Summary: Uninitialized PACKET_UNIT_ORDERS
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 16:19:48 CET
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: S2_2, S2_3, S2_4, trunk
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

'base' and 'road' fields  are not initialized in send_path_orders(). It
results invalid read for sending to the server. Fix attached.




___

File Attachments:


---
Date: dim. 10 févr. 2013 16:19:48 CET  Name:
goto_unitilialized_packet_fields.diff  Size: 365 o   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3689] timer_list cleanup

[pepeto]

URL:
  

 Summary: timer_list cleanup
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 13:57:29 CET
Category: general
Priority: 3 - Low
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Use the new speclist functions to simplify the usage of the ping timer_list.




___

File Attachments:


---
Date: dim. 10 févr. 2013 13:57:29 CET  Name: timer_list_cleanup.diff  Size: 2
ko   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3688] dio_put_xxx() cleanup

[pepeto]

Update of patch #3688 (project freeciv):

  Depends on: => patch #3685


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3688] dio_put_xxx() cleanup

[pepeto]

URL:
  

 Summary: dio_put_xxx() cleanup
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 13:44:46 CET
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

This patch :
* adds error messages when fields inserted in the struct data_out cannot be
correctly set.
* doesn't assume anymore that sizeof(int) == 4 when converting signed and
unsigned values.
* set correct values in packets before being sending (using most of the time
the xxx_count() wrappers).




___

File Attachments:


---
Date: dim. 10 févr. 2013 13:44:46 CET  Name: dio_put_xxx.diff  Size: 12 ko  
By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3687] Ensure all packets fields have been correctly read

[pepeto]

Follow-up Comment #1, patch #3687 (project freeciv):

I forgot to say that this patch also remove some obsolete comments about the
network protocol.


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3687] Ensure all packets fields have been correctly read

[pepeto]

Update of patch #3687 (project freeciv):

  Depends on: => patch #3686


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3687] Ensure all packets fields have been correctly read

[pepeto]

URL:
  

 Summary: Ensure all packets fields have been correctly read
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 13:31:54 CET
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Currently, if the server or the client fails to read some fields on a packet,
it restore former values or set them to zero. The packet can be very different
of what the other instance wanted to send. Actually this should never happen
as long as the packets are encoded by the dio_put_xxx() functions and the
capability string handle correctly the variants.

This patch break the connections when fields are missing or incorrectly
encoded.




___

File Attachments:


---
Date: dim. 10 févr. 2013 13:31:54 CET  Name: packet_full_checking.diff  Size:
24 ko   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3686] dio__float()

[pepeto]

Update of patch #3686 (project freeciv):

  Depends on: => patch #3685


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3686] dio__float()

[pepeto]

URL:
  

 Summary: dio__float()
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 13:26:38 CET
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Small patch to allow float encoding, without generate_packets.py hacks.




___

File Attachments:


---
Date: dim. 10 févr. 2013 13:26:38 CET  Name: dio_put_get_float.diff  Size: 5
ko   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3685] dio_get_xxx() returned value

[pepeto]

URL:
  

 Summary: dio_get_xxx() returned value
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 13:24:16 CET
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

From bug #20003:
>> IIRC return value is solely about whether data was available
>> (and read). These low-level functions do not know what data is
>> valid. Maybe dio_get_uint8() has a bug?
>
> I think so. I will try to investigate a bit deeper...

dio_get_uint8() may be wrong when 'dest' argument is NULL. After having
checked everywhere this function is called in the current code, it never
should be problematic.

So, the attached patch shouldn't fix anything, except that the returned value
is always what it is supposed to be.

I attach a version for S2_4 too.




___

File Attachments:


---
Date: dim. 10 févr. 2013 13:24:16 CET  Name: trunk_dio_get_xxx.diff  Size: 18
ko   By: pepeto


---
Date: dim. 10 févr. 2013 13:24:16 CET  Name: S2_4_dio_get_xxx.diff  Size: 18
ko   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20493] utype_by_number() returns invalid pointer

[pepeto]

URL:
  

 Summary: utype_by_number() returns invalid pointer
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 12:57:52 CET
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: S2_1, S2_2, S2_3, S2_4, trunk
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

Still when I was working on the network protocol, I experienced a crash
(SEGFAULT after many failed assertions) due to my changes (notably replacing
"(UnitTypeId) (unit8) -1" by "unit_count()".

Since r10762 for PR#13513, utype_by_number(game.control.num_unit_types)
returns a pointer != NULL.

Fix attached.




___

File Attachments:


---
Date: dim. 10 févr. 2013 12:57:52 CET  Name: utype_by_number.diff  Size: 505
o   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #20492] PACKET_UNIT_INFO unused fields

[pepeto]

URL:
  

 Summary: PACKET_UNIT_INFO unused fields
 Project: Freeciv
Submitted by: pepeto
Submitted on: dim. 10 févr. 2013 12:48:27 CET
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: trunk r20790
 Discussion Lock: Any
Operating System: None
 Planned Release: 2.5

___

Details:

When working on the protocol cleanup, I noticed some errors about strange
values inserted as 8-bits integers.

At r20790 for patch #3093, the fields "changed_from_base" and
"changed_from_road" should have been renamed "changed_from_tgt_base" and
"changed_from_tgt_road", but for some reasons, those weren't removed after
inserting the new fields.

It results that the server read and send uninitialized data to the client. But
the client doesn't handle them anyway.

Fix attached, needs capability string change.




___

File Attachments:


---
Date: dim. 10 févr. 2013 12:48:27 CET  Name: packet_unused_fields.diff  Size:
407 o   By: pepeto



___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #3675] Rivers as road types in rulesets

[Marko Lindqvist]

Follow-up Comment #2, patch #3675 (project freeciv):

> Setting the rivers to non pillageable was forgotten.

Thansk for catching this. Another bug is that in all the requirements lists
requirement "Special"/"River" should be replaced with "Road"/"River". This
affects irrigation at least.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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