[Freeciv-Dev] [patch #1967] Longer T0 turn

[Marko Lindqvist]

Update of patch #1967 (project freeciv):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #10:

- Updated patch against current svn

I can't reproduce problem mentioned by pepeto in comment #9. Or do I
misunderstand what he means? When I set timeout = 20, and first_timeout = 120,
client displays timeout of 2 mins in first turn.
If no further comments, I consider this patch ready to be committed.

(file #13262)
___

Additional Item Attachment:

File name: FirstTimeout_1967.diff Size:3 KB


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18209] Compatibility with savegames without startpos.exclude information

[Marko Lindqvist]

Update of bug #18209 (project freeciv):

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


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2726] Orientation sprite loading

[Marko Lindqvist]

URL:
  

 Summary: Orientation sprite loading
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sat 18 Jun 2011 12:23:31 PM EEST
Category: client
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

Attached patch adds loading of unit orientation sprites to client.



___

File Attachments:


---
Date: Sat 18 Jun 2011 12:23:31 PM EEST  Name: LoadOrintationSprites.diff 
Size: 6kB   By: cazfi



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Marko Lindqvist]

Update of patch #2719 (project freeciv):

  Depends on: => patch #2726


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2727] Display unit orientation sprites

[Marko Lindqvist]

URL:
  

 Summary: Display unit orientation sprites
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sat 18 Jun 2011 12:51:41 PM EEST
Category: client
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

Untested patch to actually use orientation sprites on client.

Untested because I've not yet set up testing tileset with orientation
sprites.



___

File Attachments:


---
Date: Sat 18 Jun 2011 12:51:41 PM EEST  Name: ShowOrientationSprites.diff 
Size: 2kB   By: cazfi



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Marko Lindqvist]

Update of patch #2719 (project freeciv):

  Depends on: => patch #2727


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Jacob Nevins]

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

Thinking about this, there are natural extensions to just orientation. For
instance, different sprites when a unit is doing a certain activity (sentried,
fortified, irrigating etc). Clearly, in the core code, we could define sprite
names for all activities and display them at the appropriate times.

However, there are also desirable things that it won't be practical to build
into the core game engine. For instance, when certain kinds of sea unit fight,
it might be desirable for them to rotate 90° to look like a broadside attack.
This sort of knowledge clearly can't be built into the game engine; it would
have to be handled by Lua scripting, I think.

Here's a sketch of a design that would be script-friendly:
* Allow tilesets to define a set of sprites for each unit with arbitrary
string tags (not just n, ne, etc), and load them all when loading the tileset.
(Requires associative lookup whenever the sprites are accessed...)
* Normally the sprite used for a unit will be determined by the core game
engine in the manner that's being implemented by these patches. This probably
handles movement, and could extend to fights/activities or not, as we choose.
* A script function allows the script to override the sprite for a specific
unit with the string of its choosing. This override stays in effect until the
script removes it.
** Hooks/signals are added so that the script can get in on unit attack,
activity change, etc.
** A function is added to get the current orientation of a unit (which is
tracked even if the sprite is overridden), so that the "broadside" case can be
implemented.

Possible problems:
* Scripting runs on the server, but the tileset defining the sprites is on
the client (and potentially different for different clients). This can be made
to work, but the sprite string has to go over the network, and the loaded
ruleset/script would have to agree with the tileset on the set and naming
convention of sprites. Probably too much faff to be worth it.
** Client-side scripting to the rescue? (I haven't looked into whether the
client scripting hinted at in patch #2515 is remotely the right shape.) In
this case, only orientation would have to go over the network.
* Performance -- I don't have a feel for this. Is having scripts involved in
any of unit movement/activity/fights going to be too slow?
** If the scripting is on the client, then perhaps it's less of an issue?
** We can trade off frequency against adaptability (having ordinary movement
handled by the core engine seems like a reasonable trade-off).

(I'm not remotely suggesting we should aim to get all of this in 2.4, just
that we should consider a design that extends to it in future.)

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2728] Save unit orientation to savegame

[Marko Lindqvist]

URL:
  

 Summary: Save unit orientation to savegame
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sat 18 Jun 2011 01:12:36 PM EEST
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

Attached patch makes freeciv to save unit orientation to savegame (and to
load it from it).



___

File Attachments:


