Changes between Initial Version and Version 1 of Ticket #1719, comment 8


Ignore:
Timestamp:
May 30, 2013, 12:09:36 AM (11 years ago)
Author:
zoot

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1719, comment 8

    initial v1  
    44> * It seems like there could be almost constant attacked sounds if there were numerous attacks on different parts of the map, which would be annoying and not really more informative (would it?).
    55
    6 I'm not sure if it would be annoying. But I do suspect it would annoying to receive a notification for some minor attack, and then missing the notification for a subsequent major attack due to the cooldown. (I haven't tested it, though.)
     6I'm not sure if it would be annoying. But I do suspect it would be annoying to receive a notification for some minor attack, and then missing the notification for a subsequent major attack due to the cooldown. (I haven't tested it, though.)
    77
    88> * The chat message on attack isn't working, you need to add a call to `addChatMessage()` in `handleNotifications()`.
    99
    10 True, I actually left it non-fuctional semi-intentionally. I personally would not want the text message to clutter my screen, but I figured it would be handy in some situations, like if you have no sound (or if you are deaf). So I would suggest making it toggleable with some configuation value, but I am not sure how to go about obtaining such a value from JS. Any suggestions/pointers?
     10True, I actually left it non-fuctional semi-intentionally. I personally would not want the text message to clutter my screen, but I figured it would be handy in some situations, like if you have no sound (or if you are deaf). So I would suggest making it toggleable with some configuation value, only I am not sure how to go about obtaining such a value from JS. Any suggestions/pointers?
    1111
    1212> * I think an attack notification should be sent even if a unit is invulnerable (it's important for the player to know, as it may be a temporary effect) and indeed whether or not damage is done, but we already have the `MT_Attacked` message, why not avoid passing the extra parameter to `TakeDamage(` or handling it in the damage receiver? The `AttackDetection` component already handles `MT_Attacked` messages - seems like a good fit and minimizes the interface other components need to use.