[Freeciv-Dev] [bug #20705] Transported unit in tile going fogged

2014-10-24 Thread pepeto
Update of bug #20705 (project freeciv):

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


___

Reply to this item at:

  http://gna.org/bugs/?20705

___
  Message posté via/par Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #20705] Transported unit in tile going fogged

2014-10-23 Thread pepeto
Follow-up Comment #4, bug #20705 (project freeciv):

 Forgot to mention there will be one remaining bug: after B
 takes C city, A see the city unoccupied (fogged tile).

Raised as bug #22865.


___

Reply to this item at:

  http://gna.org/bugs/?20705

___
  Message posté via/par Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #20705] Transported unit in tile going fogged

2014-10-22 Thread pepeto
Update of bug #20705 (project freeciv):

Category:None = general
  Status:None = In Progress
 Assigned to:None = pepeto 
Operating System:None = Any

___

Follow-up Comment #1:

Attaching savegame for testing matching comment #0 description.

Noticed that in all branches, A was not able to click B's transport to see
units inside.

Client A gets the following error messages:

1: in unit_transport_unload() [unit.c::2105]: assertion
'same_pos(unit_tile(pcargo), unit_tile(ptrans))' failed.
1: in unit_transport_unload() [unit.c::2105]: assertion
'same_pos(unit_tile(pcargo), unit_tile(ptrans))' failed.

(+ TRUNK only)

1: Server wants us to remove unit id 119, but we don't know about this unit!
1: Server wants us to remove unit id 119, but we don't know about this unit!
1: Server wants us to remove unit id 119, but we don't know about this unit!
1: Server wants us to remove unit id 119, but we don't know about this unit!


Client C gets the following error messages (unexpected in original summary I
think):

1: 0x1d606c0 119 Galleon at (32,25) B
1: in handle_tile_info() [packhand.c::2730]: assertion '0 ==
unit_list_size(ptile-units)' failed.


Client B and server have no error messages.


(file #22699)
___

Additional Item Attachment:

File name: bug20705.sav.bz2   Size:11 KB


___

Reply to this item at:

  http://gna.org/bugs/?20705

___
  Message posté via/par Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #20705] Transported unit in tile going fogged

2014-10-22 Thread pepeto
Update of bug #20705 (project freeciv):

  Status: In Progress = Ready For Test 
 Planned Release: = 2.5.0, 2.6.0   

___

Follow-up Comment #2:

 Noticed that in all branches, A was not able to click B's
 transport to see units inside.
Raised as bug #22851.

 Client A gets the following error messages:
 1: in unit_transport_unload() [unit.c::2105]: assertion
 'same_pos(unit_tile(pcargo), unit_tile(ptrans))' failed.
Raised as bug #22852.

 1: Server wants us to remove unit id 119, but we don't know about this
unit!
Raised as bug bug #22853 for two of them. Fixing the two other here.

 Client C gets the following error messages (unexpected in
 original summary I think):
 1: 0x1d606c0 119 Galleon at (32,25) B
 1: in handle_tile_info() [packhand.c::2730]: assertion '0 ==
 unit_list_size(ptile-units)' failed.
Fix attached: transfer_city() now hide/reveal units for all players (removed
the saw_entering) which was only working for one unit and which was also not
enabled in the case of city transferring by diplomatic treaty.

Not targeting for 2.4.4, because:
* there is no supplied ruleset able to reproduce this bug;
* this would only throw safe assertion, it is still possible to play with
them;
* I am quite scared to break something else;
* it would require more work than for S2_5 and trunk.


(file #22707, file #22708)
___

Additional Item Attachment:

File name: trunk_transfer_city_reveal_hide_units.patch Size:4 KB
File name: S2_5_transfer_city_reveal_hide_units.patch Size:4 KB


___

Reply to this item at:

  http://gna.org/bugs/?20705

___
  Message posté via/par Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #20705] Transported unit in tile going fogged

2014-10-22 Thread pepeto
Follow-up Comment #3, bug #20705 (project freeciv):

Forgot to mention there will be one remaining bug: after B takes C city, A see
the city unoccupied (fogged tile).


___

Reply to this item at:

  http://gna.org/bugs/?20705

___
  Message posté via/par Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #20705] Transported unit in tile going fogged

2013-04-03 Thread Marko Lindqvist
URL:
  http://gna.org/bugs/?20705

 Summary: Transported unit in tile going fogged
 Project: Freeciv
Submitted by: cazfi
Submitted on: Wed 03 Apr 2013 11:28:32 PM EEST
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

I think there would be still one combination corner case even when bug #20663
(when transport moves, cargo is temporarily in old tile when it's already
required in new tile) and bug #19989 (info about unit movement not yet sent to
client when movement causes old tile to become fogged) are fixed ot the extend
of their current proposed patches. It's still possible that cargo has not yet
moved when tile gets fogged.

We may get away this by the fact that also server thinks that cargo has not
yet moved - so server and client are not out-of-sync about what units exist in
tile getting fogged.

I have not tested, but I think it's possible to create such an situation:
1) Client A is allied to player B (sees inside transports)
2) A has shared vision from player C
3) B  C are at war
4) Ruleset has transport capable of occupying cities
5) A sees some B's transport only thanks to shared vision from C (that's a bit
odd situation itself - C itself does not see inside B's transport, but still
gives that information to A?). More precisely: B's transport is seen by C's
empty city next to said city
6) B's transport moves to occupy C's city. C and A lose vision of the area.





___

Reply to this item at:

  http://gna.org/bugs/?20705

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


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