- May 16, 2018
- 63
- 54
- Thread starter Night Mirror
- Start date
- Oct 13, 2021
- 248
- 750
It's getting there
Yo papa mirror. Good shit, looking forward towards the update. I dont even play the original lmao. Why would I when i got this gem at my finger tips.
- Jun 2, 2018
- 1,766
- 9,653
r3.8 Progress Report #11 - MAY 15 @ 16:50 UTC (Task List)
I know it's been a while, but we are closing in here on the final steps. I have the revisions for the new Beth scene and I'm working on putting them in after I finish this post. I still need the revisions for the new Summer scenes, and when I have those, I'll do another progress report.
So, how much time is left? Is it done yet? WHEN IS UPDATE?!
The short answer to those questions is still (unsatisfyingly): soon. While I would love to be much less vague and give a specific date, that either means forcing us to crunch to hit that, or wildly guessing about a date (which doesn't mean anything if we can't actually make that date).
Next to the scene implementation itself, round 1 scene revisions are one of the most time intensive steps. They involve not just looking for issues in the scene, but often going outside that scene to make sure things still make sense in the context of the game.
But we are in the last stages here. Once I've put in all of the major revisions, the scenes get a second round editor review (this time mainly looking for typos or omissions), then I put in any lingering changes found in round 2. Then we both have one last going over of the new scenes in the game for any unresolved problems. This will be our last chance to really change/fix anything, and after that is completed, we move onto the Release Candidate.
The RC is the final build of the game that you guys will eventually get to play, and if there are no major issues here, I flip it live and the update is out. If there is a major problem (game code errors, missing images, i.e. anything that causes the game to crash (not including save issues, no good way to fix those...)), that will get fixed, I do an RC #2, and repeat as needed. Small issues, like any typos will just have to be there until the next time.
Again, I know this one has taken longer than usual, but we are going as quickly as is reasonable. Mainly not trying to crunch on our end at all if possible. I am really excited to get this into your hands, and I hope you'll all enjoy it!
Anyhow, thanks for being awesome!
I know it's been a while, but we are closing in here on the final steps. I have the revisions for the new Beth scene and I'm working on putting them in after I finish this post. I still need the revisions for the new Summer scenes, and when I have those, I'll do another progress report.
So, how much time is left? Is it done yet? WHEN IS UPDATE?!
The short answer to those questions is still (unsatisfyingly): soon. While I would love to be much less vague and give a specific date, that either means forcing us to crunch to hit that, or wildly guessing about a date (which doesn't mean anything if we can't actually make that date).
Next to the scene implementation itself, round 1 scene revisions are one of the most time intensive steps. They involve not just looking for issues in the scene, but often going outside that scene to make sure things still make sense in the context of the game.
But we are in the last stages here. Once I've put in all of the major revisions, the scenes get a second round editor review (this time mainly looking for typos or omissions), then I put in any lingering changes found in round 2. Then we both have one last going over of the new scenes in the game for any unresolved problems. This will be our last chance to really change/fix anything, and after that is completed, we move onto the Release Candidate.
The RC is the final build of the game that you guys will eventually get to play, and if there are no major issues here, I flip it live and the update is out. If there is a major problem (game code errors, missing images, i.e. anything that causes the game to crash (not including save issues, no good way to fix those...)), that will get fixed, I do an RC #2, and repeat as needed. Small issues, like any typos will just have to be there until the next time.
Again, I know this one has taken longer than usual, but we are going as quickly as is reasonable. Mainly not trying to crunch on our end at all if possible. I am really excited to get this into your hands, and I hope you'll all enjoy it!
Anyhow, thanks for being awesome!
- Aug 6, 2019
- 1,305
- 1,072
No need to worry, I am just glad that you are doing all this, I think it is just great that once you're done I will be able to once again be a leech, and get to enjoy all your hard work.
Thank you very much!
P.S. thank you so much for taking the time to inform us, I mean you didn't even have to do that but you did.. Thank you
Thank you very much!
P.S. thank you so much for taking the time to inform us, I mean you didn't even have to do that but you did.. Thank you
So I Finally caved and played the new update.
Must say looking forward to your edits on this one.
Also I believe the Beth Scene would be a good candidate for an X-Ray Scene if /when that can be managed.
I'll add it to the request list when I get a chance (else you can if you get a chance).
Either way, Keep up the good work NM.
Looking forward to your update.
Cheers.
Hey NM,
Found this from your response to one of my questions from back in Jan. Has this Colab Scene been finished/ is being worked on/ Abandoned as of now?
Just that I hadn't seen it mentioned in your update posts.
Cheers.
Last edited:
- Jun 2, 2018
- 1,766
- 9,653
Sadly, as much as I would like x-ray throughout the game, there really isn't a way to do it. I can't draw the needed artwork and they just won't work with video animations (2-3 frame animations are possible, but not the smooth video ones). I did however "fix" the art in the scene to include missing details.
Not sure how you would add it to my request list... that's not really how it works? I've already said that x-ray throughout the game is something that most likely isn't going to happen.
Still in progress, not ready for this update, and still not ready to talk about it.
I think tbe secret is to just call him papa mirror
Crunch shouldn't exist for paid work, let alone volunteer. Thanks for the status updates.
Its worth the wait and get it done right the first time indeed. Thank you and aaronminus for the work you have put in. I know this is replying to a post from awhile ago but I think it still matters to say thanks
- Jun 2, 2018
- 1,766
- 9,653
So, turns out I've been doing something stupid with how I'm putting in past content, and while it might be too late to do much about it for this update, it is something I plan to do differently going forward for future changes. So, what's the issue.
First big shout out to these two posts: One about not fucking up saves and another about using variables (and also about not fucking up saves).
This is going to get a little technical, but no code.
First up are the .rpyc files. If you've never looked inside the game folder before, you most likely have no idea what these are. And apparently, I had the wrong idea about them too. These are the compiled files that renpy makes and uses to run the game. I include the rpy files (which are plain text (I also include the rpyc files (sort of)), renpy builds the rpyc files from the rpy files, it doesn't run off the rpy files directly (which I knew).
This is the reason players can make changes to the rpy files and the game will show those changes, Renpy recompiles the rpyc files. This is also the reason if you've every downloaded the patch only file, the game can take a while to start the first time (it has to recomplie all the rpyc files using the new rpy files).
What I didn't realize, is just how important those initial rpyc files are. I thought they just were compiled files, but as it turns out, they are part of the logic behind how renpy makes player save files. Deleting or not including them, means that while renpy can remake the rpyc files, they won't match with previous versions. Which is one of the issues causing saves not to load.
Again, while I do include the rpyc files (and have never deleted them from the main project), I haven't been putting them in the patch only file, because they are huge and I was trying to keep the file small. But it looks like I'll have to start including them there too. So, easy fix, they get put in the patch file from now on.
The current update patch (without the rpyc files) is 38MB, and with them it is 58MB. So, slightly bigger patch file. Not a big deal.
Unfortunately it isn't the only issue, and the second one is more of a pain in the ass, and personal frustration for me (although, as I type this, I think I might just have thought of a solution? maybe...).
Renpy uses something called labels for it's code management. I can use "jump" or "call" to go directly to a label and start playing the scene under it. This is how the game knows what part to start playing when you use day selector, scene selector, or replays. They define what section of the game is where and are pretty handy for jumping around the game. This is also how I tend to do choice menus, each choice is a jump to label.
Renpy also (apparently) uses labels for saving (which I did not know), remembering the name of the label and the line you were on in that label. But I've been putting scenes into past days, and I use the label system in a very procedural way. This is how the scene selector works, by looking at the day and scene number to jump to the right spot. If I put in a new scene (or break up a scene) this label represents the position of that scene, and other labels are "adjusted" to keep them in the right spot.
Which means I've been renaming labels to keep things in order, apparently a huge fucking no-no. If your save has ever loaded in the wrong scene (or not loaded at all), this is the reason why.
For example, let's say a player made a save in day 10 scene 3 (label name d10_3) and that scene has 200 lines of text, and they saved on line 150. I add a new scene to day 10 that is 100 lines long, and it needs to go into the spot (for plot reasons) scene 3 uses to be. So now the new scene uses label d10_3 and the old scene 3 is pushed forward one spot to scene 4 (d10_4).
When the player goes to load that save at line 150, scene 3 no longer has a line 150. So save doesn't load. If the player saved at say line 1 in day 10 scene 3, well now the save loads in a completely different scene, because the old scene is now scene 4, but renpy doesn't know, it's using the label which I have changed.
You might be asking, Night Mirror, how the fuck did you not know this?! I don't really have a good excuse for it, I really should have. I've been working in the renpy engine for almost 4 years now, and preserving saves has been something I really honestly want to do. But all the documentation I found about it just never pointed to this as being the issue.
There is still a lot I don't know about Renpy, I tend only to seek out new things when I need them, rather than try and take it all in and know absolutely everything about it.
So, the bigger question is: how can I fix this? To which you might be shouting at your screen STOP FUCKING CHANGING THINGS YOU FUCKING MONSTER! But again, sometimes stuff has to go into the past, and I don't want to take away the option to put scenes where they logically belong (or at least I feel they belong).
And I actually do think I have a solution: double labels. A jump label, and a save label. I can include empty label blocks, things that have no code in them. These will be the jump labels, labels I can change, that are always in order, and (that from everything I have read) shouldn't impact saves at all. And a second label, the save label, which will never change moving forward.
It seems this should largely fix the save compatibility issues I've been running into, but only time will really tell.
I think I can put in the fix for the label thing for this update (and moving forward) so that it (shouldn't) cause any save issues. I do still have some time where while I await the revisions for the last scene and it shouldn't add any extra delay to the update.
Anyhow... I'm going to go start working on that. I do think an update is very likely this week, we are down to last scene here and the review process for it will be fairly fast.
As always, thanks for being awesome!
First big shout out to these two posts: One about not fucking up saves and another about using variables (and also about not fucking up saves).
This is going to get a little technical, but no code.
First up are the .rpyc files. If you've never looked inside the game folder before, you most likely have no idea what these are. And apparently, I had the wrong idea about them too. These are the compiled files that renpy makes and uses to run the game. I include the rpy files (which are plain text (I also include the rpyc files (sort of)), renpy builds the rpyc files from the rpy files, it doesn't run off the rpy files directly (which I knew).
This is the reason players can make changes to the rpy files and the game will show those changes, Renpy recompiles the rpyc files. This is also the reason if you've every downloaded the patch only file, the game can take a while to start the first time (it has to recomplie all the rpyc files using the new rpy files).
What I didn't realize, is just how important those initial rpyc files are. I thought they just were compiled files, but as it turns out, they are part of the logic behind how renpy makes player save files. Deleting or not including them, means that while renpy can remake the rpyc files, they won't match with previous versions. Which is one of the issues causing saves not to load.
Again, while I do include the rpyc files (and have never deleted them from the main project), I haven't been putting them in the patch only file, because they are huge and I was trying to keep the file small. But it looks like I'll have to start including them there too. So, easy fix, they get put in the patch file from now on.
The current update patch (without the rpyc files) is 38MB, and with them it is 58MB. So, slightly bigger patch file. Not a big deal.
Unfortunately it isn't the only issue, and the second one is more of a pain in the ass, and personal frustration for me (although, as I type this, I think I might just have thought of a solution? maybe...).
Renpy uses something called labels for it's code management. I can use "jump" or "call" to go directly to a label and start playing the scene under it. This is how the game knows what part to start playing when you use day selector, scene selector, or replays. They define what section of the game is where and are pretty handy for jumping around the game. This is also how I tend to do choice menus, each choice is a jump to label.
Renpy also (apparently) uses labels for saving (which I did not know), remembering the name of the label and the line you were on in that label. But I've been putting scenes into past days, and I use the label system in a very procedural way. This is how the scene selector works, by looking at the day and scene number to jump to the right spot. If I put in a new scene (or break up a scene) this label represents the position of that scene, and other labels are "adjusted" to keep them in the right spot.
Which means I've been renaming labels to keep things in order, apparently a huge fucking no-no. If your save has ever loaded in the wrong scene (or not loaded at all), this is the reason why.
For example, let's say a player made a save in day 10 scene 3 (label name d10_3) and that scene has 200 lines of text, and they saved on line 150. I add a new scene to day 10 that is 100 lines long, and it needs to go into the spot (for plot reasons) scene 3 uses to be. So now the new scene uses label d10_3 and the old scene 3 is pushed forward one spot to scene 4 (d10_4).
When the player goes to load that save at line 150, scene 3 no longer has a line 150. So save doesn't load. If the player saved at say line 1 in day 10 scene 3, well now the save loads in a completely different scene, because the old scene is now scene 4, but renpy doesn't know, it's using the label which I have changed.
You might be asking, Night Mirror, how the fuck did you not know this?! I don't really have a good excuse for it, I really should have. I've been working in the renpy engine for almost 4 years now, and preserving saves has been something I really honestly want to do. But all the documentation I found about it just never pointed to this as being the issue.
There is still a lot I don't know about Renpy, I tend only to seek out new things when I need them, rather than try and take it all in and know absolutely everything about it.
So, the bigger question is: how can I fix this? To which you might be shouting at your screen STOP FUCKING CHANGING THINGS YOU FUCKING MONSTER! But again, sometimes stuff has to go into the past, and I don't want to take away the option to put scenes where they logically belong (or at least I feel they belong).
And I actually do think I have a solution: double labels. A jump label, and a save label. I can include empty label blocks, things that have no code in them. These will be the jump labels, labels I can change, that are always in order, and (that from everything I have read) shouldn't impact saves at all. And a second label, the save label, which will never change moving forward.
It seems this should largely fix the save compatibility issues I've been running into, but only time will really tell.
I think I can put in the fix for the label thing for this update (and moving forward) so that it (shouldn't) cause any save issues. I do still have some time where while I await the revisions for the last scene and it shouldn't add any extra delay to the update.
Anyhow... I'm going to go start working on that. I do think an update is very likely this week, we are down to last scene here and the review process for it will be fairly fast.
As always, thanks for being awesome!
- Sep 10, 2022
- 38
- 105
Ooh~ That's brilliant!
So it's like double bookkeeping, two ledgers with today's numbers and yesterday's. You check today's numbers with yesterday's to determine the difference and output the sumcheck total. Except in the case of Renpy's programming, one index would contain only Jump Labels while a second index runs solely for Save Jump Labels. Question is how can you get Renpy's engine to run two indexes with everything inside the directory at the same time while also being compatible with different file versions for all players?
I see why that would be an exceptional pain in the ass.
This sounds like the wrong fix. Renpy supports dynamic jumping, ie you can tell it to jump to whatever label whose name is contained in a string variable. So you can have individual scenes just having their fixed labels, and then have an array or so holding information like "What is the label of the second scene on day 23?".
- Jun 2, 2018
- 1,766
- 9,653
Here is the code to make the change a bit more clear. Currently, scene look like this:
Python:
label d23_6:
$ current_scene = '23_6'
scene black
# Image display code remove in this example.
"You peek around the door from the hall."
Python:
label x23_6:
$ current_scene = '23_6'
label d23_6:
scene black
# again, I took out the image display code to make the example less cluttered.
"You peek around the door from the hall."I am using dynamic jumping to get to things, the actual code that jumps is: $ renpy.jump("x" + target_scene)
I could build another list of all the scenes (or modify an existing one to have more info), so that is a possible solution as well. It does mean I'm changing a static list vs changing labels, which is the initial issue I want to solve.
That is an excellent suggestion, I'll give it some thinking over.
Edit:
Yeah, the list is 100% the way to go here. I had just convinced myself that including the scene label in the list was duplicating data because everything is in order, except, that is the exact issue, a few items are not. And putting in extra labels is just re-duplicating data anyhow, but in a much riskier way.
Thanks for the suggestion! In the process of putting in this solution instead!
Last edited:
- Jun 2, 2018
- 1,766
- 9,653
Alright, labels rolled back to match with r3.7f. Scene selector list updated to include scene labels. And scene thumbnails renamed to match as well (so that adding new thumbs in future, won't effect old thumbs). In the process of checking all the changes (across day select (along with the new past version jumps), scene select, and mind blowers) to make sure I didn't break anything. But a good sign it is doing what it should is I made saves in specific spots where things have "changed" in game version r3.7f, then loaded them in r3.8 and they all loaded without issue (saves from older versions might still have issues due to previous label changes, nothing I can do for those).
So, one less issue to worry about! Yay!
So, one less issue to worry about! Yay!
- Mar 4, 2020
- 90
- 118
Hey Night Mirror, i really enjoy what you are doing. But this must be really time Consuming, if you dont mind me asking, what else are you doing in your free time? Friends, relationships?
- Jun 2, 2018
- 1,766
- 9,653
Yeah, it can take a lot of my time, but, so does any hobby. I balance it as best I can with other things I want to do. Usually, outside of when we get new content from Ferdafs, I'm not doing all that much on the game. I work on the project when I want to (mostly when there is something fun I want to add), and don't touch it when I'm not feeling it (why blinks are lingering in hell).
Again, this isn't meant to be a job, it's mean to be fun for me. I like coding. I like writing. I like drawing (even if I suck at it). This game is what I do largely to relax from actual work, the same way someone might watch netflix or play video games, I (often) prefer to work on this project.
Who needs friends and relationships when you have an adoring hoard of lewd and loyal supporters?