[Freeciv-Dev] [bug #20792] in same_pos() [../../../../common/map.c::887]: assertion 'tile1 != ((void *)0) tile2 != ((void *)0)' failed
Follow-up Comment #9, bug #20792 (project freeciv): Well, I've left a couple of 500x250 WRAPX|ISO autogames running without issue now with 2.3.4 and the default ruleset. So whatever the crash is, it's not trivially (The fact that these proceeded apparently normally also suggests that the MAP_MAX_LINEAR_SIZE assertions are overzealous, but I haven't looked into it.) ___ Reply to this item at: http://gna.org/bugs/?20792 ___ 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 #20739] Vertical lines when using Nvidia driver
Follow-up Comment #4, bug #20739 (project freeciv): Can u check your /proc/mtrr ? if u see all mem uncachable, u should fix that (probably in bios, or by mtrr cleanup in kernel) and check if it helped for freeciv. ___ Reply to this item at: http://gna.org/bugs/?20739 ___ 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 #3906] Road movement cost granularity.
URL: http://gna.org/patch/?3906 Summary: Road movement cost granularity. Project: Freeciv Submitted by: mss_8734 Submitted on: Mon May 13 12:56:03 2013 Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Attachment 1 multiplies the movement cost factors defined in common/movement.h by 10, which enables greater road granularity. Attachment 2 adapts all rulesets that come with a default installation (data/*/terrain.ruleset). Both are made with trunk rev. 22860. ___ File Attachments: --- Date: Mon May 13 12:56:03 2013 Name: move_roads_granularity.diff Size: 476B By: mss_8734 http://gna.org/patch/download.php?file_id=17956 --- Date: Mon May 13 12:56:03 2013 Name: move_roads_granularity_rulesets.diff Size: 8kB By: mss_8734 http://gna.org/patch/download.php?file_id=17957 ___ Reply to this item at: http://gna.org/patch/?3906 ___ 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 #3775] Potential bodyguard looking for units to protect
Follow-up Comment #2, patch #3775 (project freeciv): Of course, with the new terrain features things get much more complicated for the AI. Think of a ruleset where tanks can not cross swamps (they drown), but are fast enough to find a path around and so still could keep pace with, say, a caravan. The proposed patch addresses the classical rulesets, where it gives little improvement with very little code change. In view of rulesets that make extensive use of the new terrain features, AI should check all unit types once when the ruleset is loaded, construct a can follow relationship (a partial order) and use this if possible, but fall back on some crude heuristics if now bodyguards could be found this way. The protected unit would have to check before moving if the bodyguard can follow. If a king is to be protected because of GameLoss attribute, it should stay put behind city walls and movement type of bodyguard does not matter at all. ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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 #20809] Government type list disappears
Follow-up Comment #1, bug #20809 (project freeciv): Actually, it is possible to recover the governments list. I switched to the SDL client, changed the government, and saved the game. When I got back to the GTK client, the government list was restored. ___ Reply to this item at: http://gna.org/bugs/?20809 ___ 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 #3775] Potential bodyguard looking for units to protect
Follow-up Comment #3, patch #3775 (project freeciv): I understand the limited application, but even for that, I'm not sure how this helps the AI use classical units, and all uses of uclass_move_type() are on a list I hope to eliminate. For the classic, civ1, civ2, and multiplayer rulesets, where there aren't such per-terrain restrictions, all the UMT_BOTH units appear to have either fuel or hp_loss_pct restrictions that constrain movement in ways that the current logic doesn't consider when determining potential bodyguards. Such units assigned as classical bodyguards would quickly either die or abandon their charges to survive. For the alien, civ2civ3, and experimental rulesets, the current logic already may not work for S2_5, depending on the exact placement of roads, bases, or other nativity providers. For example, a Mech. Inf. might be selected as a defender for an Engineer, but wouldn't actually be able to provide coverage for the Engineer when building a road over a mountain until the road was built (Alien has even more complex considerations). The above notwithstanding, if there is another ruleset that the AI is able to understand with the current nativity handling that has more complex types that do benefit from this change, I waive my objection, although if I can make the code work without reference to crude nativity, I'll try to patch it away. Although I like the idea of precaching potential followers, I fear that a complete solution would need to involve dynamic bodyguard assignment depending on current targets and comparative pathfinding for the unit and bodyguard to ensure they would be able to travel together and provide coverage over the entire path and during the activity at the destination (which might be only a single turn, for instance a Howitzer attacking a city). Simple precaching based on accessible terrains may not account for cases where the path around inaccessible terrain is too long to be of practical use (or even impossible: consider a thin island bisected by a mountain range), nor for the variable placement of roads and bases over time during the game. For GameLoss, staying in a city is not necessarily sufficient if migration is enabled: the city might not remain there, etc. Similarly, depending on current circumstances, it might be safer for a GameLoss unit to be on transport with some settlers and bodyguards to found a new empire than stay to defend a nearly lost cause in a poor strategic position. That said, city guards do have broader safe nativity ranges (especially if BuildAnywhere), but it may make sense to select units that are capable of attacking a majority of adjacent tiles for proactive defense, AutoAttack, etc. ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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 #3906] Road movement cost granularity.
Follow-up Comment #1, patch #3906 (project freeciv): I really like the idea of this patch, but I think there is a lot more that could be done to make this flexibly work, as follows: 1) Move SINGLE_MOVE to be a ruleset configuration variable (e.g. game.info.single_move), so that ruleset authors could select the degree to which they wanted to be able to adjust granularity (for example, with the suggested patch, there is no means to make a road cost 1/4 of SINGLE_MOVE). If the default in ruleset.c is set to 3, this has the added advantage that no adjustments are required for current rulesets (although one may wish to add comments to make the current rulesets a better source for new ruleset authors). For the ruleset modification envisioned for this patch, the ruleset would simply set this value to 30. 2) Change MOVE_COST_IGTER to be an optional unit type parameter, so that different unit types could have different maximum travel costs: this allows one to specify some units that can travel as easily over mountains as hills (utype-move_cost_igter = SINGLE_MOVE*2), but still move faster on plains, or units that move like there is a road everywhere even in the case where roads have a move_cost of 2: if stacked over patch #3900, this ought be fairly easy to implement (pass int igter_move_cost rather than bool igter to tile_move_cost_ptrs(), with '0' meaning !UTYF_IGTER, add igter_move_cost to pf_parameter, and set it when filling parameters in pf_tools.c, and pass it in single_move_cost()). This should default to 1 to reduce ruleset transition difficulties. Extra points for finding a good name for a unit class configuration variable to define the default scaling between movement points and actions (e.g. attacking) for !UCF_TERRAIN_SPEED classes (such nomenclature being one of the reasons I haven't submitted a patch to do this yet). Personally, I had planned to submit these as separate tickets, but they are both relevant to the content of this patch. A third change that helps ruleset authors adjust granularity would be to replace movement_cost for terrains with move_cost, so that one could have terrains that default to less than a single move (e.g. hardpan saltflats which oughtn't be harder to navigate than roads) without needing to prepopulate the map with lots of invisible roads on the target terrain (and then deal with the road coordination movement issues about source and destination discussed in patch #3829). ___ Reply to this item at: http://gna.org/patch/?3906 ___ 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] Freeciv-web update
Hi all Freeciv developers! It has now been about a week since Freeciv-web became playable on http://play.freeciv.org/ so I thought that I should post an update. 13,688 people visited play.freeciv.org accoding to Google Analytics. Worldwide productivity has plummeted, accoding to pcgamer.com: http://www.pcgamer.com/2013/05/10/freeciv-available-in-html5-browsers-worldwide-productivity-plummets/ As you can see from the Freeciv-web metaserver, there is quite a lot of activity: http://play.freeciv.org/freecivmetaserve/metaserver.php In fact, there is so much activity that the server is running on very high load, and isn't able to accept more players into games at times. So at the moment we already could use more server resources. Here's more background information about the Freeciv-web client: http://freeciv.wikia.com/wiki/FreecivWebClient Here's the source code on github: https://github.com/andreasrosdal/freeciv-web https://github.com/cazfi/freeciv-web (fork us on github!) I would still really like to engage more developers in Freeciv-web development. So if you are interested, then I can help you setup the development environment if you need any help. Also, developers testing the game on http://play.freeciv.org and reporting bugs would be very useful! Andreas ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3775] Potential bodyguard looking for units to protect
Follow-up Comment #5, patch #3775 (project freeciv): 2) Bases can affect tile nativity, rivers are a type of road for 2.5+ 4/6) Units are additionally subject to movement gains/losses for arbitrary requirement conditions from effects.ruleset : thinking about it, there may be a bug in pathfinding that these potential gains/losses are not checked on a per-tile basis. 7) Also, some units can subvert zones of control (e.g. using spies to ease movement of Mech. Inf. in otherwise ZOC-unfreindly terrain) 8) Unit attack capabilities (well, potential victim defense) may also be adjusted based on victim tile and unit type/flag/class. 10) Units with high movement rates may provide better defense due to the ability to perform multiple attacks against potential hostile units. For assignment, perhaps the ferry routines (which badly need an overhaul anyway) could be rewritten to generally provide multiunit accompaniment pathfinding, considering the ability for one unit to carry another, defend another, etc. Units that might seek a bodyguard would attempt to draft one on a per-mission basis, rather than as a permanent assignment. Unemployed bodyguards would seek nearby native cities to await new bodyguard requests (or just defend the city, if nothing interesting is happening nearby). Injured bodyguards/fuel-limited/hp_loss-weak bodyguards might request the charge request a new bodyguard with enough warning to be able to return to somewhere to recharge. ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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 #3775] Potential bodyguard looking for units to protect
Follow-up Comment #4, patch #3775 (project freeciv): I was developing a ruleset based on Ancients. The AI does a bad job on it so I went into the code and this patch is just one of many things I came across. The discussion of it is now already way out of proportion of any harm or benefit from that patch. So let's instead concentrate on what SHOULD be done for a proper, general solution for bodyguard assignment. You have mentioned some points that make bodyguard assignment complex, and I will add some: 1) unit types move differently according to terrain 2) unit types move differently according to terrain modifications (roads, rivers, others?) 3) unit types have different needs for fuel or are susceptible to hit point loss 4) units may have extra move points depending on veteran status 5) different unit types may have different behavior on transport or airlifting 6) movement points may vary on technologies researched 7) some units ignore zones of control, others don't 8) unit defense strength may vary greatly with terrain/modifications 9) strong attacking units might provide better protection than those strong in defense 10-20) I probably missed some So in total, in some rulesets there might be some kind of guardian angel that can follow wherever you go, but generally this will not be the case. From what I recon, there is no way around assigning bodyguards dynamically, more than one (to send one ahead while the other keeps rearguard, essential when the master-plan involves airlifting), and checking on every move if the guards can follow. The routine that assigns bodyguards will need to receive some insight of the planed moves, that is, a path to target, and the unit that should be protected has to check on every move if the guard(s) can follow or if some guards are already at the tile where it wants to move to. ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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 #3906] Road movement cost granularity.
Follow-up Comment #2, patch #3906 (project freeciv): I agree completely, but fear I lack the skill to implement this properly. Perhaps the movement cost for roads could be changed to a percentile as well, instead of a fixed number of movement points. Maybe even a flag for roads to toggle overriding/adding to terrain movement cost? User defined road flags (or accepting the terrain flags) would be great too, but I suppose that might warrant a separate ticket. ___ Reply to this item at: http://gna.org/patch/?3906 ___ 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 #3906] Road movement cost granularity.
Follow-up Comment #3, patch #3906 (project freeciv): I'm mostly working on requirement processing right now, but here are a couple untested candidate patches that implement items 1) and 2). If someone would like to test/adjust/fix these to actually work properly, they can have all the credit (large chunks are mechanical and if nothing else need adjustment to meet the line length guidelines of CodingStyle. I believe they belong in separate tickets. These are currently stacked over all sorts of patches in the review queue, so may not apply to trunk, but should at least point out the sorts of changes that would be needed. Although you claim not to have the skill to write the patches, you've demonstrated the ability to read code, think about code, and submit patches: I suspect you would be able to adapt/debug/review the untested patches. Note that I may have missed something in these patches: they were mostly generated by searching for uses of the constants and making them go away: adjusting rulesets to use the changed code and playtesting is absolutely required as a bare minimum before they could be considered for application. For road flags, I'm waiting for deeper review/application of patch #3832 or lack of other things to do to add the user-defined ones, but wouldn't mind at all if someone else chose to write that before I get to it :). Allowing these to affect the movement mid-move would require much more complex handling in tile_move_cost_ptrs(), and extends beyond my current thinking. (file #17958, file #17959) ___ Additional Item Attachment: File name: 0001-Untested-max_move_cost-patch.patch Size:24 KB File name: 0002-Untested-SINGLE_MOVE-replacement-patch.patch Size:26 KB ___ Reply to this item at: http://gna.org/patch/?3906 ___ 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 #3906] Road movement cost granularity.
Follow-up Comment #4, patch #3906 (project freeciv): I forgot to mention, it's important to do the MOVE_COST_IGTER patch first, as otherwise one has to somehow calculate MOVE_COST_IGTER in relation to SINGLE_MOVE, and hope that it just happens to work for a given value. ___ Reply to this item at: http://gna.org/patch/?3906 ___ 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 #3775] Potential bodyguard looking for units to protect
Follow-up Comment #6, patch #3775 (project freeciv): Regrettably, after the police attack of March 13 on me, I still suffer from the concussion they delivered on me, I have still trouble concentrating and suffer from very curious forms of memory leaks a way I have never known before. Excuse me, but it feels like it will still take a long time until I will be able to valuably contribute by coding or anything that needs code inspection. I'm not sure if I can give general advise or if I simply lack the retrospective to see what I meant as advise is really purest crap. ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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] Freeciv-web update
Good news! Which part (web client or server) is consuming the most resources, and is it CPU or RAM-limited? - Per On Mon, May 13, 2013 at 6:32 PM, Andreas Røsdal andre...@pvv.ntnu.no wrote: Hi all Freeciv developers! It has now been about a week since Freeciv-web became playable on http://play.freeciv.org/ so I thought that I should post an update. 13,688 people visited play.freeciv.org accoding to Google Analytics. Worldwide productivity has plummeted, accoding to pcgamer.com: http://www.pcgamer.com/2013/05/10/freeciv-available-in-html5-browsers-worldwide-productivity-plummets/ As you can see from the Freeciv-web metaserver, there is quite a lot of activity: http://play.freeciv.org/freecivmetaserve/metaserver.php In fact, there is so much activity that the server is running on very high load, and isn't able to accept more players into games at times. So at the moment we already could use more server resources. Here's more background information about the Freeciv-web client: http://freeciv.wikia.com/wiki/FreecivWebClient Here's the source code on github: https://github.com/andreasrosdal/freeciv-web https://github.com/cazfi/freeciv-web (fork us on github!) I would still really like to engage more developers in Freeciv-web development. So if you are interested, then I can help you setup the development environment if you need any help. Also, developers testing the game on http://play.freeciv.org and reporting bugs would be very useful! Andreas ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3775] Potential bodyguard looking for units to protect
Follow-up Comment #7, patch #3775 (project freeciv): My sympathies. I found your comment about what *should* be done insightful and helpful. There's plenty of other nativity issues about: I'm more than happy to delay this discussion until after you're feeling better (and may that be soon, regardless of the time before you have attention for this issue). ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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 #3907] Minor fallback check cleanup for map generator 3
URL: http://gna.org/patch/?3907 Summary: Minor fallback check cleanup for map generator 3 Project: Freeciv Submitted by: mss_8734 Submitted on: Mon May 13 18:22:25 2013 Category: rulesets Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: This patch moves a map size check and removes a doublet in server/generator/mapgen.c:mapgenerator3(). ___ File Attachments: --- Date: Mon May 13 18:22:25 2013 Name: mapgen3_fallback.diff Size: 1kB By: mss_8734 http://gna.org/patch/download.php?file_id=17960 ___ Reply to this item at: http://gna.org/patch/?3907 ___ 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 #3775] Potential bodyguard looking for units to protect
Follow-up Comment #8, patch #3775 (project freeciv): Thanks a lot. I am open to discussion quite well (I have some bright moments once a day :) ). What I wanted to point out is that I can't do any coding/inspection reliably. Discussion as such is fine, it probably even helps me find a way back. If only those taking part in the discussion are aware of my condition and health and do not take offense if some response is unduly late or possibly in a strange way out of topic. (Btw, as I don't feel able neither to code or even to play freeciv I have fallen back to nethack. Wasn't even able to do that in the first 4 weeks after the incident.) ___ Reply to this item at: http://gna.org/patch/?3775 ___ 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] Freeciv-web update
On Mon, 13 May 2013, Per Inge Mathisen wrote: Good news! Which part (web client or server) is consuming the most resources, and is it CPU or RAM-limited? It's limited by both CPU and RAM at the moment. Memory usage 78% and system load (uptime) between 2 and 4. This is running 200 freeciv-web(civserver) server processes. Adding more game servers requires more CPU and RAM. Andreas ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Freeciv play on a Website
Dear Sir or Madam, i'm the webmaster of osgames.de I've heard Freeciv can now be play on a website and must not install on a OS like Windows, Linux etc. I want to support Freeciv and create a new Domain like playfreeciv.de so users can play freeciv like a browsergame. Please contact me. Greetings Martin ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3908] Map size rounding for tilesperplayer map size selection.
URL: http://gna.org/patch/?3908 Summary: Map size rounding for tilesperplayer map size selection. Project: Freeciv Submitted by: mss_8734 Submitted on: Mon May 13 20:36:33 2013 Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Whilst playing around with the map generator code I noticed that the resulting map often has less than 85% of the requested landmass when using tilesperplayer. Applying this patch yields a smaller discrepancy by some crude rounding. ___ File Attachments: --- Date: Mon May 13 20:36:33 2013 Name: mapsize_tpp_rounding.diff Size: 674B By: mss_8734 http://gna.org/patch/download.php?file_id=17961 ___ Reply to this item at: http://gna.org/patch/?3908 ___ 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 #3909] Fix default.lua gettext warning
URL: http://gna.org/patch/?3909 Summary: Fix default.lua gettext warning Project: Freeciv Submitted by: cazfi Submitted on: Tue 14 May 2013 12:00:07 AM EEST 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.3.5, 2.4.0, 2.5.0, 2.6.0 ___ Details: ___ File Attachments: --- Date: Tue 14 May 2013 12:00:07 AM EEST Name: DefLuaGettext.patch Size: 483B By: cazfi http://gna.org/patch/download.php?file_id=17962 ___ Reply to this item at: http://gna.org/patch/?3909 ___ 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 #3910] Mark Alien ruleset strings as no-c-format for gettext
URL: http://gna.org/patch/?3910 Summary: Mark Alien ruleset strings as no-c-format for gettext Project: Freeciv Submitted by: cazfi Submitted on: Tue 14 May 2013 12:15:40 AM EEST Category: rulesets 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: Mark all alien ruleset strings containing % as no-c-format strings for gettext. ___ File Attachments: --- Date: Tue 14 May 2013 12:15:40 AM EEST Name: AlienCFormat.patch Size: 5kB By: cazfi http://gna.org/patch/download.php?file_id=17963 ___ Reply to this item at: http://gna.org/patch/?3910 ___ 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 #3879] Remove negated reqs{} field in favor of something semantically nicer
Update of patch #3879 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3879 ___ 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 #3856] Add nativity check for find_closest_city()
Update of patch #3856 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.4.0, 2.5.0, 2.6.0 ___ Reply to this item at: http://gna.org/patch/?3856 ___ 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 #3908] Map size rounding for tilesperplayer map size selection.
Follow-up Comment #1, patch #3908 (project freeciv): I'm not convinced this part of the code is the issue. I can generate a 20% discrepancy anyway (tilesperplayer=60, landmass=30, mapsize player, 5 players). Everything is evenly divisible, so it falls into the second part of the conditional, but I get a map of 1200 tiles (of which typically more than 350 are land, and I've gotten numbers as high as 389, without enabling tinyisles). At a high level, this is a 20% overage (1200 vs 1000), and much of that is available at a lower level. This doesn't seem to be running against the minimum size (512 tiles), so I blame something in set_sizes(). The same 5 players typically get an underage (4800 from 5000 is only 4%) with tilesperplayer=300. Not to say that this isn't also a potential issue, but since we're counting in thousands for map.server.size, increasing a value of 1.5 from 1 to 2 only reduces us from being 33% wrong to being 25% wrong. We could probably be more accurate if we had more significant digits (and wouldn't need rounding), so we'd be explicitly requesting 1500 tiles for 20% landmass, 5 players, 60 tiles per player, rather than trying to decide which of 1000 or 2000 is a closer match. Given the requirements of map cardinality and defined ratios, I'd argue that sizing/fitting issues cause greater discrepancy than rounding if we carried all the digits. On a side note, if this code is being improved, it may be worth bounding it so that size can't be 0: this causes the server to crash being unable to construct a map (e.g. landmass 45%, 5 players, 60 tiles per player): this rounding will make it harder to hit this condition, but it may still be possible with some input conditions. ___ Reply to this item at: http://gna.org/patch/?3908 ___ 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 #3839] Low hanging nativity fixes
Update of patch #3839 (project freeciv): Status: In Progress = Ready For Test ___ Follow-up Comment #9: For the SDL client fix, it's mostly a random swipe to remove it from grep results. That function should really be rewritten entirely to do things correctly, and if the nativity issue is a good reminder about that, there's no reason to patch it away. From the name of the function to be patched this is affecting how dialog gets constructed. So, is do_paradrop() comment relevant here? It won't be called before player requests (maybe illegally) the paradrop action. Consequently, does this change mean that playher can try to paradrop even when it will not be possible? ___ Reply to this item at: http://gna.org/patch/?3839 ___ 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 #3839] Low hanging nativity fixes
Follow-up Comment #10, patch #3839 (project freeciv): This change may increase the cases where a player may attempt an impossible paradrop, but it also reduces the cases where a player may not attempt a possible paradrop. While it makes no difference for classical rulesets, this code means that no UMT_SEA or UMT_BOTH unit with UTYF_PARADROP may paradrop at all for SDL players, and also means that players using the SDL client may not paradrop onto oceanic transport, regardless of the ruleset definition of paradrop_to_transport. The removal allows these behaviours at the cost of a network exchange potentially reporting Cannot paradrop for units attempting to do things like paradrop to non-native terrain without transport. Note that this network round-trip is currently present for the GTK clients (either library version: try paradropping into ocean with the classic ruleset). The GTK clients currently use can_unit_paradrop() as the only condition, with everything else handled as server response from do_paradrop(), which makes sense to me, but I didn't want to tear all the conditionals out of the SDL client because I don't use it, so might not notice if I broke something removing more than necessary. ___ Reply to this item at: http://gna.org/patch/?3839 ___ 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 #3911] Improve protocol documentation
URL: http://gna.org/patch/?3911 Summary: Improve protocol documentation Project: Freeciv Submitted by: sveinung Submitted on: Mon 13 May 2013 11:10:23 PM GMT Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Add the name of the algoritm used and specify what is in the size field of a normal chunk packet ___ File Attachments: --- Date: Mon 13 May 2013 11:10:23 PM GMT Name: CompressionDocumentation.patch Size: 1kB By: sveinung http://gna.org/patch/download.php?file_id=17964 ___ Reply to this item at: http://gna.org/patch/?3911 ___ 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 #3909] Fix default.lua gettext warning
Follow-up Comment #1, patch #3909 (project freeciv): Argh, oops, sorry. ___ Reply to this item at: http://gna.org/patch/?3909 ___ 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 #20595] Errow while setting temperature below 14 with temperate map
Follow-up Comment #7, bug #20595 (project freeciv): My problem is already solved. I figured to use lua, applied command: code/lua cmd edit.climate_change(edit.NUCLEAR_WINTER,1000)/code (I have small map) Which produced probably far better results than generator would have produced. It would be nice if there were third option, not temperate map or normal map, but temperate map with slight variations in it wetness and coldness values. Better yet if they were configurable. ___ Reply to this item at: http://gna.org/bugs/?20595 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
