persistent.myvariable = True
.config.developer
and config.console
are set to True
... usually by running the project via the RenPy launcher).Not sure it will really help since it limits to the game values, hiding those coming from Ren'py's core. What, for the persistent file, imply that 99% of the content is hidden.I'm not sure it's everything you are looking for, but anne O'nymous 's Extended Variable Viewer shows program controlled persistent variables.
What do you mean by "corrupted", and how you know it happen ?While testing and modding some games, the persistent file get constantly corrupted [...]
What do you mean by "corrupted", and how you know it happen ?
I mean, I mod for Ren'py since four years, and played/tested probably near to 1.000 Ren'py games, and never encountered a case where this file was corrupted. I know that in my early Ren'py modding years, I happened to corrupt the save files, and more than once, trying this or that, but never ever the "persistent" one was impacted. As I implied above, it mostly serve to handle Ren'py's internals, and they are relatively tied and secured.
So, knowing what you're effectively looking for would help to answer you accurately.
that doesn't really help it's quitting for a reason tells us what game it is and post the log/traceback/error txt fileBecause first the game force quits and then when I try to start it again, it starts loading but then quits again, and when I delete the persistent file it gets fixed.
[...] since [the extended variable viewer] limits to the game values, hiding those coming from Ren'py's core. What, for the persistent file, imply that 99% of the content is hidden.
Because first the game force quits and then when I try to start it again, it starts loading but then quits again, and when I delete the persistent file it gets fixed.
D:\Games\{game-ID}\game\saves\
C:\Users\{username}\AppData\Roaming\RenPy\{game-ID}\
.persistent
file in both these folders should be the same date/time and be the same size.Same than the others, it's too few information. And since you talk about trying to mod, I would add to their queries: When is the game force quitting the first time, what is the last modification you did before that, and in what file.Because first the game force quits and then when I try to start it again, it starts loading but then quits again, and when I delete the persistent file it gets fixed.
Sorry, you'll have to wait for the two others feature request: Make it Python 3 ready and make it works with the last found bug.Feature request... toggle for "Show internal RenPy Persistent Variables".
Personally I see it more as a compatibility issue.The need to delete the persistent file to get the game running again makes me think that the initial crash of the game is the real source of your issues. Perhaps it's something as simple as getting a disk write error while trying to write the save/persistent data.
that doesn't really help it's quitting for a reason tells us what game it is and post the log/traceback/error txt file
Because first the game force quits and then when I try to start it again, it starts loading but then quits again, and when I delete the persistent file it gets fixed.
I'm sorry, but an uncaught exception occurred.
While running game code:
File "game/tl/english/dialogues/breakfast.enhanced.rpy", line 16, in script
old "Ну да, на словах все такие храбрые. А на деле..."
File "game/tl/english/dialogues/breakfast.enhanced.rpy", line 16, in script
old "Ну да, на словах все такие храбрые. А на деле..."
Exception: A translation for "Ну да, на словах все такие храбрые. А на деле..." already exists at game/tl/english/dialogues/breakfast.enhanced.rpy:5.
-- Full Traceback ------------------------------------------------------------
Full traceback:
File "renpy/bootstrap.py", line 326, in bootstrap
renpy.main.main()
File "renpy/main.py", line 515, in main
renpy.game.context().run(node)
File "game/tl/english/dialogues/breakfast.enhanced.rpy", line 16, in script
old "Ну да, на словах все такие храбрые. А на деле..."
File "game/tl/english/dialogues/breakfast.enhanced.rpy", line 16, in script
old "Ну да, на словах все такие храбрые. А на деле..."
File "renpy/ast.py", line 2470, in execute
renpy.translation.add_string_translation(self.language, self.old, self.new, newloc)
File "renpy/translation/__init__.py", line 453, in add_string_translation
stl.add(old, new, newloc)
File "renpy/translation/__init__.py", line 394, in add
quote_unicode(old), fn, line))
Exception: A translation for "Ну да, на словах все такие храбрые. А на деле..." already exists at game/tl/english/dialogues/breakfast.enhanced.rpy:5.
Windows-10-10.0.19041
Ren'Py 7.4.4.1439
Большой брат: Другая история 0.06.5.09
Wed Jun 23 02:11:36 2021
As rayminator says, I think some examples might help here.
Is it just one game? Based on your initial "While testing and modding some games", that sounds like it's happening fairly often to multiple games.
Have you ever published any of your mods? i.e. Is there somewhere we could download one of them? I can see messages here on F95 where you have discussed other peoples mods for Big Brother: Another Story, Long Short Story and Milfy City - but nothing concerning your own mods. I only ask, because perhaps it's something your mod(s) is doing that causes the game to initially "force quit". If we could see a recent mod that has caused you problems, perhaps we can see something that's causing it.
Have you ever had RenPy games "force quit" on you without you trying to mod or unpack them? Again, I only ask because it's possible that it isn't RenPy or your mod(s) and is your computer setup itself. If unmodded RenPy games crash for you but not the rest of the community - that points to something unique to you. If only modded games crash, then it possible something you are doing is the cause.
The need to delete the persistent file to get the game running again makes me think that the initial crash of the game is the real source of your issues. Perhaps it's something as simple as getting a disk write error while trying to write the save/persistent data.
One practical thing you could check is whether both copies of the persistent file are been kept in line.
Save and persistent files are stored in two places on your computer.
Firstly the game folder's own save folder. PerhapsD:\Games\{game-ID}\game\saves\
... and a common RenPy folder. LikelyC:\Users\{username}\AppData\Roaming\RenPy\{game-ID}\
.
Thepersistent
file in both these folders should be the same date/time and be the same size.
Exception: A translation for "Ну да, на словах все такие храбрые. А на деле..." already exists at game/tl/english/dialogues/breakfast.enhanced.rpy:5.
This traceback do not correspond to the mod you joined, and also it explicitly tell that the problem do not come from the persistent file.This may be the traceback of the last time it failed:
By doing what ? Assuming that it's effectively a corrupted persistent file, the corruption didn't happened by itself.The errors happen when I'm modding,
How do you know that it's a corruption of the persistent file ? And, no, "deleting the persistent file solve the problem" is not a proof that the file is corrupted.usually there is some mistake that causes the game to crash and ends up corrupting the persistent file,
What make my question even more important: What are you doing, and where...It never has happened with unmodded games or with proper mods, only when modding, but I unpack all games and enable the Console and Developer Menu.
the traceback is telling why you getting that error
are you trying to make a translation for the game?Code:Exception: A translation for "Ну да, на словах все такие храбрые. А на деле..." already exists at game/tl/english/dialogues/breakfast.enhanced.rpy:5.
old "Ну да, на словах все такие храбрые. А на деле..."
new "Yeah, like you'd have the guts..."
This traceback do not correspond to the mod you joined, and also it explicitly tell that the problem do not come from the persistent file.
By doing what ? Assuming that it's effectively a corrupted persistent file, the corruption didn't happened by itself.
old "Ну да, на словах все такие храбрые. А на деле..."
new "Yeah, like you'd have the guts..."
How do you know that it's a corruption of the persistent file ? And, no, "deleting the persistent file solve the problem" is not a proof that the file is corrupted.
The SDK offer the possibility to delete it for any project for a good reason. It reset the global context of the game, what can solve a lot of external errors and potential conflict ; especially when you make too radical change. But this absolutely don't mean that the persistent file is corrupted.
What make my question even more important: What are you doing, and where...
Your change are the reason of those crash, it's there that you should look, and not in a file that you would probably don't understand even if you add access to its content in a human readable way.
there are 2 locations for the persistent files
C:\Users\Your_name\AppData\Roaming\RenPy\Game-XXXX
D:\DOWNLOAD\Bright_Past-0.84.0-pc\Bright_Past-0.84.0-pc\game\saves
delete both of them
just a question
have you tried using a old save for any renpy games that was updated?
because that can cause problems.
Pretty sure by now that it's a bug inYes, that's what I've been doing, it's the only way for the game to start.
Nope, just new saves, but since I'm messing around and modding the game, it sometimes crashes and of those crashes sometimes the persistent file gets corrupted and I have to delete it.
I would like to know what's happening with it, what exactly corrupts it but it seems there's no way to do it.
What don't prove that there's a bug in the version 7.4.4.Pretty sure by now that it's a bug in
Ren'Py 7.4.4.1439
Since I've switched to this version, I'm getting complaints from user that their game won't start any more.
Once they delete the persistent file, it works again. There is nothing in the log that helps.
Without disagreeing with your general statement, there is one big problem. Unfortunately, without using the 7.4.x, you lose the ability to produce Android builds. It was an unfortunately choice by PyTom-and-company "back when" to rely on a third-party server to provide required content for that. (That's not being accusatory - as developers, we've all made bad choices now and again. I'm sure PyTom, in retrospect, would agree.)Anyway, the whole 7.4.x branch shouldn't be used for production.
One of the best things you could do would be to capture a copy of a persistent data file from someone having the problem (before they delete it), prove to yourself that it crashes on your own machine and then open an issue atPretty sure by now that it's a bug in
Ren'Py 7.4.4.1439
Since I've switched to this version, I'm getting complaints from user that their game won't start any more.
Once they delete the persistent file, it works again. There is nothing in the log that helps.
Unfortunately, without using the 7.4.x, you lose the ability to produce Android builds.
For a good jump to a 7.4.x, I advice having a last update with a none 7.4.x, in which you clean up your variables.Obviously, one of the things you can do to maximize the chance of surviving version updates is to be very careful what you store, both in your saves and also in the persistent data. For example, I completely avoid saving classes as part of saves (for a lot of reasons). Everything in my saves or persistent data is a Python built-in. (Primitive, list, dict, etc.)
Ah - OK. I misunderstood. I thought you'd updated from an earlier version to 7.4.x, and the upgraded game was having issues reading persistent data from a previous version. Clearly that's not what's happened.You can play the game for hours without any problem. You close it down and try to start it again some time later and it won't start until you delete the persistent file.
# Ensure that it works with Python 2.x
#rpy python 3
init python:
import pickle
# Ensure that the path to Ren'py's core is known by Python.
PATH_TO_RENPY_IN_SDK = "[Path to Ren'py's SDK]\renpy"
if not PATH_TO_RENPY_IN_SDK in renpy.sys.path: renpy.sys.path.append( PATH_TO_RENPY_IN_SDK )
def unpickle( path ):
# Decode the 'persistent' file
FH = open( renpy.os.path.join( path, "persistent." ), "rb")
s = FH.read().decode("zlib")
FH.close()
# Save as pure pickle file
FH = open( renpy.os.path.join( path, "persistent.RAW" ), "a" )
FH.write( s.encode( encoding='UTF-8' ) )
FH.close()
# Load the pickled file
FH = open( renpy.os.path.join( path, "persistent.RAW" ), "rb" )
# Here you should have a "print pickle.....", but it would log all this on
# the console, what risk to be too many information. Therefore I
# decided to load it on a variable, and from there to try to proceed
# whatever will be loaded.
raw = pickle.load( FH )
FH.close()
# Here come the processing of /raw/ content... if it load
label start:
# /!\ WARNING - You can NOT open the persistent file of the current project /!\
$ unpickle( "PATH TO THE persistent file]" )
"END"