Possible change?

[gas]

Actually, when you exit a mode to enter another, any mode callback is staged at the very next interaction.

What does this mean?
Main menu, choice menu and any other context are unable to stage any meaningfull feedback.

Case of use.
You click START on the main menu. The rempy behaviour is to immediately exit this context and start the new interaction.This prevent any chance to play sounds or animations as a feedback reaction while in the same context.
Practically ALL GAMES since 1983 give you such feedbacks. Even GameBoy games do so: click start and the start flash for a second BEFORE darkening the screen.

The same is for game choices. You cannnot have contextual feedbacks, as the moment the action is processed, you'll enter the new interaction. This prevent, for example, to underline a choice like practically all NVL since early 1990 PC ports of NEC games... I can do hundred of examples, it look like an industry standard.
An example is CARTAGRA. Pick a choice, the other fade out, this one move to center and blink.
THEN the next scene is staged.
As for actual renpy, if you'll try to do so, any scene and transition and screen shown are staged ALONG such feedback (you've already entered the next interaction).

As such kind of feedbacks are here since the early '90, is strange that Renpy lack it in 2020...

If I'm correct, the check of a mode change is made AFTER entering the new mode, and so the next interaction.
This is 'cause (from what I've understood) renpy does "one thing at the time", even if this mean doing multiple things at once. That make for a single "step" called "interaction".
So, the button feedback of a mode callback will be staged along the "things" of the next interaction. As renpy is unable to predict the next mode (obviously) before entering it, and anyway the present interaction has been already staged...

Anyway, I'm TOTALLY sure renpy is able to determine the end of a context. And that is all suffice to trigger a behaviour change.
Now, adding "meta_interaction" phases between modes should solve the issue.
If nothing is stated, the meta is void and not executed.
If something is pushed inside the meta, it get executed between the previous and next mode, generating a temporary context with his own interaction.
Such meta_interaction don't care about future modes, only "we're not anymore the present mode". So execute anyway.
After the meta interaction, execution immediately shift to the planned context (no user input).
The effect will be:
[choice mode]
[pick a choice]
[Are you exiting the mode?] > yes > [check the meta_interaction] > something? > [stage the meta_interaction]
[next interaction]

I hope this make any sense.
It could be very helpfull to increase renpy ergonomy.

[Imperf3kt]

You can make this yourself using the available resources at hand. In one of my games, clicking the start button makes the buttons fade out then the game interface fades in.
I achieve this by making the button call an animation instead of using the start() action.

In another (much older) project, bringing up the "pause menu" or trying to quit the game, makes some kind of tablet cover interface close over the screen before bringing up the appropriate menu.


You can achieve what you want, you just need to think outside the box.

[gas]

Hi!
Surely there are ways to cheat the engine the way you want. You can also forego the entire main menu.
I'm talking the default renpy behaviour and what is able to do out of the box given the standard functions.

Anyway, as for your example, the fade belonged to the next interaction. And that's strange, as logically what you wished for is to have something happen between this mode and the other, not in the other directly. That forced you to cheat the engine while it sound reasonable to have pre-emptive events.

The choice menu is probably the most blatant case, any feedback will be automatically staged the next interaction. That imply a number of issue: if there's a scene change, the background change, and the first side image (at least until my last attempts) is gone for some timing issue. You cannot even pause: the pause happen in the next interaction (if you'll pause in the script as a consequence of the choice, the pause is staged BEFORE the feedback).
This happen just for a design choice: the moment the menu context return, it automatically exit the mode and quiiickly rush to the next interaction - that's not mandatory for the thing to work, just a design choice of the dev team (PyTom).

If you have "placeholder callbacks" between modes, you can have such feedbacks and keep all the regular functions.

Probably that's not a great thing on the surface, and as you said you can code creative workarounds, but doing workarounds the whole time while kids got Live2D support is enervating XD XD.

[PyTom]

This is one of those things that's a lot more subtle than it appears at first.

If I'm understanding what you want, it's a way to display something after an interaction, but before the engine continues. So the question is - what does that thing consist of. My guess is you want to keep re-using the existing screens, but in a way in which the buttons can't be interacted with until the the transition effect finishes. In order to implement this, we need a whole new kind interaction in which some things can't be interacted with.

I think this might make sense, but it's a huge set of changes, and one that I suspect one that doesn't add a lot of value over, say, the fade transition. So I sort of prioritize this lower than something like Live2D, which I get a tons of request for, Python 3, and the massive year-long process of updating everything Ren'Py depends on.

This is less of a specific design choice, and more that you're asking for something that's genuinely hard, and will take quite a bit of time to implement.

[gas]

This is one of those things that's a lot more subtle than it appears at first.

If I'm understanding what you want...

You've totally understood the practical implementations.

I think this might make sense, but it's a huge set of changes, and one that I suspect one that doesn't add a lot of value over...

Perfectly fine it is a low (low == never) priority thing, the cost/advantage seems to be unfair as you said. But... doable, I suppose.

Hope people will put such Live2D support to good use - VNMaker was proud of offering it and failed.