[Freeciv-Dev] [bug #21795] fortify action more even in concurrent mode

[David Fernandez]

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

I admit I did not take into account this difference between civ1 and current
freeciv when I wrote it, but my idea was to calculate automatically if the
unit is fortified or not, not linked to the "fortify" action, but to the
movement points of the unit, so the setting "unitwaittime" can be taken into
account.

I'd rewrite it for freeciv current behavior:
- when the unit is going to recover the movement points (after the
"unitwaittime" of this turn), if the unit had remaining movement points from
previous turn, then the unit is automatically considered fortified (and the
fortified icon is drawn), until it moves again.

But I admit I like the civ1 alternative and it would be great to be able to
choose between them.

___

Reply to this item at:

  

___
  Mensaje enviado vía/por Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #4608] civ2civ3 rules: added pre-fortress

[David Fernandez]

Follow-up Comment #12, patch #4608 (project freeciv):

>What if you give Triremes Zoc?
Sounds good, but you could bypass it with one explorer/diplomat in one of the
triremes. I think the same tricks would be possible, just a bit harder.
I guess a human player can defend his terrain by placing a fortress in the
middle of the river, but I do not expect the ai to do the same, and I do not
like to introduce additional disavantages for the ai.

Anyway, I think the current version of civ2civ3 for v2.5 is playable as it is.
I guess future changes will go to v2.6.

I find the economical part of the ruleset mostly finished. It has been tested
online, and I personally like it offline.

It is the combat system what I do not consider finished, in part due to some
of these available trick/exploits.
In part because I made the latest changes with the idea of a future rule where
units in open field can get defensive bonuses from adjacent units, or
penalties from adjacent enemies (one day I'll open another ticket to try to
convince you about this possibility...).
Right now, the combat in civ2civ3 is a bit simplistic, and the chances to win
an attack in open terrain use to be 99% no matter the units involved. I still
prefer it to classic rules, but online players are not liking some of these
latest changes. If we see that offline players agree, I'll create a patch to
make v2.6 more similar to greatturn rules that people seem to like.

Thats all for now. See you.

___

Reply to this item at:

  

___
  Mensaje enviado vía/por Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #21583] Client can connect to manually started server rather than its own spawned one

[Marko Lindqvist]

Follow-up Comment #9, bug #21583 (project freeciv):

- Remove SO_REUSEADDR from client side sockets too.

(file #20364)
___

Additional Item Attachment:

File name: SoReuseAddrRm-2.patch  Size:1 KB


___

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 #21795] fortify action more even in concurrent mode

[Marko Lindqvist]

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

> Calculate automatically the bonus to defend no matter if the 
> units was ordered to fortify or not, in a similar way that it
> is already done for units in cities or fortresses.

If I understand correctly, you want to revert to civ1 model, where fortifying
in the open is immediate action, not requiring the one turn to go from
FORTIFYING -> FORTIFIED. Note that units in cities already are always
considered fortifIED, even if they have spent all their movement to reach the
city (and thus would do even the fortifYING only next turn).

That would make it easier to advance and fortify where you got.
Current model vs civ1:
turn 1: moved / moved (0 movement points left)
turn 2: fortifying / fortified
turn 3: fortified / fortified


___

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 #21807] Metaserver scan finalized twice in case of error

[Marko Lindqvist]

URL:
  

 Summary: Metaserver scan finalized twice in case of error
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 17 Mar 2014 02:53:58 AM EET
Category: client-gtk-2.0
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 2.5.0, 2.6.0

___

Details:

gtk-clients:
Server list scan error handling callback finalizes the scan. So does the main
thread once it notices that scan has ended. This leads to double free.

Attached fix removes extra finalization from error handling callback.



___

File Attachments:


---
Date: Mon 17 Mar 2014 02:53:58 AM EET  Name: ScanDoubleFinalization.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] [patch #4616] Do not wait scan to finish when leaving network page

[Marko Lindqvist]

URL:
  

 Summary: Do not wait scan to finish when leaving network page
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 17 Mar 2014 02:46:29 AM EET
Category: client-gtk-2.0
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, 2.6.0

___

Details:

gtk-clients:

Do not block leaving of network page by waiting metaserver scan to finish.
Only if entire program is being closed, or one re-enters network page,
previous scan must absolutely be finished.



___

File Attachments:


---
Date: Mon 17 Mar 2014 02:46:29 AM EET  Name: DestroyScanAtExit.patch  Size:
3kB   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 #21806] End of ui_main() skipped

[Marko Lindqvist]

URL:
  

 Summary: End of ui_main() skipped
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 17 Mar 2014 02:36:16 AM EET
Category: client-gtk-2.0
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 2.4.3, 2.5.0, 2.6.0

___

Details:

Gtk clients often quit by calling client_exit() directly while inside gtk main
loop. Correct way is just to end the gtk main loop, after which it returns to
finish ui_main() and continues to shut down.

Fix attached.



___

File Attachments:


---
Date: Mon 17 Mar 2014 02:36:16 AM EET  Name: UiMainFinish.patch  Size: 4kB  
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 #4615] Allocate client metaserver scan mutex later

[Marko Lindqvist]

URL:
  

 Summary: Allocate client metaserver scan mutex later
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 17 Mar 2014 02:32:49 AM EET
Category: client
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, 2.6.0

___

Details:

Allocate metaserver scan mutex only when really needed. Especially do it after
connecting the metaserver as that might hang for a long time if metaserver is
unreachable.




___

File Attachments:


---
Date: Mon 17 Mar 2014 02:32:49 AM EET  Name: MetaMutex.patch  Size: 742B   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 #4608] civ2civ3 rules: added pre-fortress

[Marko Lindqvist]

Follow-up Comment #11, patch #4608 (project freeciv):

What if you give Triremes Zoc? That wouldn't affect them on oceanic tiles
where Zoc never applies, but while sailing the river, even adjacent enemy
units could stop it.

___

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 #4608] civ2civ3 rules: added pre-fortress

[David Fernandez]

Follow-up Comment #10, patch #4608 (project freeciv):

It is not really a bug, it is the way the trireme works when movement on river
is enabled, and I don't really know how could it be improved.

These are the issues I see related to triremes moving on rivers:
- you can use a river to unload units like you do in a city, without being
affected by "slow invasion".
It makes rivers better places to disembark than other coastal tiles and it
encourages counter-intuitive tactics, like the construction of fast
fortresses.
- you can use a river to cross the enemy border with the trireme, and the
loaded units will not lose one movement point as they do when moving on land.
I like it for other transports, I just find it too powerful for ancient
triremes.
- you can move the trireme 3 tiles along the river, and when it finish, the
loaded unit can move another 3 tiles along the same river. It encourages
micromanagment and chaining of triremes that I do not like.

I don't know if there is a reason for a bug report, I just don't like some
aspects of this feature, and I wonder if it is worth to keep it enabled in the
ruleset.

___

Reply to this item at:

  

___
  Mensaje enviado vía/por Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #21805] Transformation by irrigate or mining impossible

[Marko Lindqvist]

URL:
  

 Summary: Transformation by irrigate or mining impossible
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 17 Mar 2014 12:39:31 AM EET
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 2.6.0

___

Details:

Client does not send ACTIVITY_IRRIGATE request to server when
next_extra_for_tile() returns NULL. Until recently this was masked by another
bug that next_extra_for_tile() gave irrigation and mining extras even for
tiles where transformation should occur instead.

Fix attached



___

File Attachments:


---
Date: Mon 17 Mar 2014 12:39:31 AM EET  Name: IrrigMineTransformPossible.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] [bug #21630] Default AI diplomacy tries to read minds

[Marko Lindqvist]

Update of bug #21630 (project freeciv):

  Status:  Ready For Test => Fixed  
 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 #21794] FC_QT_COMPILETEST used instead of FC_QT5_COMPILETEST

[Marko Lindqvist]

Update of bug #21794 (project freeciv):

  Status:  Ready For Test => Fixed  
 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 #4614] Flush when thawing mapview

[Marko Lindqvist]

URL:
  

 Summary: Flush when thawing mapview
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 16 Mar 2014 05:18:25 PM EET
Category: client-gtk-3.0
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.3, 2.5.0, 2.6.0

___

Details:

Do not only mark view dirty, but flush it when thawing mapview freeze.



___

File Attachments:


---
Date: Sun 16 Mar 2014 05:18:25 PM EET  Name: ThawFlush.patch  Size: 395B   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 #21803] Map canvas sliding after reconnecting

[Marko Lindqvist]

URL:
  

 Summary: Map canvas sliding after reconnecting
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 16 Mar 2014 02:35:32 PM 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 have not tried to setup actual test, but reading the sources...

Client remembers the old mapview canvas position so it can smoothly slide the
view when new position is set. There's two exceptions:
- When client is first started, static variable "first" in
center_tile_mapcanvas() tells that there's no old position to slide from
- set_mapview_scroll_pos() that's called for scroll bar handling disables
sliding temporarily

Neither of these seem to handle the case of client to remembering position
from the previous server when connecting new one. In theory this can result in
at least unnecessary sliding from randomish position to the position game
should start from. Worse things may happen if old server had bigger map than
new one and the client remembers position outside new map boundaries.




___

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 #4608] civ2civ3 rules: added pre-fortress

[Marko Lindqvist]

Follow-up Comment #9, patch #4608 (project freeciv):

> The triremes seem to ignore the enemy border

If that's not because of the rules definitions, please open a bug and attach
savegame from which to reproduce.

___

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 #21696] [patch] build fix: libfreeciv-srv.la depends on lua libraries

[Marko Lindqvist]

Update of bug #21696 (project freeciv):

  Status: In Progress => Ready For Test 

___

Additional Item Attachment:

File name: LuaSrvLib-2.patch  Size:5 KB
File name: LuaSrvLib-S2_5-2.patch Size:4 KB
File name: LuaSrvLib-S2_4-2.patch Size:4 KB


___

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 #21696] [patch] build fix: libfreeciv-srv.la depends on lua libraries

[Marko Lindqvist]

Update of bug #21696 (project freeciv):

  Status:  Ready For Test => In Progress

___

Follow-up Comment #4:

Not only freeciv-server/libfreeciv-srv issue, but lua libraries should be
added to correct libraries, and not executables, in general.

___

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