Ren'Py Pause until mouse release

[ErgoVis]

Hello,
As in the title, I want to stop Ren'py from proceeding to the next line until the user releases mouse button (or ideally, whatever else they're using to advance the game).

scene expression image_1
with piston  #piston is my custom transistion

#"pause until mouseup_1==True" or something, this is the line I have problem with

scene expression image_2
with dissolve

I came up with two possible solutions, the first is to dynamically remap keys every time the game runs the piece of code given above, but that seems extremely heavy handed and also very, very stupid. My second idea is to add a line to lock the game at the end of the "piston" transition which came to my mind only because I know there's a keyword "event" in ATL but I have no idea how would I go about coding it.

All help appreciated.

 

[anne O'nymous]

As in the title, I want to stop Ren'py from proceeding to the next line until the user releases mouse button (or ideally, whatever else they're using to advance the game).

Why ? Or, more precisely, what are you trying to achieve exactly ?

No one keep the key or mouse button pressed in such case. A small quick press, followed by an instant release, it's how everyone do.
It sounded less lewd in my head.

So, yeah, what is your goal behind such game mechanism ?


This being said, the answer is probably to rely on the

You must be registered to see the links

ATL statement.
You proceed all the ATL inside it, and in the same time use PyGame to test the mouse button and key state. The function returning None (so, "don't call me again") only when both are on "released" state.

But, once again, this will probably not have the result you picture in your head.
Unless you warn before hand that they need to keep the key/button pressed, everything will end before it even started.

 

[ErgoVis]

No one keep the key or mouse button pressed in such case. A small quick press, followed by an instant release, it's how everyone do.
It sounded less lewd in my head.

So, yeah, what is your goal behind such game mechanism ?

As you said, I fully expect people to just run past the mechanic unless I specifically force the fact of its existence into their brains which is precisely what I was planning on doing.

As to what is my goal, I just think it would play nice with the transitions I'm using, giving a more immersive player experience (corporate speak much?), but I can't be sure how well it will work until I have a working prototype.

This being said, the answer is probably to rely on the

You must be registered to see the links

ATL statement.
You proceed all the ATL inside it, and in the same time use PyGame to test the mouse button and key state. The function returning None (so, "don't call me again") only when both are on "released" state.

Would you be able to give example code just checking the state of mouse button (I'll figure it out from there, hopefully)? I've been trying to google it and I found some documentation but can't quite figure out what to do with it.

 

[anne O'nymous]

As you said, I fully expect people to just run past the mechanic unless I specifically force the fact of its existence into their brains which is precisely what I was planning on doing.

And, unless you intend to release the game only once totally finished, you'll have to force this fact with every single update. Because even if you intent to release an update every week, there's players that will have totally forget this particularity.

And since there's absolutely no guaranty that a player will effectively save at the end of the previous update, and not in the middle of it for whatever reason, you'll have in fact to constantly remind that it's how it works.

As to what is my goal, I just think it would play nice with the transitions I'm using, giving a more immersive player experience (corporate speak much?), but I can't be sure how well it will work until I have a working prototype.

A transition is a transition. Therefore it's just a nice effect that permit to pass from an image to another. This mean that you necessarily need to have a full control over its duration.

If the transition is shorter that what you planed, it will not be finished when the new image will be fully displayed, what will looks ridiculous.
Imagine that your transition is the current image fading to black, then the next image fading from black. If the player interrupt the transition before the fade to black is finished, the current image will be immediately replaced by the next one, and this before it have fully disappeared. The player will only see the next image, but the effect will be ugly and, as I said, looks ridiculous.

And the same apply for the opposite, therefore a transition longer than what you planed.
With still my fade to then fade from transition, what will happen ? The next image will be fully displayed, and then what ? Well, then nothing, the transition is finished, there's nothing more to do because there's nothing more that can be done.

And, of course, you can't time the transition to match the time the player will pass pressing the button, because you've no way to know this before hand, therefore when you have to plane the time past doing this and the time past doing that.

If your "transition" can be either shorter or longer than what you planed, then it's not a transition, it's an looped effect. And therefore it should be used like a transition, but like an effect.


To this have to be added that transition can be purely skipped if the player want it. And basing a game mechanism on something that can be skipped isn't really a good idea.

Would you be able to give example code just checking the state of mouse button

Not at this time of the night.
There's example in the doc if my memory don't betray me, and some in this forum.

 

[ErgoVis]

A transition is a transition. Therefore it's just a nice effect that permit to pass from an image to another. This mean that you necessarily need to have a full control over its duration.

If the transition is shorter that what you planed, it will not be finished when the new image will be fully displayed, what will looks ridiculous.
Imagine that your transition is the current image fading to black, then the next image fading from black. If the player interrupt the transition before the fade to black is finished, the current image will be immediately replaced by the next one, and this before it have fully disappeared. The player will only see the next image, but the effect will be ugly and, as I said, looks ridiculous.

And the same apply for the opposite, therefore a transition longer than what you planed.
With still my fade to then fade from transition, what will happen ? The next image will be fully displayed, and then what ? Well, then nothing, the transition is finished, there's nothing more to do because there's nothing more that can be done.

And, of course, you can't time the transition to match the time the player will pass pressing the button, because you've no way to know this before hand, therefore when you have to plane the time past doing this and the time past doing that.

If your "transition" can be either shorter or longer than what you planed, then it's not a transition, it's an looped effect. And therefore it should be used like a transition, but like an effect.


To this have to be added that transition can be purely skipped if the player want it. And basing a game mechanism on something that can be skipped isn't really a good idea.

Based on that little rant above, I'm guessing that you've misunderstood my point.

I have absolutely no need to base the length of the transition on any form of user input. I want the transition to happen precisely as coded, in its entirety, every time it's called. If the player ends up skipping it, that's no skin of my back to be honest, even if I disagree with said player's aesthetics.

Here's a hopefully better explanation:

scene expression image_1
with piston  # only once this completes we enter into the realm of my issue

pause(variable)
# If once the piston transition completes, the player just so happens to still be holding down the mouse
# button (or key on a keyboard) pause the program until said button is released.
# As things are I put a pause(variable) to keep image_1 on display for a predefined amount of time, but I'd rather
# the length of time image_1 is displayed depended on a dynamic user input (with an enforced minimum) rather 
# than any variable. I could obviously just put a pause here so that the program waits for another click instead, 
# but that feels extremely unnatural in my specific scenario (I tried). While I can't be sure until I test it out, 
# I have good reasons to believe that allowing the game to proceed on conditions laid out above would work very well,
# and I repeat again, in my specific scenario.

scene expression image_2
with dissolve

By the way, what I'm working on is hardly any secret, my mod is publicly available on the forum, you could just download it and give it a shot. You'd probably be able to easily figure out exactly what effect I'm trying to achieve and why. You might just agree that it actually makes sense .