patchFreeciv - Patches: patch #2061, [mapimg04] define player colors in...

 
 
Show feedback again

patch #2061: [mapimg04] define player colors in the ruleset

Submitted by:  Matthias Pfafferodt <syntron>
Submitted on:  Tue 12 Oct 2010 01:07:14 PM UTC  
 
Category: generalPriority: 5 - Normal
Status: DonePrivacy: Public
Assigned to: Matthias Pfafferodt <syntron>Open/Closed: Closed
Planned Release: 2.4.0

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 27 Jan 2011 05:07:01 PM UTC, SVN revision 19137:

update capabilities after terrain & player color changes

  • see patch #2060 and patch #2061
  • tilespec capabilities (color definitions)
  • network capabilities (send colors)
  • ruleset capabilities (definition of colors)

see gna patch #2313

(Browse SVN revision 19137)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Thu 27 Jan 2011 04:54:33 PM UTC, SVN revision 19136:

define player colors in the ruleset

  • use game.ruleset
  • changes to the network protocol
  • automatically generate the sprites needed
  • gtk client: working
  • sdl client: working
  • xaw client: I do not not why it is working but it does; the border

lines etc. use a mask - they are not as strong as in the other
clients. I do not know enough about this client to fix it

  • qt client: dummy create_sprite() function

see gna patch #2061

(Browse SVN revision 19136)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Tue 25 Jan 2011 05:24:06 PM UTC, comment #38:

> 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)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Tue 25 Jan 2011 04:32:18 PM UTC, comment #37:

> add dummy create_sprite() function to qt client


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

FYI I'm going to commit Qt sprite implementation patch #2388 in a couple of hours. There should be no conflict between these two patches, but you may want to recheck after my commit.

Marko Lindqvist <cazfi>
Project Administrator
Tue 25 Jan 2011 04:17:44 PM UTC, comment #36:

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)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Tue 25 Jan 2011 04:10:05 PM UTC, comment #35:

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

Vijay Kiran Kamuju <infyquest>
Project Member
Tue 25 Jan 2011 03:53:28 PM UTC, comment #34:

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)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Mon 24 Jan 2011 10:41:53 AM UTC, comment #33:

I would like to commit this patch set - but it breaks the xaw client. How should I proceed?

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Fri 21 Jan 2011 09:31:03 AM UTC, comment #32:

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?

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Sat 15 Jan 2011 07:26:33 PM UTC, comment #31:

> this new patch is not crashing... did anything change?


I still have the same crash (trunk + patch #2060 + this one + patch #2313)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Sat 15 Jan 2011 05:59:28 PM UTC, comment #30:

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

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Sat 15 Jan 2011 11:28:45 AM UTC, comment #29:

this new patch is not crashing... did anything change?

Vijay Kiran Kamuju <infyquest>
Project Member
Fri 14 Jan 2011 07:23:20 PM UTC, comment #28:

rebased to current trunk

(file #11873)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Fri 14 Jan 2011 03:06:04 PM UTC, comment #27:

can you rebase this patch again, I am unable to apply it and compile with the recent server changes.

Vijay Kiran Kamuju <infyquest>
Project Member
Fri 14 Jan 2011 10:58:20 AM UTC, comment #26:

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)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Thu 13 Jan 2011 05:20:59 PM UTC, comment #25:

for the terrain patch issues, attach the bug reports to the corresponding patch. I shall look into them. I will try to fix those errors first. The player colors patch will continously be tested

Vijay Kiran Kamuju <infyquest>
Project Member
Thu 13 Jan 2011 05:12:00 PM UTC, comment #24:

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)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Thu 13 Jan 2011 04:44:31 PM UTC, comment #23:

I prefer to commit patch #2060, this patch and patch #2313 in one step as the first two change a lot of capabilities (network, ruleset and tileset) and the last one changes the capability strings.

Compiling with mapimg03 (patch #2060) should work. I did it just now and also testet the xaw client. This is working! I will now at this patch ...

But there are some strange effect with this client:

  • if the terrain relief option for the overview is toggled the main map is not shown anymore
  • the option page look strange
  • after some testing the client crashed

Should I send bug reports for these?

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Thu 13 Jan 2011 01:36:27 PM UTC, comment #22:

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 :)

Vijay Kiran Kamuju <infyquest>
Project Member
Thu 13 Jan 2011 12:55:49 PM UTC, comment #21:

> havent tested it yet, and with patch 3 try to compile the sdl.
> There might be issue with SDL client


Could it be bug #17475? Marko Lindqvist posted a bug fix for it. A similar one is also include in this patch.

> 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.


This are more informations than I got! Can I help finding the issue? I do know nothing about xaw ...

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Thu 13 Jan 2011 12:44:09 PM UTC, comment #20:

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.

Vijay Kiran Kamuju <infyquest>
Project Member
Wed 12 Jan 2011 04:45:16 PM UTC, comment #19:

havent tested it yet, and with patch 3 try to compile the sdl.
There might be issue with SDL client

Vijay Kiran Kamuju <infyquest>
Project Member
Wed 12 Jan 2011 11:22:12 AM UTC, comment #18:

rebased patch

