[Freeciv-Dev] [patch #4970] Better path-finding reverse maps
Update of patch #4970 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4970 ___ 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] [patch #4971] Make path-finding tools able to guess the real move rate of a unit type
Update of patch #4971 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4971 ___ 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 #22389] Server allows to move to transport tile even if it cannot load into
URL: http://gna.org/bugs/?22389 Summary: Server allows to move to transport tile even if it cannot load into Project: Freeciv Submitted by: pepeto Submitted on: jeu. 24 juil. 2014 08:21:52 CEST Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: None Originator Email: Open/Closed: Open Release: S2_4 Discussion Lock: Any Operating System: Any Planned Release: 2.4.3 ___ Details: Another variant of bug #22299 which is only present in the S2_4 branch. Because it is impossible to load into nested transporters, unit_class_transporter_capacity() shouldn't take in account already transported units. Fix attached. ___ File Attachments: --- Date: jeu. 24 juil. 2014 08:21:52 CEST Name: unit_class_transporter_capacity.patch Size: 878 o By: pepeto http://gna.org/bugs/download.php?file_id=21530 ___ Reply to this item at: http://gna.org/bugs/?22389 ___ 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 #22364] Pre-2.3 savegame causing network warnings about too great values to a data type
Follow-up Comment #1, bug #22364 (project freeciv): Actually the problem is not about too big values, but about uninitialized data (I never get the same values in messages). All errors occurs from common/packets_gen.c: line 13938: dio_put_sint8(dout, real_packet-orders_bases[i]); line 13949: dio_put_sint8(dout, real_packet-orders_roads[i]); This looks quite similar to bug #22216. ___ Reply to this item at: http://gna.org/bugs/?22364 ___ 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 #22216] trunk server crashes in execute_orders()
Follow-up Comment #2, bug #22216 (project freeciv): See also bug #22364. ___ Reply to this item at: http://gna.org/bugs/?22216 ___ 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 #22347] helptext_building() - is_nation_pickable(): assertion '!is_server()' failed
Update of bug #22347 (project freeciv): Status:None = Ready For Test Release: = S2_5, trunk Planned Release: = 2.5.0, 2.6.0 ___ Follow-up Comment #1: Quick fixes attached. This bug shows the limit of the is_server() model since we have multiplied freeciv tools. (file #21531, file #21532) ___ Additional Item Attachment: File name: trunk_freeciv_manual.patch Size:2 KB File name: S2_5_freeciv_manual.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?22347 ___ 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 #22346] assertion '((void *)0) != punitclass-cache.native_tile_extras' failed
Follow-up Comment #1, bug #22346 (project freeciv): Attached fix for bug #22347 would also solve this one. ___ Reply to this item at: http://gna.org/bugs/?22346 ___ 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 #22347] helptext_building() - is_nation_pickable(): assertion '!is_server()' failed
Follow-up Comment #2, bug #22347 (project freeciv): See also bug #22346. ___ Reply to this item at: http://gna.org/bugs/?22347 ___ 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 #22386] in can_unit_do_activity_targeted_at() [common/unit.c::1018]: assertion 'target != NULL' failed
Update of bug #22386 (project freeciv): Status:None = Ready For Test Planned Release: = 2.6.0 ___ Follow-up Comment #1: Probable fix attached. (file #21533) ___ Additional Item Attachment: File name: can_unit_do_activity_targeted_at.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?22386 ___ 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 #22390] Musicset option change does not take effect immediately
URL: http://gna.org/bugs/?22390 Summary: Musicset option change does not take effect immediately Project: Freeciv Submitted by: cazfi Submitted on: Thu 24 Jul 2014 11:42:00 AM EEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.6.0 ___ Details: reported by mqtx in the forums: changing musicset requires client restart. Fix attached. ___ File Attachments: --- Date: Thu 24 Jul 2014 11:42:00 AM EEST Name: MusicsetChangeCallback.patch Size: 2kB By: cazfi http://gna.org/bugs/download.php?file_id=21534 ___ Reply to this item at: http://gna.org/bugs/?22390 ___ 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 #22390] Musicset option change does not take effect immediately
Update of bug #22390 (project freeciv): Category:None = client ___ Reply to this item at: http://gna.org/bugs/?22390 ___ 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 #22386] in can_unit_do_activity_targeted_at() [common/unit.c::1018]: assertion 'target != NULL' failed
Follow-up Comment #2, bug #22386 (project freeciv): Also Pollution and Fallout cleaning activities are targeted (though their check is the other way around from irrigation/mine - extra *must* exist to be removed) Are they similarly affected? ___ Reply to this item at: http://gna.org/bugs/?22386 ___ 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 #4968] Infracache to calculate value of extras, and not separately for roads and bases
Follow-up Comment #1, patch #4968 (project freeciv): - Handle conflicting extras correctly when calculating value of extra addition (like base evaluation used to do) (file #21535) ___ Additional Item Attachment: File name: InfraExtra-2.patch Size:13 KB ___ Reply to this item at: http://gna.org/patch/?4968 ___ 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 #22391] Crash in do_paradrop()
URL:
http://gna.org/bugs/?22391
Summary: Crash in do_paradrop()
Project: Freeciv
Submitted by: pepeto
Submitted on: jeu. 24 juil. 2014 12:47:25 CEST
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
Status: Ready For Test
Assigned to: None
Originator Email:
Open/Closed: Open
Release: S2_5, trunk
Discussion Lock: Any
Operating System: Any
Planned Release: 2.5.0-beta2, 2.6.0
___
Details:
Due to patch #3805, there is a potential use of 'punit' pointer after
unit_move().
Fix attached with a good cleanup in the whole function.
Program received signal SIGSEGV, Segmentation fault.
is_native_to_class (punitclass=0x21, pterrain=0xac21e0 civ_terrains+896,
bases=..., roads=...) at movement.c:284
284 if (BV_ISSET(pterrain-native_to, uclass_index(punitclass))) {
(gdb) bt
#0 is_native_to_class (punitclass=0x21, pterrain=0xac21e0 civ_terrains+896,
bases=..., roads=...) at movement.c:284
#1 0x00559f21 in is_native_tile (punittype=0x16c8030,
ptile=0xbc82e0)
at movement.c:242
#2 0x0045459f in do_paradrop (punit=0x16c7f30, ptile=0xbc82e0)
at unittools.c:2793
#3 0x004eb6aa in handle_unit_paradrop_to (
pplayer=pplayer@entry=0x24e67a0, unit_id=optimized out,
tile=optimized out) at unithand.c:2269
#4 0x0049d46d in server_handle_packet (
type=type@entry=PACKET_UNIT_PARADROP_TO, packet=optimized out,
pplayer=pplayer@entry=0x24e67a0, pconn=pconn@entry=0x924920
connections)
at hand_gen.c:217
#5 0x004372e7 in server_packet_input (
pconn=pconn@entry=0x924920 connections, packet=optimized out,
type=80)
at srv_main.c:1652
#6 0x004dc6ea in incoming_client_packets (pconn=optimized out)
at sernet.c:450
#7 server_sniff_all_input () at sernet.c:846
#8 0x00438905 in srv_running () at srv_main.c:2336
#9 srv_main () at srv_main.c:2808
#10 0x00430aee in main (argc=1, argv=0x7fffddb8) at
civserver.c:454
___
File Attachments:
---
Date: jeu. 24 juil. 2014 12:47:25 CEST Name: trunk_do_paradrop.patch Size: 7
ko By: pepeto
http://gna.org/bugs/download.php?file_id=21536
---
Date: jeu. 24 juil. 2014 12:47:25 CEST Name: S2_5_do_paradrop.patch Size: 7
ko By: pepeto
http://gna.org/bugs/download.php?file_id=21537
___
Reply to this item at:
http://gna.org/bugs/?22391
___
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] [patch #4982] Better transporter_for_unit()
URL: http://gna.org/patch/?4982 Summary: Better transporter_for_unit() Project: Freeciv Submitted by: pepeto Submitted on: jeu. 24 juil. 2014 12:51:47 CEST 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, 2.6.0 ___ Details: * prefer transporters without orders, then transporters which can freely unload, then transporters less nested. * use this function instead of transport_from_tile() for scripting, server carriers and server try_to_save_unit() function ; ___ File Attachments: --- Date: jeu. 24 juil. 2014 12:51:47 CEST Name: trunk_transporter_for_unit.patch Size: 5 ko By: pepeto http://gna.org/patch/download.php?file_id=21538 --- Date: jeu. 24 juil. 2014 12:51:47 CEST Name: S2_5_transporter_for_unit.patch Size: 5 ko By: pepeto http://gna.org/patch/download.php?file_id=21539 ___ Reply to this item at: http://gna.org/patch/?4982 ___ 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 #22386] in can_unit_do_activity_targeted_at() [common/unit.c::1018]: assertion 'target != NULL' failed
Follow-up Comment #3, bug #22386 (project freeciv): It seems you have done the check in patch #4086. I don't get any error messages for pollution nor nuclear fallout. ___ Reply to this item at: http://gna.org/bugs/?22386 ___ 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 #22216] trunk server crashes in execute_orders()
Follow-up Comment #3, bug #22216 (project freeciv): Fixed typo for bug #21143. (file #21540) ___ Additional Item Attachment: File name: load_S2_5_unit_orders.patchSize:0 KB ___ Reply to this item at: http://gna.org/bugs/?22216 ___ 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 #22364] Pre-2.3 savegame causing network warnings about too great values to a data type
Update of bug #22364 (project freeciv): Category:None = general Status:None = Ready For Test Planned Release: = 2.4.3, 2.5.0-beta2, 2.6.0 ___ Follow-up Comment #2: This looks quite similar to bug #22216. Actually, this looks like bug #21143. Patches attached for S2_4 (no warning, and safe anyway), S2_5 and trunk (I don't understand why don't I get errors in this branch). (file #21541, file #21542, file #21543) ___ Additional Item Attachment: File name: trunk_load_old_savegame.patch Size:0 KB File name: S2_5_load_old_savegame.patch Size:0 KB File name: S2_4_load_old_savegame.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?22364 ___ 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] [patch #4983] Introduce the UnitState requirement type with the test Transported
URL: http://gna.org/patch/?4983 Summary: Introduce the UnitState requirement type with the test Transported Project: Freeciv Submitted by: sveinung Submitted on: Thu 24 Jul 2014 12:45:53 PM UTC Category: None Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: sveinung Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Add the new requirement type UnitState. UnitState is for checking the properties of a unit's state. It is intended to be like CityTile, but for units. The first test, Transported, checks if the unit is transported. ___ File Attachments: --- Date: Thu 24 Jul 2014 12:45:53 PM UTC Name: 0001-Introduce-the-UnitState-requirement-type-with-the-te.patch Size: 11kB By: sveinung http://gna.org/patch/download.php?file_id=21544 ___ Reply to this item at: http://gna.org/patch/?4983 ___ 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 #22381] Inconsistent nativity limits on source tile for regular attacks
Follow-up Comment #2, bug #22381 (project freeciv): _ For the source tile in unit_attack_unit_at_tile_result(), changing to can_exist_at_tile() would be better._ Another benefit of testing for can exist is that it becomes consistent with spy actions. ___ Reply to this item at: http://gna.org/bugs/?22381 ___ 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 #4894] Add the new test TransportDependent to the UnitState requirement type
Update of patch #4894 (project freeciv): Summary: UnitState requirement type with the test TransportDependent = Add the new test TransportDependent to the UnitState requirement type ___ Follow-up Comment #3: Update to apply on top of current trunk and patch #4983 _To confirm, the intent is to use the same nativity logic as is used for attacks_ The intent of the patch is to check if the unit can exist on its tile (without a transport). That is the current restriction on spy actions. This is what you listed. At the moment (bug #22381) this is different from what is used in attacks. _ if there is a UnitState requirement, having an IsTransported state may be potentially useful anyway, even if not required to implement this specific abstraction._ I agree. See patch #4983 (file #21545) ___ Additional Item Attachment: File name: 0002-Add-the-new-test-TransportDependent-to-the-UnitState.patch Size:4 KB ___ Reply to this item at: http://gna.org/patch/?4894 ___ 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 #4683] Make the Marines and AttFromNonNative flags action neutral
Update of patch #4683 (project freeciv): Status: Wont Do = In Progress Open/Closed: Closed = Open ___ Follow-up Comment #3: _It seems a logical accompaniment to patch #4894 to allow ruleset authors to express that a specific action can be performed by a transport-dependent unit only if they have one of the Marines or AttFromNonNative flags set_ Good point. ___ Reply to this item at: http://gna.org/patch/?4683 ___ 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 #22381] Inconsistent nativity limits on source tile for regular attacks
Follow-up Comment #3, bug #22381 (project freeciv): That the source tile isn't checking can_exist_at_tile() now is an oversight (and a bug). I'm unsure of the right solution for the destination tile though. Should the source bug just be fixed, and we can discuss the destination more? Should can_exist_at_tile() be refactored so that there is another function that includes everything by the safety test that can be called from can_exist_at_tile(), and that used, so everything is a single commit? Is there a narrative reason UTYF_TRIREME units should not attack unsafe terrains? ( I almost added a patch for this as soon as it was raised, but suddenly became uncertain regarding these questions, so commented instead). As for consistency with spy actions: I strongly believe we need to determine the right answer, and then have that apply in both situations (ignoring facilities for ruleset flexibility that may permit ruleset authors to adjust this), rather than that we ought make this change for the value of consistency (that the current actions implementation happens to be right means that I actually want consistency, just not for the sake of consistency). Unfortuntately, I don't have capacity to think about this deeply currently, so can't help that much (and would be happy with the conclusion of anyone else who is able to think about it sooner). ___ Reply to this item at: http://gna.org/bugs/?22381 ___ 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 #4984] What destination tiles should a non AttackNonNative be able to attack?
URL: http://gna.org/patch/?4984 Summary: What destination tiles should a non AttackNonNative be able to attack? Project: Freeciv Submitted by: sveinung Submitted on: Thu 24 Jul 2014 01:18:40 PM UTC Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: In bug #22381 Emmet Hikory persia wrote: _I'm unsure of the right solution for the destination tile though. (...) Should can_exist_at_tile() be refactored so that there is another function that includes everything by the safety test that can be called from can_exist_at_tile(), and that used, so everything is a single commit? Is there a narrative reason UTYF_TRIREME units should not attack unsafe terrains?_ ___ Reply to this item at: http://gna.org/patch/?4984 ___ 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 #4984] What destination tiles should a non AttackNonNative be able to attack?
Follow-up Comment #1, patch #4984 (project freeciv): * The current limit is that the tile must have a native terrain type or be native from an extra. * Should a city where the unit could exist make it native? _Is there a narrative reason UTYF_TRIREME units should not attack unsafe terrains?_ A possible narrative is that it may have to enter the unsafe terrain to attack a unit on it. So a small near cost boat may have a problem attacking a ship in the open sea. ___ Reply to this item at: http://gna.org/patch/?4984 ___ 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 #22381] Inconsistent nativity limits on source tile for regular attacks
Follow-up Comment #4, bug #22381 (project freeciv): _Should the source bug just be fixed, and we can discuss the destination more?_ I think that is a good idea. I raised patch #4984 for discussing that issue. I could start working on this bug today (unless you already have started). _As for consistency with spy actions: I strongly believe we need to determine the right answer, and then have that apply in both situations_ Agreed. (This is why patch #4894 still is In Progress) ___ Reply to this item at: http://gna.org/bugs/?22381 ___ 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 #22381] Inconsistent nativity limits on source tile for regular attacks
Update of bug #22381 (project freeciv): Status: In Progress = None Assigned to:sveinung = None ___ Follow-up Comment #6: I wrote the source patch on Tuesday, but discarded it :) Please feel free to do it, as I won't have time to test it properly until this weekend, at the soonest. A strategy involving patch #4984 seems a reasonable plan (and provides proper semantic separation between the bugfix and the potential behaviour change). ___ Reply to this item at: http://gna.org/bugs/?22381 ___ 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 #4985] Path-finding better attack handling
URL: http://gna.org/patch/?4985 Summary: Path-finding better attack handling Project: Freeciv Submitted by: pepeto Submitted on: jeu. 24 juil. 2014 16:07:28 CEST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Two noticeable changes: 0 path-finding is able to handle unit reachability ; 0 when attack is impossible, don't try fall back to ACTION_NONE and try to do a normal move. Note it may need changes, depending of current discussions about combat rules (bug #22381, patch #4984). ___ File Attachments: --- Date: jeu. 24 juil. 2014 16:07:28 CEST Name: pf_better_attack_handling.patch Size: 9 ko By: pepeto http://gna.org/patch/download.php?file_id=21548 ___ Reply to this item at: http://gna.org/patch/?4985 ___ 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] [patch #4985] Path-finding better attack handling
Follow-up Comment #2, patch #4985 (project freeciv): I have thought about that and based by first version of the patch on it. But the process is very different. In combat.c, we test unit/unit (duplicating lot of useless tests) with full data. In path-finding, we want to know (1) if we are able to attack (then if it is useful to test attack at all), (2) if we would be to attack a tile, (3) if we can attack the tile from many tiles. ___ Reply to this item at: http://gna.org/patch/?4985 ___ 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 #22187] Client allows attempted violation of embarks/disembarks restrictions
Update of bug #22187 (project freeciv): Assigned to: pepeto = None ___ Follow-up Comment #12: I won't do that for S2_5. ___ Reply to this item at: http://gna.org/bugs/?22187 ___ 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 #22392] 1: in is_native_to_class() [movement.c::301]: assertion '((void *)0) != punitclass-cache.native_tile_bases' failed.
URL: http://gna.org/bugs/?22392 Summary: 1: in is_native_to_class() [movement.c::301]: assertion '((void *)0) != punitclass-cache.native_tile_bases' failed. Project: Freeciv Submitted by: pepeto Submitted on: jeu. 24 juil. 2014 20:35:38 CEST Category: client Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_4 r25712 Discussion Lock: Any Operating System: None Planned Release: ___ Details: Noticed on terminal, but I don't know the exact circumstances: 1: in is_native_to_class() [movement.c::301]: assertion '((void *)0) != punitclass-cache.native_tile_bases' failed. 2: Backtrace: 2: 0: ./client/freeciv-gtk2() [0x5de24b] 2: 1: ./client/freeciv-gtk2(vdo_log+0x8b) [0x5e27fb] 2: 2: ./client/freeciv-gtk2(do_log+0x7d) [0x5e28ad] 2: 3: ./client/freeciv-gtk2(fc_assert_fail+0x8e) [0x5e2a9e] 2: 4: ./client/freeciv-gtk2(is_native_to_class+0x1cf) [0x533f6f] 2: 5: ./client/freeciv-gtk2(is_native_tile_to_class+0x2e) [0x53434e] 2: 6: ./client/freeciv-gtk2(is_native_near_tile+0x1de) [0x53453e] 2: 7: ./client/freeciv-gtk2(collect_eventually_buildable_targets+0x109) [0x472a69] 2: 8: ./client/freeciv-gtk2(refresh_worklist+0x84) [0x467f44] 2: 9: ./client/freeciv-gtk2(real_city_dialog_refresh+0x16b) [0x4c7d4b] 2:10: ./client/freeciv-gtk2(real_city_dialog_popup+0x1773) [0x4c9a53] 2:11: ./client/freeciv-gtk2() [0x4bcc53] 2:12: ./client/freeciv-gtk2() [0x4bc9f2] 2:13: ./client/freeciv-gtk2() [0x44650a] 2:14: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x135) [0x7fbf341f0ce5] 2:15: /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49048) [0x7fbf341f1048] 2:16: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a) [0x7fbf341f130a] 2:17: /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7) [0x7fbf34f4c447] 2:18: ./client/freeciv-gtk2(ui_main+0x539) [0x447789] 2:19: ./client/freeciv-gtk2(client_main+0x305) [0x46ec15] 2:20: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fbf33be5ec5] 2:21: ./client/freeciv-gtk2() [0x44469e] ___ Reply to this item at: http://gna.org/bugs/?22392 ___ 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 #22392] 1: in is_native_to_class() [movement.c::301]: assertion '((void *)0) != punitclass-cache.native_tile_bases' failed.
Update of bug #22392 (project freeciv): Status:None = Ready For Test Operating System:None = Any Planned Release: = 2.4.3 ___ Follow-up Comment #1: I found the cause. I connected after the game was over. When attaching, the client doesn't allocate the unit_class caches. Noticed that with many cycles of attaching/detaching, the cache was allocated many times (but not free). Hack attached. (file #21552) ___ Additional Item Attachment: File name: S2_4_client_set_unit_class_caches.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?22392 ___ 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 #22393] 1: in begin_phase() [srv_main.c::1028]: assertion 'ptrans != ((void *)0)' failed.
Follow-up Comment #1, bug #22393 (project freeciv): Looks like its cause by land barbarians in the ocean. Attaching savegame with barbarians in ocean. Started with a a set gameseed and mapseed so reproducable: /ruleset classic /set minplayers 0 /set timeout -1 /set saveturns 100 /set alliedvictory disabled /set citymindist 7 /hard /set mapseed 142012235 /set gameseed 126418634 /start (file #21553) ___ Additional Item Attachment: File name: BarbarOcean.sav.bz2Size:20 KB ___ Reply to this item at: http://gna.org/bugs/?22393 ___ 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 #22393] 1: in begin_phase() [srv_main.c::1028]: assertion 'ptrans != ((void *)0)' failed.
Follow-up Comment #2, bug #22393 (project freeciv): Do the second patch in patch ##4973 solve your issue? ___ Reply to this item at: http://gna.org/bugs/?22393 ___ 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 #22393] 1: in begin_phase() [srv_main.c::1028]: assertion 'ptrans != ((void *)0)' failed.
Follow-up Comment #3, bug #22393 (project freeciv): _Do the second patch in patch ##4973 solve your issue?_ Yes. ___ Reply to this item at: http://gna.org/bugs/?22393 ___ 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 #4977] Add meta knowledge for the building (improvement) requirement type.
Update of patch #4977 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4977 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
