Re: [Freeciv-Dev] (PR#39453) amplio civ3+ water
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39453
Committed trunk revision 13096.
Index: data/amplio/water.spec
===
--- data/amplio/water.spec (revision 13095)
+++ data/amplio/water.spec (working copy)
@@ -25,7 +25,7 @@
dy = 48
pixel_border = 1
-tiles = { row, column,tag
+tiles = { row, column, tag
; Rivers (as special type), and whether north, south, east, west
; also has river or is ocean:
@@ -122,7 +122,7 @@
dy = 24
pixel_border = 1
-tiles = { row, column,tag
+tiles = { row, column, tag
; ocean cell sprites. See doc/README.graphics
0, 0, t.l0.ocean_cell_u000
@@ -162,6 +162,7 @@
2, 15, t.l0.ocean_cell_r111
; coast cell sprites. See doc/README.graphics
+ 0, 0, t.l0.coast_cell_u
0, 0, t.l0.coast_cell_u000
0, 2, t.l0.coast_cell_u100
0, 4, t.l0.coast_cell_u010
@@ -171,6 +172,7 @@
0, 12, t.l0.coast_cell_u011
0, 14, t.l0.coast_cell_u111
+ 1, 0, t.l0.coast_cell_d
1, 0, t.l0.coast_cell_d000
1, 2, t.l0.coast_cell_d100
1, 4, t.l0.coast_cell_d010
@@ -180,6 +182,7 @@
1, 12, t.l0.coast_cell_d011
1, 14, t.l0.coast_cell_d111
+ 2, 0, t.l0.coast_cell_l
2, 0, t.l0.coast_cell_l000
2, 2, t.l0.coast_cell_l100
2, 4, t.l0.coast_cell_l010
@@ -189,6 +192,7 @@
2, 12, t.l0.coast_cell_l011
2, 14, t.l0.coast_cell_l111
+ 2, 1, t.l0.coast_cell_r
2, 1, t.l0.coast_cell_r000
2, 3, t.l0.coast_cell_r100
2, 5, t.l0.coast_cell_r010
@@ -198,7 +202,44 @@
2, 13, t.l0.coast_cell_r011
2, 15, t.l0.coast_cell_r111
-; shelf fallback to coast tiles
+ 0, 0, t.l1.coast_cell_u000
+ 0, 2, t.l1.coast_cell_u100
+ 0, 4, t.l1.coast_cell_u010
+ 0, 6, t.l1.coast_cell_u110
+ 0, 8, t.l1.coast_cell_u001
+ 0, 10, t.l1.coast_cell_u101
+ 0, 12, t.l1.coast_cell_u011
+ 0, 14, t.l1.coast_cell_u111
+
+ 1, 0, t.l1.coast_cell_d000
+ 1, 2, t.l1.coast_cell_d100
+ 1, 4, t.l1.coast_cell_d010
+ 1, 6, t.l1.coast_cell_d110
+ 1, 8, t.l1.coast_cell_d001
+ 1, 10, t.l1.coast_cell_d101
+ 1, 12, t.l1.coast_cell_d011
+ 1, 14, t.l1.coast_cell_d111
+
+ 2, 0, t.l1.coast_cell_l000
+ 2, 2, t.l1.coast_cell_l100
+ 2, 4, t.l1.coast_cell_l010
+ 2, 6, t.l1.coast_cell_l110
+ 2, 8, t.l1.coast_cell_l001
+ 2, 10, t.l1.coast_cell_l101
+ 2, 12, t.l1.coast_cell_l011
+ 2, 14, t.l1.coast_cell_l111
+
+ 2, 1, t.l1.coast_cell_r000
+ 2, 3, t.l1.coast_cell_r100
+ 2, 5, t.l1.coast_cell_r010
+ 2, 7, t.l1.coast_cell_r110
+ 2, 9, t.l1.coast_cell_r001
+ 2, 11, t.l1.coast_cell_r101
+ 2, 13, t.l1.coast_cell_r011
+ 2, 15, t.l1.coast_cell_r111
+
+; shelf cell sprites. See doc/README.graphics
+ 0, 0, t.l0.shelf_cell_u
0, 0, t.l0.shelf_cell_u000
0, 2, t.l0.shelf_cell_u100
0, 4, t.l0.shelf_cell_u010
@@ -208,6 +249,7 @@
0, 12, t.l0.shelf_cell_u011
0, 14, t.l0.shelf_cell_u111
+ 1, 0, t.l0.shelf_cell_d
1, 0, t.l0.shelf_cell_d000
1, 2, t.l0.shelf_cell_d100
1, 4, t.l0.shelf_cell_d010
@@ -217,6 +259,7 @@
1, 12, t.l0.shelf_cell_d011
1, 14, t.l0.shelf_cell_d111
+ 2, 0, t.l0.shelf_cell_l
2, 0, t.l0.shelf_cell_l000
2, 2, t.l0.shelf_cell_l100
2, 4, t.l0.shelf_cell_l010
@@ -226,6 +269,7 @@
2, 12, t.l0.shelf_cell_l011
2, 14, t.l0.shelf_cell_l111
+ 2, 1, t.l0.shelf_cell_r
2, 1, t.l0.shelf_cell_r000
2, 3, t.l0.shelf_cell_r100
2, 5, t.l0.shelf_cell_r010
@@ -235,6 +279,43 @@
2, 13, t.l0.shelf_cell_r011
2, 15, t.l0.shelf_cell_r111
+; note: inverse of floor (below)
+ 0, 0, t.l1.shelf_cell_u000
+ 4, 2, t.l1.shelf_cell_u100
+ 4, 14, t.l1.shelf_cell_u010
+ 4, 6, t.l1.shelf_cell_u110
+ 4, 8, t.l1.shelf_cell_u001
+ 4, 10, t.l1.shelf_cell_u101
+ 4, 12, t.l1.shelf_cell_u011
+ 4, 4, t.l1.shelf_cell_u111
+
+ 1, 0, t.l1.shelf_cell_d000
+ 3, 2, t.l1.shelf_cell_d100
+ 3, 14, t.l1.shelf_cell_d010
+ 3, 6, t.l1.shelf_cell_d110
+ 3, 8, t.l1.shelf_cell_d001
+ 3, 10, t.l1.shelf_cell_d101
+ 3, 12, t.l1.shelf_cell_d011
+ 3, 4, t.l1.shelf_cell_d111
+
+ 2, 0, t.l1.shelf_cell_l000
+ 5, 3, t.l1.shelf_cell_l100
+ 5, 15, t.l1.shelf_cell_l010
+ 5, 7, t.l1.shelf_cell_l110
+ 5, 9, t.l1.shelf_cell_l001
+ 5, 11, t.l1.shelf_cell_l101
+ 5, 13, t.l1.shelf_cell_l011
+ 5, 5, t.l1.shelf_cell_l111
+
+ 2, 1, t.l1.shelf_cell_r000
+ 5, 2, t.l1.shelf_cell_r100
+ 5, 14, t.l1.shelf_cell_r010
+ 5, 6, t.l1.shelf_cell_r110
+ 5, 8, t.l1.shelf_cell_r001
+ 5, 10, t.l1.shelf_cell_r101
+ 5, 12, t.l1.shelf_cell_r011
+ 5, 4, t.l1.shelf_cell_r111
+
; Deep Ocean sprites.
3, 0, t.l0.deep_cell_u000
3, 2, t.l0.deep_cell_u100
@@ -273,6 +354,7 @@
5, 15, t.l0.deep_cell_r111
; ocean floor sprites.
+ 3, 0, t.l0.floor_cell_u
3, 0, t.l0.floor_cell_u000
3, 2, t.l0.floor_cell_u100
3, 4, t.l0.floor_cell_u010
@@ -282,6 +364,7 @@
3, 12, t.l0.floor_cell_u011
3, 14, t.l0.floor_cell_u111
+ 4, 0, t.l0.floor_cell_d
4, 0, t.l0.floor_cell_d000
4, 2, t.l0.floor_cell_d100
4, 4, t.l0.floor_cell_d010
@@ -291,6 +374,7 @@
4, 12, t.l0.floor_cell_d011
4, 14, t.l0.floor_cell_d111
+ 5, 0,
[Freeciv-Dev] (PR#39454) small bug in kurd.ruleset
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39454 trunk of today data/nation/kurd.ruleset line 55: Serêkanî, ; Kurdish name for Ra's Al Ein (Syria) ^ ascii 27h not allowed - replace with something else Christian -- Christian Knoke* * *http://cknoke.de * * * * * * * * * Ceterum censeo Microsoft esse dividendum. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39454) small bug in kurd.ruleset
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39454 On 7/12/07, Christian Knoke [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39454 trunk of today data/nation/kurd.ruleset line 55: Serêkanî, ; Kurdish name for Ra's Al Ein (Syria) ^ ascii 27h not allowed - replace with something else Christian Done in r13097. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#17191) Fixes for tutorial
URL: 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
Re: [Freeciv-Dev] (PR#39441) tracking release 2.0.10
On Tue, 10 Jul 2007, William Allen Simpson wrote: But 2.2 will definitely not be readable by 2.1 or 2.0, as it will have lots of new civ3 terrain and resource definitions. Even though I understand what you are saying, please be careful saying things like the above when mentioning certain similarly featured commercial products. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#15260) GTK2: interface quirks being observer
URL: 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
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: 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() It seems a good idea, as it would cache the *_name pointers, but are there high performance issues for a scripted language? 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 ___ 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
URL: 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]: URL: 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
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Ulrik Sverdrup wrote: 2007/7/13, William Allen Simpson [EMAIL PROTECTED]: 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. 1) Non-C coders need even longer and more descriptive functions, as they are less likely to read the underlying C code itself. 2) Consistency is even more important. We'll have to debug their code. 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. Hell, no! The lack of clear distinction was what caused me to waste nearly all of my free time for a month to fix this crap. Particularly irksome that prior coders had identified the problem, and left comment blocks about it, but left it for somebody else 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. 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. Damned straight! Some parts of this code are nicely done. Others are/were a mess, and difficult to fix because folks didn't use the *existing* accessor functions. Abstraction was developed by computer scientists for a reason. It's not just an undergraduate exercise. 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. Yes. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