---
Date: Sat 18 Jun 2011 01:12:36 PM EEST  Name: OrientationSaving.diff  Size:
2kB   By: cazfi



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Marko Lindqvist]

Update of patch #2719 (project freeciv):

  Depends on: => patch #2728


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Marko Lindqvist]

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

Based on my previous discussions with potential modders I have to disagree.
While making everything extremely flexible by using scripting is what
programmer types like you and I desire, need for scripting in simple tasks
should be avoided. No modder wants to learn lua programming language just to
add unit orientation. Some have said quite bluntly that need for scripting is
greatest *shortcoming* of freeciv moddability.

Obviously I'm not targeting to simplicity always myself - I'm making features
that I myself find fun to develop and to use. But there must be some balance
between simplicity and flexibility. I usually prefer simple ruleset fields to
scripting, and I think quite a lot of what you want can be achieved that way
(we could define in ruleset what orientation unit takes when it's fighting,
for instance)

But all that aside, and focusing to just this ticket: Do we agree that
current design can go in for now (meaning 2.4)? (You may hope it to be only
temporary solution, and I plan to build on top of it in the future, but that's
beside the point)

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2727] Display unit orientation sprites

[Marko Lindqvist]

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

Well, I have missed some caching mechanism or similar, as unit orientation
now changes only when client is restarted.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2729] Circassian nation

[Andrzej M. Gorzym]

URL:
  

 Summary: Circassian nation
 Project: Freeciv
Submitted by: artaxes
Submitted on: Sat 18 Jun 2011 12:06:34 PM GMT
Category: rulesets
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Flag:
http://flagspot.net/flags/ru-01.html



___

File Attachments:


---
Date: Sat 18 Jun 2011 12:06:34 PM GMT  Name: circassian.ruleset  Size: 3kB  
By: artaxes



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2727] Display unit orientation sprites

[Marko Lindqvist]

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

Bug found and fix tested. My local copy just has so much cruft at the moment
that it takes a while before I have patch ready.

Not exactly a bug, but a problem: I'm probably not the last one naming
sprites wrong way. I forgot that south is *not* toward bottom of the screen.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[David Lowe]

Follow-up Comment #3, patch #2719 (project freeciv):

Please reread the second sentence of jtn's post.  His initial suggestion
seems to be to provide different sprites for different activities [i.e.,
Fortify vs. Sentry], and then he optimistically expands from that to more
complicated options.  Activity based sprites can be done similarly to
orientation based sprites.  The complicated stuff will probably require
complicated ways to achieve.  Though related, i see this as two separate tasks
that could each go into a separate ticket.  Since we don't currently have such
tickets, i'll comment here.

1) Activity based sprites seem like a highly desirable feature.  Civ III
actually had a separate animation of each unit doing each activity.  Perhaps
we don't need to go that far, but it would be nice to [for instance] have a
picture of a Worker with a pick instead of a Worker with the letter M over his
head.

2) The complicated stuff is more of a want-to-have than a need-to-have.  The
sprite to be displayed will be chosen based not just on unit information, but
also upon exterior information [enemy location, direction to nearest coast,
etc.]  Doing this right will require lots of hooks to provide different kinds
of info.  It could potentially be overwhelming, and based on that we should
think hard before committing to go this way.

* No matter which way we go with this, more sprites means more art.  Do we
have enough artist time do all this?  The effect is mostly lost as long as we
have missing sprites for any given tileset.  I ask as we don't yet have all
the images of, for instance, the Hospital.  Also, are we ready for complaints
about ballooning file sizes?

* My thoughts on scripting: A modder shouldn't *need* scripting to make a
basic modpack.  That said, a modder who wants to make a really fancy modpack
should be allowed to use all the optional features, scripting included.  By
way of comparison, Battle For Wesnoth uses two scripting languages: lua for AI
control, and Wesnoth Markup Language for scenario/campaign creation.  A basic
campaign can be knocked together over the weekend, but some stunningly rich
campaigns have been created by the ones who dug deep into the language. 
Scripting allows creative users to come up with stuff that developers haven't
even considered possible.  BTW, BFW does also have a separate forum for WML as
well a good section of their wiki.  Still, it seems like this area does not
need an undue amount of support.

* Finally, i agree that the orientation patches should go forward regardless
of what is decided about activity based and script based sprites.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2730] Avar nation