(file #11813)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Sun 21 Nov 2010 08:36:06 PM UTC, comment #17:

rebased patch

(file #11334)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Sun 21 Nov 2010 06:43:24 PM UTC, comment #16:

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

Vijay Kiran Kamuju <infyquest>
Project Member
Wed 03 Nov 2010 11:53:48 AM UTC, comment #15:

update target to freeciv 2.4.0

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Sun 24 Oct 2010 04:47:08 PM UTC, comment #14:

small update:

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

(file #10918)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Wed 20 Oct 2010 11:45:38 AM UTC, comment #13:

> Sometimes, using LANG=C allow the client to launch, but it
> usually crash very often due to the unmaintained state of it.


Lang=C does not help ...

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Tue 19 Oct 2010 09:55:49 AM UTC, comment #12:

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.

Marko Lindqvist <cazfi>
Project Administrator
Fri 15 Oct 2010 03:02:01 PM UTC, comment #11:

> At a related notw, it would be great if we could publish release
> notes for each new tileset format in the future.


That's a good idea. What support do you suggest to do that?

pepeto <pepeto>
Project Member
Fri 15 Oct 2010 12:56:14 AM UTC, comment #10:

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.

Daniel Markstedt <dmarks>
Project Administrator
Wed 13 Oct 2010 07:13:41 PM UTC, comment #9:

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


... using the date of the last change. At the time of a new release it could be changed to +Freeciv2.3" or something similar.

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Wed 13 Oct 2010 07:01:37 PM UTC, comment #8:

> 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>"

pepeto <pepeto>
Project Member
Wed 13 Oct 2010 06:59:43 PM UTC, comment #7:

> The log for the xaw client shows the following but no core dump
> is created.


Sometimes, using LANG=C allow the client to launch, but it usually crash very often due to the unmaintained state of it. Where is our xaw maintainer?

pepeto <pepeto>
Project Member
Wed 13 Oct 2010 06:49:35 PM UTC, comment #6:

>> 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.

pepeto <pepeto>
Project Member
Wed 13 Oct 2010 06:05:37 PM UTC, comment #5:

The log for the xaw client shows the following but no core dump is created.

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Wed 13 Oct 2010 05:52:15 PM UTC, comment #4:

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)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Wed 13 Oct 2010 04:11:33 PM UTC, comment #3:

> 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'?

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Tue 12 Oct 2010 03:14:22 PM UTC, comment #2:

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.

pepeto <pepeto>
Project Member
Tue 12 Oct 2010 02:27:29 PM UTC, comment #1:

This patch removes colors.misc and changes colors.tilespec - does this requires an updated capability string for the tileset files? (see also patch #2060)

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.
Tue 12 Oct 2010 01:07:14 PM UTC, original submission:
  • 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 ...

Matthias Pfafferodt <syntron>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Digest:
   patch dependencies.

 

Carbon-Copy List
  • -unavailable- added by infyquest (Posted a comment)
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by dmarks (Posted a comment)
  • -unavailable- added by pepeto (Posted a comment)
  • -unavailable- added by syntron (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 18 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 27 Jan 2011 04:56:30 PM UTCsyntronStatusReady For Test=>Done
      Open/ClosedOpen=>Closed
    Tue 25 Jan 2011 05:24:06 PM UTCsyntronAttached File-=>Added 20110125.2-mapimg02-define-player-colors-in-the-ruleset.patch, #12096
    Tue 25 Jan 2011 04:17:44 PM UTCsyntronAttached File-=>Added 20110125.1-mapimg02-define-player-colors-in-the-ruleset.patch, #12093
    Tue 25 Jan 2011 03:53:28 PM UTCsyntronAttached File-=>Added 20110125-mapimg02-define-player-colors-in-the-ruleset.patch, #12092
      StatusIn Progress=>Ready For Test
    Fri 14 Jan 2011 07:23:20 PM UTCsyntronAttached File-=>Added 20110114-mapimg02-define-player-colors-in-the-ruleset.patch, #11873
    Fri 14 Jan 2011 10:58:20 AM UTCsyntronAttached File-=>Added test-xaw-error.patch, #11863
    Thu 13 Jan 2011 05:12:00 PM UTCsyntronAttached File-=>Added test-xaw-error.patch, #11840
    Wed 12 Jan 2011 11:22:12 AM UTCsyntronAttached File-=>Added 20110112-mapimg02-define-player-colors-in-the-ruleset.patch, #11813
    Sun 21 Nov 2010 08:36:06 PM UTCsyntronAttached File-=>Added 20101121-04-trunk-define-player-colors-in-the-ruleset.patch, #11334
      Summary[mapimg] define player colors in the ruleset=>[mapimg04] define player colors in the ruleset
    Wed 03 Nov 2010 11:53:48 AM UTCsyntronPlanned Release2.3.0=>2.4.0
    Sun 24 Oct 2010 04:47:08 PM UTCsyntronAttached File-=>Added 20101024-05-trunk-define-player-colors-in-the-ruleset.patch, #10918
    Wed 13 Oct 2010 05:52:15 PM UTCsyntronAttached File-=>Added 20101013-05-trunk-define-player-colors-in-the-ruleset.patch, #10765
    Wed 13 Oct 2010 05:50:21 PM UTCsyntronDependencies-=>patch #2066 is dependent
    Tue 12 Oct 2010 01:08:12 PM UTCsyntronDependencies-=>patch #1391 is dependent
    Tue 12 Oct 2010 01:07:14 PM UTCsyntronAttached File-=>Added 20101012-05-trunk-define-player-colors-in-the-ruleset.patch, #10742
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup