|
From: SourceForge.net <no...@so...> - 2005-08-12 00:06:26
|
Feature Requests item #1256710, was opened at 2005-08-11 13:42 Message generated for change (Comment added) made by eric_mcdonald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1256710&group_id=124062 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface: General Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Skala (matthewskala) Assigned to: Nobody/Anonymous (nobody) Summary: Attempt attack by default Initial Comment: There's some room for debate as to what's the correct behaviour here, which is why I'm filing this as an RFE instead of a bug, but: If I click on an enemy unit to attack it, the UI code will make a capture attempt if capture is possible at all; and a capture attempt means no attack attempt occurs. On the other hand, if I explicitly request an attack (not capture) I get the capture attempt afterwards anyway, and for free with no ACP cost. When capture is available as a choice, then attack will only be availabe if explicitly requested. If (as is the case in one game I'm working on) the chance of success with an attack is high, but the chance of success with a capture is low, then just clicking around on the map means I'll be wasting my effort in seldom-successful capture attempts. I'd rather have the default when I click be "attack", and do an explicit capture command when I want to attempt a capture without doing damage. That seems more intuitive and useful. It might be possible to simulate in the GDL by using the "surrender" mechanism rather than the "capture" mechanism, but that may have different semantics, it means capture as a separate action without attack is no longer possible, and I don't know whether it would connect with the changed-type-if-captured table. I think the simplest way to make this change would be to move the capture logic that starts around like 3336 of ui.c, to after the regular-attack logic, but I haven't tested that carefully. ---------------------------------------------------------------------- >Comment By: Eric McDonald (eric_mcdonald) Date: 2005-08-12 00:06 Message: Logged In: YES user_id=1158352 My biggest problem with the whole attack/capture issue is that there is not a separate table for capture chance from an attack. I ran into this problem several years ago, and it annoyed me. Basically, if you want to allow direct capture, and attack, then you also automatically allow capture-by-attack. From my point of view, I think direct capture could be made into a more useful game device by having the ability to shut off capture-by-attack (and capture-by-fire). As far as the UI attempting direct capture before capture-by-attack, I have mixed feelings on the subject. On the one hand, I certainly see your viewpoint. One the other hand, I think we should still prefer the more graceful method. Why trash something that you can capture cleanly? Was it not Sun Tzu in his Thirteen Chapters (aka., the Art of War), who recommended that attrition only be used as the last resort? One possible improvement would be to always choose the method that costs the least resources (ACP inclusive-or materials). If an attack (with or without capture) cost less than a direct capture, then that would be preferred. Otherwise, the direct capture would be attempted. But, like I said at the beginning of this reply, attack-with-capture being implied by a >0% capture chance and the availability of an attack bothers me more than the UI's affinity for one or the other. I would rather be able to shut off the capture extension for attacks and firing. This would cleanly separate the two actions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1256710&group_id=124062 |