[Andrzej M. Gorzym]

URL:
  

 Summary: Avar nation
 Project: Freeciv
Submitted by: artaxes
Submitted on: Sat 18 Jun 2011 05:56:39 PM GMT
Category: rulesets
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

The Eurasian Avars.

Flag:
http://www.crwflags.com/fotw/flags/tr_imp.html#ava



___

File Attachments:


---
Date: Sat 18 Jun 2011 05:56:39 PM GMT  Name: avar.ruleset  Size: 2kB   By:
artaxes



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Jacob Nevins]

Follow-up Comment #4, patch #2719 (project freeciv):

> Based on my previous discussions with potential modders I have 
> to disagree. While making everything extremely flexible by 
> using scripting is what programmer types like you and I 
> desire, need for scripting in simple tasks should be avoided.
Oh, definitely. Having to learn someone's scripting interface to do stuff,
rather than providing simple data, tends to put me off hacking. Less is more,
make the common stuff easy and the rest possible, and that. (Although I may
have temporarily forgotten that ;).

So, arguments from both efficiency and moddability say that we should plan to
implement all the obvious cases (movement, fighting, activities) in the core
game engine rather than deferring them to scripting (at whatever rate we like
-- I think it's fine to start off with just movement).

Scripting (which is a lot of work devs right not have time for, and modders
mightn't demand) is reserved for cases too complicated to handle via simple
fields, and stuff we haven't thought of, for those modders who are really keen
to add polish.

> But all that aside, and focusing to just this ticket: Do we 
> agree that current design can go in for now (meaning 2.4)?
I think it's fine as it is. Simple and to the point.

[Due diligence: the sprite naming is extensible to arbitrary string tags (not
that it would be the end of the world to change the tileset format); and I
think I've convinced myself that those string tags wouldn't go over the
network in the ideal design, so it's fine for enumerated orientations to be in
the network packet (again, we could change it if we had to).]

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2719] [metaticket] Unit orientation

[Marko Lindqvist]

Follow-up Comment #5, patch #2719 (project freeciv):

> Also, are we ready for complaints about ballooning file sizes?

Which, once sprites are loaded, means bigger memory usage...
I'm actually already worried what happens with small embedded devices if our
default tileset will contain all the orientation sprites. Of course
orientation sprites are optional (tileset author may decide to omit them) so
maybe we just have to ship separate tileset without those sprites. Well, we
can do that as long as no (default ruleset) rules depend on unit orientation,
so it's not information player really needs. But now that server has unit
orientation information, it would be nice to implement features like
backstabbing for fantasy ruleset...


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18207] Terms for report tabs not consistent

[Jacob Nevins]

Update of bug #18207 (project freeciv):

  Status:  Ready For Test => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2714] Autosettlers consider building farmland even if city has no supermarket

[Marko Lindqvist]

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

This shows no improvement for ai in autogames I've tested. But that was
half-expected as I'm well aware of other ai-code shortcomings that affect this
too (amortized 1 = 0 = absolutely nothing)

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2731] Omit final release date from beta release

[Marko Lindqvist]

URL:
  

 Summary: Omit final release date from beta release
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 19 Jun 2011 12:03:27 AM EEST
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

As beta phases of our releases take rather long, and as volunteer project we
really don't know in advance how much manpower we will have in any given time,
we honestly have no clue when the final release will be out when we are
releasing first beta.

In a quite different time beta versions were made to tell final release
month. So we've been forced to put something there, no matter if has made any
sense at all (we've had over a year long beta phases, so just having name of
the month there has been amusing. Are you going to release in 2 or 14
months?)

Attached patch makes this message in beta releases optional. We can omit it
from fist betas and add it to later betas when we have better estimate
available.



___

File Attachments:


---
Date: Sun 19 Jun 2011 12:03:27 AM EEST  Name: ReleaseMonthOmit.diff  Size:
2kB   By: cazfi



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2524] Client 'city bar' terminology

[Marko Lindqvist]

Update of patch #2524 (project freeciv):

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


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18231] AI do not take into account pop cost of settlers to buy them

[Marko Lindqvist]

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

- Updated patch according to comment #2 suggestion, and added related code
comment

