It might be better if you saw it working and were able to play around with working code, with working images.
So I'm including a little test program I wrote to demonstrate your own picture. Just unpack it to your RenPy projects folder and edit it to your heart's content. Imagebutton Example Source :
You must be registered to see the links
- Edit: Link expired. Sorry.
It was all a bit rushed and since the base I used was for a different screen size - things looks a bit odd. But the code and the "game" both work.
If you'd rather just see the end results... here's the final built version of the game... Imagebutton Example "Game" :
You must be registered to see the links
There is no way to exit the game other than just closing it. The map screen is a closed loop.
Is there anyway to keep the background and other buildings visible, while the building you clicked is the only image that disappears; while jumping to the label to start a conversation? Basically, keeping the background image and buildings you didn't click in the background during a conversation?
Is there anyway to keep the background and other buildings visible, while the building you clicked is the only image that disappears; while jumping to the label to start a conversation? Basically, keeping the background image and buildings you didn't click in the background during a conversation?
Show the screen after the click. But then you'll need a way to know what building have been clicked.
You'll also need to have a mask over the image, in order for the other hotspots to not be clickable. Else, it will branch the player to another part of the game while he's still in the middle of something ; this would break both the code and the story.
Something like this should works:
[Warning, wrote on the fly, there's possibly some typos]
Python:
# Actually selected location, in order to hide the button.
default mapLocation = None
label whatever:
[...]
# Reset the screen.
call screen myMap( True )
label jumpedLocation:
show screen myMap
[...]
screen myMap( reset=False ):
# It's a reset, forget about the previously clicked
# location.
if reset:
$ mapLocation = None
imagemap:
[...]
# Activate only if it's NOT the clicked location.
if mapLocation != "LocationName":
hotspot [...] action [ SetVariable( "mapLocation", "LocationName" ), Jump( "jumpedLocation" ) ]
# Make the whole map not clickable if it's not
# a called screen.
if not reset:
imagebutton:
idle Solid( "#00000000" )
xpos 0
ypos 0
xsize config.screen_width
ysize config.screen_height
action NullAction()
Show the screen after the click. But then you'll need a way to know what building have been clicked.
You'll also need to have a mask over the image, in order for the other hotspots to not be clickable. Else, it will branch the player to another part of the game while he's still in the middle of something ; this would break both the code and the story.
Something like this should works:
[Warning, wrote on the fly, there's possibly some typos]
Python:
# Actually selected location, in order to hide the button.
default mapLocation = None
label whatever:
[...]
# Reset the screen.
call screen myMap( True )
label jumpedLocation:
show screen myMap
[...]
screen myMap( reset=False ):
# It's a reset, forget about the previously clicked
# location.
if reset:
$ mapLocation = None
imagemap:
[...]
# Activate only if it's NOT the clicked location.
if mapLocation != "LocationName":
hotspot [...] action [ SetVariable( "mapLocation", "LocationName" ), Jump( "jumpedLocation" ) ]
# Make the whole map not clickable if it's not
# a called screen.
if not reset:
imagebutton:
idle Solid( "#00000000" )
xpos 0
ypos 0
xsize config.screen_width
ysize config.screen_height
action NullAction()
nice! I may have done something wrong. your solution works very well, except that NullAction() is preventing the dialog from moving forward from left clicks.
edit: Hmm, it seems that if I replace nullaction with return, the dialogue moves forward even if the imagebutton is clicked on and doesn't seem to be causing any problems, although I'm still not experienced enough to be sure.
nice! I may have done something wrong. your solution works very well, except that NullAction() is preventing the dialog from moving forward from left clicks.
Yeah, but only if you click on the screen itself. Clicking on the "say box", or pressing space, still make the dialog advance.
In fact it prevent what is more a side effect than the effective behavior ; well, more "was" than "is", it's like that since so many years now. And I admit that I didn't thought about this. I rarely use this imagebutton trick outside of a screen with a close button, and even less while there's dialogs advancing in front.
edit: Hmm, it seems that if I replace nullaction with return, the dialogue moves forward even if the imagebutton is clicked on and doesn't seem to be causing any problems, although I'm still not experienced enough to be sure.
Store the value given to it into _return ;
It can possibly interfere with called label and their own return statement. But a label returning a value, and the processing of this value generally take place inside the same interaction. Therefore, the value of _return will be proceeded before the imagebutton can possibly update it "by error".
Close the screen ;
My fear iswas that it close the screen whatever the way it appear. But you would have noticed, and said, if it was what happen. Therefore, I guess that it only call the screen if it was called, what isn't the case here.
Pass to the next line in the label.
What is precisely the behavior you're trying to reproduce.
So, in the end, except the need to be careful if you need to use _return, it feel safe for me.
I keep meaning to try it. But I'm assuming (always a bad idea) that since android devices are touch screen devices - there isn't actually a cursor to keep track of for hover to actually work as it would on mouse controlled PC's. It's not like the screen knows where your finger or stylus is until you actually touch it.
Honestly, RenPy may have a really clever thing already built in which makes it a lot easier. It does make me wonder how these open world/point and click style games actually manage to be played effectively on android. But thankfully, it's not something I have to worry about - consider perhaps, but not actually worry about.
Honestly I don't have words to describe how grateful I am for this. I mean creating a small quick game just to help people like us, thank you very much 79 flavors.
