[Ohrrpgce] Odd battle caption behaviour

[James Paige]

On Fri, Apr 28, 2017 at 7:50 AM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 29 April 2017 at 02:08, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> On Fri, Apr 28, 2017 at 6:24 AM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> I was trying out attack caption delays, and noticed two odd things.
>>>
>>
> Now I finally understand how caption delays and dramatic pause work. But I
> still don't understand how attack delays, interrupting attacks, chain
> delays, the several attack and chaining bitsets, and active-time/turn-based
> mode all interact! Maybe I should read the HOWTO again! I wonder if there's
> something that can be done, like displaying the sequence of events visually.
>

Some kind of visual debugger for the sequence of delayed events sounds like
it would be very useful. That is what I had in mind when I was making the
F11 attack queue debugger, but I did not take it far enough to be useful
for much other than attach chain delays


> (And add in animations: I was thinking of adding sync points to animation
> definitions specifically so an attack animation can start before and end
> after when an attack is actually inflicted, or for a hero pause for an
> attack animation. Potentially there could be further sync points for the
> attack delay and pause afterwards... or probably I should split it into
> attackstart, attack, attackend animations.)
>

I like that idea!


> The first, I'm pretty sure is a bug.
>>> In active-time mode, if an enemy uses an attack with a long-time caption
>>> (and "Attack captions pause battle meters" is on), but it's the player's
>>> turn next (with battle meter already full, I guess; this is easy to
>>> reproduce in test.rpg by giving attack 0 a long caption), then battle isn't
>>> totally paused: the player can go through the menus and pick an attack even
>>> while the caption is still up. But once they try to actually perform an
>>> attack, battle pauses for the caption to finish.
>>>
>>
>> Hmmm... That sounds like intended behavior to me-- but it might still be
>> something we should change. Even though I might have intended it, I might
>> have been wrong to intend it ;)
>>
>> Should captions pausing battles prevent the player's menu from opening
>> up? I would be okay with that, and it probably isn't a compat break.
>>
>
> Oh, now I'm not so sure it's a bug. I was surprised by it, but I guess it
> does actually make sense and is convenient.
>
>
>>
>>
>>> Secondly, in any battle mode, whether waiting for captions or not, if
>>> the battle ends the caption is immediately removed. I would argue that not
>>> pausing is also a bug, since it easily means a caption is gone almost
>>> immediately. RMZ complained that he has to use workarounds to prevent the
>>> battle from ending. I would argue that this is also a bug. Fixing it
>>> shouldn't be a backcompat problem, because it's only an extra delay.
>>> Alternatively, we could make the caption continue to display during the
>>> victory messages, which is useful in case that general bitset wasn't set
>>> (e.g. in all games before Zenzizenzic), and I guess pause screen fadeout if
>>> we're still waiting for a caption, in case there are no victory messages.
>>>
>>
>> Ah, yes! I do like the idea of pausing captions delaying the end of
>> battle. That should happen for both victory and death.
>>
>> I never thought of it before, but it totally should be fixed.
>>
>
> OK. But if the caption doesn't pause battle, should we keep the caption
> onscreen while the victory messages are up, or keep the current behaviour
> of dismissing it?
>

Hmmm... I think that keeping up the caption while victory messages display
is reasonable. It will be the right thing to do most of the time, and even
if it isn't, it will just be cosmetic, and never game-breaking. Maybe we
can have a per-attack bitset to clear the caption on victory if anybody
asks for it.

---
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170428/30a86669/attachment.htm>