Renpy.random.randint() persists over "back" selection

[FuzzyBunny23]

Hello All,

I have a spot where the players path is chosen by a simple random number generation in a truth or dare game. renpy.random.randint(1, 6) works fine for the die roll in this scenario, but once assigned it cannot be reassigned if a player chooses to use the back menu option to try for a different path.

I have tried placing a del ranVar right before the assignment to see if that allowed re-assignment. Nope.

Anyone run across this issue and maybe have a workaround/solution?

 

[riktor]

how are you calling the random function? (scene script, screen call, custom function, etc) if you aren't using it already, you might try calling the random function from within a custom function and using the custom function in the scene script.

 

[FuzzyBunny23]

how are you calling the random function? (scene script, screen call, custom function, etc) if you aren't using it already, you might try calling the random function from within a custom function and using the custom function in the scene script.

At the moment it's just a local call:

label .whatever:
play sound die_roll
x "You roll the dice."
$ ranVar = renpy.random.randint(1, 6)
if ranVar == 1:
do stuff ......

I tried on variant of a custom function, but I'll try again. Will also try establishing it as a global in the script for later use when needed, see if that overcomes the scene persistence.

It does re-assign if you reload or if you have left the current scene and returned.

 

[79flavors]

It's a deliberate design choice for RenPy.
Whilst I'm assured it doesn't work exactly this way... it behaves like the random numbers have been pre-rolled ahead of time and are effectively set in stone.

Basically, it's to stop the behavior you're talking about... rolling back and forward until the players gets a favorable answer. Saving or loading won't affect anything either... again, a deliberate design choice to ensure players don't save-scum their way around bad (or good) rolls.

After all, if you could just keep rolling back and forward... why have random in there at all?

There are bound to be workarounds. Unfortunately, I'm not the person to tell you what they might be. Maybe something like using the default python random() code rather than the renpy version of it - or something like that.

I can sort of empathise with you for testing purposes. But realistically, you're going to be working hard to bypass something the RenPy team worked very hard to include. Perhaps it's time to think about whether you really do want random code in there, if you're not willing to accept random answers.

 

[FuzzyBunny23]

It's a deliberate design choice for RenPy.

Basically, it's to stop the behavior you're talking about... rolling back and forward until the players gets a favorable answer. Saving or loading won't affect anything either... again, a deliberate design choice to ensure players don't save-scum their way around bad (or good) rolls.

Yeah, it's mostly just a royal pain for my testing. I'll most likely wind up just hard coding my desired value and reloading for each run. During normal game play the player is just going to have to deal with it apparently.

Still a few things to try just in case it does work.

 

[sillyrobot]

Yeah, it's mostly just a royal pain for my testing. I'll most likely wind up just hard coding my desired value and reloading for each run. During normal game play the player is just going to have to deal with it apparently.

Still a few things to try just in case it does work.

IIRC, python's random is available, just not suggested because the behaviour changes each time you return to it via rollback. Just use it.

 

[riktor]

you can use the standard python random module to bypass it.
import random
random.randint(1,6)

 

[79flavors]

If it's just a testing issue... Alter the code to python.random.randint(1,1) thru (6,6) during your tests for each path and then alter it back to (1,6) once you've finished testing. Use save files for each path to allow you to return to test each path again if further testing is needed in the future.

Alternatively, remember that you can open the RenPy console at any time using (shift+O) and just type in a renpy command like jump {label}. Which isn't an ideal testing strategy (since it's bypassing part of the code you need to test), but it will at least give you a level of control a player wouldn't have.

 

[Rich]

Another thing you can do for testing purposes - do your "forward" bit, then back up, then use the console to execute renpy.random.random() before moving forward again. This effectively pulls the "saved to be regenerated" value off the Ren'py back stack, so that the "forward" step now gets the next random number in sequence.

Doesn't guarantee what the next random number will be, but it gets around the "always get _precisely_ the same number when going forward again" problem.

 

[anne O'nymous]

Another thing you can do for testing purposes [...]

An even better "other thing" he can do for testing purposes is to download the attached file, then put it on the game folder.

It give full control over the randomization with a really easy to use (ugly) interface ; one click to enable/disable this control, and few clicks to change the value that will be always returned.
Cherry on the cake, when the control is disabled, it shortcut the modification made by Ren'py, so the value will be a random one even after a rollback.

 

[Rich]

An even better "other thing" he can do for testing purposes is to download the attached file, then put it on the game folder.

It give full control over the randomization with a really easy to use (ugly) interface ; one click to enable/disable this control, and few clicks to change the value that will be always returned.
Cherry on the cake, when the control is disabled, it shortcut the modification made by Ren'py, so the value will be a random one even after a rollback.

Very nice!

 

[FuzzyBunny23]

you can use the standard python random module to bypass it.
import random
random.randint(1,6)

This worked fine, thank you!

Thanks to everyone for the replies and ideas. Looks like there's several ways to accomplish this.

An even better "other thing" he can do for testing purposes is to download the attached file, then put it on the game folder.

OOooh, me likey