(file #13270)
___

Additional Item Attachment:

File name: PopcostCheckFix_18231-2.diff   Size:1 KB


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18227] Qt-client configure check test program compilation fails

[Marko Lindqvist]

Follow-up Comment #10, bug #18227 (project freeciv):

Your latest config.log shows exactly same error message than before, which
makes no sense with latest version of my patch - it errors to code that simply
doesn't exist. So you have not applied latest version of the patch, one from
comment #5.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18243] map window displayed incorectly with gtk+ 2.24.5

[Marko Lindqvist]

Update of bug #18243 (project freeciv):

  Status:None => Confirmed  

___

Follow-up Comment #1:

Reproduced in all branches (S2_2, S2_3, TRUNK) with upstream gtk+-2.24.5 from
gtk.org in amd64 Debian Testing.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #17878] Overview map recalculated unnecessarily => slow minimap scrolling (sometimes)

[Jacob Nevins]

Update of bug #17878 (project freeciv):

 Planned Release: 2.3.0,2.4.0 => 2.2.6,2.3.0,2.4.0  

___

Follow-up Comment #3:

This ports cleanly to S2_2, and doesn't seem to break anything.
I've not observed slowness being a problem with S2_2, but it might help
someone.
Will commit for 2.2.6 unless someone objects.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2630] Debug: identify connection in network packet log

[Jacob Nevins]

Update of patch #2630 (project freeciv):

 Planned Release: 2.3.0,2.4.0 => 2.2.6,2.3.0,2.4.0  

___

Follow-up Comment #3:

Generally useful diagnostic, so S2_2 version attached.

(file #13271)
___

Additional Item Attachment:

File name: S2_2-debug-packet-log-connection.diff Size:1 KB


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18031] Files missing from POTFILES.in

[Jacob Nevins]

Update of bug #18031 (project freeciv):

 Planned Release: 2.3.0,2.4.0 => 2.2.6,2.3.0,2.4.0  

___

Follow-up Comment #3:

Attached version for S2_2, more for tidiness than anything else (there were
files missing, but they were the unimportant ones from comment #0, so no
strings added).

(file #13272)
___

Additional Item Attachment:

File name: S2_2-potfiles-missing.diff Size:1 KB


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #16471] Info displayed on Happiness tab

[Jacob Nevins]

Update of bug #16471 (project freeciv):

 Planned Release:2.3.0, 2.4.0 => 2.2.6, 2.3.0, 2.4.0

___

Follow-up Comment #12:

This ports cleanly to S2_2 and works (tested), so I reckon we should have it
in 2.2.6.
Will commit soon unless someone else does or objects.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18243] map window displayed incorectly with gtk+ 2.24.5

[anonymous]

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

Right now, this is in a way being addressed upstream 
https://bugzilla.gnome.org/show_bug.cgi?id=652872

For the moment, it's unclear whether the result will be a revert or a
different solution will be found.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18243] map window displayed incorectly with gtk+ 2.24.5

[Marko Lindqvist]

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

When gtk+ built with following commit reverted, freeciv works:

http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=254b9a4c540e3dff1dcd17db2ceea6a9fa5df973

Same commit is causing problems for other projects, including gnome itself.
So the question is: is that bug in gtk+ and will there be fixed gtk+ version
coming, or is it bug in freeciv?

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2732] Backport glitch fixes from amplio2 to amplio

[Jacob Nevins]

URL:
  

 Summary: Backport glitch fixes from amplio2 to amplio
 Project: Freeciv
Submitted by: jtn
Submitted on: Sun Jun 19 00:00:05 2011
Category: art
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: jtn
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.2.6,2.3.0,2.4.0

___

Details:

Hogne has applied some minor tidy-ups to the amplio2 tileset recently for
little glitches.

