[Freeciv-Dev] [bug #15602] Lua errors not reported when evaluating whole file (script_do_file)

[Ulrik Sverdrup]

URL:
  

 Summary: Lua errors not reported when evaluating whole file
(script_do_file)
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 16:16
Category: None
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

The user/developer gets no indication of what is wrong if lua evaluation
fails when evaluating default.lua or similar files.

Attached a patch to report the error in lua, just the first line but normally
exactly what you need to fix syntax/simple typos in the top level of the
script file.

(Lua errors in "non-toplevel", in callbacks are of course shown later, when
the callbacks are evaluated)


With this change we get helpful errors:


2: Loading rulesets
l1: lua error:
data/default/default.lua:176: ')' expected (to close '(' at line
175) near ''
0: "data/default/script.lua": could not load ruleset script.




___

File Attachments:


---
Date: lördag 2010-03-13 den 16:16  Name:
0001-Report-lua-errors-in-script_do_file.patch  Size: 2 kB   By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15596] SCRIPT_ASSERT should always be enabled

[Ulrik Sverdrup]

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

We really need this, otherwise a simple script line like this will segfault
the server:

create_base(nil, "Ruins", nil)

With SCRIPT_ASSERT, we show a script error message instead.

"Unmasking" SCRIPT_ASSERT makes us liable to have a portable version of it,
but it seems the freelog macros use all the same __FUNCTION__ etc that
SCRIPT_ASSERT does. It should thus be safe to "unmask" for all current
compilers.


Patch attached.

(file #8502)
___

Additional Item Attachment:

File name: 0001-Enable-SCRIPT_ASSERT-regardless-of-debug-setting.patch Size:1
KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1524] Activate Partisans from Lua script (implementation)

[Ulrik Sverdrup]

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

Updated patch, changes:

+ Updated error handling. Partisan unit is now checked by SCRIPT_ASSERT in
place_partisans in the API.
+ Both winner & loser get a Partisan event message.


This script should work with all rulesets. A ruleset without partisans simply
never activates the Inspire_Partisans effect.

(file #8501)
___

Additional Item Attachment:

File name: 0005-Activate-inspired-partisans-on-city-conquest-from-Lu.patch
Size:5 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1523] API: Export place_partisans

[Ulrik Sverdrup]

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

Update to freeciv style guide.

Also updated error handling, with a proper SCRIPT_ASSERT for at least a
Partisan-role unit in the ruleset.

(file #8500)
___

Additional Item Attachment:

File name: 0004-Add-action-place_partisans-tile-owner-count-to-API.patch
Size:6 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1521] Add an effects module to Scripting API. #2

[Ulrik Sverdrup]

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

Update to freeciv style guide

(file #8499)
___

Additional Item Attachment:

File name: 0002-Add-effect-module-world_bonus-and-player_bonus-to-AP.patch
Size:2 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1520] Add an effects module to Scripting API. #1

[Ulrik Sverdrup]

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

Update to freeciv style guide

(file #8498)
___

Additional Item Attachment:

File name: 0001-Add-effects-module-with-get_city_bonus-as-city_bonus.patch
Size:4 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15596] SCRIPT_ASSERT should always be enabled

[Ulrik Sverdrup]

URL:
  

 Summary: SCRIPT_ASSERT should always be enabled
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 14:30
Category: general
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 2.2
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

SCRIPT_ASSERT does not only assure invariants in freeciv's code, but will
test user code very day when new scenarios and rulesets are built.

Because of this we need these to be enabled in all compiled versions of
freeciv, especially the release versions. Any script situation that can crash
freeciv should be considered a major bug.





___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1519] [Metaticket] Activate Partisans from Lua script

[Ulrik Sverdrup]

Update of patch #1519 (project freeciv):

  Depends on: => patch #1524


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1519] [Metaticket] Activate Partisans from Lua script

[Ulrik Sverdrup]

Update of patch #1519 (project freeciv):

  Depends on: => patch #1522


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1519] [Metaticket] Activate Partisans from Lua script

[Ulrik Sverdrup]

Update of patch #1519 (project freeciv):

  Depends on: => patch #1521


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1519] [Metaticket] Activate Partisans from Lua script

[Ulrik Sverdrup]

Update of patch #1519 (project freeciv):

  Depends on: => patch #1520


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1524] Activate Partisans from Lua script (implementation)

[Ulrik Sverdrup]

URL:
  

 Summary: Activate Partisans from Lua script (implementation)
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:42
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Remove make_partisans and activate partisans in default/default.lua.

New partisan activation code includes a message (E_CITY_LOST) (previously
there was none), "The loss of %cityname has inspired partisans!"



___

File Attachments:


---
Date: lördag 2010-03-13 den 13:42  Name:
0005-Activate-inspired-partisans-on-city-conquest-from-Lu.patch  Size: 5 kB  
By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1523] API: Export place_partisans

[Ulrik Sverdrup]

URL:
  

 Summary: API: Export place_partisans 
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:42
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Export place_partisans to Scripting API. The exported function is more
general, and can inspire partisans around any tile for any player.




___

File Attachments:


---
Date: lördag 2010-03-13 den 13:42  Name:
0004-Add-action-place_partisans-tile-owner-count-to-API.patch  Size: 6 kB  
By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1522] API: Add fields size and original to City.

[Ulrik Sverdrup]

URL:
  

 Summary: API: Add fields size and original to City.
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:41
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Export fields size and original (original owner) of the City type.



___

File Attachments:


---
Date: lördag 2010-03-13 den 13:41  Name:
0003-Export-more-fields-of-City-to-the-Scripting-API.patch  Size: 750 B   By:
englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1521] Add an effects module to Scripting API. #2

[Ulrik Sverdrup]

URL:
  

 Summary: Add an effects module to Scripting API. #2
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:39
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Add player_bonus and world_bonus

effect names should be passed as strings (the ruleset names). 



___

File Attachments:


---
Date: lördag 2010-03-13 den 13:39  Name:
0002-Add-effect-module-world_bonus-and-player_bonus-to-AP.patch  Size: 3 kB  
By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1520] Add an effects module to Scripting API. #1

[Ulrik Sverdrup]

URL:
  

 Summary: Add an effects module to Scripting API. #1
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:39
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Export get_city_bonus as effects.city_bonus in Event Scripting API



___

File Attachments:


---
Date: lördag 2010-03-13 den 13:39  Name:
0001-Add-effects-module-with-get_city_bonus-as-city_bonus.patch  Size: 4 kB  
By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1519] [Metaticket] Activate Partisans from Lua script

[Ulrik Sverdrup]

URL:
  

 Summary: [Metaticket] Activate Partisans from Lua script
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:37
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

This series of 5 patches allows us to "activate" placements of partisans from
a Lua script. The last patch includes a change to default.lua to do this.

The exact partisan placement code in place_partisans is kept in C
implementation and this function is exported to the Scripting API with a
modified signature: place_partisans(tile, owner, count).

This change comes with a couple of caveats, the semantics change since we
move the partisan creation from a very specific time inside the process of a
city being taken over, to be carried out after that in the 'city_lost'
callback. Please help me understand if this can have any bad consequences.

Since the city is already lost we can't use get_city_bonus for the inspire
partisans effect, and with this change we will use get_player_bonus. This
makes no difference in the default ruleset but it ignores local effects.

The patches themselves have explanations, first come 4 patches to expand the
Scripting API.




___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15594] Activate Partisans from Lua script

[Ulrik Sverdrup]

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

Export place_partisans to Scripting API. The exported function is more
general, and can inspire partisans around any tile for any player.

Remove make_partisans and activate partisans in default/default.lua.

New partisan activation code includes a message (E_CITY_LOST)  (previously
there was none), "The loss of %cityname has inspired partisans!"

(file #8491, file #8492)
___

Additional Item Attachment:

File name: 0004-Add-action-place_partisans-tile-owner-count-to-API.patch
Size:5 KB
File name: 0005-Activate-inspired-partisans-on-city-conquest-from-Lu.patch
Size:5 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15594] Activate Partisans from Lua script

[Ulrik Sverdrup]

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

Add an effects module to Scripting API.

Only export city_bonus, player_bonus and world_bonus right now. effect names
should be passed as strings (the ruleset names).

Add fields size and original (original owner) to City.

(file #8488, file #8489, file #8490)
___

Additional Item Attachment:

File name: 0001-Add-effects-module-with-get_city_bonus-as-city_bonus.patch
Size:4 KB
File name: 0003-Export-more-fields-of-City-to-the-Scripting-API.patch Size:0
KB
File name: 0002-Add-effect-module-world_bonus-and-player_bonus-to-AP.patch
Size:2 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15594] Activate Partisans from Lua script

[Ulrik Sverdrup]

URL:
  

 Summary: Activate Partisans from Lua script
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:19
Category: None
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

This series of 5 patches allows us to "activate" placements of partisans from
a Lua script. The last patch includes a change to default.lua to do this.

The exact partisan placement code in place_partisans is kept in C
implementation and this function is exported to the Scripting API with a
modified signature: place_partisans(tile, owner, count).

This change comes with a couple of caveats, the semantics change since we
move the partisan creation from a very specific time inside the process of a
city being taken over, to be carried out after that in the 'city_lost'
callback. Please help me understand if this can have any bad consequences.

Since the city is already lost we can't use get_city_bonus for the inspire
partisans effect, and with this change we will use get_player_bonus. This
makes no difference in the default ruleset but it ignores local effects.

The patches themselves have explanations, first come 4 patches to expand the
Scripting API.




___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15593] (Gtk) Popup/context menu on player in initial setup doesn't stay

[Ulrik Sverdrup]

URL:
  

 Summary: (Gtk) Popup/context menu on player in initial setup
doesn't stay
 Project: Freeciv
Submitted by: englabenny
Submitted on: lördag 2010-03-13 den 13:11
Category: None
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

The context menu on players in the initial game setup, where you can
choose take this player, set ai strength, etc, did not stay open after
a click, but required the button to be held down.


This was very annoying and unexpected. For me it works much better (like a
normal context menu, stays open after click), if we just send the event time
as well. Patch attached.

Patch is against 2.2.  If possible, it could go into 2.1, 2.2 and trunk?



___

File Attachments:


