- Thread starter ShaddyGames
- Start date
Devs rarely if ever do proper roadmaps and often don't really plan the story out, most of the time it's written on the fly.
Naturally they also make up the versioning as they go along.
. Normal software versioning doesn't really work for visual novels due to their complexity (Story Writing, Editing, Proof Reading, Model design, Model positioning, Animation, Ren'Py code writing, Ren'Py code bug fixing, Sound Sourcing, Sound Editing, consistency monitoring (was the model wearing a pair of glasses in the last scene?), project management, publishing, marketing, just many of the hats that Shaddy is wearing...). I'd personally recommend that they switch to Calendar Versioning. Then Shaddy could give a running total of how many renders were added and 'gameplay time' estimated on auto set at pretty low. Though they may have to do this for each 'route' they want (if and I don't recommend it) they want to have multiple routes). I feel that would be more helpful to users and also to Shaddy in the long run.It wasn't an old save it was my first game. I started with 0.7, but I turn down the text speed and auto speed and usually play on auto to avoid clicks.
Specifically it relates to the dress choosing scene, auto doesn't wait for user input for whatever reason and then screws everything else over without crashing.
Skipping works just fine though.
- Mar 5, 2019
- 738
- 1,468
Oh, right. You're using the auto forward mode. Unfortunately, afm is a bit of a dogs dinner in renpy. It's the bane of a developer's life, frankly. It's possible to stop it with a "$ preferences.afm_enable = False" call in the screen that's being used to make that dress choice but renpy will stop auto forward long before that screen is actually called - there's no way to stop it exactly where you want. It'll stop as soon as the screen is preloaded by renpy.
I've attached a modified screen call to do that, just drop the attached file into the game folder. It'll stop auto-forwarding while the girls are still in the pool, just before the dress choice screen is called. Can't really do much more than that... This is one for the developer to sort out tbh.
- Oct 5, 2017
- 7,547
- 10,056
Why would you place that call in the screen? Do that right before showing the screen. The docs are very clear that screens should not have side effects specifically because of preload.
- Mar 5, 2019
- 738
- 1,468
That doesn't cause side effects outside of the screen! It just turns auto-forwarding off. If you change it outside of the screen it'll just instantly be turned back on again anyway. The whole afm system is a mess tbh.
Last edited:
- Oct 5, 2017
- 7,547
- 10,056
That... is a side effect. You don't know what "side effects" means in programming I take it? And turning it off outside the screen does work, though it won't stop the player from turning it on again which breaks it still. The proper thing to do is to make the screen modal, which prevents it auto advancing, but keeps the afm state so that it will continue to advance automatically once the player clicks on one of them.
- Mar 5, 2019
- 738
- 1,468
Sheesh, pull your horns in. The warning about changing things in screens is about graphical changes possibly being overwritten by a screen being called multiple times. That's not an issue here, it doesn't matter how many times it gets called.
This change is just a stopgap till the dev can sort things out. Apply it or don't, but stop bleating about it.
This change is just a stopgap till the dev can sort things out. Apply it or don't, but stop bleating about it.
Guys guys... K.T.L has suggested a 'work around' fix which, seems workable. I may try it out but, probably what I'll end up doing is scrolling back a bit and turning autoforwarding off XD. My experience with autoforwarding and stopping at decisions has normally been a good one.
Doesn't mean it's an actual fix just something that may help before the dev gets around to it.
Doesn't mean it's an actual fix just something that may help before the dev gets around to it.