lagging return button (unpredicted image?)
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
- Qlara
- Regular
- Posts: 80
- Joined: Fri Nov 28, 2014 10:22 am
- Completed: Carmilla
- Skype: kantonija
- itch: visualgothic
- Location: Berlin
- Contact:
Re: lagging return button (unpredicted image?)
Thank you so much, for putting that much work into my problem. [feel free to use a female pronoun with reference to me, by the way]
Unfortunately, I can't get it to work with screen variables, although the method is familiar, as I'm using it elsewhere in a menu that has sub-menus.
Going back to the beginning, I believe that my code is actually reasonably structured. I shouldn't have to change much. We've been working from the hypothesis that showTransient (or recursion) is the problem. However, that doesn't explain why all buttons except 'Return' work all the time. Furthermore, I have unhovered -> hide in there, so why would images pile up? And it is not the repeated pressing of 'Return' that causes an actual 'Return' but simply wait time. What about the "unpredicted image" error I see in the image load log?
The problem might lie completely elsewhere.
I'm pretty sure I had good reasons to do it the way I originally had, as I had tried a lot of different ways over the years and that method stuck.
Tooltips may or may not be a good alternative, but the documentation sucks (it only tells you that's a class in the "outdated" area). The available information and gas' advice are so far above my level, I can't work with it (not for lack of trying).
Before anybody puts any more time into this, I'll sleep over it and then try older Ren'Py versions and setting config.zap_transients to False, and finding the changelog on main_menu and predictions, and as a last resort, remove the return button.
I've had the demo out for a while, and so far nobody has complained about the problem, perhaps I should let it go.
Unfortunately, I can't get it to work with screen variables, although the method is familiar, as I'm using it elsewhere in a menu that has sub-menus.
Going back to the beginning, I believe that my code is actually reasonably structured. I shouldn't have to change much. We've been working from the hypothesis that showTransient (or recursion) is the problem. However, that doesn't explain why all buttons except 'Return' work all the time. Furthermore, I have unhovered -> hide in there, so why would images pile up? And it is not the repeated pressing of 'Return' that causes an actual 'Return' but simply wait time. What about the "unpredicted image" error I see in the image load log?
The problem might lie completely elsewhere.
I'm pretty sure I had good reasons to do it the way I originally had, as I had tried a lot of different ways over the years and that method stuck.
Tooltips may or may not be a good alternative, but the documentation sucks (it only tells you that's a class in the "outdated" area). The available information and gas' advice are so far above my level, I can't work with it (not for lack of trying).
Before anybody puts any more time into this, I'll sleep over it and then try older Ren'Py versions and setting config.zap_transients to False, and finding the changelog on main_menu and predictions, and as a last resort, remove the return button.
I've had the demo out for a while, and so far nobody has complained about the problem, perhaps I should let it go.
Re: lagging return button (unpredicted image?)
I don't think unhover got triggered when a screen is shown above - I'm not sure how it physically works but I know one example of it was when I used hover to create tooltips - if something else happens before I move out of the button (like if I click on the button) then the tooltip remains until I move the cursor back to the button and out again. Unhover is probably triggered when your cursor physically leaves the button - which doesn't get picked up if there's a screen between the button you're trying to unhover and the cursor.
Plus if the unhover does happen, wouldn't the screen disappear immediately and you never get to see the chapter you've hovered on?
Step 1:
[blank entry screen]
Step 2: hover over entry 0
[entry 0]
[blank entry screen]
Step 3: if the unhovered is triggered, entry 0 will disappear, you're back to blank entry screen:
[blank entry screen]
The fact that entry 0 doesn't immediately disappear means that unhover never got triggered. If anything I wonder - since your cursor would be directly above the same button, whether another hover is immediately triggered, so it may actually be doing:
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[blank entry screen]
before you move the cursor away from the button, hopefully not!
You're right though, I could be completely off the mark here, but it's my strong impression of what's happening when you said return "sometimes" worked and is laggy.
When you said "unpredicted image" and optimising them, I guessed perhaps renpy is using up too much resources, that's why I figured it may be that the screen has been loaded many times - it's quite hard to tell without actually playing around with the game to see what's really going on.
One way you can test whether my theory is right is to make the background slightly transparent - so anything underneath would show through. If it gets darker and darker as you hover, then you'll know it's definitely what's happening. If not, then it's safe to say my hypothesis is wrong. I highly recommend you do this test to find out conclusively whether it's the problem.
In terms of using the screen variable, you just need to move the default statement to the root screen that's being shown, it recognises the screen variable as long as you're currently acting on that screen so it should work. If you've put it in another screen with the use[/u] keyword, then move the default statement to the parent screen.
Plus if the unhover does happen, wouldn't the screen disappear immediately and you never get to see the chapter you've hovered on?
Step 1:
[blank entry screen]
Step 2: hover over entry 0
[entry 0]
[blank entry screen]
Step 3: if the unhovered is triggered, entry 0 will disappear, you're back to blank entry screen:
[blank entry screen]
The fact that entry 0 doesn't immediately disappear means that unhover never got triggered. If anything I wonder - since your cursor would be directly above the same button, whether another hover is immediately triggered, so it may actually be doing:
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[entry 0]
[blank entry screen]
before you move the cursor away from the button, hopefully not!
You're right though, I could be completely off the mark here, but it's my strong impression of what's happening when you said return "sometimes" worked and is laggy.
When you said "unpredicted image" and optimising them, I guessed perhaps renpy is using up too much resources, that's why I figured it may be that the screen has been loaded many times - it's quite hard to tell without actually playing around with the game to see what's really going on.
One way you can test whether my theory is right is to make the background slightly transparent - so anything underneath would show through. If it gets darker and darker as you hover, then you'll know it's definitely what's happening. If not, then it's safe to say my hypothesis is wrong. I highly recommend you do this test to find out conclusively whether it's the problem.
In terms of using the screen variable, you just need to move the default statement to the root screen that's being shown, it recognises the screen variable as long as you're currently acting on that screen so it should work. If you've put it in another screen with the use[/u] keyword, then move the default statement to the parent screen.
- Qlara
- Regular
- Posts: 80
- Joined: Fri Nov 28, 2014 10:22 am
- Completed: Carmilla
- Skype: kantonija
- itch: visualgothic
- Location: Berlin
- Contact:
Re: lagging return button (unpredicted image?)
I played around for a long while with your code, the last error I got was "NoneType object has no attribute constant".
In the original code, the screen does disappear upon unhover. Everything works splendidly until I indulge in the pretty effect too much, and the return button gives in. If you check out my demo, you can see it yourself. (I haven't encrypted the files)
The idea that the lag was caused by resources was my first idea. I've optimized as much as is possible, though (and now you ask me to re-introduce transparency ).
I had tried commenting out all overlay images. Strangely, with my failed tooltip code, they stubbornly kept showing up, despite deleting cache and recompiling ???
With original code (top of this thread) and only text, no images, the problem persists.
Now, half transparent, ... damn, I lost my original code over the course of the last 100 hours of experimenting. I'll recover it tomorrow, then I can set the alpha value instead of re-saving my hard earned compressions as .pngs.
In the original code, the screen does disappear upon unhover. Everything works splendidly until I indulge in the pretty effect too much, and the return button gives in. If you check out my demo, you can see it yourself. (I haven't encrypted the files)
The idea that the lag was caused by resources was my first idea. I've optimized as much as is possible, though (and now you ask me to re-introduce transparency ).
I had tried commenting out all overlay images. Strangely, with my failed tooltip code, they stubbornly kept showing up, despite deleting cache and recompiling ???
With original code (top of this thread) and only text, no images, the problem persists.
Now, half transparent, ... damn, I lost my original code over the course of the last 100 hours of experimenting. I'll recover it tomorrow, then I can set the alpha value instead of re-saving my hard earned compressions as .pngs.
Re: lagging return button (unpredicted image?)
I'd just use a solid background on your frame / window temporarily and give it alpha transparency:
That should give it a 50% transparent black background.
Code: Select all
background "#0008"
- Qlara
- Regular
- Posts: 80
- Joined: Fri Nov 28, 2014 10:22 am
- Completed: Carmilla
- Skype: kantonija
- itch: visualgothic
- Location: Berlin
- Contact:
Re: lagging return button (unpredicted image?)
I took another close look and remembered that those images are not all the same size. Some stick out beyond the (drawn) frame, so if they were on top of each other, I'd see that.
And I just realized something: it seems return takes me to the last screen I hovered.
And I just realized something: it seems return takes me to the last screen I hovered.
Re: lagging return button (unpredicted image?)
Yeah that's what I figured would be happening with the return if it seems to not work at times - because it just takes you down one screen. But if the screens are identical you wouldn't be able to tell.
Re: lagging return button (unpredicted image?)
Tweak pos/aligns if you need; if there's any difference from what you had before it's negligible as far as I can tell from running it with the rest of your demo.
Code: Select all
default chapters = [ ("+ Editor's Preface","00"),
("1: A Guest", "01"),
("2: Drifting", "04"),
("3: Descending", "06"),
("4: The Story", "10"),
("5: Discovery", "13") ]
screen chaptitles:
tag menu
style_prefix "chaptitles"
add "gui/chaps.png"
default c = 6
vbox:
xpos .185
ypos .24
spacing gui.navigation_spacing
for i in range(6):
$ name = chapters[i][0]
$ num = chapters[i][1]
$ p = getattr(store.persistent, "unlock_chap"+num)
textbutton name:
if i == 0:
yoffset -18
action Start("chap00")
else:
action If(p, Start("chap"+num), NullAction())
hovered SetScreenVariable("c", i)
unhovered SetScreenVariable("c", 6)
textbutton _("Return"):
style "chaptitles_return_button"
action Return()
use chapentry_revised(c)
default chapentries = [ ("Introduction", "Editor's Preface", "In which the editor introduces {i}Visual Gothic{/i} and Laura, the heroine of this story."),
("A Guest", "Chapter 1:", "In which Laura introduces her home and a mysterious guest arrives at the castle."),
("Drifting", "Chapter 2:", "In which we hear about the girls' everyday life and take a close look at Carmilla's habits."),
("Descending", "Chapter 3:", "In which Laura begins to experience strange symptoms and disquieting nightly visions."),
("The Story", "Chapter 4:", "In which we meet the General and he tells us about the events preceding his daughter's death."),
("Discovery", "Chapter 5:", "In which few secrets come to light while the ghosts of past ages are exorcized.") ]
screen chapentry_revised(num):
style_prefix "chapentry"
if num != 6:
add "gui/overlay/ch{}over.jpg".format(num):
if num == 0:
pos (607, 59)
else:
pos (650, 72)
frame:
label chapentries[num][0]
vbox:
text chapentries[num][1]
text chapentries[num][2]
- Qlara
- Regular
- Posts: 80
- Joined: Fri Nov 28, 2014 10:22 am
- Completed: Carmilla
- Skype: kantonija
- itch: visualgothic
- Location: Berlin
- Contact:
Re: lagging return button (unpredicted image?)
Philat's code is working splendidly.
I only have one tiny syntax problem left:
Right now, there are two colors: hovered and idle.
I'd like to keep the idle color on hover for the locked buttons.
adding insensitive_color under style doesn't do anything, probably because they are not completely insensitive.
Could I add a hover_color attribute under else:? If so how?
I think the problem originally was simply moving the mouse too fast for the unhover->hide command to kick in.
Thanks everyone for all your time and effort!
I only have one tiny syntax problem left:
Right now, there are two colors: hovered and idle.
I'd like to keep the idle color on hover for the locked buttons.
adding insensitive_color under style doesn't do anything, probably because they are not completely insensitive.
Could I add a hover_color attribute under else:? If so how?
Code: Select all
textbutton name:
if i == 0:
yoffset -18
action Start("chap00")
else:
action If(p, Start("chap"+num), NullAction())
hovered SetScreenVariable("c", i)
unhovered SetScreenVariable("c", 6)
Thanks everyone for all your time and effort!
Re: lagging return button (unpredicted image?)
I'm still pretty sure the problem before was that you couldn't unhover something before because the button you tried to unhover was buried underneath another screen because of the recursion. philat's version is a detailed version of what I suggested using your exact code (thanks philat!) - I posted code stripped of your styling and formats because I couldn't test it without your images ^_^U
You can put alternative hover colour, or even different styles inside your conditions:
You can put alternative hover colour, or even different styles inside your conditions:
Code: Select all
textbutton name:
if i == 0:
yoffset -18
action Start("chap00")
else:
action If(p, Start("chap"+num), NullAction())
style "my_style" # you can do this and create another style
hover_color "#333" # or just put the hover_color in here directly if you know you're only changing one thing
hovered SetScreenVariable("c", i)
unhovered SetScreenVariable("c", 6)
style my_style is chaptitles_textbutton: # extend your style using "is" to copy existing style settings
hover_background "#000"
hover_color "#333"
- Qlara
- Regular
- Posts: 80
- Joined: Fri Nov 28, 2014 10:22 am
- Completed: Carmilla
- Skype: kantonija
- itch: visualgothic
- Location: Berlin
- Contact:
Re: lagging return button (unpredicted image?)
Putting hover_color under else (my preferred approach) results in the following error:
"hover_color is not a keyword argument or valid child for the textbutton statement."
Defining a new style results in the loss of my formatting, no matter what I set as parent style.
"hover_color is not a keyword argument or valid child for the textbutton statement."
Defining a new style results in the loss of my formatting, no matter what I set as parent style.
Re: lagging return button (unpredicted image?)
Ah, sorry! Maybe it's text_hover_color instead, as it's the text that needs formatting. I always forget that sorry!
What chaptitles styles have you created? If you list them it may be easier to see what you actually need to change?
What chaptitles styles have you created? If you list them it may be easier to see what you actually need to change?
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot]