[bug] Code execution delayed, its the interference with the console, with also breaking consequences.

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Post Reply
Message
Author
AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

[bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#1 Post by AON »

So, take this little piece of code :

Code: Select all

label start:
    $ iExist = True
    "Take a look at the console, you'll see that 'iExist' is unknew."
    "Take another look, and now 'iExist' is created."
    return
Until the version 6.99.13 included, the variable was immediately created as expected. But since the version 6.99.14, the variable will be created only when you'll see the second text. And it apply to all assignation ; they are all delayed in the same way :

Code: Select all

init python:
    myVar = 0

label start:
    $ myVar += 1
    "Take a look at the console, you'll see that 'myVar' is at 0."
    "Take another look, and now 'myVar' is at 1."
    return
At first, it looks like the code above the say statement is only executed after it, like you can see with this example :

Code: Select all

init python:
    myVar = 0
    def myFnct():
        store.myVar += 1

label start:
    $ myFnct()
    "Take a look at what 'myVar' looks like in the console. It's 0."
    "And now its value is 1."
    return
But in fact it's not this, like demonstrated with this example :

Code: Select all

init python:
    myList = []

label start:
    $ myList.append( "abc" )
    "Take a look at what 'myList' looks like in the console. Do it again, and again..."
    "And now it will stop growing."
    return
Every time you'll open then close the console, "abc" will be added to myList.

All these code works as expected with the version 6.99.13, included, and above, and are broke with all versions since the 6.99.14.
Making it happen with the console was the simplest way to demonstrate the bug, but it don't just happen in this case. I found it when I tried to run some old piece of code in the latest version, and Ren'py simply crashed saying that an attribute wasn't existing. It would be too long to demonstrate it since it imply a whole game's core, and I'll not start to isolate the part which don't like the new, and strange, way Ren'py deal with Python code statement.

Anyway, it shouldn't happen at all. The change must be already effective when the say statement is executed, not after it is passed. Like it shouldn't be done more than once, as in the list example.

AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#2 Post by AON »

UPDATE :
Well, just found a quick way to demonstrate how the new way Ren'py deal with Python code completely break all the games even the simplest ; in fact they are the most impacted by it.
Or I just found another bug, but they are too similar to not be related together.

Code: Select all

label start:
    $ myVar = 0
    menu:
        "Please, click me":
           $ myVar += 1
    menu:
        "Please, save then load before cliking on me":
            pass
    "Er... How 0+1 became [myVar] ?"
    return
Once again, works as expected with the version 6.99.13 and above, and is broke since the version 6.99.14.

Apparently, the Python code is interpreted during the next interaction. So what happen is simple:
When the second menu is displayed, myVar is finally incremented. Then you save at this point. When you load, the value is correctly restored, for Ren'Py, myVar = 1. But like the menu is displayed again, the previous Python code is interpreted again, and myVar become 2.

Like saving when a menu is displayed is the best way to don't have to restart everything in case of bad choice... Note that the problem don't happen if there's a say statement between the Python code and the menu (even if you save/load on the said statement), nor if the Python code isn't part of the previous menu.

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#3 Post by PyTom »

Two of these aren't bugs.

Code: Select all

init python:
    myList = []

label start:
    $ myList.append( "abc" )
    "Take a look at what 'myList' looks like in the console. Do it again, and again..."
    "And now it will stop growing."
    return
Is Ren'Py working as defined. SInce myList isn't changed, it isn't saved. (The object it refers to is changed, but myList is not. Use the default statement rather than init python ther.)

Code: Select all

label start:
    $ myVar = 0
    menu:
        "Please, click me":
           $ myVar += 1
    menu:
        "Please, save then load before cliking on me":
            pass
    "Er... How 0+1 became [myVar] ?"
    return
Gives the value 1, at least in the nightly.

Your first one is a bug, but it only affects the console, which rolls back before running code. As of 6.99.14, that rollback window is much longer for performance reasons. I'm not 100% sure how to fix it, but I'll think about it and see if I can.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#4 Post by AON »

PyTom wrote: Thu Apr 19, 2018 11:37 pm Two of these aren't bugs.

Code: Select all

init python:
    myList = []

label start:
    $ myList.append( "abc" )
    "Take a look at what 'myList' looks like in the console. Do it again, and again..."
    "And now it will stop growing."
    return
Is Ren'Py working as defined. SInce myList isn't changed, it isn't saved. (The object it refers to is changed, but myList is not. Use the default statement rather than init python ther.)

Code: Select all

label start:
    $ myVar = 0
    menu:
        "Please, click me":
           $ myVar += 1
    menu:
        "Please, save then load before cliking on me":
            pass
    "Er... How 0+1 became [myVar] ?"
    return
Gives the value 1, at least in the nightly.

Your first one is a bug, but it only affects the console, which rolls back before running code. As of 6.99.14, that rollback window is much longer for performance reasons. I'm not 100% sure how to fix it, but I'll think about it and see if I can.

AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#5 Post by AON »

Sorry, it took me too long to answer (English isn't my native language), and I was logged off :/ I restart :
PyTom wrote: Thu Apr 19, 2018 11:37 pm Is Ren'Py working as defined. SInce myList isn't changed, it isn't saved. (The object it refers to is changed, but myList is not. Use the default statement rather than init python ther.)
Well, I'm sorry to disapoint you, but myList is saved :

Code: Select all

init python:
    myList = []
    
label start:
    $ myList.append( "abc" )
    "Open then close the console"
    "And don't worry, it's not saved."
    "so myList is not equal to [myList]."
    return
But it's not a bug in Ren'py, it's a bug in my code because I should have used default instead...

PyTom wrote: Thu Apr 19, 2018 11:37 pm

Code: Select all

label start:
    $ myVar = 0
    menu:
        "Please, click me":
           $ myVar += 1
    menu:
        "Please, save then load before cliking on me":
            pass
    "Er... How 0+1 became [myVar] ?"
    return
Gives the value 1, at least in the nightly.
And here your answer is to not increment anymore variables in case like this one...

PyTom wrote: Thu Apr 19, 2018 11:37 pm Your first one is a bug, but it only affects the console, which rolls back before running code.
You wanted to write "among other case, it happen with the console", right ? Because as demonstrated above, the changes are reported outside of the console, and since:
PyTom wrote: Thu Apr 19, 2018 11:37 pmAs of 6.99.14, that rollback window is much longer for performance reasons. I'm not 100% sure how to fix it, but I'll think about it and see if I can.
It's effectively the same problem which is demonstrated with the menu example in my update.

Like it's related to the way you now deal with rollback, there's, without any possible doubt, way more case when it will happen, that I myself thought.
There the one which made me discover the problem and for which I still can't find a short way to demonstrate, plus the two I demonstrated here. And there's another one I found, but haven't fully understood, so haven't been able to even reproduce ; but reading your comment regarding the rollback window and its now bigger size, there's no doubt that it's the same issue. Four variations of the same problem in less than two days...
And how many other which haven't been discovered yet because nobody have saved/loaded or performed a rollback at an instant it can be triggered ? Without counting the ones possibly discovered by amateur coders who're still trying to figure out where their code is wrong, when in fact it's the rollback window size which is responsible of the error.

It's not the small issue you seem to think. Any rollback and loading can happen during one of the particular case where the rollback window is now too big to works as intended.
Either it will just make the player cheat against his will because a variable change will happen twice, or completely break the game because an event will be put twice in the queue. In both case, the game will be seen as shitty when it's not the case. It can even make Ren'py crash. It's the case I haven't been able to reproduce. In all case, game authors will have to deal with bugs they aren't responsible for, this while their code works fine and as expected in any version prior to the 6.99.14.

PyTom wrote: Thu Apr 19, 2018 11:37 pmI'm not 100% sure how to fix it, but I'll think about it and see if I can.
Well, it's your engine, so do as it please you. You can either delay again the 7.0, or release a 7.0 which is a timed bomb and can at anytime broke a game because the player saved, or use this rollback feature you're so proud of (with reason) at the wrong moment.

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#6 Post by PyTom »

And here your answer is to not increment anymore variables in case like this one...
I'm very confused by this. You gave an example where the answer should be 1, Ren'Py displays 1. Not sure where the problem is.

With the myList example, you're updating an object (but not a variable) defined at init time. Those don't participate in save/load/rollback, and so when you're loading or saving, it's not changing.

There was an issue with the console (only) that has been recently fixed.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#7 Post by AON »

PyTom wrote: Sat Apr 21, 2018 3:02 am
And here your answer is to not increment anymore variables in case like this one...
I'm very confused by this. You gave an example where the answer should be 1, Ren'Py displays 1. Not sure where the problem is.
Are you kidding ? Have you even tried the example before answering ?

Code: Select all

label start:
    $ myVar = 0
    menu:
        "Please, click me":
           $ myVar += 1
    menu:
        "Please, save then load before cliking on me":
            pass
    "Er... How 0+1 became [myVar] ?"
    return
Do as said (save then load when the button ask you to do it) with, lets say the 6.99.14.1 version, but it "works" as well with 6.99.14, 6.99.14.2 and 6.99.14.3. Ren'py will not display 1, it will display 2...
Now, if it display 1 with your working version, good. It mean that the issue will be fixed with the next release. But it doesn't mean that there were no issue in the previous ones.

PyTom wrote: Sat Apr 21, 2018 3:02 amWith the myList example, you're updating an object (but not a variable) defined at init time. Those don't participate in save/load/rollback, and so when you're loading or saving, it's not changing.
Thanks, but I know how to read a documentation, read a code and perform tests. So I know that objects created at init time aren't saved ; unless forced into renpy.python.store_dicts[storeName].ever_been_changed, which is bad seen from a Python perspective. Like I know that if they aren't saved, it imply that they aren't part of the rollback.
I also know that, when updating them, Ren'py in fact don't care if they were silently transmuted on revertable object at creation time (because created on a .rpy file) or are natural list, set or dict (because created in a .py file). In both case they'll never been added to the ever_been_changed set. For the one created in the .py files, they'll be added only if created after the start label.
Which is in contradiction with the documentation, and all your previous comments on this subject, which imply that only objects will not be saved if created inside an init block, even when their value is changed ; and yes, I also know that in Python everything is in fact an object. Both the documentation and your comments should talk about scalar and none scalar attributes, without assuming that list, set and dict have been automatically transmuted ; and without even saying that they are.
I even know that (class) objects are transmuted to inherit from renpy.store.object (with the same limitation than for the list, set or dict), making them rollback compliant by default, since the version 6.99.5. One of the many things missing in the change log, but a bug saving addition.

On the other hand, I don't know English this much (isn't it said at the top of the post you answered ?), like I don't read mind. So it can happen that I confuse, "not saved" as in "the value change will only be seen in the console", and "not saved" as in "the attribute will not be added to the ever_been_changed set".

PyTom wrote: Sat Apr 21, 2018 3:02 am There was an issue with the console (only) that has been recently fixed.
By recently fixed, you mean in the future 7.0, right ? Because in the late 6.99.14.3, that I just downloaded again to be sure that I have the last public build, the issue is still here.

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#8 Post by PyTom »

Do as said (save then load when the button ask you to do it) with, lets say the 6.99.14.1 version, but it "works" as well with 6.99.14, 6.99.14.2 and 6.99.14.3. Ren'py will not display 1, it will display 2...
Now, if it display 1 with your working version, good. It mean that the issue will be fixed with the next release. But it doesn't mean that there were no issue in the previous ones.
For me, it's displaying "Err... How 0+1 became 1 ?", which is correct.

I'm very confused by your digression about the myList example. There's no such thing as a scalar attribute in Python - everything in Python is a reference to an object. I think you might be trying to apply to Python and Ren'Py terminology from other languages.

The issue with the console was fixed in the nightly builds, and is fixed as of the first 7.0.0 prerelease.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#9 Post by AON »

PyTom wrote: Sun Apr 22, 2018 5:15 pm For me, it's displaying "Err... How 0+1 became 1 ?", which is correct.
I just tested it, and effectively the issue is corrected with the version 7.0.0.

PyTom wrote: Sun Apr 22, 2018 5:15 pmThere's no such thing as a scalar attribute in Python - everything in Python is a reference to an object.
You mean that when I wrote :
AON wrote: Sat Apr 21, 2018 12:11 pm and yes, I also know that in Python everything is in fact an object.
I was right ? Very surprising... But well, my bad, should have wrote "scalar-like" and not just "scalar".

PyTom wrote: Sun Apr 22, 2018 5:15 pm The issue with the console was fixed in the nightly builds, and is fixed as of the first 7.0.0 prerelease.
Well, partially fixed only. It's still here in the 7.0.0, and yes, I mean the build 51. But whatever the number of time you'll open the console, you'll always have only two iterations of what was appended to the list. So, I assume that myList is, lets say "cleaned", when the console is opened, but still the Python statement is run twice.
This said, it's less an issue than the menu problem.

philat
Eileen-Class Veteran
Posts: 1900
Joined: Wed Dec 04, 2013 12:33 pm
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#10 Post by philat »

I didn't bother with the other examples, but I couldn't recreate the menu bug in 6.99.14.3 (3347 if that matters). myVar displays as 1.

AON
Newbie
Posts: 10
Joined: Tue Oct 31, 2017 9:54 am
Contact:

Re: [bug] Code execution delayed, its the interference with the console, with also breaking consequences.

#11 Post by AON »

philat wrote: Tue Apr 24, 2018 1:32 am I didn't bother with the other examples, but I couldn't recreate the menu bug in 6.99.14.3 (3347 if that matters). myVar displays as 1.
I found the bug playing a game using the 6.99.14.3, and so didn't tested it myself with this version. It was apparently wrong to assumed that it was the last build.
Anyway, it don't happen anymore, which is a great news. Greatest news, it was solved with 6.99.14.3, so most game released lately don't have it if the author update correctly.

Post Reply

Who is online

Users browsing this forum: No registered users