[Freeciv-Dev] [bug #19029] Possible trouble saving/loading players' known territory for player indices >=40

[Marko Lindqvist]

Follow-up Comment #12, bug #19029 (project freeciv):

> (Need to think further about dropping unnecessary backwards
> compatibility for S2_4 and trunk before commit.)

I'd commit it with savegame format version (2.4.0, 2.5.0) internal backward
compatibility in place first. So for a while savegames created with latest
freeciv would be usable with just recent freeciv. Later, when any "recent"
freeciv can read the new-style known information, we can drop that
compatibility saving, or rather move it to 2.4 -> 2.3 savegame format
compatibility functions. This *if* we retain ability to save in old formats.
After fighting a while with gen-roads related savegame issues, I really wonder
if being able to save in old format is so important feature that it's worth
the huge maintenance work. How many people ever actually save in older
format?


___

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 #19029] Possible trouble saving/loading players' known territory for player indices >=40

[Jacob Nevins]

Additional Item Attachment, bug #19029 (project freeciv):

File name: known-24.sav.bz2   Size:34 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 #19029] Possible trouble saving/loading players' known territory for player indices >=40

[Jacob Nevins]

Follow-up Comment #13, bug #19029 (project freeciv):

Attached patches for S2_4 and trunk with backward compatibility measures
(they're basically identical). This allows these versions to understand all
2.3.x savefiles while keeping a clean format for new savefiles.

Using the savefile compat mechanisms, relative to the previous patch, these
remove backward compatibility cruft from the core save/load functions (saving
~20 lines each). But they add ~5x that to loading, and ~2.5x that to saving.
The latter can probably go one day, but the former will be around forever.
It's a little hard to see this as a win... on the other hand, it means 2.4.x+
savefiles are noticeably smaller due to the new semantics of comment #11.
* A general comment on the compatibility mechanism design: it is particularly
hard to do complex transformations when loading secfiles, since standard
functions can't be used as most data structures aren't set up (we don't even
have map.xsize/ysize). It's hard to see how it could be otherwise while
keeping the compat code away from the main code. Save compatibility is easier
since we have the in-memory data structures (although there's a small chance
of future disturbance of save compatibility code if the in-memory data
structures change significantly, whereas ideally you'd want never to have to
touch it again).

The way I've done it is that from now on, S2_4/trunk "kXX_" means the sane
version, where before this patch it meant the broken version; "kvbXX_" and
"knownv2" are not used at all. This means that old S2_4/trunk savegames with
player indices less than 32 will load fine (because sane==broken in that
case), but ones with >=32 will silently break. As cazfi noted elsewhere, that
case is probably rather theoretical. If anyone cares, such files can be
recovered by saving them with saveversion=2.3.0 in an old S2_4/trunk build,
then loading them into a new S2_4/trunk build.

I've taken no measures to allow old trunk/S2_4 to load new savefiles, as that
seems pointless.

I've tested it every which way: starting with file #15322 and with a version
that's been through a fixed S2_3, I've loaded that into a fixed S2_4, saved it
back in 2.3 format and loaded it into broken and fixed S2_3s, both in the same
S2_4 session and via a S2_4 savefile, which I also loaded into a fixed S2_4.
In all cases I looked at the known info on the minimap for both players, and
diffed/eyeballed the savefiles.

Also I tested loading a new "broken" S2_4 savefile (file #15323) and verified
that it did the right thing for player indices <32 when loaded into a fixed
server.

> After fighting a while with gen-roads related savegame issues, 
> I really wonder if being able to save in old format is so 
> important feature that it's worth the huge maintenance work. 
> How many people ever actually save in older format?
I've also wondered why we've committed to maintaining that capability. What's
the use case, beyond occasional convenience for developers?

(But since it's there currently, this patch supports it -- it was not the
hardest part by any means.)

(file #15324, file #15325)
___

Additional Item Attachment:

File name: S2_4-KnownSaveBitOrder-4.diff  Size:12 KB
File name: trunk-KnownSaveBitOrder-4.diff Size:12 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 #3140] Roads order to savegame

[Jacob Nevins]

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

Bit late but:
> I actually would appreciate some input about how we should 
> handle savegame compatibility issues in development. [...] 
> Can we just ignore the compatibility issues between two 
> savegame formats that are introduced during active 
> development (trunk) of the new version? If not, do we 
> icrease format version number between the intermediate 
> formats and provide compatibility hooks, or do we adjust 
> to such changes within main loading code?
For my money, while it's desirable to maintain continuous compatibility during
development if practical (helps with binary chop, etc), if it means we have to
keep compatibility code forever for some transient state that only ever
existed deep on an unstable development branch, I'd rather we just broke
compatibility (saying so in commit messages).

(See also bug #19029.)

___

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 #19497] S2_3 crashes opening city dialog...

[Jacob Nevins]

Update of bug #19497 (project freeciv):

  Status:None => Duplicate  
 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 #18532] Cannot gracefuly /end a game on a big map

[Jacob Nevins]

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

This can be dealt with without a protocol change, right? -- either by making
buffers bigger or perhaps by sending stuff slower?

___

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 #3180] -f (load savefile) for client

[Jacob Nevins]

URL:
  

 Summary: -f (load savefile) for client
 Project: Freeciv
Submitted by: jtn
Submitted on: Sat Mar  3 22:30:07 2012
Category: client
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

It would be nice if the clients supported the "-f savefile" option to load a
savefile directly from the command line. Should be fairly easy to modify the
spawn-a-server code to add this?




___

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] 2.2.8? (was: [bug #19485] Database has too small field for account creation address if it's IPv6 address)

[Jacob Nevins]

Marko Lindqvist writes:
> Is there any demand for 2.2.8 release? Having one more even more stable 2.2
> release while bugs are still discovered from 2.3 would be nice-to-have, but
> making a release would take valuable time from other tasks and if nobody would
> use the release...

If anyone is still using 2.2.x, then there are already enough important
bugfixes to be worth a release.

I'd be happy to do one if there's demand; it's not a massive job. (I
don't know if our packagers still have a setup appropriate to 2.2.x,
though.)

Data points:
 * The Linux distributions I know about have gone to 2.3.x, so wouldn't
   take an update. (I haven't checked all distros though.)
 * I haven't seen any 2.2 games on the metaserver the last couple of
   times I've checked.

In the absence of visible demand, I shall assume it's not worth it.

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

[Freeciv-Dev] [patch #3178] Max_Trade_Routes effect

[Marko Lindqvist]

Update of patch #3178 (project freeciv):

  Status:  Ready For Test => In Progress


___

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 #19160] in player_load_units_transporter() [savegame.c::2285]: assertion 'id_trans == -1 || ptrans != ((void *)0)' failed

[Jacob Nevins]

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

The problem appears to be do with units on allied transporters.

When the assertion fires, id_unit=414 (Slovenian Musketeers) and id_trans=713
(Cambodian Transport). The Cambodians are after the Slovenians in the
savefile.

I'm guessing it's checking transporter consistency after loading each player,
rather than all of them (but I haven't looked closer).

It appeared with r20387
, patch
#2477.

It seems to be specific to savegame.c (not savegame2.c); if I load and re-save
the game in 2.3.x, the resulting savefile doesn't trigger the assertion.

___

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 #3181] Kittitian and Nevisian

[J.M. Maalderink]

URL:
  

 Summary: Kittitian and Nevisian
 Project: Freeciv
Submitted by: mixcoatl
Submitted on: Sat Mar  3 23:30:09 2012
Category: rulesets
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: mixcoatl
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Saint Kitts and Nevis

Flag from Denelson83 and Pumbaa80:
http://commons.wikimedia.org/wiki/File:Flag_of_Saint_Kitts_and_Nevis.svg



___

File Attachments:


---
Date: Sat Mar  3 23:30:09 2012  Name: kittitian.ruleset  Size: 2kB   By:
mixcoatl


---
Date: Sat Mar  3 23:30:09 2012  Name: saint_kitts_and_nevis.svg  Size: 1kB  
By: mixcoatl



___

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 #3181] Kittitian and Nevisian nation

[J.M. Maalderink]

Update of patch #3181 (project freeciv):

 Summary:  Kittitian and Nevisian => Kittitian and Nevisian
nation


___

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 #3182] Saint Lucian nation

[J.M. Maalderink]

URL:
  

 Summary: Saint Lucian nation
 Project: Freeciv
Submitted by: mixcoatl
Submitted on: Sat Mar  3 23:40:14 2012
Category: rulesets
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: mixcoatl
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Saint Lucia

Flag based on http://commons.wikimedia.org/wiki/File:Flag_of_Saint_Lucia.svg
by SKopp, Denelson83 and Zscout370



___

File Attachments:


---
Date: Sat Mar  3 23:40:14 2012  Name: saint_lucia.svg  Size: 2kB   By:
mixcoatl


---
Date: Sat Mar  3 23:40:14 2012  Name: saintlucian.ruleset  Size: 2kB   By:
mixcoatl



___

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 #18532] Cannot gracefuly /end a game on a big map

[Marko Lindqvist]

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

> either by making buffers bigger or perhaps by sending stuff
> slower?

I actually suspect (have not tested) that this happens due to our extra
buffering when sending a lot of tiles. Server does not try to send tiny tile
(or other) packets one by one when there's going to be many of them, but
instead buffers them to be sent at once (in many cases as one TCP/IP packet).
I don't know if that's strictly freeze to thaw buffering mechanis, or if it
can send data even between if enough data has been collected.
There's actually two ways this could cause problems.
1) Filling server side buffers as server send is in freeze state collecting
more and more data
2) When huge amount of data is finally sent, it happens *really* quickly from
buffers. There's no longer any packet construction work to do for the server
between packets.

If it's still missing, implementing that "even during "freeze" send each
TCP/IP packet as soon as there's enough data in buffers" could help here too.
Maybe renaming "freeze" & "thaw" to something like "buffering_mode"
"buffering_mode_off" to indicate that it's not stric freeze.

___

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 #3183] Road gfx tags from ruleset

[Marko Lindqvist]

URL:
  

 Summary: Road gfx tags from ruleset
 Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 04 Mar 2012 02:06:12 AM EET
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.5.0

___

Details:

This patch replaces hardcoded tileset road tags (of two road types) with ones
read from ruleset. This is just first step towards supporting drawing more
road types - actual drawing code still supports only first two road types.



___

File Attachments:


---
Date: Sun 04 Mar 2012 02:06:12 AM EET  Name: RoadGfxTags.diff.bz2  Size: 5kB  
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 #3171] City center road upgrade to handle them as road types

[Marko Lindqvist]

Update of patch #3171 (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] [patch #3184] Cantonese nation

[J.M. Maalderink]

URL:
  

 Summary: Cantonese nation
 Project: Freeciv
Submitted by: mixcoatl
Submitted on: Sun Mar  4 00:10:53 2012
Category: rulesets
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: mixcoatl
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Cantonese

flag based on the Hong Kong flag



___

File Attachments:


---
Date: Sun Mar  4 00:10:53 2012  Name: cantonese.ruleset  Size: 2kB   By:
mixcoatl


---
Date: Sun Mar  4 00:10:53 2012  Name: cantonese.svg  Size: 6kB   By: mixcoatl



___

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 #19459] Disbanding units from city dialog by mistake

[Jacob Nevins]

Update of bug #19459 (project freeciv):

  Status:None => Ready For Test 
 Assigned to:None => jtn
 Planned Release: => 2.3.2,2.4.0,2.5.0  

___

Follow-up Comment #1:

Attached patch adds confirmation to the "disband" action for all clients, in
all circumstances. (I'm assuming this is uncontroversial.)

(file #15333, file #15334, file #15335)
___

Additional Item Attachment:

File name: trunk-disband-confirm.diff Size:32 KB
File name: S2_4-disband-confirm.diff  Size:31 KB
File name: S2_3-disband-confirm.diff  Size:27 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 #19493] Unit disband "handling" is very very bad

[Jacob Nevins]

Update of bug #19493 (project freeciv):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Duplicate of bug #19459.

___

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 #18754] Unit context menu too responsive

[Jacob Nevins]

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

I'm adding confirmation to the disband action specifically in bug #19459. I'll
leave this ticket for the more general issue of the Gtk city dialog menus
being a bit twitchy.

___

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 #18532] Cannot gracefully /end a game on a big map

[Jacob Nevins]

Update of bug #18532 (project freeciv):

 Summary: Cannot gracefuly /end a game on a big map => Cannot
gracefully /end a game on a big map


___

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