[Ohrrpgce] Odd battle caption behaviour

Fri Apr 28 17:46:20 PDT 2017

On 29 April 2017 at 04:37, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Fri, Apr 28, 2017 at 9:30 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 29 April 2017 at 03:07, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>> 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
>>>
>>
>> I was actually thinking of something in the editor, but an in-game view
>> would also be good/better
>>
>>>
>>>
>>>> (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!
>>>
>>
>> Which one?
>>
>
> Just the idea of animation sync points in general :)
>
>
>>
>>>
>>>
>>>> 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.
>>>
>>
>> I think a caption during victory wouldn't be strange or unwanted, as long
>> as it disappears soon. Does any game actually use long caption times? I
>> can't think of any reason to have a caption last more than a few seconds,
>> other than to annoy... or perhaps for a slow countdown.
>> I think I would cap the caption time to about 2-3 more seconds once
>> victory is triggered.
>>
>>
> That would be reasonable.
>
>
>> Hmm, delaying the end of battle on victory is one thing, but when the
>> player loses a battle the screen fades out immediately once the animation
>> is done. I actually like that it's so sudden, although missing captions can
>> be annoying. So I'm still a bit cautious about changing it.
>>
>
> I often feel like death goes too quick, and I am sometimes left wondering
> what killed me-- but that is probably a job for a separate feature, like a
> simple option for a global delay after death-in-battle, or maybe an option
> to change the speed of the death fade (do we even have any custom-length
> fades yet anywhere?)
>

Well, I often feel like that too; I guess I'm just so used to being
surprised by death that I came to accept it on its own merits :) I guess
it's not really something that needs to be preserved; but I was only
talking about attacks with captions that pause. A separate option to ensure
a minimum pause before death fade out would be good (and could be
initialised to something larger than 0).

Still not even an argument for fade length

>
> ---
> James
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170429/e214dee0/attachment.htm>