Before amplio is spun off into a standalone package (task #7246), and for
2.2.6, we may as well apply the tidy-ups to it, if it's not too much work.

It looks like it's not. We have:
* patch #2584 (modern city glitch): amplio and amplio2 moderncities.png had
diverged. amplio then is the same as amplio now (on S2_2/S2_3/trunk). Copy
individual tile across, creating new image (attached).
* patch #2586 (lake blending): patch applied to amplio2 specs appears to work
just as well for amplio. Diff attached.
* patch #2587 (various unit glitches): prior to this, S2_3 amplio/2 units.png
and S2_2 amplio units.png were all identical, so just copy the new file across
(the amplio2 file hasn't changed since).
* bug #17998 (city map glitches): tiles.png was identical before this in
amplio/amplio2, so easy to fix. On S2_3/trunk was fixed in amplio as a side
effect of bug #17906, so no change required. Backport to S2_2's amplio
attached.

(It's not possible to represent all this as a diff. If someone wants more
explicit notes on my intentions for review, shout.)




___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2732] Backport glitch fixes from amplio2 to amplio

[Jacob Nevins]

Update of patch #2732 (project freeciv):

  Status: In Progress => Ready For Test 

___

Additional Item Attachment:

File name: amplio-moderncities.pngSize:96 KB
File name: trunk-S2_3-S2_2-amplio-lake.diff Size:0 KB
File name: S2_2-amplio-tiles.png  Size:44 KB


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [task #7246] Publish Amplio for 2.3 as stand-alone package

[Marko Lindqvist]

Follow-up Comment #2, task #7246 (project freeciv):

I'm not currently for removing amplio from svn. It should be enough that it's
not part of distribution tarball.

I don't see it causing any trouble in svn.
I consider it as a test case for tileset handling, and it's much more
convenient to maintain along other tilesets in svn than otherwise in case
someone still wants to use it. So I'd say we keep it in svn until some tileset
format change or similar would create need for too-big-to-be-sensible
maintenance fix for it.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2733] amortize_abs_zero()

[Marko Lindqvist]

URL:
  

 Summary: amortize_abs_zero()
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 19 Jun 2011 02:48:44 AM EEST
Category: ai
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

Integer math is not really suitable for amortize() kind of operation.
Especially problematic is return value 0. Many callers handle (or rather don't
handle at all) that specially. For example: if best tile improvement thing
settler may do gets want value 0, settler keeps its current, i.e., doing
nothing, state. Obviously it would be better to do just slightly (want value
between 0 and 1) beneficial thing than nothing.

While changing amortize() return value from int to float or double may seem
like correct solution, it would require changing a lot of codebase to use
those types to be really correctly implemented.
Instaed attached patch trades one problem to another, but hopefully less
dramatic, problem. Instead of returning value "0" too often, new function
amortize_abs_zero() returns "1" or "-1" too often. It returns "0" only if
there really is no value in doing something.

This patch needs a lot of testing to see that it really improves, and not
decrease, overall performance of ai.



___

File Attachments:


---
Date: Sun 19 Jun 2011 02:48:44 AM EEST  Name: AmortizeAbsZero.diff  Size: 7kB
  By: cazfi



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2513] [lua01] rename files (preparation for lua module rework)

[Marko Lindqvist]

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

> This patch only moves files; no changes

What is the patch file then? You should move files with "svn mv" to preserve
history, not by removing old files and creating new ones by applying a patch.

Of course you need to make changes to configure.ac, Makefile.am:s,
POTFILES.in (at least) with a patch, but patch here didn't look like that one.

___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2727] Display unit orientation sprites

[Marko Lindqvist]

Follow-up Comment #3, patch #2727 (project freeciv):

- Copy orientation from temporary unit structure to actual unit structure in
client end when receiving packet about already existing unit

(file #13277)
___

Additional Item Attachment:

File name: ShowOrientationSprites_2727-2.diff Size:2 KB


___

Reply to this item at:

  

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


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

[Freeciv-Dev] [patch #2734] Unit unpackaging to temporary structure code comments

[Marko Lindqvist]

URL:
  

 Summary: Unit unpackaging to temporary structure code
comments
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 19 Jun 2011 03:59:56 AM EEST
Category: client
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

While writing patch #2727 I were bitten by the fact that unpackage_unit() and
unpackage_short_unit() do not write to real unit structure, but only to
temporary structure from which you have to copy them later. Attached patch
adds code comments which hopefully help others from making same mistake.



___

File Attachments:


---
Date: Sun 19 Jun 2011 03:59:56 AM EEST  Name: TempUnitWarnComment.diff  Size:
1kB   By: cazfi



___

Reply to this item at:

  

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


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

[Freeciv-Dev] [bug #18237] --disable-nls compiler warning for freeciv-modpack

[Marko Lindqvist]

Update of bug #18237 (project freeciv):

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


___

Reply to this item at:

  

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


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