> As this is expected to be non-mangled symbol it should be added
> to qtg_cside.c, not to C++ code in sprite.cpp.

Done

(file #12096)

add dummy create_sprite() function to qt client

> go ahead with the commit, I will look into it if there are any
> breaks.
> currently busy with the office work :(

Thanks for the heads up - I tested it quit carefully. It should work but improvements are possible!

I hope you will find free time outside of your office; perhaps to also do some work on the freeciv code ;-). I will start a new job in March and try to get the patches commited till then.

(file #12093)

got a working version - not nicebut working ...

• fix xaw client: create_sprite() function
• I do not not why it is working but it does
• the border lines etc. for the xaw client use a mask - they are not as strong as in the other clients. I do not know enough about this client to fix it

please test it (especially the xaw client)

(file #12092)

I did try again yesterday but I do not get it. With only patch #2060 the xaw client is working while this patch results in a crash (sdl and gtk work). The only xaw specific change is the added function create_sprite but the error seems to be elsewhere. I'm out of ideas ... Vijay, did you had any success?

Not that I know. I will test it ...

rebased to current trunk

(file #11873)

I found again some time - the create_sprite() function I created for xaw seems to be the cause for the crash. If it is deactivated the client starts. Perhaps you can write a better function which creates a pixmap of the default size with the given player color?

(file #11863)

The function load_sprite() (in ./client/tilespec.c:1869) is used by all clients. Also it is not modified by this patch and not called within the xaw specific code. What could be the reason for this function to fail after the patch?

I did some further investigation - the error seems to be located in ./client/gui-xaw/graphics.c:load_gfxfile() which is called shortly after the log message. The attached crude patch adds some hints to the code. At the moment I do not have the time for further investigations ...

(file #11840)

We need to investigate the load_sprite function.
Its failing in that for the given sprites, I also have to see the changes introduced in this patch set.
If you could commit the patch 03 would be great.
I will try to remove the patch 03 and test again.
Is this one dependent on patch 03?
I too dont know too much in details, I too am learning :)

somehow this seems to be a sprite loading issue with the xaw client.
With the amplio tile set its problem with the ocean.png
With trident tile set its problem with the units.png
We need to investigate this one, completely weird issue.

rebased patch

(file #11813)

its failing on the latest trunk
update the patch so i can test with xaw client

small update:

• fix color in the sdl-client (wrong maps)

(file #10918)

Rulesets definitely are incompatible with S2_2 rulesets, and probably also tilesets. So they definitely should have different capstr in S2_3. I think tileset capstrs used to be kept updated when ever incompatibilities were added in the past, but ruleset ones not.

I'm liking this idea a lot, too. At a related notw, it would be great if we could publish release notes for each new tileset format in the future. Up until now getting a tileset (or modpack) updated for a new version of Freeciv has been pretty much a matter of blind trial and error. I know of at least two tileset authors who gave up maintaining their tilesets because of this.

> Should the current ruleset/tileset files be updated as
> '+freeciv2.3'?

I guess that in trunk, it should looks like our network capability string: "+Freeciv.Devel.<date>"

>> For the future, I would propose that we set as capability the
>> version number (like +2.3) for every related file to this
>> version. It would also be very clearer in the compatibility of
>> the files.
>
> I think this is a good idea. So each major version step (2.3.x,
> 2.4.x) needs a revised ruleset and tileset and within the
> version no changes are allowed (similar to the network
> protocol). Should the current ruleset/tileset files be updated
> as '+freeciv2.3'?

It would be nice to have at least Jacob advice or Marko's one about it. Also, note that savegame could have exactly the same, instead of saving many times the savegame version.

This patch is mandatory for the mapimg patch series. It implements a gui dependend function which creates the sprites needed for the player colors on the fly. I did code this function for the gtk client (and it seems to work). I did try to implement it for the other two supported clients - sdl and xaw - but at least the xaw implementation crash the client. Any help with regard to this client is welcome!

gtk client (working): client/gui-gtk-2.0/sprite.c:118:create_sprite()
sdl client (working; but bug #16865): client/gui-sdl/sprite.c:119:create_sprite()
xaw client (not working): client/gui-xaw/graphics.c:222:create_sprite()

(file #10765)

I am not answering about tileset capabilities only, but also ruleset ones. I doubt we really use the advantage of them. Sometimes, the definitions has changed and we never updated the capability string of it.

For the future, I would propose that we set as capability the version number (like +2.3) for every related file to this version. It would also be very clearer in the compatibility of the files.

• use game.ruleset
• automatically generate the sprites needed
• changes to the network protocol

Please check (and if possible fix) the function create_sprite() in the sdl client (sprite.c) and xaw client (graphics.c). I did try to get them working but these clients crash ...