[Freeciv-Dev] [patch #3814] Remove gui-win32 from S2_4
URL: http://gna.org/patch/?3814 Summary: Remove gui-win32 from S2_4 Project: Freeciv Submitted by: cazfi Submitted on: Sat 30 Mar 2013 10:21:01 AM EET Category: bootstrap Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.4.0 ___ Details: Now that gui-win32 has been removed from TRUNK there's no longer point in keeping it in S2_4 tarball either - too late for anybody to start fixing it. ___ File Attachments: --- Date: Sat 30 Mar 2013 10:21:02 AM EET Name: Win32Rm-S2_4.patch Size: 4kB By: cazfi http://gna.org/patch/download.php?file_id=17608 ___ Reply to this item at: http://gna.org/patch/?3814 ___ 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 #20652] Homeless ai caravan crash
Update of bug #20652 (project freeciv): Status: In Progress = Ready For Test ___ Follow-up Comment #3: Attached pathc makes homeless caravans to seek new homecity before even considering traderoutes. Caravan that is going to help in wonder building does not need homecity, so looking for one would just waste its turns. (file #17609, file #17610, file #17611) ___ Additional Item Attachment: File name: CaravanHomecityGet.patch Size:4 KB File name: CaravanHomecityGet-S2_4.patch Size:2 KB File name: CaravanHomecityGet-S2_3.patch Size:2 KB ___ Reply to this item at: http://gna.org/bugs/?20652 ___ 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 #3801] Helptext for defense 0 fortify
Update of patch #3801 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3801 ___ 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 #3804] Enabling restricted air transport
Update of patch #3804 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi ___ Follow-up Comment #14: Reading the patch (not yet testing) looks good. Note to committer and anyone using this patch: network capstr needs bump. It's ok that this is not included in patch as it changes very often just causing patches including it not to apply cleanly. - Could you separate experimental ruleset change to another patch (ticket). While I consider the code change to 2.5, I don't want to add new units to supplied ruleset for it in 2.5 timeframe (our major releases have been pending gfx required for new features often enough) - Another issue completely external to this patch itself: We've had plenty of problems with wipe_unit() and friends lately. Keeping it identical between S2_4 and TRUNK would give more testing to S2_4 implementation nearing stable release, so I rather postpone committing this a bit. ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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 #3804] Enabling restricted air transport
Follow-up Comment #15, patch #3804 (project freeciv): Moving the units to a separate patch seems perfectly reasonable, and I'm fairly unconcerned if that ever lands: the units and vector definitions are only set for testing, and may not actually work well in play. Shall I also separate out the refactoring of wipe_unit into something that can be applied to both S2_4 and TRUNK, and then create a patch to enable air that depends upon that? Or alternately, is the plan to wait until S2_4 release prior to applying this to TRUNK? I don't mind either way, but if the refactoring looks useful sooner than air transport, I'll separate it right away, whereas if it's only interesting in this context, I'll wait until 2.4 release, and rebase the patch on the wipe_unit() implementation existing at that point. ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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 #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver
Follow-up Comment #7, bug #20680 (project freeciv): Problem is in documentation. I had hard time deciding which order cvercmp -binary should take parameters as neither seemed to work as natural in all contexts. Sorry, I was unclear -- I think the algorithm is giving the wrong answer. I.e., it's such that Freeciv will consider 2.4.0 older than 2.4.0-beta1 when the time comes. (As it happens, I think the old, pre-r19 order of the command-line arguments is more intuitive.) This is probably getting off-topic for this ticket, but with the old (pre-r19) command-line argument order (X greater Y means is X greater than Y): 2.3.4 greater 2.4.0No# good 2.3.4 greater 2.4.0-beta1 No# good 2.4.0-beta1 greater 2.3.4 Yes # good 2.4.0-beta2 greater 2.4.0-beta1Yes # good 2.4.0-beta2 greater 2.4.0-beta2No# good 2.4.0-beta1+ greater 2.4.0-beta1 Yes # good 2.4.0 greater 2.4.0-beta1 No# bad 2.4.0 greater 2.4.0-specialNo# good, probably 2.4.0 greater 2.4.0-beta Yes # good I think the code around the comment /* Longer version number is greater if all the parts up to end of shorter one are equal. */ needs to either subtokenize (so that the cvercmp_parse_prever() spots beta1 as a thing that reverses the order), or cvercmp_parse_prever() needs to have a match-only-prefix mode. ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #20663] Unloading assert failure when autoattack kills transport
Follow-up Comment #3, bug #20663 (project freeciv): I got failed assert about cargo and transport being in same tile when wipe_unit() tries to unload cargo. Is this the same assertion that was failing at the start of bug #20045? (unit_transport_unload() [unit.c::2072]: assertion 'same_pos(unit_tile(pcargo), unit_tile(ptrans))' failed.) ___ Reply to this item at: http://gna.org/bugs/?20663 ___ 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 #20577] new parameter gameloss_style: GameLoss player's property is redistributed instead of disappearing
Update of bug #20577 (project freeciv): Summary: new parameter gameloss_style in game.ruleset = new parameter gameloss_style: GameLoss player's property is redistributed instead of disappearing ___ Reply to this item at: http://gna.org/bugs/?20577 ___ 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 #20679] [Metaticket] move_unit bugs
Follow-up Comment #1, bug #20679 (project freeciv): Do issues like bug #20682 fall into this category? ___ Reply to this item at: http://gna.org/bugs/?20679 ___ 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 #20685] City dialog sometimes comes up empty on Ubuntu Unity
URL: http://gna.org/bugs/?20685 Summary: City dialog sometimes comes up empty on Ubuntu Unity Project: Freeciv Submitted by: jtn Submitted on: Sat Mar 30 14:04:57 2013 Category: client-gtk-2.0 Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.3.2 Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: Reporting a friend's experience: On Ubuntu 12.10 (Quantal) with the Unity window manager, using the supplied Freeciv package (2.3.2-1), sometimes the city dialog comes up as an empty window frame. See screenshot; ignoring the screenshot-capture dialog, the city dialog for Linköping really is just a frame, which you can move around and the background (main window) stays put (the enclosed pixels aren't dragged around). Closing and re-opening the city dialog (by clicking on the city on the main map) generally (always?) clears this. My friend reports that this seems to occur (more) when building a city (press B, choose city name, click OK or hit Enter -- not sure which), and not so much (or at all?) when clicking on a city. Not sure we're going to do any more about this than say sigh, Unity, but I wanted the ticket as somewhere to accrete any discussion. (It was a toss-up whether to report this in Ubuntu's Launchpad or here. I chose here because their package doesn't have any exciting patches compared to our source code, so I bet a build from our source will suffer the same problem. It could be argued that it belongs in Ubuntu's tracker because sigh Unity.) ___ File Attachments: --- Date: Sat Mar 30 14:04:57 2013 Name: Screenshot from 2013-03-29 23_16_54.png Size: 442kB By: jtn Screenshot from Ubuntu 12.10, freeciv 2.3.2-1 http://gna.org/bugs/download.php?file_id=17612 ___ Reply to this item at: http://gna.org/bugs/?20685 ___ 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 #20663] Unloading assert failure when autoattack kills transport
Follow-up Comment #4, bug #20663 (project freeciv): I think it's the same. I got assert from server side on autogame, but client would probably get same assert upon handling packets server sends in same order. For the client side I also wonder what happens when allied transport (of which you see units inside) moves out of sight. Does transport get removed from the client when cargo is still in another tile? ___ Reply to this item at: http://gna.org/bugs/?20663 ___ 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 #20663] Unloading assert failure when autoattack kills transport
Follow-up Comment #5, bug #20663 (project freeciv): For the client side I also wonder what happens when allied transport (of which you see units inside) moves out of sight. Does transport get removed from the client when cargo is still in another tile? I assume this case is why we have the separate transported_by ID on the client at all -- the code talks about the possibility that the client can't always see the transport of a cargo unit it knows about, and I was struggling to think of a case where this could happen. I guess an allied submarine would do? Feels like if you have units on board a transport, the server ought to always show you any enclosing transports as a special case (but if you launch your last missile from someone else's sub, then you no longer get to see where it is unless you have shared vision). Would need to decide whether you see other cargo; if not then may need care handling capacity limits on the client side. This is all almost certainly a new ticket. ___ Reply to this item at: http://gna.org/bugs/?20663 ___ 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 #18901] Trunk client becomes unresponsive on clicking Connect
Update of bug #18901 (project freeciv): Status:None = Invalid Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?18901 ___ 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 #20685] City dialog sometimes comes up empty on Ubuntu Unity
Follow-up Comment #1, bug #20685 (project freeciv): Aside from Ubuntu 11.10 (Oneiric), all current Ubuntu packages match the Debian packages, and so if there is a desire for a change, it's probably better to ship that change through Debian (although I'll upload something directly if someone happens to have a small quick fix that would break Debian somehow). I can confirm that running on Ubuntu 12.10 Quantal with a different window manager (kwin), this behaviour isn't observed for any of the GTK2 client distributed from the Ubuntu repositories, the GTK2 client from TRUNK, or the GTK3 client from TRUNK, so I'd expect it to be related to Unity specifically, rather than any Ubuntu-local patches to the underlying libraries. I did see it occasionally in the past with Ubuntu 12.04 (Precise) GTK2 client and the Unity window manager, but never tracked it down. Does someone track it down, the best solution is likely to file a bug for the precise offending WM issue on the Unity tracker with a significantly reduced testcase. I'll also volunteer to test if someone doesn't run Unity and thinks they have a patch, as long as testing against the older release meets the test needs. ___ Reply to this item at: http://gna.org/bugs/?20685 ___ 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 #3730] Remove MAX_LEN_USERNAME
Update of patch #3730 (project freeciv): Status:None = Ready For Test Planned Release: = 2.5.0 ___ Additional Item Attachment: File name: remove_MAX_LEN_USERNAME.diff Size:0 KB ___ Reply to this item at: http://gna.org/patch/?3730 ___ 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 #3815] Provide information about unit class nativity in terrain help
URL: http://gna.org/patch/?3815 Summary: Provide information about unit class nativity in terrain help Project: Freeciv Submitted by: persia Submitted on: Sat 30 Mar 2013 03:46:16 PM GMT Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: The current help provides Land units cannot travel on oceanic terrains. as part of the helpstring for any oceanic terrain. Given the concept of terrain nativity, and that units are no longer one of Land, Sea, or Air based on UMT_LAND, UMT_SEA, and UMT_BOTH, this isn't very helpful when playing a ruleset with complex nativity. This patch replaces that with a constructed string of unit classes that are native to that terrain without any special, base, or road. The string is reused from the code to generate the road help, which I hope will reduce the impact of the new string on translators. I would be happy to backport the patch to S2_4 or earlier, if someone believes it should also be applied there. ___ File Attachments: --- Date: Sat 30 Mar 2013 03:46:16 PM GMT Name: terrain-nativity-help.patch Size: 2kB By: persia http://gna.org/patch/download.php?file_id=17614 ___ Reply to this item at: http://gna.org/patch/?3815 ___ 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 #3816] Cleanup nativity handling to ignore specials
URL: http://gna.org/patch/?3816 Summary: Cleanup nativity handling to ignore specials Project: Freeciv Submitted by: cazfi Submitted on: Sat 30 Mar 2013 06:10:10 PM EET Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Tile specials used to affect nativity when road, railroad, and river were specials. That's no longer the case, and shouldn't be in the future - upcoming extras framework should be used if such nativity features are to be added. Code cleanup to stop passing specials information around in nativity functions should be made. ___ Reply to this item at: http://gna.org/patch/?3816 ___ 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 #3804] Enabling restricted air transport
Follow-up Comment #16, patch #3804 (project freeciv): I'd say that if S2_4 wipe_unit() is not proven to be broken, we don't want to touch it any more. I just am not committing this patch immediately after 36h inspection period, but wait closer to S2_5 branching date (02-May). btw. Should wipe_unit() produce exactly same results for rulesets that do not have load/unload restriction before and after this patch? Asking for autogame testing - is it bug in patch if final savegames differ from what resulted before the patch. ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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 #3804] Enabling restricted air transport
Follow-up Comment #17, patch #3804 (project freeciv): Thanks for the clarification. If the implementation model is acceptable, that's enough for me, and I'll keep rebasing it against trunk locally until it seems safe to apply. If anyone has trouble testing the patch currently attached due to trunk changes, please report here, and I'll post a snapshot of patch changes at that time. Similarly, if problems are discovered because of the patch, please post, and I'll address issues. The only behavioural change for rulesets without embarks/disembarks vectors that I intended to introduce was a small optimisation in the drowning logic: specifically that for UTYF_GAMELOSS and UTYF_UNDISBANDABLE units, if they were unable to find transport (or, if UTYF_UNDISBANDABLE, teleport) in the first attempt, they are simply killed, rather than running them through the find-transport logic a second time (which I would expect to have the same negative result). If there is a behavioural difference with the entire patch, I'd like details, and will test against a much-reduced wipe_unit() refactoring, as if the attempt failed the first time and succeeds just because we tried again, there's probably something else wrong. Thinking about it, the current drowning logic (before this patch) iterates over all untransported units on the tile: in the event that the server is running many threads, it could be possible for two transports to be removed on the same tile in separate threads and their units to be intermixed when being saved from drowning (I haven't looked enough at the main server processing loops to know if this is even possible with the current architecture). In the refactored code, this isn't possible, as the set of units being saved/destroyed is limited to the cargo of the transport currently being destroyed, which could potentially cause differing results in saving units based on timing of transport wipes. ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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 #3804] Enabling restricted air transport
Follow-up Comment #18, patch #3804 (project freeciv): About threading: see recent discussion on freeciv-dev mailing list. Freeciv is essentially single-threaded at the moment, but we sho0uld be preparing to the time it's not. ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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] Terrain options parameters
For terrain.ruleset, there are [options] and [parameters] sections.
Do most of these still serve useful purposes? From a quick look at the
code and a bit of testing, I would think they are mostly also handled in
a different way:
[options]
may_road:
This is also managed per-terrain by the road_time entry: when 0, no
road may be built.
This is additionally managed by per-road reqs: one can force roads
to never be built by creating circular reqs.
may_irrigate:
This is also managed per-terrain by the irrigation_result value
This is additionally managed by the Irrig_Possible effect
(or the Irrig_TF_Possible effect if irrigation would transform)
may_mine:
This is also managed per-terrain by the mining_result value
This is additionally managed by the Mining_Possible effect
(or the Mining_TF_Possible effect if mining would transform)
may_transform:
This is also managed per-terrain by the transform_result value
This is additionally managed by the Transform_Possible effect
[parameters]
ocean_reclaim_requirement, land_channel_requirement:
As these depend on requirements that cannot currently be expressed
(percentage of adjacent tiles), I do not believe they can currently be
removed without more extensive changes (and so they fall outside the
scope of what is proposed here).
road_superhighway_trade_bonus:
This appears to be used only to store the value in the ruleset and
send ruleset packets continaing the value, but not in any of the code
that actually checks the trade value of a square. For all the shipping
rulesets that have a Super Highways, this appears to be managed with
the Output_Per_Tile effect.
pollution_* and fallout_*:
These seem like they would be better handled by effects. Something
like:
[effect_pollution_output]
name = Output_Per_Tile
value = -50
reqs =
{ type, name, range
Special, Pollution, Local
}
[effect_fallout_output]
name = Output_Per_Tile
value = -50
reqs =
{ type, name, range
Special, Fallout, Local
}
I'd be happy to prepare and test a patch removing all of this (and
thereby simplifying ruleset documentation), but only if there isn't some
reason to keep them that escapes me.
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Terrain options parameters
On 30 March 2013 18:42, Emmet Hikory per...@shipstone.jp wrote: For terrain.ruleset, there are [options] and [parameters] sections. Do most of these still serve useful purposes? From a quick look at the code and a bit of testing, I would think they are mostly also handled in a different way: [options] may_road: may_irrigate: may_mine: may_transform: Their removal has been in my TODO for a very long time, but I've never initiated the discussion (they have originally been added for some reason, right?) [parameters] road_superhighway_trade_bonus: This appears to be used only to store the value in the ruleset and send ruleset packets continaing the value, but not in any of the code that actually checks the trade value of a square. For all the shipping rulesets that have a Super Highways, this appears to be managed with the Output_Per_Tile effect. Is this true for stable branches too, or have I changed this as part of gen-roads? If stable branches are affected, their documentation (ruleset comments) should be updated to describe the situation. With ruleset format and network protocol freezes we can't remove it completely from stable branches. pollution_* and fallout_*: These seem like they would be better handled by effects. Something like: As we're going to rework specials for 2.6, I don't think it makes much sense to change this to temporary format that would change again to next version (forcing ruleset authors to update it for each version) - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20668] Loaded submarines are not stealth
Follow-up Comment #2, bug #20668 (project freeciv): I'm using default ruleset. Cannot say if missiles had been loaded or unloaded recently since there are submarines of AI player which I see with missiles on board. I saw several times missile(s) in the middle of the ocean with my battleship or AWACS prior I got closer and saw submarine carrying it. I haven't seen it yet close to my city. I will try to build some buoys to test it. Also I will provide you with a savegame as soon as I will discover another one. ___ Reply to this item at: http://gna.org/bugs/?20668 ___ 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 #3027] libicu
Update of patch #3027 (project freeciv): Planned Release: 2.5.0 = 2.6.0 ___ Follow-up Comment #3: http://site.icu-project.org/ Not only UTF-8, but stuff like collations. As for portability concerns, I added icu build to crosser, and it at least builds fine for MinGW. ___ Reply to this item at: http://gna.org/patch/?3027 ___ 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 #20686] assert 'ai-phase_initialized || game.info.phase_mode != PMT_CONCURRENT' failed
URL: http://gna.org/bugs/?20686 Summary: assert 'ai-phase_initialized || game.info.phase_mode != PMT_CONCURRENT' failed Project: Freeciv Submitted by: cazfi Submitted on: Sat 30 Mar 2013 11:27:59 PM EET Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: r22627 Discussion Lock: Any Operating System: None Planned Release: ___ Details: Attached autogame results in assert failure turn 180. Backtrace shows interesting chain of events. First pact between two players is cancelled. I assume it was alliance as cancellation results in unit stack resolving. During stack resolving unit is teleported next to unit or city of third player. That gives new contact between the players, and they negotiate a treaty. 0: in dai_plr_data_get() [../../../../src.patched/ai/default/aidata.c::313]: assertion 'ai-phase_initialized || game.info.phase_mode != PMT_CONCURRENT' failed. 2: Backtrace: 2: 0: ./server/freeciv-server() [0x60492d] 2: 1: ./server/freeciv-server(vdo_log+0x89) [0x608239] 2: 2: ./server/freeciv-server(do_log+0x7d) [0x6082ed] 2: 3: ./server/freeciv-server(fc_assert_fail+0x9f) [0x60851f] 2: 4: ./server/freeciv-server(dai_plr_data_get+0xcf) [0x50b32f] 2: 5: ./server/freeciv-server() [0x4fa5be] 2: 6: ./server/freeciv-server(dai_treaty_evaluate+0x112) [0x4fb6a2] 2: 7: ./server/freeciv-server(handle_diplomacy_create_clause_req+0x10a) [0x48b83a] 2: 8: ./server/freeciv-server(make_contact+0x270) [0x49e2b0] 2: 9: ./server/freeciv-server(maybe_make_contact+0x2eb) [0x49e6bb] 2:10: ./server/freeciv-server(unit_move+0x125) [0x456485] 2:11: ./server/freeciv-server(bounce_unit+0x3c2) [0x45ab02] 2:12: ./server/freeciv-server() [0x45af54] 2:13: ./server/freeciv-server(resolve_unit_stacks+0x3a) [0x45b02a] 2:14: ./server/freeciv-server(handle_diplomacy_cancel_pact+0x53c) [0x49ed2c] 2:15: ./server/freeciv-server() [0x43da9e] 2:16: ./server/freeciv-server(srv_main+0x2b8) [0x43f318] 2:17: ./server/freeciv-server(main+0x21e) [0x43664e] 2:18: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f99eeef9ead] 2:19: ./server/freeciv-server() [0x437061] ___ File Attachments: --- Date: Sat 30 Mar 2013 11:27:59 PM EET Name: phaserepro.serv Size: 184B By: cazfi http://gna.org/bugs/download.php?file_id=17616 ___ Reply to this item at: http://gna.org/bugs/?20686 ___ 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 #3807] Update config.rpath
Update of patch #3807 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3807 ___ 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 #20669] Missing migration from old killcitizen value
Update of bug #20669 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20669 ___ 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 #3818] Ruleset option to disable civil war
URL: http://gna.org/patch/?3818 Summary: Ruleset option to disable civil war Project: Freeciv Submitted by: cazfi Submitted on: Sat 30 Mar 2013 11:48:35 PM EET Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Civil war was just avoided in alien ruleset: Could not throw Adventurers into civil war - no available nations But if someone plays the ruleset with less than all nations, civil war could happen. Picking one of the ruleset's nations as new civil war nation doesn't make sense. Even nation legends tell how the nation in question arrived with its own ship to the planet. Also people that were part of old nation suddenly getting traits of the new nation is a bit off. I'd like to be able to turn off civil war from alien ruleset completely. ___ Reply to this item at: http://gna.org/patch/?3818 ___ 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 #3818] Ruleset option to disable civil war
Update of patch #3818 (project freeciv): Category:None = general Status:None = Ready For Test Planned Release: 2.6.0 = 2.5.0 ___ Follow-up Comment #1: Untested patch (file #17617) ___ Additional Item Attachment: File name: CivilWarOption.patch Size:7 KB ___ Reply to this item at: http://gna.org/patch/?3818 ___ 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 #20661] unit.c::is_square_threatened() uses H_MAP instead of H_FOG
Update of bug #20661 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20661 ___ 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 #19474] max_players dual meaning
Follow-up Comment #2, bug #19474 (project freeciv): Further testing in TRUNK with midgame player /create (new feature in S2_4, which is likely to be affected too) 1. Start singleplayer game with default maxplayers: 126 2. Save 3. Inspect savegame to see that maxplayers setting is 126 there 4. Load 5. /explain maxplayers to see it's 1 6. /create midgamer with no errors 7. /explain maxplayers to see it's still 1 8. /list to see that new player really exist 9. Save with new name 10. Load - 1: Savegame: error restoring 'maxplayers' . (Number of players (5) is higher than requested value (1). Keeping old value.) I don't know yet how many separate bugs that makes. Good news is that there's bugs countering each other (midgame player creation is possible despite maxplayers getting to set to value that should prevent it) ___ Reply to this item at: http://gna.org/bugs/?19474 ___ 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 #19474] max_players cleanup
Update of bug #19474 (project freeciv): Summary: max_players dual meaning = max_players cleanup ___ Follow-up Comment #3: I don't know yet how many separate bugs that makes. Turning this to meta ticket. ___ Reply to this item at: http://gna.org/bugs/?19474 ___ 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 #20689] Maxplayers setting gets set to number of game start players when loading savegame
URL: http://gna.org/bugs/?20689 Summary: Maxplayers setting gets set to number of game start players when loading savegame Project: Freeciv Submitted by: cazfi Submitted on: Sun 31 Mar 2013 02:30:10 AM EET Category: general 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.3.5, 2.4.0, 2.5.0 ___ Details: Split from bug #19474: When loading savegame of running game, maxplayers setting gets set to number of players in game. This is because there's code meant to limit max_players in scenarios to number of starting positions - there cannot be more players than starting positions. That same code gets wrongly applied when one loads already started game with generated starting positions. Number of generated starting positions is one for each player who was present when game started - maxplayers gets set to number of game start players. Attached fix makes maxplayer to be set to number of starting positions in pregame only. ___ File Attachments: --- Date: Sun 31 Mar 2013 02:30:10 AM EET Name: RunningGameStartposCount.patch Size: 3kB By: cazfi http://gna.org/bugs/download.php?file_id=17618 --- Date: Sun 31 Mar 2013 02:30:10 AM EET Name: RunningGameStartposCount-S2_4.patch Size: 3kB By: cazfi http://gna.org/bugs/download.php?file_id=17619 ___ Reply to this item at: http://gna.org/bugs/?20689 ___ 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 #20690] maxplayers setting does not prevent midgame player /create
URL: http://gna.org/bugs/?20690 Summary: maxplayers setting does not prevent midgame player /create Project: Freeciv Submitted by: cazfi Submitted on: Sun 31 Mar 2013 02:39:37 AM EET Category: general 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.4.0, 2.5.0 ___ Details: One can /create players to running game without maxplayers setting any way restricting it. Fix attached. ___ File Attachments: --- Date: Sun 31 Mar 2013 02:39:37 AM EET Name: MidgameMaxplayers.patch Size: 670B By: cazfi http://gna.org/bugs/download.php?file_id=17620 ___ Reply to this item at: http://gna.org/bugs/?20690 ___ 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 #19474] max_players cleanup
Update of bug #19474 (project freeciv): Depends on: = bugs #20689 ___ Reply to this item at: http://gna.org/bugs/?19474 ___ 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 #19474] max_players cleanup
Update of bug #19474 (project freeciv): Depends on: = bugs #20690 ___ Reply to this item at: http://gna.org/bugs/?19474 ___ 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 #3800] activity_type_iterate() optimization
Update of patch #3800 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3800 ___ 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 #3819] Generalise helptext for AttFromNonNative and Marines
URL: http://gna.org/patch/?3819 Summary: Generalise helptext for AttFromNonNative and Marines Project: Freeciv Submitted by: persia Submitted on: Sun 31 Mar 2013 04:44:58 AM GMT Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: There is currently no helptext for UCF_ATT_FROM_NON_NATIVE and the helptext for UTYF_MARINES makes specific references to Land and Sea. The attached patch adds helptext for UCF_ATT_FROM_NON_NATIVE based on the comments in the ruleset definitions, and changes the helptext for UTYF_MARINES to match the new text. ___ File Attachments: --- Date: Sun 31 Mar 2013 04:44:58 AM GMT Name: AttFromNonNative-helptext.patch Size: 1kB By: persia http://gna.org/patch/download.php?file_id=17621 ___ Reply to this item at: http://gna.org/patch/?3819 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Terrain options parameters
On Sat, Mar 30, 2013 at 10:02:02PM +0200, Marko Lindqvist wrote: On 30 March 2013 18:42, Emmet Hikory wrote: For terrain.ruleset, there are [options] and [parameters] sections. Do most of these still serve useful purposes? From a quick look at the code and a bit of testing, I would think they are mostly also handled in a different way: [options] may_road: may_irrigate: may_mine: may_transform: Their removal has been in my TODO for a very long time, but I've never initiated the discussion (they have originally been added for some reason, right?) Bernd Jendrissek helpfully pointed me at SVN commit 1466 which added these values. The inclusion of the more recent per-terrain controls seems to be SVN commit 7513 with per-terrain target activities, which also inherited the may_* values (perhaps for compatibility). I'm not sure they are still needed since commits 19264, 21796, 21845, and 21850 which included the effect controls, and even less with the more recent gen_road changes (I'm not sure precisely which commit to blame for this obsolescence of may_road). Given the timing and history, I think they can be safely removed now that everything else has landed (arguably they might have been candidates for removal post 7513, but the more recent work gives ruleset authors enough flexibility that the original options seem awkward). [parameters] road_superhighway_trade_bonus: This appears to be used only to store the value in the ruleset and send ruleset packets continaing the value, but not in any of the code that actually checks the trade value of a square. For all the shipping rulesets that have a Super Highways, this appears to be managed with the Output_Per_Tile effect. Is this true for stable branches too, or have I changed this as part of gen-roads? If stable branches are affected, their documentation (ruleset comments) should be updated to describe the situation. With ruleset format and network protocol freezes we can't remove it completely from stable branches. This appears to be true for S2_0, S2_1, S2_2, S2_3, S2_4, and trunk. In S1_14, the value is used in city.c:base_city_get_trade_tile(). It appears to be removed with SVN revision 8202, which introduces the effect-based improvement for relevant then-current rulesets. While there's no handy way to search for gen-road revisions, I believe that this was rendered obsolete before any of the gen-road work. For the ruleset comment patches, which releases are still sufficiently supported to benefit from this? For 2.4, can the parameter just be dropped? For trunk, I presume it should be dropped. Also, procedurally, should this be one ticket or multiple tickets? Is it better to call it patch or bug? pollution_* and fallout_*: These seem like they would be better handled by effects. Something like: As we're going to rework specials for 2.6, I don't think it makes much sense to change this to temporary format that would change again to next version (forcing ruleset authors to update it for each version) I looked through the mailing list archives a bit trying to find discussion of the plan for extras, without success. Is there a reference available? -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