---
Date: lördag 2010-03-13 den 13:11  Name:
0001-Gtk-client-Make-player-context-menu-in-initial-setup.patch  Size: 1 kB  
By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15531] [RT#40289] lua: error in error handling

[Ulrik Sverdrup]

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

This patch fixes error handling and restores tracebacks for me. It's related
to Lua5.1 no longer having a _TRACEBACK global function.

Big thanks to the people in #lua who helped out.

Patch against 2.2

(file #8465)
___

Additional Item Attachment:

File name: 0001-Use-Lua5.1-s-debug.traceback-for-error-reporting.patch Size:1
KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [patch #1235] [Metaticket] variable city radii

[Ulrik Sverdrup]

Follow-up Comment #14, patch #1235 (project freeciv):

Patch #1222 introduced an Event Scripting API change and I think it can be
avoided. Was it necessary? If possible, the API should be stable, see
https://gna.org/bugs/index.php?15587

If needed, the new name can be introduced alongside the old name.

The only important thing is to keep the externally visible name stable, so
all other things kept constant, I only want to revert this change in
server/scripting/api.pkg:

 -- Tile methods
-function Tile:city_exists_within_city_radius(center)
-  return methods_tile_city_exists_within_city_radius(self, center)
+function Tile:city_exists_within_max_city_map(center)
+  return methods_tile_city_exists_within_max_city_map(self, center)
 end
 



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15587] Request: Try to Keep Event Scripting API stable

[Ulrik Sverdrup]

URL:
  

 Summary: Request: Try to Keep Event Scripting API stable
 Project: Freeciv
Submitted by: englabenny
Submitted on: fredag 2010-03-12 den 16:44
Category: general
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

As of 2.2 we now have something where people can probably make scenarios with
the event scripting. It is yet quite unexplored, but there should be lots of
possibilities in spite of our scripting's all limitations.

We should consider keeping the API as stable as possible between *major*
Freeciv versions. This is quite simple, adding to the API is always possible.
Changing methods, type's fields or actions should be considered very well
before it is carried out.

I have documented the API (and I think it's correct now) at:
http://freeciv.wikia.com/wiki/Events_Reference_Manual

The 2.1 to 2.2 incompatibilities are forgiven, let's start on a new round
now!

At the moment we have only one incompatibility between 2.2 and trunk, one
method of Tile was renamed:

 -- Tile methods
-function Tile:city_exists_within_city_radius(center)
-  return methods_tile_city_exists_within_city_radius(self, center)
+function Tile:city_exists_within_max_city_map(center)
+  return methods_tile_city_exists_within_max_city_map(self, center)
 end

A cursory look suggests that this change was not needed at all. I think this
change should be worked around, and changes like this in the future should be
avoided.






___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15586] Scripting: Can not save Player value into savegame (Failed to dump variables)

[Ulrik Sverdrup]

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

Here is the patch in alternate version, instead using :number() method.

(file #8464)
___

Additional Item Attachment:

File name: 0001-Add-Player-number-method-to-allow-saving-players-in-.patch
Size:3 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15586] Scripting: Can not save Player value into savegame (Failed to dump variables)

[Ulrik Sverdrup]

Update of bug #15586 (project freeciv):

  Status:None => Ready For Test 

___

Follow-up Comment #1:

A suggested patch is attached. Patch text:

Subject: [PATCH] Add Player:id() method to allow saving players in savegame

Bug #15586: Scripting: Can not save Player value into savegame (Failed
to dump variables)

Since revision r14223, Player does not have any .id field anymore,
so it can not be saved by our dump function (in fact the whole dump
failed).

How this change can/could have been made better:
It may be possible to add properties with tolua (so that the .id
field is a maskeraded function call), but no documentation for this
was found.

It may be preferable to name this method :index() or :number()
instead, since it is not symmetric with the .id fields of other types
anyway.



Patch against 2.2 attached.
Updated testcase attached (testcase will correctly load a Player variable).

I suggest applying this to 2.2 as a bug fix (Player save bug is fixed and API
is extended, not modfied)

A different solution where find.player(..) would accept a player name was
explored, but it does not work: At the time when the server evaluates the
saved vars=$$ code, the player names are not available.

(file #8462, file #8463)
___

Additional Item Attachment:

File name: 0001-Add-Player-id-method-to-allow-saving-players-in-save.patch
Size:3 KB
File name: FailDumpPlayer.sav Size:33 KB


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15586] Scripting: Can not save Player value into savegame (Failed to dump variables)

[Ulrik Sverdrup]

URL:
  

 Summary: Scripting: Can not save Player value into savegame
(Failed to dump variables)
 Project: Freeciv
Submitted by: englabenny
Submitted on: fredag 2010-03-12 den 13:37
Category: general
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 2.2
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

The Player value has no .id field anymore so it cannot be saved via the
script values scheme.

The Player "class" lost its 'id' field in Revision r14223

Attached scenario tries to store a player value in a global script variable.
It will print the error "lua error: Failed to dump variables" if you try to
save a savegame. However, the rest of the savegame seems to save intact so
freeciv does very well.

It looks like the only way to fix it is to re-add the 'id' field, since all
our types are supposed to have it, but I don't know what that technically
entails.

the alternative is an id() accessor and then special-casing Players in the
dumper(?)

Discovered when updating
http://freeciv.wikia.com/wiki/Events_Reference_Manual

thanks

Script inside the savegame, with the output vars=$$:

[script]
code=$
function new_turn_callback(turn, year)
local player = find.player(0)
I_am_player = player
notify.all("Found player %s of the %s, now try save him/her into a
savefile", player.name, player.nation:plural_translation())
end

I_am_player = nil

signal.connect('turn_started', 'new_turn_callback')
$
vars=$$

---

The expected output in vars would be to somehow save the I_am_player
variable.

If there would have been more variables, all would be lost, not just the
player variable.



___

File Attachments:


---
Date: fredag 2010-03-12 den 13:37  Name: FailDumpPlayer.sav  Size: 33 kB  
By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15581] Save Scenario without players still saves borders

[Ulrik Sverdrup]

URL:
  

 Summary: Save Scenario without players still saves borders
 Project: Freeciv
Submitted by: englabenny
Submitted on: torsdag 2010-03-11 den 20:53
Category: editor
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 2.2
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

The following test scenario (being edited/in progress so contains some
strange stuff, like the script)  saves borders without players when saved
without 'Save Players'

When starting a new game, the old borders of old players are there, and are
assigned to other players (by sequence I think). You can see this if you
/observe.

Please see attached file. Attached file is Europe (classic/giant) "ported" to
ancients ruleset.



___

File Attachments:


---
Date: torsdag 2010-03-11 den 20:53  Name: TestAncientEuropeBorders.sav.bz2 
Size: 12 kB   By: englabenny



___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

[Freeciv-Dev] [bug #15579] Scenario Name/Description not available in the Editor

[Ulrik Sverdrup]

URL:
  

 Summary: Scenario Name/Description not available in the
Editor
 Project: Freeciv
Submitted by: englabenny
Submitted on: torsdag 2010-03-11 den 19:53
Category: editor
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 2.2
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

You can save scenario name and description in the editor, but if you load the
scenario again at some later time, the defined values are not available in the
editor. This makes it harder for scenario developers, I guess they have to
enter the same description again each time they save the scenario in a new
editing session.




___

Reply to this item at:

  

___
  Meddelandet skickades via/av Gna!
  http://gna.org/


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

Re: [Freeciv-Dev] [bug #13508] [Patch] Configurable game start year

[Ulrik Sverdrup]

Hello Marko,

Thank you for merging this! This is great for ruleset and scenario
authors, together with the calendar changes I think. So now everything
is set for example, for the Ancients ruleset to have a (for example)
2500 BC to 500 AD timeline(?).

I wanted to contribute to freeciv, but I can't manage my time, and
it's not possible. Maybe in a different life. It's hard for me to see
freeciv requiring so much work (but having lots of potential).

Mvh
ulrik

2009/5/12 Marko Lindqvist :
>
> URL:
>  
>
>                 Summary: [Patch] Configurable game start year
>                 Project: Freeciv
>            Submitted by: cazfi
>            Submitted on: Tuesday 05/12/2009 at 01:03
>                Category: general
>                Severity: 3 - Normal
>                Priority: 1 - Later
>                  Status: None
>             Assigned to: None
>        Originator Email:
>             Open/Closed: Open
>         Discussion Lock: Any
>                 Release:
>        Operating System: None
>
>    ___
>
> Details:
>
> This patch adds start year setting to game.ruleset
>
>
>
>
>    ___
>
> File Attachments:
>
>
> ---
> Date: Tuesday 05/12/2009 at 01:03  Name: StartYear.diff  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 mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work

[Ulrik Sverdrup]

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

2008/4/28 Madeline Book <[EMAIL PROTECTED]>:
>
>  http://bugs.freeciv.org/Ticket/Display.html?id=40184 >
>
>  The usual status update, gentlemen.
>
>  I will have more time to work on this this week since
>  the stuff I wanted to do for longturn is done now. ;)
>

You've made the Global observer work again, I noticed! Would it work
in a networked game too? I haven't looked into the details in the
changes. If so, could we break out that part and commit it as soon as
possible? AFAIK Marko would be happy to have the global observer back.
And I would too.

ulrik



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

Re: [Freeciv-Dev] (PR#39821) Global Lists Bug... Can't Add to top of list?

[Ulrik Sverdrup]

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

Committed to S2_1, S2_2 and trunk revisions r14622 - r14624

Patches exactly as already posted

Ulrik

>From 7eed27385744eae2eeb75267209364158fd0dec3 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 24 Apr 2008 21:18:30 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?

The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.
---
 client/gui-gtk-2.0/wldlg.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index 29cccdc..0b1bab6 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -898,7 +898,8 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
   /* update widget sensitivity. */
   if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
 if (can_client_issue_orders()
-	&& ptr->pcity && city_owner(ptr->pcity) == game.player_ptr) {
+  && (!ptr->pcity || city_owner(ptr->pcity) == game.player_ptr)) {
+  /* if ptr->pcity is NULL, this is a global worklist */
   gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
-- 
1.5.5

>From aede16b3f7b792881a5bacc17d8aabbe2a78afeb Mon Sep 17 00:00:00 2001
From: englabenny <[EMAIL PROTECTED]>
Date: Thu, 24 Apr 2008 19:43:11 +
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?

The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.



git-svn-id: http://svn.gna.org/svn/freeciv/branches/[EMAIL PROTECTED] a0f10bec-cc02-0410-94fc-a9cfff90b4cd
---
 client/gui-gtk-2.0/wldlg.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index a3373d1..6bdf509 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -873,7 +873,8 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
   /* update widget sensitivity. */
   if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
 if (can_client_issue_orders()
-	&& ptr->pcity && city_owner(ptr->pcity) == client.conn.playing) {
+  && (!ptr->pcity || city_owner(ptr->pcity) == client.conn.playing)) {
+  /* if ptr->pcity is NULL, this is a global worklist */
   gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
-- 
1.5.5

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

Re: [Freeciv-Dev] 2.1.4 ready to go

[Ulrik Sverdrup]

2008/4/23, Daniel Markstedt <[EMAIL PROTECTED]>:
> Hi all,
>
>  The 2.1.4 packages are ready to go at ftp.freeciv.org/freeciv/stable -
>  I briefly smoketested the code from the source directory and it
>  compiles and executes, but didn't have time to test the install
>  scripts. Could someone just try to slap a make && make install on it
>  to see so all is ok?

It builds and installs fine.

Regards
ulrik
>
>  I updated PEOPLE but since I've not been following development recent
>  months I'm not quite in the position to write NEWS. If a kind soul
>  could take care of that (and maybe upload to sourceforge) I'll
>  announce the release within 24h. :)
>
>  Best,
>   ~Daniel
>

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

Re: [Freeciv-Dev] (PR#40209) A minor memory leak

[Ulrik Sverdrup]

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

2008/4/21, Marko Lindqvist <[EMAIL PROTECTED]>:
>
>  http://bugs.freeciv.org/Ticket/Display.html?id=40209 >
>
>
> On 21/04/2008, Elmo Todurov  wrote:
>  >
>  >  Now I want a cookie!
>  >  $ svn diff
>  >  Index: server/sernet.c
>  >  ===
>  >  --- server/sernet.c (revision 14605)
>  >  +++ server/sernet.c (working copy)
>  >  @@ -185,6 +185,7 @@
>  >line_internal = local_to_internal_string_malloc(line);
>  >(void) handle_stdin_input(NULL, line_internal, FALSE);
>  >free(line_internal);
>  >  +  free(line);
>  >
>  >readline_handled_input = TRUE;
>  >   }
>
>
>  Are you sure about this? Does readline really expect callback to free
>  the line? (and if it does, can it be bug in the specific readline
>  version you are using?)
>
>
>
>   - ML

A cursory look suggests Elmo is right.

That you should free the returned line is explicitly mentioned when
using the readline() call:

http://www.delorie.com/gnu/docs/readline/rlman_24.html#IDX174

No further mention at the reference for the alternative interface:

http://www.delorie.com/gnu/docs/readline/rlman_41.html#IDX288

Ulrik



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

Re: [Freeciv-Dev] (PR#39821) Global Lists Bug... Can't Add to top of list?

[Ulrik Sverdrup]

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

2008/4/15, Marko Lindqvist <[EMAIL PROTECTED]>:
>
>  http://bugs.freeciv.org/Ticket/Display.html?id=39821 >
>
>
> On 10/04/2008, Ulrik Sverdrup wrote:
>  >
>  >  Can someone test this? I can't find any other case than the global
>  >  worklist editor where pcity is NULL.
>
>
>  I don't think pcity can be NULL in any other case. Checking against
>  such case is still good thing to do.
>   I tested latest version. Seems ok to me.
>   I'll commit some fixes to S2_1 tomorrow and then hopefully freeze it
>  (S2_1 code part) for 2.1.4 testing. You can commit this one now, or
>  wait after 2.1.4)
>
>
>
>   - ML

Hello

I don't really have time to commit this week, I'm not at home. I
haven't yet set up a 2.2 tree for building and committing. I'll have
that working by next week.

I'm assuming this one is too late for 2.1.4 now, but if that's not the
case you could commit the patch in just S2_1 for me if you wanted.

Regards
Ulrik



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

Re: [Freeciv-Dev] (PR#39938) paratroopers disappear

[Ulrik Sverdrup]

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

2008/4/15, Marko Lindqvist <[EMAIL PROTECTED]>:
>
>  http://bugs.freeciv.org/Ticket/Display.html?id=39938 >
>
>
> On 10/04/2008, Ulrik Sverdrup wrote:
>  >
>  >  Trivial patch looks like this. Tested on trunk but is probably
>  >  harmless on any branch, including 2.1
>
>
>  Yes, this one should go to S2_1 (and other branches for now). For
>  S2_2 and TRUNK we should probably add new event category for unit
>  deaths other than normal battle.
>
>
>
>   - ML
>
I agree completely. Notice that this is similar to a bug I posted long ago:
#39412: Make sure Barbarian Leader message is displayed by default
http://bugs.freeciv.org/Ticket/Display.html?id=39412

Ulrik



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

[Freeciv-Dev] Fwd: (PR#39821) Global Lists Bug... Can't Add to top of list?

[Ulrik Sverdrup]

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

Sorry for the spam, Core. I was trying to send this to the list. I
really have to learn some things about operating email...

Here is an email I *should* have sent to the bugtracker yesterday.

Ulrik

-- Forwarded message --
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: 10.04.2008 21:55
Subject: Re: [Freeciv-Dev] (PR#39821) Global Lists Bug... Can't Add to
top of list?
To: [EMAIL PROTECTED]


2008/4/10, Ulrik Sverdrup <[EMAIL PROTECTED]>:

>
 >  http://bugs.freeciv.org/Ticket/Display.html?id=39821 >
 >
 >
 >  The worklist editor assumes that if ptr->pcity is NULL, you can't edit
 >  the worklist. This reverses that to allow the global worklist editor
 >  to enable all buttons.
 >
 >  The original reporter only mentions the prepend button but the append
 >  button should also have been affected.
 >
 >  Attached simple patches to trunk and 21 branches that fix this by
 >  modifying the sensitivity check.
 >
 >  Old check:
 >  client can issue commands AND pcity not NULL AND player owns pcity
 >  New check
 >  client can issue commands AND ( (pcity not NULL AND player owns pcity)
 >  OR pcity is NULL)
 >
 >  The "extra" null check is so that we don't get a crash on looking up
 >  an owner for city NULL, of course.
 >
 >  Can someone test this? I can't find any other case than the global
 >  worklist editor where pcity is NULL.
 >
 >  Ulrik
 >


Always embarrassing to send something twice. Staring at the logic
 above long enough, you'll see that it's simpler to write the
 conditional as in this patch, taking advantage of course of C's
 cross-circuiting rules.


 Ulrik

>From 3dbfd15b8272d12981e5de5be629f801ea62e584 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:41:50 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?

The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.

This is the fix for S2_1 branch
---
 client/gui-gtk-2.0/wldlg.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index 29cccdc..0b1bab6 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -898,7 +898,8 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
   /* update widget sensitivity. */
   if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
 if (can_client_issue_orders()
-	&& ptr->pcity && city_owner(ptr->pcity) == game.player_ptr) {
+  && (!ptr->pcity || city_owner(ptr->pcity) == game.player_ptr)) {
+  /* if ptr->pcity is NULL, this is a global worklist */
   gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
-- 
1.5.4.4

>From 10d5e1cb71b0293c58e854c2b5e76d091bdadeb0 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:41:50 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?

The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.
---
 client/gui-gtk-2.0/wldlg.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index a3373d1..6bdf509 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -873,7 +873,8 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
   /* update widget sensitivity. */
   if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
 if (can_client_issue_orders()
-	&& ptr->pcity && city_owner(ptr->pcity) == client.conn.playing) {
+  && (!ptr->pcity || city_owner(ptr->pcity) == client.conn.playing)) {
+  /* if ptr->pcity is NULL, this is a global worklist */
   gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
-- 
1.5.4.4

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

[Freeciv-Dev] (PR#10040) "progress of global warming" is useless

[Ulrik Sverdrup]

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

Fixed in the gtk2 client, it has a nice tooltip explaining it in
accurate terms. However, the SDL client offers no explanation on this.

ulrik



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

Re: [Freeciv-Dev] (PR#40167) Client crash on scenario load

[Ulrik Sverdrup]

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

Hello Marko and Pepeto

Ticket #40083 seems to have more info
http://bugs.freeciv.org/Ticket/Display.html?id=40083

Even though it curiously predates the server-side fix? I can at least
reproduce the backtrace there with curren trunk.

When it crashes, the server is still up, so you can connect back to it
and it won't crash. There you'll see that every single player is set
to AI, that's why the explorer moves as soon as the game starts.

The linked ticket also gives another clue: hagworld aka earth
medium/classic won't crash but all the others do.

The reason is of course that hagworld is in a different "format", just
grep server_state in the scenarios:

data/scenario/british-isles-85x80-v2.80.sav:server_state=0
data/scenario/earth-160x90-v2.sav:server_state=0
data/scenario/earth-80x50-v2.sav:server_state=0
data/scenario/europe-200x100-v2.sav:server_state=0
data/scenario/hagworld-120x60-v1.2.sav:server_state=2
data/scenario/iberian-peninsula-136x100-v1.0.sav:server_state=0
data/scenario/tutorial.sav:server_state=0

That is about as much of a clue I have. It seems this issue is pretty tricky

Regards
Ulrik



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

[Freeciv-Dev] (PR#39821) Global Lists Bug... Can't Add to top of list?

[Ulrik Sverdrup]

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

The worklist editor assumes that if ptr->pcity is NULL, you can't edit
the worklist. This reverses that to allow the global worklist editor
to enable all buttons.

The original reporter only mentions the prepend button but the append
button should also have been affected.

Attached simple patches to trunk and 21 branches that fix this by
modifying the sensitivity check.

Old check:
client can issue commands AND pcity not NULL AND player owns pcity
New check
client can issue commands AND ( (pcity not NULL AND player owns pcity)
OR pcity is NULL)

The "extra" null check is so that we don't get a crash on looking up
an owner for city NULL, of course.

Can someone test this? I can't find any other case than the global
worklist editor where pcity is NULL.

Ulrik

>From 32957c4d9520d8363ae891c18b9bb4fe7427586a Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:41:50 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?

The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.

This is a patch for S2_1 branch
---
 client/gui-gtk-2.0/wldlg.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index 29cccdc..4b4d133 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -898,7 +898,9 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
   /* update widget sensitivity. */
   if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
 if (can_client_issue_orders()
-	&& ptr->pcity && city_owner(ptr->pcity) == game.player_ptr) {
+  && ( (ptr->pcity && city_owner(ptr->pcity) == game.player_ptr)
+  || !ptr->pcity )) {
+  /* if ptr->pcity is NULL, this is a global worklist */
   gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
-- 
1.5.4.4

>From 425efab7beb72aec45daccad3ac03f1ddf20c110 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:41:50 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?

The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.
---
 client/gui-gtk-2.0/wldlg.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index a3373d1..6f39638 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -873,7 +873,9 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
   /* update widget sensitivity. */
   if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
 if (can_client_issue_orders()
-	&& ptr->pcity && city_owner(ptr->pcity) == client.conn.playing) {
+  && ( (ptr->pcity && city_owner(ptr->pcity) == client.conn.playing)
+  || !ptr->pcity )) {
+  /* if ptr->pcity is NULL, this is a global worklist */
   gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
   gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
-- 
1.5.4.4

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

[Freeciv-Dev] (PR#40138) Assert in exchange of city in v 2.1.3

[Ulrik Sverdrup]

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

Was this crash fixed by ticket #40185: [Patch] Fix AI crash when city
destroyed during trade negotiation ?

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

ulrik



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

[Freeciv-Dev] (PR#39938) paratroopers disappear

[Ulrik Sverdrup]

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

Trivial patch looks like this. Tested on trunk but is probably
harmless on any branch, including 2.1

ulrik

>From c8c28d54c5e6fa266a045a6cf78555abc54ec036 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 16:15:42 +0200
Subject: [PATCH] (PR#39938) paratroopers 'disapear' when dropped on protected city

Make sure the "paratroopers killed when dropped on city"-message is
displayed by default, by changing its message category to
Unit: Defender destroyed (E_UNIT_LOST), just like paradrops into the
ocean.
---
 server/unittools.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/server/unittools.c b/server/unittools.c
index 1ac2fdf..cd5ad7a 100644
--- a/server/unittools.c
+++ b/server/unittools.c
@@ -2199,7 +2199,7 @@ bool do_paradrop(struct unit *punit, struct tile *ptile)
   || is_non_allied_unit_tile(ptile, pplayer)) {
 map_show_circle(pplayer, ptile, unit_type(punit)->vision_radius_sq);
 maybe_make_contact(ptile, pplayer);
-notify_player(pplayer, ptile, E_UNIT_LOST_ATT,
+notify_player(pplayer, ptile, E_UNIT_LOST,
  _("Your %s was killed by enemy units at the "
"paradrop destination."),
  unit_name_translation(punit));
-- 
1.5.4.4

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

[Freeciv-Dev] (PR#40201) #39938 : Paratroopers disappear

[Ulrik Sverdrup]

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

There is a message, but this bug is due to that message being turned
off by default.

When a paratrooper is killed at its destination, a message of type
Unit: Attack failed is sent, which is turned off by default. However,
paradropping into the ocean (due to unnoticed terraforming), sends a
message of type Unit: Defender destroyed, which is shown by default.

Notice that these categories only affect the filtering and not the
actual content of the messages.

One easy solution is to use Unit: Defender destroyed (called
E_UNIT_LOST in the code) for the KIA case as well. Otherwise we could
create a new paratrooper category, or turn on more messages by
default.

Ulrik



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

Re: [Freeciv-Dev] (PR#39413) Effects-ize the calender

[Ulrik Sverdrup]

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

Hello

Would it be interesting to update this for the current trunk? If you
think the current draft works (mostly) well as designed, it should be
fairly easy to get this in, I looked at it yesterday.

I realize this bug has distinct parts
1. /set startyear
2. MinYear
3. Use Slow_Down_Timeline to "effects-ize the calendar"

The first one is the least intrusive.

Regards
Ulrik



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

[Freeciv-Dev] (PR#39917) Diplomacy model bug: War as default relation for (previously) uncontacted allies of allies

[Ulrik Sverdrup]

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

Bug in the diplomacy model reported against 2.1

Short description of the situation:
Your AI opponents A and B are allied.
1. You have never met B, but have alliance with A.
2. Now as you meet B, your relation to B changes from 'no contact' to
war, but simultaneously you get a ceasefire proposal.
3. Before you resolve diplomacy with B, A tells you they break the
alliance since you are now at war with their ally B.
4. I could resolve this by accepting B's proposal, then proposing
alliance with A.

The error at point 3 here is that the default relation is War, even to
allies of your allies. If this applies to peace parties to your allies
I don't know yet. This is somehow a design error or hole in the
diplomacy model. One way to resolve it is to use a different first
relation than war in point 2, for example cease-fire.

I regrettably have no savegame yet.



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

[Freeciv-Dev] (PR#39916) Diplomacy proposals last after end of turn

[Ulrik Sverdrup]

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

Reporting a bug in the Diplomacy code that affects (at least) the Gtk2
client in version 2.1.1.

If not answered, the initial Ceasefire proposal tabs are still not
closed after end of turn.

This means you can save this proposal and accept it several turns
later where (I think) the AI does not want it.

Steps to reproduce:
1. Meet your opponent for the first time, recieve a ceasefire
proposal. Neither accept nor cancel it.
2. During the next few turns, build an army, destroy some of the
opponent's cities.
3. When fitting, accept ceasefire.

Suggested resolution:
1. Close tab in the user interface
2. Sanity checks in the diplomacy code


Regards,
Ulrik "engla" Sverdrup



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

[Freeciv-Dev] (PR#15260) GTK2: interface quirks being observer

[Ulrik Sverdrup]

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

Bug [for global observers, not attached to player] :
- 'Wonders of the World' and 'Top Five Cities' should be
available but doesn't currently have any effect when selected.

The server did not allow PACKET_REPORT_REQ packets for non-attached
connections The patches add this type as allowed.

The patch for trunk is easy.

To patch 2.1 branch, I backported changes from r11590 to flag the packet
PACKET_SINGLE_WANT_HACK_REQ with handle-via-packet; then it 
too can be handled by server_handle_packet, generalizing the code. 
Due to this patch, 2.1 becomes much more similar in the code structure 
in the handle_packet_input function in srv_main.c


QUESTION: This patch allows even detached connections to send report
packets and get the reports back. Is this a fundamental problem? If
observers are not allowed at all in a game, they could still get this
information.
Index: server/srv_main.c
===
--- server/srv_main.c	(revision 13116)
+++ server/srv_main.c	(arbetskopia)
@@ -1110,6 +1110,7 @@
   if (type == PACKET_CHAT_MSG_REQ
   || type == PACKET_SINGLE_WANT_HACK_REQ
   || type == PACKET_NATION_SELECT_REQ
+  || type == PACKET_REPORT_REQ
   || type == PACKET_EDIT_MODE
   || type == PACKET_EDIT_TILE
   || type == PACKET_EDIT_UNIT
Index: server/hand_gen.c
===
--- server/hand_gen.c	(revision 13116)
+++ server/hand_gen.c	(arbetskopia)
@@ -312,6 +312,10 @@
   ((struct packet_spaceship_place *)packet)->num);
 return TRUE;
 
+  case PACKET_SINGLE_WANT_HACK_REQ:
+handle_single_want_hack_req(pconn, packet);
+return TRUE;
+
   default:
 return FALSE;
   }
Index: server/hand_gen.h
===
--- server/hand_gen.h	(revision 13116)
+++ server/hand_gen.h	(arbetskopia)
@@ -73,5 +73,7 @@
 void handle_conn_pong(struct connection *pc);
 void handle_spaceship_launch(struct player *pplayer);
 void handle_spaceship_place(struct player *pplayer, enum spaceship_place_type type, int num);
+struct packet_single_want_hack_req;
+void handle_single_want_hack_req(struct connection *pc, struct packet_single_want_hack_req *packet);
 
 #endif /* FC__HAND_GEN_H */
Index: server/srv_main.c
===
--- server/srv_main.c	(revision 13116)
+++ server/srv_main.c	(arbetskopia)
@@ -1068,18 +1068,16 @@
   }
   
   /* valid packets from established connections but non-players */
-  if (type == PACKET_CHAT_MSG_REQ) {
-handle_chat_msg_req(pconn,
-			((struct packet_chat_msg_req *) packet)->message);
+  if (type == PACKET_CHAT_MSG_REQ
+  || type == PACKET_SINGLE_WANT_HACK_REQ
+  || type == PACKET_REPORT_REQ) {
+if (!server_handle_packet(type, packet, NULL, pconn)) {
+  freelog(LOG_ERROR, "Received unknown packet %d from %s",
+	  type, conn_description(pconn));
+}
 return TRUE;
   }
 
-  if (type == PACKET_SINGLE_WANT_HACK_REQ) {
-handle_single_want_hack_req(pconn,
-		(struct packet_single_want_hack_req *) packet);
-return TRUE;
-  }
-
   pplayer = pconn->player;
 
   if(!pplayer) {
Index: server/gamehand.c
===
--- server/gamehand.c	(revision 13116)
+++ server/gamehand.c	(arbetskopia)
@@ -508,8 +508,7 @@
 the file values. Sends an answer to the client once it's done.
 **/
 void handle_single_want_hack_req(struct connection *pc,
- const struct packet_single_want_hack_req
- *packet)
+ struct packet_single_want_hack_req *packet)
 {
   struct section_file file;
   char *token = NULL;
Index: server/gamehand.h
===
--- server/gamehand.h	(revision 13116)
+++ server/gamehand.h	(arbetskopia)
@@ -28,10 +28,4 @@
 
 const char *new_challenge_filename(struct connection *pc);
 
-struct packet_single_want_hack_req;
-
-void handle_single_want_hack_req(struct connection *pc,
- const struct packet_single_want_hack_req
- *packet);
-
 #endif  /* FC__GAMEHAND_H */
Index: common/packets.def
===
--- common/packets.def	(revision 13116)
+++ common/packets.def	(arbetskopia)
@@ -1279,7 +1279,7 @@
 /*
  Below are the packets that control single-player mode.  
 */
-PACKET_SINGLE_WANT_HACK_REQ=108;cs,handle-per-conn,no-handle
+PACKET_SINGLE_WANT_HACK_REQ=108;cs,handle-per-conn,handle-via-packet
  STRING token[MAX_LEN_NAME];
 end
 
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39467) Bug: Game setup screen and main menu shown together

[Ulrik Sverdrup]

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

Under certain circumstances, the game screen is shown simultaneously
(overlapped by) with the main menu in the SDL client.

Steps to reproduce:
1. Connect to a server
2. The server cuts you or closes
3. Game screen _and_ main menu are both visible.

In #19204, a change to make sure that clients display the main menu was
checked in. This commit revealed this bug. (Previously the sdl client
would hang at the splash screen after the above steps, which was even
worse.)

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

[Freeciv-Dev] (PR#19204) superfluous call to set_client_page() in clinet.c?

[Ulrik Sverdrup]

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

Committed cproc's patch to 2.1 branch as r13115 and trunk as r13116.

(PR#19204) superfluous call to set_client_page() in clinet.c?

Halfway revert removal of "superfluous" call.

Call set_client_page to make sure the gtk client and sdl client
return to the main menu when the client disconnects from server
while still in CLIENT_PRE_GAME_STATE.

Patch and report by Cproc.

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

[Freeciv-Dev] (PR#17187) Move hut code into lua script

[Ulrik Sverdrup]

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

Committed the patch that takes away the hardcoded hut behavior and uses
lua event scripting. Committed to trunk as r13113. Final patch attached,
only spelling changes, but is is much larger as it includes the same
script.lua file for the rulesets default, civ1 and civ2.

Also committed a change (previously posted) to make move_unit in
server/unittools.c have return type void. In move_unit checks are done
(caller does that), and the return type is not really used right now.
Removed since we can't predict move_unit side effects due to hut events
any more.

Keeping this open until the dependency PR#39466 is closed.

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

[Freeciv-Dev] (PR#39466) make find unit type by unit role available in the scripting api

[Ulrik Sverdrup]

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

For #17187: Move hut code into lua script, and can be useful in the future.

>> One hut issue remains: Only Legions are given as mercenaries. This can
>> be solved by porting a method to find a unittype for role, or simplified
>> now that different rulesets can customize by script.
>We should probably port find_a_unit_type to find units by role to the
>scripting api.

To make scripts able to access ruleset data, we should make (for
example) the function find_a_unit_type available. It would fit in the
find module as for example:

find.unit_type_for_roles(role, role_tech)

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

[Freeciv-Dev] (PR#39451) Add signal emit to scripting api

[Ulrik Sverdrup]

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

Committed the attached patch to trunk as r13112, posted first three days
ago.

Rationale:

(PR#39451) Add signal emit to scripting api

Make sure the scripting api action give_technology sends a 
script signal message for every researched technology.
give_technology now takes a new argument reason that is sent
with the signal, and it should almost always be "hut" for
scripts.

It was decided that script signal emission should not be 
exposed to the scripting api.
diff --git a/server/scripting/api.pkg b/server/scripting/api.pkg
index d8a5986..3eee83d 100644
--- a/server/scripting/api.pkg
+++ b/server/scripting/api.pkg
@@ -494,5 +494,6 @@ void api_actions_create_city @ create_city (Player *pplayer, Tile *ptile,
 	const char *name);
 void api_actions_change_gold @ change_gold (Player *pplayer, int amount);
 Tech_Type *api_actions_give_technology @ give_technology (Player *pplayer,
-		Tech_Type *ptech);
+		Tech_Type *ptech,
+		const char *reason);
 
diff --git a/server/scripting/api_actions.c b/server/scripting/api_actions.c
index 61600bf..ad93f9c 100644
--- a/server/scripting/api_actions.c
+++ b/server/scripting/api_actions.c
@@ -21,6 +21,7 @@
 #include "unittools.h"
 
 #include "api_find.h"
+#include "script_signal.h"
 
 #include "api_actions.h"
 
@@ -59,10 +60,13 @@ void api_actions_change_gold(Player *pplayer, int amount)
   Give pplayer technology ptech.  Quietly returns A_NONE (zero) if 
   player already has this tech; otherwise returns the tech granted.
   Use NULL for ptech to grant a random tech.
+  sends script signal "tech_researched" with the given reason
 **/
-Tech_Type *api_actions_give_technology(Player *pplayer, Tech_Type *ptech)
+Tech_Type *api_actions_give_technology(Player *pplayer, Tech_Type *ptech,
+   const char *reason)
 {
   Tech_type_id id;
+  Tech_Type *result;
 
   if (ptech) {
 id = ptech->index;
@@ -76,7 +80,11 @@ Tech_Type *api_actions_give_technology(Player *pplayer, Tech_Type *ptech)
   if (get_invention(pplayer, id) != TECH_KNOWN) {
 do_free_cost(pplayer, id);
 found_new_tech(pplayer, id, FALSE, TRUE);
-return api_find_tech_type(id);
+result = api_find_tech_type(id);
+script_signal_emit("tech_researched", 3,
+   API_TYPE_TECH_TYPE, result, API_TYPE_PLAYER, pplayer,
+   API_TYPE_STRING, reason);
+return result;
   } else {
 return api_find_tech_type(A_NONE);
   }
diff --git a/server/scripting/api_actions.h b/server/scripting/api_actions.h
index 135340c..4273ea1 100644
--- a/server/scripting/api_actions.h
+++ b/server/scripting/api_actions.h
@@ -21,7 +21,8 @@ Unit *api_actions_create_unit(Player *pplayer, Tile *ptile, Unit_Type *ptype,
 			  int moves_left);
 void api_actions_create_city(Player *pplayer, Tile *ptile, const char *name);
 void api_actions_change_gold(Player *pplayer, int amount);
-Tech_Type *api_actions_give_technology(Player *pplayer, Tech_Type *ptech);
+Tech_Type *api_actions_give_technology(Player *pplayer, Tech_Type *ptech,
+   const char *reason);
 
 #endif
 
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39450) Make unit_type etc names available in the scripting api

[Ulrik Sverdrup]

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

Committed to trunk as r13111

It is possible to backport this change to the 2.1 branch, if needed or
wanted. 

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

[Freeciv-Dev] (PR#17187) Move hut code into lua script

[Ulrik Sverdrup]

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

2007/7/14, Ulrik Sverdrup <[EMAIL PROTECTED]>:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=17187 >
>
> Here are the three patches for this ticket and its two children:
> #39450: Make unit_type etc names available in the scripting api
>   api_class_names_v3.diff
> #39451: Add signal emit to scripting api
>   techsig_v1.diff
> #17187: Move hut code into lua script
>   hut_v3.diff
>

> Hut changes:
> Ported hut_get_barbarian as noted in previous emails. unleash_barbarians
> is available as an api action, as noted before.
>
> Introduced hut_get_limited for ai players with handicap H_LIMITEDHUTS;
> we cannot put this in the script file without passing irrelevant
> parameters to the hut_entered signal callback, or opening ai handicaps
> etc to the script api.
>
> hut_get_limited is a simplified version of the previous behavior; 25
> gold is given as before, but with 1/12 chance the unit is simply wiped
> (normally unleash_barbarians) would be called; but as the wipe is the
> most common outcome this was simplified.

I have here a patch to simplify: unit_enter_hut and move_unit should
return void, not bool. Currently move_unit returns bool, but the
returned value has no point; as stated in the function documentation
checks should be done by the caller, which they also are. The change
to return void has no side effects to current users, previously it did
semantically wrong things, for example;
if a paratrooper landed on a tile, wakes its neighbors and is killed
by auto-attack, the paradrop is reported internally as FALSE, not
successful. However this is ignored in the code and does not show
ofcourse.

The attached patch applies on top of the three previous.

> One hut issue remains: Only Legions are given as mercenaries. This can
> be solved by porting a method to find a unittype for role, or simplified
> now that different rulesets can customize by script.

We should probably port find_a_unit_type to find units by role to the
scripting api.

diff --git a/server/maphand.c b/server/maphand.c
index d065ab7..4979edd 100644
--- a/server/maphand.c
+++ b/server/maphand.c
@@ -1526,7 +1526,7 @@ static void bounce_units_on_terrain_change(struct tile *ptile)
 			   punit->tile, E_UNIT_RELOCATED,
 			   _("Moved your %s due to changing terrain."),
 			   unit_name_translation(punit));
-	  (void) move_unit(punit, ptile2, 0);
+	  move_unit(punit, ptile2, 0);
 	  if (punit->activity == ACTIVITY_SENTRY) {
 	handle_unit_activity_request(punit, ACTIVITY_IDLE);
 	  }
diff --git a/server/unithand.c b/server/unithand.c
index 32ba567..f46fcf6 100644
--- a/server/unithand.c
+++ b/server/unithand.c
@@ -1180,7 +1180,7 @@ bool handle_unit_move_request(struct unit *punit, struct tile *pdesttile,
   if (can_unit_move_to_tile_with_notify(punit, pdesttile, igzoc)) {
 int move_cost = map_move_cost_unit(punit, pdesttile);
 
-(void) move_unit(punit, pdesttile, move_cost);
+move_unit(punit, pdesttile, move_cost);
 
 return TRUE;
   } else {
diff --git a/server/unittools.c b/server/unittools.c
index 48965eb..6f54a10 100644
--- a/server/unittools.c
+++ b/server/unittools.c
@@ -1095,7 +1095,8 @@ bool teleport_unit_to_city(struct unit *punit, struct city *pcity,
 
 if (move_cost == -1)
   move_cost = punit->moves_left;
-return move_unit(punit, dst_tile, move_cost);
+move_unit(punit, dst_tile, move_cost);
+return TRUE;
   }
   return FALSE;
 }
@@ -2138,7 +2139,7 @@ bool do_airline(struct unit *punit, struct city *city2)
 		   _("%s transported succesfully."),
 		   unit_name_translation(punit));
 
-  (void) move_unit(punit, city2->tile, punit->moves_left);
+  move_unit(punit, city2->tile, punit->moves_left);
 
   /* airlift fields have changed. */
   send_city_info(city_owner(city1), city1);
@@ -2237,7 +2238,8 @@ bool do_paradrop(struct unit *punit, struct tile *ptile)
   {
 int move_cost = unit_type(punit)->paratroopers_mr_sub;
 punit->paradropped = TRUE;
-return move_unit(punit, ptile, move_cost);
+move_unit(punit, ptile, move_cost);
+return TRUE;
   }
 }
 
@@ -2273,18 +2275,16 @@ static bool hut_get_limited(struct unit *punit)
 }
 
 /**
-  Return FALSE if unit is known killed, TRUE means no information.
-  This is due to the effects in the script signal callback can not
-  be predicted.
+  Due to the effects in the scripted hut behavior can not be predicted,
+  unit_enter_hut returns nothing.
 **/
-static bool unit_enter_hut(struct unit *punit)
+static void unit_enter_hut(struct unit *punit)
 {
   struct player *pplayer = unit_owner(punit);
-  bool ok = TRUE;
   enum hut_behavior behavior = unit_class(punit)->hut_behavior;
   
   if

[Freeciv-Dev] (PR#17187) Move hut code into lua script

[Ulrik Sverdrup]

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

Here are the three patches for this ticket and its two children:
#39450: Make unit_type etc names available in the scripting api
  api_class_names_v3.diff
#39451: Add signal emit to scripting api
  techsig_v1.diff
#17187: Move hut code into lua script
  hut_v3.diff

Applies to trunk r13103
They are interdependent and should be applied in from top to bottom. I
used git to sort out the interlocking patches, apply to test with
cat ../api_class_names_v3.diff ../techsig_v1.diff ../hut_v3.diff  |
patch -p1
The patches can and should be checked in in succession, none of them
break the build.

Name api changes:
Now we have:
:rule_name()
:name_translation()
and for Nation_Type there is also:
:plural_translation()

Techsig changes:
the api action give_technology now takes a reason string as well; a
script signal with
the given reason is sent; it was decided in #39451 that the signal
events are so fundamental that scripts should not directly emit them.

Hut changes:
Ported hut_get_barbarian as noted in previous emails. unleash_barbarians
is available as an api action, as noted before.

Introduced hut_get_limited for ai players with handicap H_LIMITEDHUTS;
we cannot put this in the script file without passing irrelevant
parameters to the hut_entered signal callback, or opening ai handicaps
etc to the script api.

hut_get_limited is a simplified version of the previous behavior; 25
gold is given as before, but with 1/12 chance the unit is simply wiped
(normally unleash_barbarians) would be called; but as the wipe is the
most common outcome this was simplified.

One hut issue remains: Only Legions are given as mercenaries. This can
be solved by porting a method to find a unittype for role, or simplified
now that different rulesets can customize by script. 

Ready for comments
diff --git a/server/scripting/api.pkg b/server/scripting/api.pkg
index 6f0af93..d8a5986 100644
--- a/server/scripting/api.pkg
+++ b/server/scripting/api.pkg
@@ -94,16 +94,28 @@ struct Terrain {
 
 
 /* Class methods. */
+
+/* Player */
 int api_methods_player_num_cities
 	@ methods_player_num_cities (Player *pplayer);
 int api_methods_player_num_units
 	@ methods_player_num_units (Player *pplayer);
 
-bool api_methods_unit_type_has_flag
-	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
-bool api_methods_unit_type_has_role
-	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
-
+/* Government */
+const char *api_methods_government_rule_name
+	@ methods_government_rule_name (Government *pgovernment);
+const char *api_methods_government_name_translation
+	@ methods_government_name_translation (Government *pgovernment);
+
+/* Nation_Type */
+const char *api_methods_nation_type_rule_name
+	@ methods_nation_type_rule_name (Nation_Type *pnation);
+const char *api_methods_nation_type_name_translation
+	@ methods_nation_type_name_translation (Nation_Type *pnation);
+const char *api_methods_nation_type_plural_translation
+	@ methods_nation_type_plural_translation (Nation_Type *pnation);
+
+/* Building_Type */
 bool api_methods_building_type_is_wonder
 	@ methods_building_type_is_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_great_wonder
@@ -112,7 +124,32 @@ bool api_methods_building_type_is_small_wonder
 	@ methods_building_type_is_small_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_improvement
 	@ methods_building_type_is_improvement (Building_Type *pbuilding);
+const char *api_methods_building_type_rule_name
+	@ methods_building_type_rule_name (Building_Type *pbuilding);
+const char *api_methods_building_type_name_translation
+	@ methods_building_type_name_translation (Building_Type *pbuilding);
 
+/* Unit_Type */
+bool api_methods_unit_type_has_flag
+	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
+bool api_methods_unit_type_has_role
+	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
+const char *api_methods_unit_type_rule_name
+	@ methods_unit_type_rule_name (Unit_Type *punit_type);
+const char *api_methods_unit_type_name_translation
+	@ methods_unit_type_name_translation (Unit_Type *punit_type);
+
+/* Tech_Type */
+const char *api_methods_tech_type_rule_name
+	@ methods_tech_type_rule_name (Tech_Type *ptech);
+const char *api_methods_tech_type_name_translation
+	@ methods_tech_type_name_translation (Tech_Type *ptech);
+
+/* Terrain */
+const char *api_methods_terrain_rule_name
+	@ methods_terrain_rule_name (Terrain *pterrain);
+const char *api_methods_terrain_name_translation
+	@ methods_terrain_name_translation (Terrain *pterrain);
 
 $[
 -- Player methods.
@@ -133,6 +170,28 @@ function Unit:homecity()
   return find.city(self.owner, self.homecity_id)
 end
 
+-- Government methods
+function Government:rule_name()
+  return methods_government_rule_name(self)
+end
+
+function Government:name_translation()
+  return methods_government_name_translation(self)
+end

[Freeciv-Dev] (PR#39450) Make unit_type etc names available in the scripting api

[Ulrik Sverdrup]

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

Patch attached, applies to trunk r13103

Now we have:
:rule_name()
:name_translation()
and for Nation_Type there is also:
:plural_translation()
Index: server/scripting/api_methods.h
===
--- server/scripting/api_methods.h	(revision 13103)
+++ server/scripting/api_methods.h	(arbetskopia)
@@ -27,5 +27,21 @@
 bool api_methods_building_type_is_small_wonder(Building_Type *pbuilding);
 bool api_methods_building_type_is_improvement(Building_Type *pbuilding);
 
+/* rule name and translated name methods */
+const char *api_methods_government_rule_name(Government *pgovernment);
+const char *api_methods_government_name_translation(Government *pgovernment);
+const char *api_methods_nation_type_rule_name(Nation_Type *pnation);
+const char *api_methods_nation_type_name_translation(Nation_Type *pnation);
+const char *api_methods_nation_type_plural_translation(Nation_Type
+   *pnation);
+const char *api_methods_building_type_rule_name(Building_Type *pbuilding);
+const char *api_methods_building_type_name_translation(Building_Type 
+   *pbuilding);
+const char *api_methods_unit_type_rule_name(Unit_Type *punit_type);
+const char *api_methods_unit_type_name_translation(Unit_Type *punit_type);
+const char *api_methods_tech_type_rule_name(Tech_Type *ptech);
+const char *api_methods_tech_type_name_translation(Tech_Type *ptech);
+const char *api_methods_terrain_rule_name(Terrain *pterrain);
+const char *api_methods_terrain_name_translation(Terrain *pterrain);
 #endif
 
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg	(revision 13103)
+++ server/scripting/api.pkg	(arbetskopia)
@@ -94,16 +94,28 @@
 
 
 /* Class methods. */
+
+/* Player */
 int api_methods_player_num_cities
 	@ methods_player_num_cities (Player *pplayer);
 int api_methods_player_num_units
 	@ methods_player_num_units (Player *pplayer);
 
-bool api_methods_unit_type_has_flag
-	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
-bool api_methods_unit_type_has_role
-	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
+/* Government */
+const char *api_methods_government_rule_name
+	@ methods_government_rule_name (Government *pgovernment);
+const char *api_methods_government_name_translation
+	@ methods_government_name_translation (Government *pgovernment);
 
+/* Nation_Type */
+const char *api_methods_nation_type_rule_name
+	@ methods_nation_type_rule_name (Nation_Type *pnation);
+const char *api_methods_nation_type_name_translation
+	@ methods_nation_type_name_translation (Nation_Type *pnation);
+const char *api_methods_nation_type_plural_translation
+	@ methods_nation_type_plural_translation (Nation_Type *pnation);
+
+/* Building_Type */
 bool api_methods_building_type_is_wonder
 	@ methods_building_type_is_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_great_wonder
@@ -112,8 +124,33 @@
 	@ methods_building_type_is_small_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_improvement
 	@ methods_building_type_is_improvement (Building_Type *pbuilding);
+const char *api_methods_building_type_rule_name
+	@ methods_building_type_rule_name (Building_Type *pbuilding);
+const char *api_methods_building_type_name_translation
+	@ methods_building_type_name_translation (Building_Type *pbuilding);
 
+/* Unit_Type */
+bool api_methods_unit_type_has_flag
+	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
+bool api_methods_unit_type_has_role
+	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
+const char *api_methods_unit_type_rule_name
+	@ methods_unit_type_rule_name (Unit_Type *punit_type);
+const char *api_methods_unit_type_name_translation
+	@ methods_unit_type_name_translation (Unit_Type *punit_type);
 
+/* Tech_Type */
+const char *api_methods_tech_type_rule_name
+	@ methods_tech_type_rule_name (Tech_Type *ptech);
+const char *api_methods_tech_type_name_translation
+	@ methods_tech_type_name_translation (Tech_Type *ptech);
+
+/* Terrain */
+const char *api_methods_terrain_rule_name
+	@ methods_terrain_rule_name (Terrain *pterrain);
+const char *api_methods_terrain_name_translation
+	@ methods_terrain_name_translation (Terrain *pterrain);
+
 $[
 -- Player methods.
 function Player:is_human()
@@ -133,6 +170,28 @@
   return find.city(self.owner, self.homecity_id)
 end
 
+-- Government methods
+function Government:rule_name()
+  return methods_government_rule_name(self)
+end
+
+function Government:name_translation()
+  return methods_government_name_translation(self)
+end
+
+-- Nation_Type methods
+function Nation_Type:rule_name()
+  return methods_nation_type_rule_name(self)
+end
+
+function Nation_Type:name_translation()
+  retu

[Freeciv-Dev] (PR#39455) Warning: makes integer from pointer without a cast in menu.c

[Ulrik Sverdrup]

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

Committed patch to 2.1 as r13102 and trunk as r13103

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

Re: [Freeciv-Dev] (PR#39451) Add signal emit to scripting api

[Ulrik Sverdrup]

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

> That sounds better to me.  KISS.
>
> Remember, the lua code cannot do anything that requires understanding of
> the underlying structure, nor anything random (choosing), as that would
> break fundamental assumptions of the network, ruleset, and savegame code.

Good catch: The hut code that per has been working on (and now I),
uses api_utilities_random in server/scripting/api_utilities.c . That
is a random outcome on the server, and should be reproducible since it
uses myrand. Is this not safe in the long run?



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

Re: [Freeciv-Dev] (PR#39455) Warning: makes integer from pointer without a cast in menu.c

[Ulrik Sverdrup]

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

2007/7/14, William Allen Simpson <[EMAIL PROTECTED]>:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=39455 >
>
> Ulrik, as I learned the hard way myself, all developers should compile
> with ./autogen.sh --enable-debug

Thanks. You can check in that patch early since I broke the build; or
I can take care of it with your permission.



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

[Freeciv-Dev] (PR#39455)

[Ulrik Sverdrup]

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

Caused by the checkin in #15260. Here is a patch that works with both
the 2.1 and trunk branches.
Index: client/gui-gtk-2.0/menu.c
===
--- client/gui-gtk-2.0/menu.c	(revision 13101)
+++ client/gui-gtk-2.0/menu.c	(arbetskopia)
@@ -1270,6 +1270,7 @@
 const char *path =
   menu_path_remove_uline("/_Government/_Change Government");
 GtkWidget *parent = gtk_item_factory_get_widget(item_factory, path);
+bool attached_to_player = (game.player_ptr != NULL);
 
 if (parent) {
   GList *list, *iter;
@@ -1326,11 +1327,11 @@
 
 /* If the client is not attached to a player these reports are
  * disabled. */
-menus_set_sensitive("/_Reports/_Cities", game.player_ptr);
-menus_set_sensitive("/_Reports/_Units", game.player_ptr);
-menus_set_sensitive("/_Reports/_Economy", game.player_ptr);
-menus_set_sensitive("/_Reports/_Science", game.player_ptr);
-menus_set_sensitive("/_Reports/_Demographics", game.player_ptr);
+menus_set_sensitive("/_Reports/_Cities", attached_to_player);
+menus_set_sensitive("/_Reports/_Units", attached_to_player);
+menus_set_sensitive("/_Reports/_Economy", attached_to_player);
+menus_set_sensitive("/_Reports/_Science", attached_to_player);
+menus_set_sensitive("/_Reports/_Demographics", attached_to_player);
 menus_set_sensitive("/_Reports/S_paceship",
 			(game.player_ptr
 			 && game.player_ptr->spaceship.state != SSHIP_NONE));
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39451) Add signal emit to scripting api

[Ulrik Sverdrup]

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

I looked at this one, and it is hard.

The C API for emitting signals uses the varargs script_signal_emit, and
specifies type for each argument etc.

I was trying to get a script wrapper for this that would both type check
the arguments to the signal before emitting, and then passing the list
of "dynamically-typed" arguments from Lua to C. I can't figure out how
to do any of those two problems.

A simpler workaround would be for us to provide static copies, a
function for each possible sent signal, like for example:

signal.emit.tech_researched(Tech_Type *t, Player *p, enum tech_reason
reason) 

etc for each signal. 

As a third option, we could make more abstract functions for giving
techs etc so that it would not be necessary to initiate signals in the
code; really if a tech is given in a scenario script, the side effects
(signals etc) should be so fundamental that we shouldn't need to send
the signals manually.

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

Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api

[Ulrik Sverdrup]

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

I have worked through the patches one more time. I realized we have
the special case for nations, were we must provide plural name
translations as well. So for this class, we have three types:

nation_rule_name(const struct nation_type *pnation);
nation_name_translation(struct nation_type *pnation);
nation_plural_translation(struct nation_type *pnation);

According to what we have discussed we now have

:rule_name()
:translated_name()

and the logic would lead us to

:plural_name()  -- it is always translated.

But we could go for consistency the other way around and change our
mind and use:

:rule_name()
:name_translation()
:plural_translation()

to follow the C function names

Another inconsistency in our code I noticed though is that some types
(like tech/advance) use the index of the type, but others use the
whole struct (for example unit_type). Nothing script authors will need
to worry about of course.



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

Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api

[Ulrik Sverdrup]

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

Attached patch v1. Also attached test .sav file, that should work by
just loading it with the server, no need to even start the game.

Using suggested
:rule_name()
:translated_name()

Sorted everything in the order the types are defined, that is:
Government
Nation_Type
Building_Type
Unit_Type
Tech_Type
Terrain

Index: server/scripting/api_methods.h
===
--- server/scripting/api_methods.h	(revision 13101)
+++ server/scripting/api_methods.h	(arbetskopia)
@@ -27,5 +27,19 @@
 bool api_methods_building_type_is_small_wonder(Building_Type *pbuilding);
 bool api_methods_building_type_is_improvement(Building_Type *pbuilding);
 
+/* rule name and translated name methods */
+const char *api_methods_government_rule_name(Government *pgovernment);
+const char *api_methods_government_translated_name(Government *pgovernment);
+const char *api_methods_nation_type_rule_name(Nation_Type *pnation);
+const char *api_methods_nation_type_translated_name(Nation_Type *pnation);
+const char *api_methods_building_type_rule_name(Building_Type *pbuilding);
+const char *api_methods_building_type_translated_name(Building_Type 
+  *pbuilding);
+const char *api_methods_unit_type_rule_name(Unit_Type *punit_type);
+const char *api_methods_unit_type_translated_name(Unit_Type *punit_type);
+const char *api_methods_tech_type_rule_name(Tech_Type *ptech);
+const char *api_methods_tech_type_translated_name(Tech_Type *ptech);
+const char *api_methods_terrain_rule_name(Terrain *pterrain);
+const char *api_methods_terrain_translated_name(Terrain *pterrain);
 #endif
 
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg	(revision 13101)
+++ server/scripting/api.pkg	(arbetskopia)
@@ -94,16 +94,26 @@
 
 
 /* Class methods. */
+
+/* Player */
 int api_methods_player_num_cities
 	@ methods_player_num_cities (Player *pplayer);
 int api_methods_player_num_units
 	@ methods_player_num_units (Player *pplayer);
 
-bool api_methods_unit_type_has_flag
-	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
-bool api_methods_unit_type_has_role
-	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
+/* Government */
+const char *api_methods_government_rule_name
+	@ methods_government_rule_name (Government *pgovernment);
+const char *api_methods_government_translated_name
+	@ methods_government_translated_name (Government *pgovernment);
 
+/* Nation_Type */
+const char *api_methods_nation_type_rule_name
+	@ methods_nation_type_rule_name (Nation_Type *pnation);
+const char *api_methods_nation_type_translated_name
+	@ methods_nation_type_translated_name (Nation_Type *pnation);
+
+/* Building_Type */
 bool api_methods_building_type_is_wonder
 	@ methods_building_type_is_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_great_wonder
@@ -112,8 +122,33 @@
 	@ methods_building_type_is_small_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_improvement
 	@ methods_building_type_is_improvement (Building_Type *pbuilding);
+const char *api_methods_building_type_rule_name
+	@ methods_building_type_rule_name (Building_Type *pbuilding);
+const char *api_methods_building_type_translated_name
+	@ methods_building_type_translated_name (Building_Type *pbuilding);
 
+/* Unit_Type */
+bool api_methods_unit_type_has_flag
+	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
+bool api_methods_unit_type_has_role
+	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
+const char *api_methods_unit_type_rule_name
+	@ methods_unit_type_rule_name (Unit_Type *punit_type);
+const char *api_methods_unit_type_translated_name
+	@ methods_unit_type_translated_name (Unit_Type *punit_type);
 
+/* Tech_Type */
+const char *api_methods_tech_type_rule_name
+	@ methods_tech_type_rule_name (Tech_Type *ptech);
+const char *api_methods_tech_type_translated_name
+	@ methods_tech_type_translated_name (Tech_Type *ptech);
+
+/* Terrain */
+const char *api_methods_terrain_rule_name
+	@ methods_terrain_rule_name (Terrain *pterrain);
+const char *api_methods_terrain_translated_name
+	@ methods_terrain_translated_name (Terrain *pterrain);
+
 $[
 -- Player methods.
 function Player:is_human()
@@ -133,6 +168,24 @@
   return find.city(self.owner, self.homecity_id)
 end
 
+-- Government methods
+function Government:rule_name()
+  return methods_government_rule_name(self)
+end
+
+function Government:translated_name()
+  return methods_government_translated_name(self)
+end
+
+-- Nation_Type methods
+function Nation_Type:rule_name()
+  return methods_nation_type_rule_name(self)
+end
+
+function Nation_Type:translated_name()
+  return methods_nation_type_translated_name(self)
+end
+
 -- Building_Type methods.
 function Building_Type:build_shield_cost()
   return se

Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api

[Ulrik Sverdrup]

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

> > If we only make the translated name available, it should be clear that
> > it is not the rule name, so it should be name_translated()
> >
> No, it should be translated_name()  Consistency, always consistency.
> You don't want to have to grep half a dozen possible function names,
> even in this small project.  That gets rapidly tiresome, and you miss
> too many.
I meant to type translated_name().

Now I know what to do, so I'll try to work on this soon.



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

Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api

[Ulrik Sverdrup]

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

Thanks for replying to this, you are the one who knows the related code well.

2007/7/13, William Allen Simpson <[EMAIL PROTECTED]>:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=39450 >
>
> Ulrik Sverdrup wrote:
> > So we would have
> > Unit_Type:rule_name()
> > Unit_Type:name()
> > etc.
> >
> No, that would be rule_name() and translated_name()

I understand. I just try to think of that others who are not freeciv
coders should eventually use the interface, so I thought our
consistency standards didn't apply in the same way.

I thought: If we use both, one should be :name() to make sure that it
is the one you want to use in user messages.

If we only make the translated name available, it should be clear that
it is not the rule name, so it should be name_translated()

Disregarding all that and giving that discussion no weight, we don't
do anything wrong by sticking to the name conventions used in the rest
of the code.

> It seems a good idea, as it would cache the *_name pointers, but are
> there high performance issues for a scripted language?

No. I only thought it might be an abstraction thing; as you said
during the transition you wished that more code used the accessor
functions.


> > Design question: Should both :rule_name() and :name() be available?
> > I'm in favor of only the translated name, I'm not sure I know any uses
> > of the rule name.
> >
> Presumably for find_*_by_name(), which is always a rule_name!
>
> Easier to write them both, and have them in the code as needed, than not
> have them and need to await the next code release.  We've not been very
> fast at code releases

Yeah, but find by name only works on known rule names -- these
accessors are only there for when you get an object of unknown type
and want to (for example) print a message about it-- if you have an
unknown 'unit' do find.unit_type(unit.utype:name()) you could just as
well use unit:utype() ; and the same for other cases.

But on the other hand I agree that it is easy to write them both. Much
of the api generation for us is just many, many easily written short
pieces of code and this is just more of that.



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

[Freeciv-Dev] (PR#15260) GTK2: interface quirks being observer

[Ulrik Sverdrup]

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

Committed to trunk as r13100 and S2_1 as r13101.

gtk2 client: Deactivate irrelevant reports for observers. Make sure that
some shortcut keys (F1..F11 and shift+arrows) work for observers. Some
reindentation in the touched function. Based on patches by
[EMAIL PROTECTED]

server: Send an end_phase packet to observers at end of turn, otherwise
they don't get any and the messages pane fills up. Patch by Jason Dorje
Short

---

Only one issue in this ticket now remains:
- 'Wonders of the World' and 'Top Five Cities' should be
available but doesn't currently have any effect when selected.

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

[Freeciv-Dev] (PR#39450) Make rule names available in the scripting api

[Ulrik Sverdrup]

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

Resor Augusti 2007

Kolla åt Uta
Swebus: Buss till berlin/hannover
Flyg från berlin till kbh, vad kostar det?

Design proposal
Make use of the functions
*_rule_name
*_name_translation
and add wrappers for them as methods on the following API types:

Government
Nation_Type
Building_Type
Unit_Type
Tech_Type
Terrain

So we would have 
Unit_Type:rule_name()
Unit_Type:name()
etc.

Design question: Should both :rule_name() and :name() be available?
I'm in favor of only the translated name, I'm not sure I know any uses
of the rule name.

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

[Freeciv-Dev] (PR#17191) Fixes for tutorial

[Ulrik Sverdrup]

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

This patch should have been attached in the previous message

Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13095)
+++ data/scenario/tutorial.sav	(arbetskopia)
@@ -5,6 +5,13 @@
 
 [script]
 code=$
+function has_unit_type_name(unit, utype_name) 
+  return (unit.utype.id == find.unit_type(utype_name).id)
+end
+function has_tile_terrain_name(tile, terrain_name)
+  return (tile.terrain.id == find.terrain(terrain_name).id)
+end
+
 function turn_callback(turn, year)
   if turn == 0 then
 notify.event(nil, nil, E.TUTORIAL,
@@ -20,9 +27,9 @@
 function unit_moved_callback(unit, src_tile, dst_tile)
   if unit.owner:is_human() then
 if citiesbuilt == 0
-  and unit.type.name == 'Settlers'
-  and (dst_tile.terrain.name == 'Grassland'
-   or dst_tile.terrain.name == 'Plains') then  
+  and has_unit_type_name(unit, 'Settlers')
+  and (has_tile_terrain_name(dst_tile, 'Grassland')
+   or has_tile_terrain_name(dst_tile, 'Plains')) then  
   notify.event(unit.owner, dst_tile, E.TUTORIAL,
 _("This looks like a good place to build a city.  The next time this\n\
 unit gets a chance to move, press (b) to found a city.\n\
@@ -195,7 +202,7 @@
   if not unit.owner:is_human() then
 return
   end
-  if unit.type.name == 'Settlers' then
+  if has_unit_type_name(unit, 'Settlers') then
 if settlersbuilt == 0 then
   notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("You have built a settler unit.  Settlers are best used to build \n\
@@ -233,7 +240,7 @@
   if not city.owner:is_human() then
 return
   end
-  if building.name == 'Barracks' and not barracksmsg then
+  if building.id == find.building_type('Barracks').id and not barracksmsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("You have built a Barracks.  This building will make any military\n\
 units you build start out as veterans.  Veteran units are stronger\n\
@@ -255,7 +262,7 @@
   if not city.owner:is_human() then
 return
   end
-  if unittype.name == 'Settlers' and not nosettlermsg then
+  if unittype.id == find.unit_type('Settlers').id and not nosettlermsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("Your city cannot build a settler.  Settlers take one unit of\n\
 population to build, so a city of size one cannot build one without\n\
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#17191) Fixes for tutorial

[Ulrik Sverdrup]

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

Committed changes to 2.1 branch as r13098 and trunk as r13099.
Final patches attached.

Doing no spelling fixing since I don't know how that impacts 
translation. Two spelling errors in tutorial.sav remain in 2.1 branch.
Keeping this ticket open for that, patch to fix the spelling attached.
(spelling fixes by Daniel Markstedt)
Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13098)
+++ data/scenario/tutorial.sav	(arbetskopia)
@@ -279,7 +279,7 @@
 _("You have built your first military unit!  Military units have two\n\
 basic purposes: attack and defense.  Each unit has an attack strength\n\
 and a defense strength.  While a Warriors is a measly 1/1, a Phalanx\n\
-is a must stronger defender with 2 defense (1/2).  A Catapult is a good\n\
+is a much stronger defender with 2 defense (1/2).  A Catapult is a good\n\
 attacking unit because it has 6 attack (6/1).\n\
 \n\
 Usually it is a good idea to keep one or two defenders in each city.\n\
@@ -363,7 +363,7 @@
   if not hutmsg then
 notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("Your unit has found a Hut.  These are small villages scattered across\n\
-the landscape.  When a unit enters one several things may happen.  The\n\
+the landscape.  When a unit enters one, several things may happen.  The\n\
 most likely outcome is that you will find resources worth a small\n\
 amount of gold.  However it is also possible to find technologies or\n\
 mercenary units inside a hut.  Some huts contain native settlers\n\
Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13097)
+++ data/scenario/tutorial.sav	(revision 13098)
@@ -5,6 +5,13 @@
 
 [script]
 code=$
+function has_unit_type_name(unit, utype_name) 
+  return (unit.utype.id == find.unit_type(utype_name).id)
+end
+function has_tile_terrain_name(tile, terrain_name)
+  return (tile.terrain.id == find.terrain(terrain_name).id)
+end
+
 function turn_callback(turn, year)
   if turn == 0 then
 notify.event(nil, nil, E.TUTORIAL,
@@ -20,9 +27,9 @@
 function unit_moved_callback(unit, src_tile, dst_tile)
   if unit.owner:is_human() then
 if citiesbuilt == 0
-  and unit:type().name == 'Settlers'
-  and (dst_tile:terrain().name == 'Grassland'
-   or dst_tile:terrain().name == 'Plains') then  
+  and has_unit_type_name(unit, 'Settlers')
+  and (has_tile_terrain_name(dst_tile, 'Grassland')
+   or has_tile_terrain_name(dst_tile, 'Plains')) then  
   notify.event(unit.owner, dst_tile, E.TUTORIAL,
 _("This looks like a good place to build a city.  The next time this\n\
 unit gets a chance to move, press (b) to found a city.\n\
@@ -195,7 +202,7 @@
   if not unit.owner:is_human() then
 return
   end
-  if unit:type().name == 'Settlers' then
+  if has_unit_type_name(unit, 'Settlers') then
 if settlersbuilt == 0 then
   notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("You have built a settler unit.  Settlers are best used to build \n\
@@ -233,7 +240,7 @@
   if not city.owner:is_human() then
 return
   end
-  if building.name == 'Barracks' and not barracksmsg then
+  if building.id == find.building_type('Barracks').id and not barracksmsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("You have built a Barracks.  This building will make any military\n\
 units you build start out as veterans.  Veteran units are stronger\n\
@@ -255,7 +262,7 @@
   if not city.owner:is_human() then
 return
   end
-  if unittype.name == 'Settlers' and not nosettlermsg then
+  if unittype.id == find.unit_type('Settlers').id and not nosettlermsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("Your city cannot build a settler.  Settlers take one unit of\n\
 population to build, so a city of size one cannot build one without\n\
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39382) civ1 and civ2 rulesets crash, no sea barbarians, bad tech Never

[Ulrik Sverdrup]

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

To resolve the last item in this bug, the "bad tech Never" message for
the civ1 ruleset; trunk requires a req for Airbase that is always false.
Here is a small patch.
(The requirement "None" is always active, and negated it is never active)
Index: data/civ1/terrain.ruleset
===
--- data/civ1/terrain.ruleset	(revision 13094)
+++ data/civ1/terrain.ruleset	(arbetskopia)
@@ -939,8 +939,8 @@
 graphic_alt  = "-"
 activity_gfx = "unit.airbase"
 reqs =
-{ "type", "name", "range"
-  "Tech", "Never", "Player"
+{ "type", "name", "range", "negated"
+  "None", "", "", 1
 }
 gui_type = "Airbase"
 native_to= "Air", "Missile"
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#13215) AI choice problems in civ1 ruleset

[Ulrik Sverdrup]

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

(PR#13215) AI choice problems in civ1 ruleset
(PR#39399) 2.1 Ancients modpack bug

Combined these tickets; both the civ1 and ancients rulesets have a
'simplified' list of alternatives in the early game which gives this
behaviour from the ai.

In civ1 there is no Coinage and in Ancients there is no Coinage or
NonMil or even Workers (the Settlers in Ancients can only found cities).

According to the code error text, this is a bug in the ruleset. But the
documentation does not say that units with unit flags NonMil, Settlers
and possibly others should be available from the start.

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

[Freeciv-Dev] (PR#39441) tracking release 2.0.10

[Ulrik Sverdrup]

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

Further about savegame compatibility:
In 2.1 we introduced the $..$ delimiter for secfiles for code blocks. 

First it was read-only, but that caused ticket 39442: So I built upon
that in http://bugs.freeciv.org/Ticket/Display.html?id=39442 so that
saves with code blocks are probably not 2.0-compatible anymore. That
change could maybe be backed out for S2_1 of course, making $..$
read-only again.

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

Re: [Freeciv-Dev] (PR#39441) tracking release 2.0.10

[Ulrik Sverdrup]

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

2007/7/11, William Allen Simpson <[EMAIL PROTECTED]>:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=39441 >
>
> Ulrik Sverdrup wrote:
> > http://bugs.freeciv.org/Ticket/Display.html?id=19044 >
> >
> > Just for information, this ticket is open for 2.0.x:
> > #19044: 2.0 => 2.1 forward compatibility
> >
> No, it should be open for 2.1.  Forward means (as the subject says)
> from 2.0 to 2.1.  (This is also known as "backward" compatibility.)
>
> Of course, the subject could be wrong as written.
>
> The other way, 2.1 => 2.0 would be "reverse" compatibility.  I have no
> interest in retrofitting old versions to read newer versions.
>
> Indeed, 2.1 doesn't save map.l lines, so 2.0 will exit with error.
>
> We should be able to read old savegames, but not those that are
> completely incompatible.  AFAIK, the current cutoff is 1.14.x.

I'm getting confused! :)

But, the content of the ticket I linked to is about changing S2_0 to
read 2.1 savegames better. So it is (was?) a bug for 2.0.x, invalid or
not.

Ulrik Sverdrup



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

[Freeciv-Dev] (PR#39413) Effects-ize the calendar

[Ulrik Sverdrup]

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

New version of the patch; now split up into three parts:
effects_timeline_startyear_v3.diff startyear server option
effects_timeline_doc_ruleset_v3.diff MinYear Req type, Effects and
modifications to game_next_year
effects_timeline_doc_ruleset_v3.diff Modifications to README.effects and
civ1, civ2 and default rulesets

Only changes from previous version: removed rounding in game_next_year.
Added the step 15 years/turn for symmetry; it is not used in any default
ruleset but then we have a symmetric list of year steps: 50, 25, 20, 15,
10, 5, 2, 1

The startyear option discards the year 0. We should really interpret
that as year 1 AD, but setting startyear to 0 is disallowed since that
year is never reached in the regular game otherwise, and there is no
possibility to change the value in the validation callback
startyear_callback in server/settings.c.
Index: server/cityturn.c
===
--- server/cityturn.c	(revision 13092)
+++ server/cityturn.c	(arbetskopia)
@@ -888,6 +888,20 @@
  API_TYPE_CITY, pcity,
  API_TYPE_STRING, "need_terrainclass");
 	  break;
+	case REQ_MINYEAR:
+	  /* FIXME: if negated: we should skip rather than postpone,
+	   * since we'll never be able to meet this req... */
+	  notify_player(pplayer, pcity->tile, E_CITY_CANTBUILD,
+			   _("%s can't build %s from the worklist; "
+ "Only available from %s.  Postponing..."),
+			   pcity->name,
+			   get_impr_name_ex(pcity, building->index),
+			   textyear(preq->source.value.minyear));
+	  script_signal_emit("building_cant_be_built", 3,
+ API_TYPE_BUILDING_TYPE, building,
+ API_TYPE_CITY, pcity,
+ API_TYPE_STRING, "need_minyear");
+	  break;
 	case REQ_NONE:
 	case REQ_LAST:
 	  assert(0);
Index: common/effects.c
===
--- common/effects.c	(revision 13092)
+++ common/effects.c	(arbetskopia)
@@ -93,6 +93,7 @@
   "No_Incite",
   "Gain_AI_Love",
   "Slow_Down_Timeline",
+  "Slow_Down_Timeline_2",
   "Civil_War_Chance",
   "Empire_Size_Base",
   "Empire_Size_Step",
Index: common/effects.h
===
--- common/effects.h	(revision 13092)
+++ common/effects.h	(arbetskopia)
@@ -81,6 +81,7 @@
   EFT_NO_INCITE,
   EFT_GAIN_AI_LOVE,
   EFT_SLOW_DOWN_TIMELINE,
+  EFT_SLOW_DOWN_TIMELINE_2, /* Space module tech slowdown */
   EFT_CIVIL_WAR_CHANCE,
   EFT_EMPIRE_SIZE_BASE, /* +1 unhappy when more than this cities */
   EFT_EMPIRE_SIZE_STEP, /* adds additional +1 unhappy steps to above */
Index: common/game.c
===
--- common/game.c	(revision 13092)
+++ common/game.c	(arbetskopia)
@@ -431,8 +431,10 @@
 ***/
 int game_next_year(int year)
 {
-  const int slowdown = (game.info.spacerace
-			? get_world_bonus(EFT_SLOW_DOWN_TIMELINE) : 0);
+  const int calendar_slowdown = get_world_bonus(EFT_SLOW_DOWN_TIMELINE);
+  const int space_slowdown = (game.info.spacerace
+			? get_world_bonus(EFT_SLOW_DOWN_TIMELINE_2) : 0);
+	int inc;
 
   if (year == 1) /* hacked it to get rid of year 0 */
 year = 0;
@@ -450,22 +452,31 @@
* about 1900 AD
*/
 
-  /* Note the slowdown operates even if Enable_Space is not active.  See
-   * README.effects for specifics. */
-  if (year >= 1900 || (slowdown >= 3 && year > 0)) {
-year += 1;
-  } else if (year >= 1750 || slowdown >= 2) {
-year += 2;
-  } else if (year >= 1500 || slowdown >= 1) {
-year += 5;
-  } else if( year >= 1000 )
-year += 10;
-  else if( year >= 0 )
-year += 20;
-  else if( year >= -1000 ) /* used this line for tuning (was -1250) */
-year += 25;
-  else
-year += 50; 
+  /* Calendar slowdowns commented with years in the default ruleset
+   * Note the space_slowdown operates even if Enable_Space is not active.  
+   * See README.effects for specifics. */
+  if (calendar_slowdown >= 7 || space_slowdown >= 3 ) { /*1900*/
+if (year == 0) /* year 0 hack */
+  inc = 2;
+else
+  inc = 1;
+  } else if (calendar_slowdown >= 6 || space_slowdown >= 2) { /* >=  1750 */
+inc = 2;
+  } else if (calendar_slowdown >= 5 || space_slowdown >= 1) { /* >=  1500 */
+inc = 5;
+  } else if( calendar_slowdown >= 4 ) {/* >=  1000 */
+inc = 10;
+  } else if( calendar_slowdown >= 3 ) {/*(not used)*/
+inc = 15;
+  } else if( calendar_slowdown >= 2 ) {/* >= 0 */
+inc = 20;
+  } else if( calendar_slowdown >= 1 ) {/* >= -1000 */
+inc = 25;
+  } else {
+inc = 50;
+  }
+  
+  year += inc;
 
   if (year == 0) 
 year = 1;
Index: common/requirements.c
===
--- common/requirements.c	(revision 13092)
+++ common/requirements.c	(arbetskopia)
@@ -43,7 +43,8 @@
   "Spe

[Freeciv-Dev] (PR#39441) tracking release 2.0.10

[Ulrik Sverdrup]

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

Just for information, this ticket is open for 2.0.x:
#19044: 2.0 => 2.1 forward compatibility

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

[Freeciv-Dev] (PR#36323) 2.1 svn bugs

[Ulrik Sverdrup]

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

> [EMAIL PROTECTED] - Søn. 25. Feb. 2007 08:48:03]:
> 
> > Interesting glitch. Did you USE to have a city there?
> 
> Nope, nowhere near. I've seen this glitch a few times since as well.
> Save games don't have history to determine the cause?
> 
The territory owned near Edinburgh has the fortress at its source. You
won't lose that until someone conquers your fortress.

Referring to #39394: Rigid border rules in S2_1

Btw, the sciencebox crash is probably fixed.

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

[Freeciv-Dev] (PR#39422) [patch] Scroll city style selector

[Ulrik Sverdrup]

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

Committed patch to 2.1 branch as r13090 and trunk as r13091

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

[Freeciv-Dev] (PR#17191) Fixes for tutorial

[Ulrik Sverdrup]

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

> [wsimpson - Tir. 10. Jul. 2007 22:00:55]:
> 
> To be consistent with other naming conventions, that should be:
> 
> has_unit_type_name(unit, rule_name)
> 
> because its argument is a unit, not a utype.
> 
> ===
> 
> Likewise,
> 
> function has_tile_terrain_name(tile, rule_name)
> 

Absolutely. If it was my scenario, convenience function names could be
sloppy. This one could be frequently copied and edited though so it is
right.

Also, it's sad that the == operator doesn't work on Unit_Types and the
like, it seems to go after reference (actual instance) equality, and the
id comparison is all I've got to reliably work.

Also, I managed to attach v1 and not v2 last time, that's the reason for
 the unneeded print call.

Attached v3 with your suggested changes

Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13088)
+++ data/scenario/tutorial.sav	(arbetskopia)
@@ -5,6 +5,13 @@
 
 [script]
 code=$
+function has_unit_type_name(unit, utype_name) 
+  return (unit.utype.id == find.unit_type(utype_name).id)
+end
+function has_tile_type_name(tile, terrain_name)
+  return (tile.terrain.id == find.terrain(terrain_name).id)
+end
+
 function turn_callback(turn, year)
   if turn == 0 then
 notify.event(nil, nil, E.TUTORIAL,
@@ -20,9 +27,9 @@
 function unit_moved_callback(unit, src_tile, dst_tile)
   if unit.owner:is_human() then
 if citiesbuilt == 0
-  and unit.type.name == 'Settlers'
-  and (dst_tile.terrain.name == 'Grassland'
-   or dst_tile.terrain.name == 'Plains') then  
+  and has_unit_type_name(unit, 'Settlers')
+  and (has_tile_type_name(dst_tile, 'Grassland')
+   or has_tile_type_name(dst_tile, 'Plains')) then  
   notify.event(unit.owner, dst_tile, E.TUTORIAL,
 _("This looks like a good place to build a city.  The next time this\n\
 unit gets a chance to move, press (b) to found a city.\n\
@@ -195,7 +202,7 @@
   if not unit.owner:is_human() then
 return
   end
-  if unit.type.name == 'Settlers' then
+  if has_unit_type_name(unit, 'Settlers') then
 if settlersbuilt == 0 then
   notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("You have built a settler unit.  Settlers are best used to build \n\
@@ -233,7 +240,7 @@
   if not city.owner:is_human() then
 return
   end
-  if building.name == 'Barracks' and not barracksmsg then
+  if building.id == find.building_type('Barracks').id and not barracksmsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("You have built a Barracks.  This building will make any military\n\
 units you build start out as veterans.  Veteran units are stronger\n\
@@ -255,7 +262,7 @@
   if not city.owner:is_human() then
 return
   end
-  if unittype.name == 'Settlers' and not nosettlermsg then
+  if unittype.id == find.unit_type('Settlers').id and not nosettlermsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("Your city cannot build a settler.  Settlers take one unit of\n\
 population to build, so a city of size one cannot build one without\n\
Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13088)
+++ data/scenario/tutorial.sav	(arbetskopia)
@@ -5,6 +5,13 @@
 
 [script]
 code=$
+function has_unit_type_name(unit, utype_name) 
+  return (unit.utype.id == find.unit_type(utype_name).id)
+end
+function has_tile_type_name(tile, terrain_name)
+  return (tile.terrain.id == find.terrain(terrain_name).id)
+end
+
 function turn_callback(turn, year)
   if turn == 0 then
 notify.event(nil, nil, E.TUTORIAL,
@@ -20,9 +27,9 @@
 function unit_moved_callback(unit, src_tile, dst_tile)
   if unit.owner:is_human() then
 if citiesbuilt == 0
-  and unit:type().name == 'Settlers'
-  and (dst_tile:terrain().name == 'Grassland'
-   or dst_tile:terrain().name == 'Plains') then  
+  and has_unit_type_name(unit, 'Settlers')
+  and (has_tile_type_name(dst_tile, 'Grassland')
+   or has_tile_type_name(dst_tile, 'Plains')) then  
   notify.event(unit.owner, dst_tile, E.TUTORIAL,
 _("This looks like a good place to build a city.  The next time this\n\
 unit gets a chance to move, press (b) to found a city.\n\
@@ -195,7 +202,7 @@
   if not unit.owner:is_human() then
 return
   end
-  if unit:type().name == 'Settlers' then
+  if has_unit_type_name(unit, 'Settlers') then
 if settlersbuilt == 0 then
   notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("You have built a settler unit.  Settlers are best used to build \n\
@@ -233,7 +240,7 @@
   if not city.owner:is_human() then
 return
   end
-  if building.name == 'Barracks' and not barracksmsg then
+  if building.id == find.building_type('Barracks').id and not barracksmsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("You have built a Barracks.  This building will make any mi

[Freeciv-Dev] (PR#15260) GTK2: interface quirks being observer

[Ulrik Sverdrup]

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

Consolidated the above posted patches, ready for commit to trunk and S2_1
disable_reports.diff
end_phase.diff
observer_keys.diff

Changed the observer keys handling a bit: Now the shift-arrow keys to
scroll the mapview work as well, just like center on capital (not when
being global observer, then the message "Oh my, You seem to have no
capital" is generated, which seems harmless.

The logic was also simplified in key handling: return if observer after
having handled shift-key events. Removal of the large else clause caused
a lot of reindenting in the patch, but no changes.


Index: server/srv_main.c
===
--- server/srv_main.c	(revision 13088)
+++ server/srv_main.c	(arbetskopia)
@@ -759,6 +759,14 @@
 
   freelog(LOG_DEBUG, "Endturn");
 
+  /* Hack: because observer players never get an end-phase packet we send
+   * one here.  It would be better perhaps to have a full end-turn packet. */
+  conn_list_iterate(game.est_connections, pconn) {
+if (!pconn->player) {
+  send_packet_end_phase(pconn);
+}
+  } conn_list_iterate_end;
+
   map_calculate_borders();
 
   /* Output some AI measurement information */
Index: client/gui-gtk-2.0/gui_main.c
===
--- client/gui-gtk-2.0/gui_main.c	(revision 13088)
+++ client/gui-gtk-2.0/gui_main.c	(arbetskopia)
@@ -455,89 +455,93 @@
 return FALSE;
   }
 
-  if (!client_is_observer()) { /* FIXME: is this check right? */
-if ((ev->state & GDK_SHIFT_MASK)) {
-  switch (ev->keyval) {
-	case GDK_Left:
-	  scroll_mapview(DIR8_WEST);
-	  return TRUE;
 
-	case GDK_Right:
-	  scroll_mapview(DIR8_EAST);
-	  return TRUE;
+  if ((ev->state & GDK_SHIFT_MASK)) {
+switch (ev->keyval) {
+case GDK_Left:
+  scroll_mapview(DIR8_WEST);
+  return TRUE;
 
-	case GDK_Up:
-	  scroll_mapview(DIR8_NORTH);
-	  return TRUE;
+case GDK_Right:
+  scroll_mapview(DIR8_EAST);
+  return TRUE;
 
-	case GDK_Down:
-	  scroll_mapview(DIR8_SOUTH);
-	  return TRUE;
+case GDK_Up:
+  scroll_mapview(DIR8_NORTH);
+  return TRUE;
 
-	case GDK_Home:
-	  key_center_capital();
-	  return TRUE;
+case GDK_Down:
+  scroll_mapview(DIR8_SOUTH);
+  return TRUE;
 
-	case GDK_Return:
-	case GDK_KP_Enter:
-	  key_end_turn();
-	  return TRUE;
+case GDK_Home:
+  key_center_capital();
+  return TRUE;
 
-case GDK_Page_Up:
-  g_signal_emit_by_name(main_message_area, "move_cursor",
-			  GTK_MOVEMENT_PAGES, -1, FALSE);
-  return TRUE;
+case GDK_Return:
+case GDK_KP_Enter:
+  key_end_turn();
+  return TRUE;
 
-case GDK_Page_Down:
-  g_signal_emit_by_name(main_message_area, "move_cursor",
-			  GTK_MOVEMENT_PAGES, 1, FALSE);
-  return TRUE;
-  
-	default:
-	  break;
-  }
+case GDK_Page_Up:
+  g_signal_emit_by_name(main_message_area, "move_cursor",
+	  GTK_MOVEMENT_PAGES, -1, FALSE);
+  return TRUE;
+
+case GDK_Page_Down:
+  g_signal_emit_by_name(main_message_area, "move_cursor",
+	  GTK_MOVEMENT_PAGES, 1, FALSE);
+  return TRUE;
+
+default:
+  break;
 }
+  }
+  /* Return here if observer */
+  if (client_is_observer()) {
+return FALSE;
+  }
 
-if (GTK_WIDGET_HAS_FOCUS(map_canvas)) {
-  switch (ev->keyval) {
-case GDK_Up:
-  key_unit_move(DIR8_NORTH);
-  return TRUE;
+  if (GTK_WIDGET_HAS_FOCUS(map_canvas)) {
+switch (ev->keyval) {
+case GDK_Up:
+  key_unit_move(DIR8_NORTH);
+  return TRUE;
 
-case GDK_Page_Up:
-  key_unit_move(DIR8_NORTHEAST);
-  return TRUE;
+case GDK_Page_Up:
+  key_unit_move(DIR8_NORTHEAST);
+  return TRUE;
 
-case GDK_Right:
-  key_unit_move(DIR8_EAST);
-  return TRUE;
+case GDK_Right:
+  key_unit_move(DIR8_EAST);
+  return TRUE;
 
-case GDK_Page_Down:
-  key_unit_move(DIR8_SOUTHEAST);
-  return TRUE;
+case GDK_Page_Down:
+  key_unit_move(DIR8_SOUTHEAST);
+  return TRUE;
 
-case GDK_Down:
-  key_unit_move(DIR8_SOUTH);
-  return TRUE;
+case GDK_Down:
+  key_unit_move(DIR8_SOUTH);
+  return TRUE;
 
-case GDK_End:
-  key_unit_move(DIR8_SOUTHWEST);
-  return TRUE;
-  
-case GDK_Left:
-  key_unit_move(DIR8_WEST);
-  return TRUE;
+case GDK_End:
+  key_unit_move(DIR8_SOUTHWEST);
+  return TRUE;
+  
+case GDK_Left:
+  key_unit_move(DIR8_WEST);
+  return TRUE;
 
-case GDK_Home:		
-  key_unit_move(DIR8_NORTHWEST);
-	  return TRUE;
+case GDK_Home:		
+  key_unit_move(DIR8_NORTHWEST);
+  return TRUE;
 
-	default:
-	  break;
-  }
+default:
+  break;
 }
+  }
 
-assert(MAX_NUM_BATTLEGROUPS == 4);
+  assert(M

[Freeciv-Dev] (PR#19204) superfluous call to set_client_page() in clinet.c?

[Ulrik Sverdrup]

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

The patch attached by cproc is needed to return the client(s) to the
main page when the server disconnects in a lot of cases. It should
probably be committed soon.

> [dmarks - Tir. 03. Jul. 2007 02:48:09]:
> 
> S2_1 r13041 on MacOSX 10.3.9:
> 
> To reproduce, start a new civserver, join it with the SDL client,
> while the client is showing the pregame screen, terminate civserver;
> now click the Back button in the client and the game freezes showing
> the start splash without a main menu.
> 
>  ~Daniel
> 

This issue is fixed by cproc's patch, but another bug shows; when the
client now goes back to the main page, the main page is only overlaid on
the 'game setup' page and they both show and overlap each other.

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

[Freeciv-Dev] (PR#39451) Add signal emit to scripting api

[Ulrik Sverdrup]

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

Allow signals to be emitted from Lua scripts.

Add a wrapper for script_signal_emit to the signal module.

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

[Freeciv-Dev] (PR#39442) Lua script newlines not restored correctly from save

[Ulrik Sverdrup]

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

Committed to S2_1 as r13087 and trunk as r13088

(PR#39442) Lua script newlines not restored correctly from save 

Make escaped an attribute of entry so that it can be carried over from
load to save

Changed moutstr so that it takes a full_escapes argument
just like minstr. moutstr to returns a string with
delimiters to simplify the code throughout.

Add secfile_insert_str_noescape so that noescaped strings (script.code
and script.vars) can be inserted.

Small refactoring: added entry_init(struct *entry)

Now script.code and script.vars use secfile_insert_str_noescape

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

[Freeciv-Dev] (PR#17187) Move hut code into lua script

[Ulrik Sverdrup]

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

Updated the patch to the latest revision trunk. 

The patch is almost ready but depends on #39450: Make rule names
available in the scripting api; right now there is no way to tell the
user "Your %s was killed by barbarians"

Expanded the patch slightly by porting hut_get_barbarians to Lua, using
a new method Tile:city_exists_within_city_radius and a new action
barbarian_uprising(tile)

Added a copyright header to the script.lua file since it now has a
substantial amount of code; I hope that it is correct.
Index: server/scripting/api_actions.h
===
--- server/scripting/api_actions.h	(revision 13086)
+++ server/scripting/api_actions.h	(arbetskopia)
@@ -16,6 +16,7 @@
 
 #include "api_types.h"
 
+bool api_unleash_barbarians(Tile *ptile);
 Unit *api_actions_create_unit(Player *pplayer, Tile *ptile, Unit_Type *ptype,
 		  	  int veteran_level, City *homecity,
 			  int moves_left);
Index: server/scripting/api_methods.h
===
--- server/scripting/api_methods.h	(revision 13086)
+++ server/scripting/api_methods.h	(arbetskopia)
@@ -16,12 +16,17 @@
 
 #include "api_types.h"
 
+bool api_methods_unit_city_can_be_built_here(Unit *punit);
+
 int api_methods_player_num_cities(Player *pplayer);
 int api_methods_player_num_units(Player *pplayer);
 
 bool api_methods_unit_type_has_flag(Unit_Type *punit_type, const char *flag);
 bool api_methods_unit_type_has_role(Unit_Type *punit_type, const char *role);
 
+bool api_methods_tile_city_exists_within_city_radius(Tile *ptile, 
+ bool may_be_on_center);
+
 bool api_methods_building_type_is_wonder(Building_Type *pbuilding);
 bool api_methods_building_type_is_great_wonder(Building_Type *pbuilding);
 bool api_methods_building_type_is_small_wonder(Building_Type *pbuilding);
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg	(revision 13086)
+++ server/scripting/api.pkg	(arbetskopia)
@@ -94,6 +94,7 @@
 
 
 /* Class methods. */
+
 int api_methods_player_num_cities
 	@ methods_player_num_cities (Player *pplayer);
 int api_methods_player_num_units
@@ -103,7 +104,12 @@
 	@ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag);
 bool api_methods_unit_type_has_role
 	@ methods_unit_type_has_role (Unit_Type *punit_type, const char *role);
+bool api_methods_unit_city_can_be_built_here
+	@ methods_unit_city_can_be_built_here (Unit *punit);
 
+bool api_methods_tile_city_exists_within_city_radius
+	@ methods_tile_city_exists_within_city_radius (Tile *ptile, bool center);
+
 bool api_methods_building_type_is_wonder
 	@ methods_building_type_is_wonder (Building_Type *pbuilding);
 bool api_methods_building_type_is_great_wonder
@@ -133,6 +139,15 @@
   return find.city(self.owner, self.homecity_id)
 end
 
+function Unit:is_on_possible_city_tile()
+  return methods_unit_city_can_be_built_here(self)
+end
+
+-- Tile methods
+function Tile:city_exists_within_city_radius(center)
+  return methods_tile_city_exists_within_city_radius(self, center)
+end
+
 -- Building_Type methods.
 function Building_Type:build_shield_cost()
   return self.build_cost
@@ -402,4 +417,4 @@
 void api_actions_change_gold @ change_gold (Player *pplayer, int amount);
 Tech_Type *api_actions_give_technology @ give_technology (Player *pplayer,
 		Tech_Type *ptech);
-
+bool api_unleash_barbarians @ unleash_barbarians (Tile *ptile);
Index: server/scripting/api_actions.c
===
--- server/scripting/api_actions.c	(revision 13086)
+++ server/scripting/api_actions.c	(arbetskopia)
@@ -15,6 +15,7 @@
 #include 
 #endif
 
+#include "barbarian.h"
 #include "plrhand.h"
 #include "citytools.h"
 #include "techtools.h"
@@ -26,6 +27,14 @@
 
 
 /**
+  Unleash barbarians on a tile, for example from a hut
+**/
+bool api_unleash_barbarians(Tile *ptile)
+{
+  return unleash_barbarians(ptile);
+}
+
+/**
   Create a new unit.
 **/
 Unit *api_actions_create_unit(Player *pplayer, Tile *ptile, Unit_Type *ptype,
Index: server/scripting/api_methods.c
===
--- server/scripting/api_methods.c	(revision 13086)
+++ server/scripting/api_methods.c	(arbetskopia)
@@ -21,6 +21,14 @@
 #include "script.h"
 
 /**
+  Can punit found a city on its tile?
+**/
+bool api_methods_unit_city_can_be_

[Freeciv-Dev] (PR#39450) Make rule names available in the scripting api

[Ulrik Sverdrup]

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

Make rule names available in the scripting api.

Right now, in a callback in lua; for example:

hut_entered_callback(punit)

there is no way to get the rule name of punit, only the reverse by
find.unit_type('Settlers') and similar.

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

[Freeciv-Dev] (PR#39449) Implement Create Player and Create Barbarians in scripting api

[Ulrik Sverdrup]

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

Implement functions (actions) in the scripting api to create new players
and specifically also create new barbarian players.

This would allow us to move some of the barbarian logic to scripting.

Ideas taken from http://freeciv.wikia.com/wiki/Barbarians

We need among other things:

Tile *find_hostile_spawn_point(Player *against_player)
Player *create_player(leader_name, is_barbarian, ...)

where create_player creates or in the case of barbarians also can
recreate barbarians. 

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

[Freeciv-Dev] (PR#17191) Fixes for tutorial

[Ulrik Sverdrup]

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

New fixes for the tutorial; to fix that .name is no longer available and
use find.unit_type and similar. Introduces convenience functions since
the test for unit type is not so straightforward 

(Might also be a good example for those who read the tutorial to learn
how to write scripts)

One patch for the 2.1 branch and one for trunk, revision 13075. The
patches are different in details but they make tutorial.sav identical in
both versions. 
Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13075)
+++ data/scenario/tutorial.sav	(arbetskopia)
@@ -5,6 +5,14 @@
 
 [script]
 code=$
+function has_utype(unit, utype_name) 
+  print(utype_name)
+  return (unit.utype.id == find.unit_type(utype_name).id)
+end
+function has_terrain(tile, terrain_name)
+  return (tile.terrain.id == find.terrain(terrain_name).id)
+end
+
 function turn_callback(turn, year)
   if turn == 0 then
 notify.event(nil, nil, E.TUTORIAL,
@@ -20,9 +28,9 @@
 function unit_moved_callback(unit, src_tile, dst_tile)
   if unit.owner:is_human() then
 if citiesbuilt == 0
-  and unit:type().name == 'Settlers'
-  and (dst_tile:terrain().name == 'Grassland'
-   or dst_tile:terrain().name == 'Plains') then  
+  and has_utype(unit, 'Settlers')
+  and (has_terrain(dst_tile, 'Grassland')
+   or has_terrain(dst_tile, 'Plains')) then  
   notify.event(unit.owner, dst_tile, E.TUTORIAL,
 _("This looks like a good place to build a city.  The next time this\n\
 unit gets a chance to move, press (b) to found a city.\n\
@@ -195,7 +203,7 @@
   if not unit.owner:is_human() then
 return
   end
-  if unit:type().name == 'Settlers' then
+  if has_utype(unit, 'Settlers') then
 if settlersbuilt == 0 then
   notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("You have built a settler unit.  Settlers are best used to build \n\
@@ -233,7 +241,7 @@
   if not city.owner:is_human() then
 return
   end
-  if building.name == 'Barracks' and not barracksmsg then
+  if building.id == find.building_type('Barracks').id and not barracksmsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("You have built a Barracks.  This building will make any military\n\
 units you build start out as veterans.  Veteran units are stronger\n\
@@ -255,7 +263,7 @@
   if not city.owner:is_human() then
 return
   end
-  if unittype.name == 'Settlers' and not nosettlermsg then
+  if unittype.id == find.unit_type('Settlers').id and not nosettlermsg then
 notify.event(city.owner, city.tile, E.TUTORIAL,
 _("Your city cannot build a settler.  Settlers take one unit of\n\
 population to build, so a city of size one cannot build one without\n\
@@ -272,7 +280,7 @@
 _("You have built your first military unit!  Military units have two\n\
 basic purposes: attack and defense.  Each unit has an attack strength\n\
 and a defense strength.  While a Warriors is a measly 1/1, a Phalanx\n\
-is a must stronger defender with 2 defense (1/2).  A Catapult is a good\n\
+is a much stronger defender with 2 defense (1/2).  A Catapult is a good\n\
 attacking unit because it has 6 attack (6/1).\n\
 \n\
 Usually it is a good idea to keep one or two defenders in each city.\n\
@@ -356,7 +364,7 @@
   if not hutmsg then
 notify.event(unit.owner, unit.tile, E.TUTORIAL,
 _("Your unit has found a Hut.  These are small villages scattered across\n\
-the landscape.  When a unit enters one several things may happen.  The\n\
+the landscape.  When a unit enters one, several things may happen.  The\n\
 most likely outcome is that you will find resources worth a small\n\
 amount of gold.  However it is also possible to find technologies or\n\
 mercenary units inside a hut.  Some huts contain native settlers\n\
Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav	(revision 13086)
+++ data/scenario/tutorial.sav	(arbetskopia)
@@ -5,6 +5,14 @@
 
 [script]
 code=$
+function has_utype(unit, utype_name) 
+  print(utype_name)
+  return (unit.utype.id == find.unit_type(utype_name).id)
+end
+function has_terrain(tile, terrain_name)
+  return (tile.terrain.id == find.terrain(terrain_name).id)
+end
+
 function turn_callback(turn, year)
   if turn == 0 then
 notify.event(nil, nil, E.TUTORIAL,
@@ -20,9 +28,9 @@
 function unit_moved_callback(unit, src_tile, dst_tile)
   if unit.owner:is_human() then
 if citiesbuilt == 0
-  and unit.type.name == 'Settlers'
-  and (dst_tile.terrain.name == 'Grassland'
-   or dst_tile.terrain.name == 'Plains') then  
+  and has_utype(unit, 'Settlers')
+  and (has_terrain(dst_tile, 'Grassland')
+   or has_terrain(dst_tile, 'Plains')) then  
   notify.event(unit.owner, dst_tile, E.TUTORIAL,
 _("This looks like a good place to build a city.  The next time this\n\
 unit gets a chance to mo

[Freeciv-Dev] (PR#13019) Meta-Ticket: Improved scripting

[Ulrik Sverdrup]

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

Reopen to continue adding to the scripting API

These are "low hanging fruit" api_actions, and use server/unittools and
server/citytools
remove_unit to immediately remove a unit
upgrade_unit to upgrade a unit if possible (free)
remove_city to remove a city completely
transfer_city to transfer ownership of a city (and its units)

remove_city is a draft; it is an unsafe action in some callbacks (like
removing the city itself in it's city_growth callback)

diff to trunk r13086

Also attached is a savegame with a script that tests these actions.
Index: server/scripting/api_actions.h
===
--- server/scripting/api_actions.h	(revision 13086)
+++ server/scripting/api_actions.h	(arbetskopia)
@@ -19,7 +19,13 @@
 Unit *api_actions_create_unit(Player *pplayer, Tile *ptile, Unit_Type *ptype,
 		  	  int veteran_level, City *homecity,
 			  int moves_left);
+void api_actions_remove_unit(Unit *punit);
+void api_actions_upgrade_unit(Unit *punit);
+			  
 void api_actions_create_city(Player *pplayer, Tile *ptile, const char *name);
+void api_actions_remove_city(City *pcity);
+void api_actions_transfer_city(Player *ptaker, City *pcity);
+
 void api_actions_change_gold(Player *pplayer, int amount);
 Tech_Type *api_actions_give_technology(Player *pplayer, Tech_Type *ptech);
 
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg	(revision 13086)
+++ server/scripting/api.pkg	(arbetskopia)
@@ -397,8 +397,15 @@
 	 Unit_Type *ptype,
 	 int veteran_level,
 	 City *homecity, int moves_left);
+void api_actions_remove_unit @ remove_unit (Unit *punit);
+void api_actions_upgrade_unit @ upgrade_unit (Unit *punit);
+	 
 void api_actions_create_city @ create_city (Player *pplayer, Tile *ptile,
 	const char *name);
+void api_actions_remove_city @ remove_city (City *pcity);
+void api_actions_transfer_city @ transfer_city (Player *ptaker, 
+	City *pcity);
+
 void api_actions_change_gold @ change_gold (Player *pplayer, int amount);
 Tech_Type *api_actions_give_technology @ give_technology (Player *pplayer,
 		Tech_Type *ptech);
Index: server/scripting/api_actions.c
===
--- server/scripting/api_actions.c	(revision 13086)
+++ server/scripting/api_actions.c	(arbetskopia)
@@ -37,6 +37,24 @@
 }
 
 /**
+  Remove a unit.
+**/
+void api_actions_remove_unit(Unit *punit)
+{
+  wipe_unit(punit);
+}
+
+/**
+  Upgrade a unit, for free.
+**/
+void api_actions_upgrade_unit(Unit *punit)
+{
+  Unit_Type *utype;
+  if ( (utype = can_upgrade_unittype(punit->owner, punit->utype)))
+upgrade_unit(punit, utype, TRUE); 
+}
+
+/**
   Create a new city.
 **/
 void api_actions_create_city(Player *pplayer, Tile *ptile, const char *name)
@@ -48,6 +66,23 @@
 }
 
 /**
+  Remove a city.
+**/
+void api_actions_remove_city(City *pcity)
+{
+  remove_city(pcity);
+}
+
+/**
+  Transfer a city to a new owner.
+  Transfer all units, be verbose, resolve stack, no raze.
+**/
+void api_actions_transfer_city(Player *ptaker, City *pcity)
+{
+  transfer_city(ptaker, pcity, -1, TRUE, TRUE, FALSE); 
+}
+
+/**
   Change pplayer's gold by amount.
 **/
 void api_actions_change_gold(Player *pplayer, int amount)


scengame-3800m.sav.gz
Description: GNU Zip compressed data
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39422) [patch] Scroll city style selector

[Ulrik Sverdrup]

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

Proposing default window height 590 px: fits on 800x600 screens,
displays default city style list with amplio without scrollbar, and thus
very close to the current default size with amplio.

Otherwise the same patch as before. Applies to 2.1 branch r13086
Index: client/gui-gtk-2.0/dialogs.c
===
--- client/gui-gtk-2.0/dialogs.c	(revision 13086)
+++ client/gui-gtk-2.0/dialogs.c	(arbetskopia)
@@ -780,7 +780,7 @@
   setup_dialog(shell, toplevel);
 
   gtk_window_set_position(GTK_WINDOW(shell), GTK_WIN_POS_CENTER_ON_PARENT);
-  gtk_window_set_default_size(GTK_WINDOW(shell), -1, 310);
+  gtk_window_set_default_size(GTK_WINDOW(shell), -1, 590);
 
   frame = gtk_frame_new(_("Select a nation"));
   gtk_container_add(GTK_CONTAINER(GTK_DIALOG(shell)->vbox), frame);
@@ -810,7 +810,7 @@
   gtk_table_set_row_spacings(GTK_TABLE(table), 2);
   gtk_table_set_col_spacing(GTK_TABLE(table), 0, 12);
   gtk_table_set_col_spacing(GTK_TABLE(table), 1, 12);
-  gtk_box_pack_start(GTK_BOX(vbox), table, FALSE, FALSE, 0);
+  gtk_box_pack_start(GTK_BOX(vbox), table, TRUE, TRUE, 0);
 
   /* Leader. */ 
   combo = gtk_combo_new();
@@ -824,17 +824,17 @@
   "xalign", 0.0,
   "yalign", 0.5,
   NULL);
-  gtk_table_attach_defaults(GTK_TABLE(table), label, 0, 1, 0, 2);
-  gtk_table_attach_defaults(GTK_TABLE(table), combo, 1, 3, 0, 1);
+  gtk_table_attach(GTK_TABLE(table), label, 0, 1, 0, 2, 0, 0, 0, 0);
+  gtk_table_attach(GTK_TABLE(table), combo, 1, 3, 0, 1, 0, 0, 0, 0);
 
   cmd = gtk_radio_button_new_with_mnemonic(NULL, _("_Female"));
   races_sex[0] = cmd;
-  gtk_table_attach_defaults(GTK_TABLE(table), cmd, 1, 2, 1, 2);
+  gtk_table_attach(GTK_TABLE(table), cmd, 1, 2, 1, 2, 0, 0, 0, 0);
 
   cmd = gtk_radio_button_new_with_mnemonic_from_widget(GTK_RADIO_BUTTON(cmd),
   _("_Male"));
   races_sex[1] = cmd;
-  gtk_table_attach_defaults(GTK_TABLE(table), cmd, 2, 3, 1, 2);
+  gtk_table_attach(GTK_TABLE(table), cmd, 2, 3, 1, 2, 0, 0, 0, 0);
 
   /* City style. */
   store = gtk_list_store_new(3, G_TYPE_INT,
@@ -851,7 +851,7 @@
   gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(sw),
   GTK_SHADOW_ETCHED_IN);
   gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(sw),
-  GTK_POLICY_NEVER, GTK_POLICY_NEVER);
+  GTK_POLICY_NEVER, GTK_POLICY_AUTOMATIC);
   gtk_container_add(GTK_CONTAINER(sw), list);
   gtk_table_attach(GTK_TABLE(table), sw, 1, 3, 2, 4,
   GTK_EXPAND|GTK_FILL, GTK_EXPAND|GTK_FILL, 0, 0);
@@ -863,7 +863,7 @@
   "xalign", 0.0,
   "yalign", 0.5,
   NULL);
-  gtk_table_attach_defaults(GTK_TABLE(table), label, 0, 1, 2, 3);
+  gtk_table_attach(GTK_TABLE(table), label, 0, 1, 2, 3, 0, 0, 0, 0);
 
   render = gtk_cell_renderer_pixbuf_new();
   column = gtk_tree_view_column_new_with_attributes(NULL, render,
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39395) Backport cursor fix from trunk to 2.1 branch

[Ulrik Sverdrup]

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

Already fixed in trunk as #37801. I am proposing this very similar patch
to fix; Modified since there is no update_mouse_cursor in S2_1.

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

[Freeciv-Dev] (PR#39427) BUG: city_style & unit_class name translation

[Ulrik Sverdrup]

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

In the scripting api, Unit_Type.name disappeared with this patch (in
api.pkg). How is it going to be replaced? The tutorial uses it (although
there are also syntax errors now, that need to be fixed with type ->
utype and :type() -> .utype). 

We (probably) need some way to get translated names of Unit_Types,
Impr_Types etc in the scripting api.

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

[Freeciv-Dev] (PR#39443) RFE: Add custom UnitFlags

[Ulrik Sverdrup]

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

> [wsimpson - Søn. 08. Jul. 2007 13:56:22]:
> 
> Marko Lindqvist wrote:
> >  This has been discussed in #37436.
> > 
> I'd prefer the solution discussed there, ruleset definable flags.
> 
> But keep this ticket open to implement it!
> 
Ok, Agreed

1. What about separate solutions, use two Custom1/Custom2 flags in the
2.1 branch and make it customizable in trunk?

2. We have to make a difference between some flags and other flags. The
Airbase flag is clearly only used in the ruleset, that's a "custom type"
flag. But some flags, like "AddToCity", "Cities" etc are used in the
client interface (orders menu) etc. So we have to make a list of
"default flags" that are used in the actual code and "custom flags" that
are only used in the ruleset. We have both right now in the code, and we
should reasonably only allow (or recommend) renaming the custom type flags.

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

[Freeciv-Dev] (PR#39442) Lua script newlines not restored correctly from save

[Ulrik Sverdrup]

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

Patch that applies to S2_1 and trunk r13075 attached.

Make escaped an attribute of entry so that it can be carried over from
load to save; change moutstr so that it takes a full_escapes argument
just like minstr. Also changed moutstr to return a string with
delimiters (either " " for escaped or $ $ for unescaped), to simplify
the code throughout.

Add secfile_insert_str_noescape so that noescaped strings (script.code
and script.vars) can be inserted.

Refactor slightly. introduce entry_init(struct *entry) so that all
entries are inited to good null values properly (removed various
duplicated NULL and 0-setting throughout other functions)

Make script.code and script.vars use the noescape function so that they
are saved back with $..$ delimiters. Now they can load correctly and are
easy to edit (good for scenario/.sav hand-editors)

Now tutorial script works from savegames!

We need to commit this to the 2.1 branch if we seriously want lua and
the tutorial to work, even if it is a bit intrusive to the registry, it
should be safe.
Index: utility/registry.c
===
--- utility/registry.c	(revision 13075)
+++ utility/registry.c	(arbetskopia)
@@ -186,6 +186,7 @@
   int dim;			/* vector's size */
   int  used;			/* number of times entry looked up */
   char *comment;/* comment, may be NULL */
+  bool escaped; /* " or $. Usually TRUE */
 };
 
 /* create a 'struct entry_list' and related functions: */
@@ -228,7 +229,7 @@
 
 static char *minstrdup(struct sbuffer *sb, const char *str,
bool full_escapes);
-static char *moutstr(char *str);
+static char *moutstr(char *str, bool full_escapes);
 
 static struct entry*
 section_file_lookup_internal(struct section_file *my_section_file,  
@@ -356,6 +357,21 @@
 }
 
 /**
+  Initialize the entry struct and set to default (empty) values.
+**/
+static void entry_init(struct entry *pentry)
+{
+  pentry->name = NULL;
+  pentry->svalue = NULL;
+  pentry->ivalue = 0;
+  pentry->used = 0;
+  pentry->dim = 0;
+  pentry->vec_values = NULL;
+  pentry->comment = NULL;
+  pentry->escaped = TRUE;
+}
+
+/**
   Return a new entry struct, allocated from sb, with given name,
   and where tok is a "value" return token from inputfile.
   The entry value has any escaped double-quotes etc removed.
@@ -366,20 +382,18 @@
   struct entry *pentry;
 
   pentry = sbuf_malloc(sb, sizeof(struct entry));
+  entry_init(pentry);
   pentry->name = sbuf_strdup(sb, name);
-  pentry->comment = NULL;
   if (tok[0] != '-' && !my_isdigit(tok[0])) {
 /* It is not integer, but string with some border character. */
-bool escapes = (tok[0] != '$'); /* Border character '$' means no escapes */
+pentry->escaped = (tok[0] != '$'); /* Border character '$' means no escapes */
 
 /* minstrdup() starting after border character */
-pentry->svalue = minstrdup(sb, tok+1, escapes);
-pentry->ivalue = 0;
+pentry->svalue = minstrdup(sb, tok+1, pentry->escaped);
 if (SECF_DEBUG_ENTRIES) {
   freelog(LOG_DEBUG, "entry %s '%s'", name, pentry->svalue);
 }
   } else {
-pentry->svalue = NULL;
 if (sscanf(tok, "%d", &pentry->ivalue) != 1) {
   freelog(LOG_ERROR, "'%s' isn't an integer", tok);
 }
@@ -387,7 +401,6 @@
   freelog(LOG_DEBUG, "entry %s %d", name, pentry->ivalue);
 }
   }
-  pentry->used = FALSE;
   return pentry;
 }
 
@@ -821,8 +834,8 @@
 
 	  if(icol>0)
 	fz_fprintf(fs, ",");
-	  if(pentry->svalue) 
-	fz_fprintf(fs, "\"%s\"", moutstr(pentry->svalue));
+	  if(pentry->svalue)
+	fz_fprintf(fs, "%s", moutstr(pentry->svalue, pentry->escaped));
 	  else
 	fz_fprintf(fs, "%d", pentry->ivalue);
 	  
@@ -842,13 +855,13 @@
   if(!pentry) break;
   
   if (pentry->vec_values) {
-fz_fprintf(fs, "%s=\"%s\"", pentry->name,
-	   moutstr(pentry->vec_values[0]));
+fz_fprintf(fs, "%s=%s", pentry->name,
+	   moutstr(pentry->vec_values[0], pentry->escaped));
 	for (i = 1; i < pentry->dim; i++) {
-	  fz_fprintf(fs, ", \"%s\"", moutstr(pentry->vec_values[i]));
+	  fz_fprintf(fs, ", %s", moutstr(pentry->vec_values[i], pentry->escaped));
 	}
   } else if (pentry->svalue) {
-	fz_fprintf(fs, "%s=\"%s\"", pentry->name, moutstr(pentry->svalue));
+	fz_fprintf(fs, "%s=%s", pentry->name, moutstr(pentry->svalue, pentry->escaped));
   } else {
 	fz_fprintf(fs, "%s=%d", pentry->name, pentry->ivalue);
   }
@@ -862,7 +875,7 @@
   }
   section_list_iterate_end;
   
-  (void) moutstr(NULL);		/* free internal buffer */
+  (void) moutstr(NULL, TRUE);		/* free internal buffer */
 
   if (fz_ferror(fs) != 0) {
 freelog(LOG_ERROR, "Error before closi

[Freeciv-Dev] (PR#39398) 2.1.0-beta4 Fantasy modpack crash

[Ulrik Sverdrup]

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

Commited the attached patch to S2_1 r13074 and trunk r13075

As this is probably the cause of this crash (letting player gold go
below 0) this bug could be marked closed.


(PR#39398): 2.1.0-beta4 Fantasy modpack crash

Make sure only sellable improvements counted in potential gold, so that
player gold can't go below 0.

A very probable fix for a hard to reproduce crash.

modified:
server/unittools.c



Index: server/unittools.c
===
--- server/unittools.c	(revision 13028)
+++ server/unittools.c	(arbetskopia)
@@ -282,7 +282,9 @@
   int potential_gold = 0;
 
   built_impr_iterate(pcity, pimpr) {
-potential_gold += impr_sell_gold(pimpr);
+if (can_city_sell_building(pcity, pimpr)) {
+  potential_gold += impr_sell_gold(pimpr);
+}
   } built_impr_iterate_end;
 
   unit_list_iterate_safe(pcity->units_supported, punit) {
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39444) Meta:Easier Customization and Modpacks

[Ulrik Sverdrup]

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

Tracking issues and features that helps customization

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

[Freeciv-Dev] (PR#39443) Rfe: Add cutom UnitFlags

[Ulrik Sverdrup]

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

To help modpack authors, we should add "Custom1" etc unitflags to
freeciv;  with effects there is nothing special that neccessarily has to
be coded to make a new unitflag meaningful. It can be useful to add 1-5
custom unitflags so that modpack authors have full freedom to introduce
new categories of units and effects that apply to them. (Difference to
UnitClass is that flags are not exclusive)

Suggested design:
Add unitflags "Custom1" and "Custom2" to the code (at least two should
be available).
Include in the units.ruleset header with helptext
"Not used in default ruleset. Available for custom rulesets"

These items should always be kept last.

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

[Freeciv-Dev] (PR#39440) [patch] gtk2 client menu switches Add to city and Build City

[Ulrik Sverdrup]

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

> [wsimpson - Fre. 06. Jul. 2007 12:58:48]:
> 
> OK.  I made a small revision after checking the other routines, as the
> decision whether the menu items exists and the default is already made
> earlier by can_unit_add_or_build_city(), no need for the extra default.
> Also added {}.
> 
> Committed trunk revision 13064, S2_1 revision 13065.
> 
> 
Thanks, very good that way!

Ulrik

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

[Freeciv-Dev] (PR#34228) [tutorial] no message on city growth beyond size 3

[Ulrik Sverdrup]

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

> [dmarks - Søn. 21. Jan. 2007 11:05:14]:
> 
> Running the tutorial (in beta2/windows build):
> 
> The message for growth to size 3 works fine, but nothing happens for
> size 5. I didn't try further growth. A quick look at the Lua code
> doesn't reveal any obvious bugs.
> 
>  ~Daniel
> 
I can't reproduce that in 2.1 or trunk right now. Shows the messages at
least up to sz 8 fine.

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

[Freeciv-Dev] (PR#39442) Lua script newlines not restored correctly from save

[Ulrik Sverdrup]

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

Newlines in lua scripts are saved as the \n char combination in
savegames, and in stings that continue over newlines (continued with \
then newline), that is saved as \\n in the savegame. When the savegame
is restored, newlines are inserted in the strings causing lua syntax
errors.

The result is that the lua script is not run properly when loading games.

Using 2.1 branch r13060
To reproduce:
Start a new game with the tutorial scenario
Save during the first turn
Leave, load the save

>From server log:

3: Trying "default/script.lua".
1:
lua error:
[string "script.code"]:5: unfinished string near `"Welcome to
Freeciv.  You lead a civilization.  Your'

 2: function turn_callback(turn, year)
 3:   if turn == 0 then
 4: notify.event(nil, nil, E.TUTORIAL,
-->  5: _("Welcome to Freeciv.  You lead a civilization.  Your
 6: task is to conquer the world!  You should start by
 7: exploring the land around you with your explorer,
 8: and using your settlers to find a good place to build

1:
lua error:
attempt to call a table value
stack traceback:


Is this a regression? Does it depend on lua version?



tutorial-turn-0.sav.gz
Description: GNU Zip compressed data
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#39440) [patch] gtk2 client menu switches Add to city and Build City

[Ulrik Sverdrup]

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

> [wsimpson - Tor. 05. Jul. 2007 15:02:06]:
> 
> Good idea.  However, have to get permission to add new translation
> strings for 2.1.
> 

There are no new strings in the patch, there is only
"Help _Build Wonder"
"Add to City (_B)
"_Build City"
all there since before

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

[Freeciv-Dev] (PR#39440) [patch] gtk2 client menu switches Add to city and Build City

[Ulrik Sverdrup]

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

In the gtk2 client, "Add to city" is shown when you can build cities
and "build city" when you can add the settler to a city.. this is both
in 2.1 branch and trunk.

The attached patch fixes this, and an additional bug: It is assumed
that F_CITIES assumes F_ADD_TO_CITY. These should be treated
differently, so the code restructures a bit to test those cases. The
logic should be very clear.

Attached patch to trunk r13054. The patch also applies to the 2.1
branch. Tested lightly with 2.1 branch.

Attached is also a patch to units.ruleset that adds "Settlers no add"
and "Settlers no cit", which are units with only Cities and "Add to
city" flags respectively. The patch can be used to test the attached
savegame on trunk, where I tested all the combinations of flags were
tested -> both, or one of the two.

Index: client/gui-gtk-2.0/menu.c
===
--- client/gui-gtk-2.0/menu.c	(revision 13054)
+++ client/gui-gtk-2.0/menu.c	(arbetskopia)
@@ -1441,26 +1441,27 @@
   menus_set_sensitive("/_Orders/Explode Nuclear",
 			  units_have_flag(punits, F_NUCLEAR, TRUE));
   if (units_have_flag(punits, F_HELP_WONDER, TRUE))
-	menus_rename("/_Orders/_Build City", _("Help _Build Wonder"));
-  else if (units_have_flag(punits, F_CITIES, TRUE)) {
-	bool can_build = FALSE;
+menus_rename("/_Orders/_Build City", _("Help _Build Wonder"));
+  else {
+bool city_on_tile = FALSE;
 
-	/* FIXME: this overloading doesn't work well with multiple focus
-	 * units. */
-	unit_list_iterate(punits, punit) {
-	  if (!punit->tile->city) {
-	can_build = TRUE;
-	break;
-	  }
-	} unit_list_iterate_end;
-
-	if (can_build)
-	  menus_rename("/_Orders/_Build City", _("Add to City (_B)"));
-	else
-	  menus_rename("/_Orders/_Build City", _("_Build City"));
+/* FIXME: this overloading doesn't work well with multiple focus
+ * units. */
+unit_list_iterate(punits, punit) {
+  if (punit->tile->city) {
+city_on_tile = TRUE;
+break;
+  }
+} unit_list_iterate_end;
+
+if (!city_on_tile && units_have_flag(punits, F_CITIES, TRUE))
+  menus_rename("/_Orders/_Build City", _("_Build City"));
+else if (city_on_tile && 
+   units_have_flag(punits, F_ADD_TO_CITY, TRUE))
+  menus_rename("/_Orders/_Build City", _("Add to City (_B)"));
+else 
+  menus_rename("/_Orders/_Build City", _("_Build City"));
   }
-  else 
-	menus_rename("/_Orders/_Build City", _("_Build City"));
  
   if (units_have_flag(punits, F_TRADE_ROUTE, TRUE))
 	menus_rename("/_Orders/Build _Road", _("Make Trade _Route"));


settlers-buildcity-addtocity2.sav.gz
Description: GNU Zip compressed data
Index: data/default/units.ruleset
===
--- data/default/units.ruleset	(revision 13054)
+++ data/default/units.ruleset	(arbetskopia)
@@ -306,6 +306,67 @@
  Engineers is highly vulnerable to enemy attacks.\
 ")
 
+
+[unit_settlers_no_add]
+name  = _("Settlers No add")
+class = "Land"
+tech_req  = "None"
+obsolete_by   = "None"
+graphic   = "u.settlers"
+graphic_alt   = "-"
+sound_move= "m_settlers"
+sound_move_alt = "m_generic"
+sound_fight   = "f_settlers"
+sound_fight_alt = "f_generic"
+build_cost= 40
+pop_cost  = 1
+attack= 0
+defense   = 1
+hitpoints = 20
+firepower = 1
+move_rate = 1
+vision_radius_sq = 2
+transport_cap = 0
+fuel  = 0
+uk_happy  = 0
+uk_shield = 1
+uk_food   = 1
+uk_gold   = 0
+flags = "Settlers", "NonMil", "Cities", "NoVeteran"
+roles = "Cities"
+helptext  = _("\
+")
+
+[unit_settlers_no_cit]
+name  = _("Settlers No Cit")
+class = "Land"
+tech_req  = "None"
+obsolete_by   = "None"
+graphic   = "u.settlers"
+graphic_alt   = "-"
+sound_move= "m_settlers"
+sound_move_alt = "m_generic"
+sound_fight   = "f_settlers"
+sound_fight_alt = "f_generic"
+build_cost= 40
+pop_cost  = 1
+attack= 0
+defense   = 1
+hitpoints = 20
+firepower = 1
+move_rate = 1
+vision_radius_sq = 2
+transport_cap = 0
+fuel  = 0
+uk_happy  = 0
+uk_shield = 1
+uk_food   = 1
+uk_gold   = 0
+flags = "Settlers", "NonMil", "AddToCity", "NoVeteran"
+roles = "Cities"
+helptext  = _("\
+")
+
 [unit_worker]
 name  = _("Workers")
 class = "Land"
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev