[Freeciv-Dev] [patch #1416] Adds ruleset for Republic of Venice
Update of patch #1416 (project freeciv): Assigned to:None = dmarks ___ Reply to this item at: http://gna.org/patch/?1416 ___ 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 #1411] game_was_started(): check if the game was started
Update of patch #1411 (project freeciv): Status:None = Ready For Test Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/patch/?1411 ___ 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 #1410] 32 player colors
Update of patch #1410 (project freeciv): Status:None = Ready For Test Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/patch/?1410 ___ 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 #13871] [patch 05/07] add setting action callback function
Update of bug #13871 (project freeciv): Status:None = Ready For Test Assigned to: cazfi = pepeto ___ Reply to this item at: http://gna.org/bugs/?13871 ___ 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 #13873] [patch 07/07] load game settings from ruleset file
Update of bug #13873 (project freeciv): Assigned to: cazfi = pepeto ___ Follow-up Comment #9: This patch could be improved a lot with the new registry interface. ___ Reply to this item at: http://gna.org/bugs/?13873 ___ 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 #1189] [Patch] Allow airlifts to allied cities
Update of patch #1189 (project freeciv): Category:None = general Status:None = In Progress Assigned to:None = pepeto Planned Release: = 2.3.0 ___ Reply to this item at: http://gna.org/patch/?1189 ___ 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 #1198] show changed game settings after reset and rulesetdir
Update of patch #1198 (project freeciv): Status:None = Ready For Test Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/patch/?1198 ___ 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 #1278] struct connection clean up
Update of patch #1278 (project freeciv): Status:None = In Progress Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/patch/?1278 ___ 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 #13498] client abort in 2.1.9+ GTK
Update of bug #13498 (project freeciv): Status: Confirmed = Works For Me Assigned to: mbook = pepeto Open/Closed:Open = Closed ___ Follow-up Comment #26: Doesn't occur anymore in the current branch. I take the responsibility to close this item, whereas it is not really safely fixed for the S2_1 branch. ___ Reply to this item at: http://gna.org/bugs/?13498 ___ 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 #13620] [Wichlist] Gfx layer about native tiles
Update of bug #13620 (project freeciv): Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/bugs/?13620 ___ 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 #13620] [Wichlist] Gfx layer about native tiles
Update of bug #13620 (project freeciv): Planned Release: = 2.3.0 ___ Reply to this item at: http://gna.org/bugs/?13620 ___ 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 #13848] [Patch] More detailed coding style guidelines
Update of bug #13848 (project freeciv): Status:None = In Progress Assigned to: mbook = pepeto ___ Reply to this item at: http://gna.org/bugs/?13848 ___ 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 #13942] No way to unload a busy worker from a transport.
Update of bug #13942 (project freeciv): Assigned to:None = pepeto Planned Release: 2.3.0 = 2.2.0 ___ Reply to this item at: http://gna.org/bugs/?13942 ___ 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 #13943] Allow unit to choose which transport to load onto
Update of bug #13943 (project freeciv): Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/bugs/?13943 ___ 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 #15187] Crash using editing mode
Follow-up Comment #2, bug #15187 (project freeciv): See also bug #14053. ___ Reply to this item at: http://gna.org/bugs/?15187 ___ 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 #14053] nation.c:262: die(bad nation) reached
Update of bug #14053 (project freeciv): Category:None = editor Status:None = Duplicate Assigned to:None = pepeto ___ Follow-up Comment #1: Duplicate of bug #15187. ___ Reply to this item at: http://gna.org/bugs/?14053 ___ 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 #14053] nation.c:262: die(bad nation) reached
Update of bug #14053 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?14053 ___ 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 #14210] optionally include advance benefits in output message
Update of bug #14210 (project freeciv): Planned Release: = 2.3.0 ___ Reply to this item at: http://gna.org/bugs/?14210 ___ 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 #14549] Crash - unknown cause
Follow-up Comment #9, bug #14549 (project freeciv): Does this bug still happen for you? ___ Reply to this item at: http://gna.org/bugs/?14549 ___ 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 #14788] My Freeciv crashes often after only a bit of playing
Follow-up Comment #1, bug #14788 (project freeciv): A lot of crashes have been fixed since the 2.1.6 version. Do you still get this problem with 2.1.10 or 2.1.11? ___ Reply to this item at: http://gna.org/bugs/?14788 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Remove unmaintained clients
Le samedi 16 janvier 2010 à 15:50 +0100, Pepeto a écrit : There is still no answer from Freeciv administrators... Still no answer. Attaching some old comment by Marko: Le jeudi 09 juillet 2009 à 22:29 +0300, Marko Lindqvist a écrit : Keeping clients in a compiling state is not thta much work, typically just search and replace. At least they exist if somebody steps up and starts actie development on some of them, like cproc did with 2.1 SDL client. Developers and hardcore players usually prefer GTK client for its feature completeness.SDL client has large user base among average players for its much better look. IIRC some old versions of Windows cannot use gtk or sdl client, only native client. There might be other portability issues in providing any one client to some platforms. Support for multiple clients has served us well in the past. That allowed us to develop gtk client and later gtk2 client so that they were eventually made default client. Had we decided that we will maintain only the best client of the time, we would still be using xaw client. All that said, we could consider level of maintenance for each client. FTWL has been inactive project for a long time. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1417] Use my_snprintf() instead of snprintf()
URL: http://gna.org/patch/?1417 Summary: Use my_snprintf() instead of snprintf() Project: Freeciv Submitted by: cproc Submitted on: Sonntag 24.01.2010 um 11:42 Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.2.0 ___ Details: $subject Patch for S2_2 and trunk. ___ File Attachments: --- Date: Sonntag 24.01.2010 um 11:42 Name: use_my_snprintf-2010-01-24.diff Size: 977B By: cproc http://gna.org/patch/download.php?file_id=7778 ___ Reply to this item at: http://gna.org/patch/?1417 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Remove unmaintained clients
On Sat, Jan 2, 2010 at 1:30 PM, Pepeto pepet...@gmail.com wrote: I guess those removal would be a solution to speed up the development of Freeciv which is very slow nowadays. There cannot be more clients than active developers! Rather than preemptively remove them, IMO just label them as unmaintained and dont worry about compatibility when making core changes anymore. Either someone will notice the lack and step up to keep them up-to-date (they only really need minor updates before releases) or eventually they'll be outdated and can be removed. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #14549] Crash - unknown cause
Follow-up Comment #10, bug #14549 (project freeciv): I haven't seen it for a while, but I also haven't been playing freeciv much lately, so that's not very conclusive. ___ Reply to this item at: http://gna.org/bugs/?14549 ___ 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 2.1.11 released
Freeciv 2.1.11 has been released. It is a bugfix release for the stable 2.1 branch. For a list of changes, see http://freeciv.org/wiki/NEWS-2.1.11 Find the source tarballs at: http://sourceforge.net/projects/freeciv/files/ http://download.gna.org/freeciv/stable/ On behalf of the Freeciv Dev team, Daniel Markstedt ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1418] Fix a 'FIXME' in md5.c
URL: http://gna.org/patch/?1418 Summary: Fix a 'FIXME' in md5.c Project: Freeciv Submitted by: pepeto Submitted on: dimanche 24.01.2010 à 12:59 Category: general Priority: 1 - Later Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: ___ File Attachments: --- Date: dimanche 24.01.2010 à 12:59 Name: trunk_S2_2_FIXME_md5.diff Size: 529 o By: pepeto http://gna.org/patch/download.php?file_id=7780 ___ Reply to this item at: http://gna.org/patch/?1418 ___ 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 #1278] struct connection clean up
Update of patch #1278 (project freeciv): Status: In Progress = Ready For Test ___ Follow-up Comment #1: Patch attached: remove the useless field 'is_server' from the connection structure, use is_server() function instead. (file #7781, file #7782) ___ Additional Item Attachment: File name: trunk_struct_connection.diff Size:4 KB File name: S2_2_struct_connection.diffSize:4 KB ___ Reply to this item at: http://gna.org/patch/?1278 ___ 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 #13942] No way to unload a busy worker from a transport.
Update of bug #13942 (project freeciv): Category:None = client Status: Confirmed = Ready For Test Planned Release: 2.2.0 = 2.1.12, 2.2.0 ___ Follow-up Comment #3: Fix attached: request the 'idle' activity only if the unit has the 'sentry' activity. Else, it doesn't make sense to cancel. (file #7783, file #7784) ___ Additional Item Attachment: File name: trunk_S2_2_unit_unload.diffSize:0 KB File name: S2_1_unit_unload.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?13942 ___ 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 #1419] Spelling errors
URL: http://gna.org/patch/?1419 Summary: Spelling errors Project: Freeciv Submitted by: None Submitted on: Sunday 01/24/10 at 17:52 CET Category: rulesets Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: ___ File Attachments: --- Date: Sunday 01/24/10 at 17:52 CET Name: norway.diff Size: 636B By: None http://gna.org/patch/download.php?file_id=7785 ___ Reply to this item at: http://gna.org/patch/?1419 ___ 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 #1419] Spelling errors
Update of patch #1419 (project freeciv): Status:None = Ready For Test Assigned to:None = dmarks Planned Release: = 2.2.0 ___ Reply to this item at: http://gna.org/patch/?1419 ___ 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 #15193] Wish: GTK+ client to fit on 480px-tall screens
URL: http://gna.org/bugs/?15193 Summary: Wish: GTK+ client to fit on 480px-tall screens Project: Freeciv Submitted by: drink Submitted on: Sunday 01/24/2010 at 19:14 Category: client-gtk-2.0 Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: Many small computers have displays with only 480 lines, for example Asus EEE 701 or most MID devices and PDAs, which have at best typically only VGA (640x480) resolution. FreeCiv is not playable on these devices because the display does not allow resizing down to a useful size, though there is no particular reason all necessary elements could not fit on the display. I can play civilization in a virtual machine, but I can't play FreeCiv... ___ Reply to this item at: http://gna.org/bugs/?15193 ___ 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 #15193] Wish: GTK+ client to fit on 480px-tall screens
Follow-up Comment #1, bug #15193 (project freeciv): I ignore what version do you play, but there is a client option in the graphics tab to arrange the widgets for small resolutions... Have a try on it. ___ Reply to this item at: http://gna.org/bugs/?15193 ___ 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 #15193] Wish: GTK+ client to fit on 480px-tall screens
Follow-up Comment #2, bug #15193 (project freeciv): I meant in the _Interface_ tab (last setting). ___ Reply to this item at: http://gna.org/bugs/?15193 ___ 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 #15041] Cannot free the fortify order
Follow-up Comment #5, bug #15041 (project freeciv): Can you give more detail on what you were trying to do with the unit which the client wouldn't let you? Also, was the unit ACTIVITY_FORTIFYING, or ACTIVITY_FORTIFIED? This change has unfortunately broken a desirable behaviour of the client for me. I was very pleased when the Clear unit orders on selection option was added (back in RT#40724), as previously it was impossible to focus certain units without losing important state (settler progress or fortification, say); and it's necessary to focus units to see their combat chances against an enemy units, or how many movement points they have left. Now I run with this option cleared all the time, for that reason. I'd like to regain this ability, but obviously without resurrecting *your* problem. I think this means reverting this change and possibly replacing it with another. The most obvious thing you can't do with a focused but busy unit is move it with the cursor keys / number pad -- nothing happens. (All the other orders I've tried supersede fortification.) This movement restriction seems to be enforced on the server, not the client -- variously in test_unit_move_to_tile() (silently discards action) and handle_unit_orders() (discards with error). I don't know if this is deliberate. I can see a point to such a restriction -- it stops you accidentally moving the wrong unit and losing e.g. progress towards a terrain improvement. However, a user can't in general rely on Freeciv to stop them making irreversible mistakes -- accidentally moving a unit somewhere silly is in the same category, and can't be caught. So, I could live without this safety net. If the problem is with unit movements, then I can raise a new bug with an alternative workaround, which depends on what we want to do: * If we want to allow move keys to clear orders, then I think simply calling clear_unit_orders() from key_unit_move() or thereabouts should fix the issue. * If we don't want that, then revert this change and somehow document how you tell a unit that yes, you _really_ mean to disturb it -- there are a couple ways: ** The [G]oto key works even if a unit is fortified/fortifying (the client clears the orders). ** More cumbersome: pressing [SPACE] always clears a unit's orders. You can then re-focus it and use the cursor keys. ___ Reply to this item at: http://gna.org/bugs/?15041 ___ 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 #15041] Cannot free the fortify order
Update of bug #15041 (project freeciv): Status: Fixed = Need Info Open/Closed: Closed = Open ___ Follow-up Comment #6: I checked RT#40724 again. It seems I missed understand the meaning of that option: Patch implements a client option to disable the behaviour that makes units lose their orders/current activity when they are selected. So when the option is not set to its default value, clicking on a unit or selecting a group of units with the selection rectangle or mass select shortcuts (e.g. 'y') will not immediately make the units stop what they are doing. Instead, the units' orders will only be cleared when the user issues new orders (e.g. goto somewhere else, a different activity, etc.) or when space is pressed. You are right on numerous points. My problem was that I was unable to assign new orders to one unit fortified (I don't remember if it was CTIVITY_FORTIFYING or ACTIVITY_FORTIFIED). In this case, shouldn't we consider adding a new key to free the orders of the selected units? ___ Reply to this item at: http://gna.org/bugs/?15041 ___ 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 #15193] Wish: GTK+ client to fit on 480px-tall screens
Follow-up Comment #3, bug #15193 (project freeciv): I forgot to mention that I just tried building myself to get this option, and had it, and the display is still not small enough. ___ Reply to this item at: http://gna.org/bugs/?15193 ___ 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 #15194] Can't abort nuke/paradrop with Esc
URL: http://gna.org/bugs/?15194 Summary: Can't abort nuke/paradrop with Esc Project: Freeciv Submitted by: jtn Submitted on: Sunday 24/01/10 at 20:26 Category: client Severity: 2 - Minor Priority: 5 - Normal Status: Ready For Test Assigned to: jtn Originator Email: Open/Closed: Open Release: 2.1.11, 2.2.0-beta3 Discussion Lock: Any Operating System: None Planned Release: ___ Details: If you've pressed the nuke button Shift+N but have been sobered by the scary nuke cursor, you can't retreat from the brink by pressing Esc. Similarly, you can't abort a paradrop this way. Patch attached. Against S2_2, but also applies to S2_1 and I imagine to trunk as well. ___ File Attachments: --- Date: Sunday 24/01/10 at 20:26 Name: nuke-paradrop-abort.diff Size: 947B By: jtn Allow nuke/paradrop orders to be aborted with Esc. Against S2_2 r16614 http://gna.org/bugs/download.php?file_id=7786 ___ Reply to this item at: http://gna.org/bugs/?15194 ___ 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 #14717] install for all users
Update of bug #14717 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #1: Thanks for the Wesnoth hint. I've adapted the multiuser changes from the Wesnoth installer script to the Freeciv 2.1.11 installer scripts (available at http://download.gna.org/freeciv/packages/windows/installer-scripts/). ___ Reply to this item at: http://gna.org/bugs/?14717 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15041] Cannot free the fortify order
Follow-up Comment #7, bug #15041 (project freeciv): In this case, shouldn't we consider adding a new key to free the orders of the selected units? I have been wondering about that for a while. I do go through the focus unit, [SPACE], re-focus unit, [W] rigmarole to clear a unit's orders/activity and get it back on the available list without actually committing to an order there and then; but I thought that might just be me procrastinating. Do you do the same thing? Currently we have [W] which will dismiss a busy unit without disturbing it, and [SPACE] which will clear a busy unit's orders and also remove it from the list of unit awaiting orders. What we don't have is a key which clears the unit's orders and puts it on the list of units awaiting orders. Clearly we need the ability to do the first and third things. I'm not convinced the second is useful. So, I think we only really *need* two keys, and adding yet another key to all the clients is (a) one more thing to remember (b) a dreadful faff. We could change [SPACE] so that for busy units it doesn't dismiss them entirely (requiring another [SPACE] to do that), or we could swap the function of [W] and [SPACE] for busy units. ___ Reply to this item at: http://gna.org/bugs/?15041 ___ 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] Usability survey
Just spotted this usability survey on the web client. Most of it seems to be of interest to Freeciv in general. www.feedbackarmy.com/get_feedback.slp?url=http://www.freeciv.net ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15041] Cannot free the fortify order
Update of bug #15041 (project freeciv): Status: Need Info = Invalid ___ Follow-up Comment #9: Ok, thank you for the explanation which points out my mistake. I will revert the committed patch immediately. ___ Reply to this item at: http://gna.org/bugs/?15041 ___ 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 #15041] Cannot free the fortify order
Update of bug #15041 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?15041 ___ 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 #15195] Behaviour with Clear unit orders on selection unset is sub-optimal
URL: http://gna.org/bugs/?15195 Summary: Behaviour with Clear unit orders on selection unset is sub-optimal Project: Freeciv Submitted by: jtn Submitted on: Sunday 24/01/10 at 21:34 Category: None Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: Reposted from discussion in bug #15041: The Clear unit orders on selection client option is great for not losing progress towards terrain improvements, fortification bonus, etc. However, there are a couple of issues with interacting with busy units -- that is, units with orders / doing activities, as opposed to idle units). 1. You can't move a busy unit with the cursor keys / number pad -- nothing happens if you try. This movement restriction seems to be enforced on the server, not the client -- variously in test_unit_move_to_tile() (silently discards action) and handle_unit_orders() (discards with error). I don't know if this is deliberate. I can see a point to such a restriction -- it stops you accidentally moving the wrong unit and losing e.g. progress towards a terrain improvement. However, a user can't in general rely on Freeciv to stop them making irreversible mistakes -- accidentally moving a unit somewhere silly is in the same category, and can't be caught. So, I could live without this safety net. If we want to allow move keys to clear orders, then I think simply calling clear_unit_orders() from key_unit_move() or thereabouts should do that. I have a patch lying around which does this; it seems to work. (With no change to the current code, you can always use [G]oto to achieve the same effect, as that clears any orders.) 2. You can't straightforwardly clear a busy unit's orders / activities and get it back on the list of available units (the ones that [W] cycles through). You can focus unit, [SPACE], re-focus unit, [W] rigmarole to clear a unit's orders/activity and get it back on the available list; but this is a faff, especially for units in cities. This may be just a quirk of my playing style; I tend to procrastinate about what to do with units rather than giving them orders there and then. If it's just me, then it's probably not worth doing anything about. However, some thoughts on what could be done, in case anyone else thinks it's a good idea: Currently we have [W] which will dismiss a busy unit without disturbing it, and [SPACE] which will clear a busy unit's orders and also remove it from the list of unit awaiting orders. What we don't have is a key which clears the unit's orders and puts it on the list of units awaiting orders. Clearly we need the ability to do the first and third things. I'm not convinced the second is terribly useful. So, I think we only really need two keys, and adding yet another key to all the clients would be (a) one more thing to remember (b) a dreadful faff. We could change [SPACE] so that for busy units it doesn't dismiss them entirely (requiring another [SPACE] to do that), or we could swap the function of [W] and [SPACE] for busy units. ___ Reply to this item at: http://gna.org/bugs/?15195 ___ 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 #15041] Cannot free the fortify order
Follow-up Comment #13, bug #15041 (project freeciv): I've raised bug #15195 for some of the the issues I raised earlier, to see if anyone else thinks it can be improved. ___ Reply to this item at: http://gna.org/bugs/?15041 ___ 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 #15195] Behaviour with Clear unit orders on selection unset is sub-optimal
Follow-up Comment #1, bug #15195 (project freeciv): 1. This is a bug, and it's probably what I observed for bug #15041. The fix you describe with clear_unit_orders() in the client side is good. Another approach would be to allow to move in the server side from busy units. It would reduce the packet number traffic. However, we should take care to be sure about the implementation, I fear the AI use unit_move_handling() to be sure the unit should move, so probably we would need to set the ACTIVITY_IDLE in handle_unit_move(). 2. I totally agree with you. ___ Reply to this item at: http://gna.org/bugs/?15195 ___ 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 #15195] Behaviour with Clear unit orders on selection unset is sub-optimal
Follow-up Comment #2, bug #15195 (project freeciv): Patch for point 1 attached. 2. I totally agree with you. I didn't actually commit to a course of action (much like my playing style ;) I think of [W] as a harmless, do-nothing key, and [SPACE] as a commit-to-something key (because once you've dismissed a unit with [SPACE] it's a pain to retrieve it). Which suggests my first option -- [SPACE] once clears the orders, a second time dismisses the unit. (file #7787) ___ Additional Item Attachment: File name: clear-unit-orders-on-move.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?15195 ___ 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 #15194] Can't abort nuke/paradrop with Esc
Follow-up Comment #1, bug #15194 (project freeciv):
Don't forget that the bracket {} are required after if () according to
http://freeciv.wikia.com/wiki/Coding_Style ...
___
Reply to this item at:
http://gna.org/bugs/?15194
___
Message posté via/par Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
