Update of bug #18529 (project freeciv):
Status: Ready For Test = Fixed
Assigned to:None = cazfi
Open/Closed:Open = Closed
Follow-up Comment #10, patch #2715 (project freeciv):
It will likely sound obnoxious, but a bit of googling gave me a solution of
the corruption problem - both the sprites in treeview and transparent cursors
look correctly,
It was just a matter of adding 5 short lines to surface_get_pixbuf
Update of patch #2943 (project freeciv):
Assigned to:None = syntron
Summary: Shave 8/24 bytes of struct tile = Remove
x,y,nat_x,nat_y from struct tile
___
Follow-up Comment
Follow-up Comment #11, patch #2715 (project freeciv):
OK, in the hindsight, it was painfully obvious (and - in a way - already
hinted at in comment 5).
It's actually just 4 lines.
When creating tmpsurf, between cairo_create and cairo_set_source_surface, put
following:
cairo_save(cr);
Follow-up Comment #3, bug #18529 (project freeciv):
This change is causing assertion failures on building cities and crashing
soon afterwards on trunk and S2_3.
I'm looking at it and will commit something soon. The simplest fix which
makes the immediate crashes go away is to wrap the
Follow-up Comment #4, bug #18529 (project freeciv):
Confirmed that my simplest fix doesn't help when building a city on top of
a fortress.
It seems the only safe time to do the destroy_base() is before the city is
created, or at any rate before tile_set_worked(ptile, pcity) (which plumbs it
in
Follow-up Comment #7, bug #18529 (project freeciv):
There's probably a different bug if more than one border
claiming base is on a tile and one is destroyed, too.
That's why initial implementation of border claiming bases made them to
always implicitly (=even when ruleset didn't explicitly)
Update of patch #2806 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #2855 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
URL:
http://gna.org/bugs/?18598
Summary: Assertion failed in tile_set_terrain()
Project: Freeciv
Submitted by: jcreus
Submitted on: Sat Sep 3 22:20:00 2011
Category: client
Severity: 3 - Normal
Follow-up Comment #1, bug #18598 (project freeciv):
This looks like bug #18549.
We haven't got many clues there, so if you can get a reliable reproduction
case, we'd be ever so grateful. Can you retrace your steps from a past
savegame and try to reproduce it?
Follow-up Comment #9, bug #18549 (project freeciv):
See also bug #18598.
___
Reply to this item at:
http://gna.org/bugs/?18549
___
Message sent via/by Gna!
http://gna.org/
Update of patch #2856 (project freeciv):
Status: In Progress = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #18598 (project freeciv):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Yep, sounds
URL:
http://gna.org/patch/?2951
Summary: Generalise RoadNative/RiverNative
Project: Freeciv
Submitted by: jtn
Submitted on: Sun Sep 4 00:49:08 2011
Category: general
Priority: 5 - Normal
Follow-up Comment #6, bug #16383 (project freeciv):
In experimental ruleset, I'd suggest to remove TerrainSpeed
flag from Trireme, else they can move up to 9 tiles along
rivers.
Fixed in bug #18590, thanks.
I would like to be able to create a land class that can't cross
rivers unless
Update of bug #16383 (project freeciv):
Priority: 1 - Later = 5 - Normal
Status: Need Info = In Progress
Assigned to:None = jtn
Release:
Follow-up Comment #10, bug #18549 (project freeciv):
I have a way to reproduce the problem. The assertion fails whenever the focus
moves to a unit inside the problematic city. If the city is empty, nothing
happens. If you move a unit into it (or if a unit is built inside the city),
the message
Update of bug #18549 (project freeciv):
Status:None = Confirmed
___
Follow-up Comment #11:
Yep, confirmed that I can reproduce given those instructions. Brilliant,
thanks.
Update of bug #18549 (project freeciv):
Category:None = client
___
Reply to this item at:
http://gna.org/bugs/?18549
___
Message sent
Follow-up Comment #12, bug #18549 (project freeciv):
Hm, actually, it seems to depend exactly when/how you move the unit, so
here's my reproduction case:
* Take these Workers: [l tgt=unit id=107 name=Workers /]
** Move them North. Turn Done.
** North again. Turn Done.
** North-west. Assertion
Follow-up Comment #13, bug #18549 (project freeciv):
...and here's a Gtk client backtrace (S2_3 r20223):
#0 0x7f9219b3d7bb in raise (sig=value optimised out)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
No locals.
#1 0x005601bf in fc_assert_fail (file=0x5c53fb tile.c,
I was trying to debug some issues with the AI, and i realized that
some checks I put in the code didn't succeed because the 'same_pos'
function does not check the value of x and y in the structure, instead
it just compares the points!!!!!!
How is that supposed to work??!! Which
Update of bug #18549 (project freeciv):
Planned Release: = 2.3.1,2.4.0
___
Follow-up Comment #14:
This seems to have come in with patch #2866 (post-2.3.0), which seems
plausible.
24 matches
Mail list logo
