Draggable Background-JPGs [with x-y-limits w/o story-break]?

[Conquestus]

Hi girls and guys. I need to ask for your assistance, I hope you can help me.

Let me explain first what I'm trying to do. My idea seems pretty simple, but since I'm a total noob to renpy + python, it's pretty hard for me. Maybe you can help me with that, I would appreciate it.

All I want to do, is to make background images draggable ingame (with limits based on the maximum size of the used image, so that the image can't be dragged over the borders of the image [image size > screen size]), while the story can continue by pressing space ONLY or something like that (not by mouseclick, because it's needed for dragging).

I tried something like this:

///////////////////////////////////////////////////////////////////////////////////////////////////////

Code: Select all

#Define Pictures
image bg draggablePicture0001_WorldMap = "draggablePictures/0001.jpg"

# [heres some relevant code]

init:

# [heres some other relevant code]

label draggablePicture1:
 scene bg draggablePicture0001_WorldMap at Position(xpos=0.5, ypos=0.5, xanchor=0.5, yanchor=0.5, draggable=True) with fade
 "Mind" "I can drag the map to explore the world."
 "Mind" "Hm? Wait... What?"
 "Mind" "Whoops... The picture showed up, but isn't draggable... I'm such a noob."
 return

///////////////////////////////////////////////////////////////////////////////////////////////////////


With help of this: https://www.renpy.org/doc/html/drag_drop.html
I managed to make the narrator-box draggable by editing the say screen... which wasn't even my intention, but I can't make background screens draggable.

Alternatevily I thought about to try to make background screen images controllable with the arrow-keys, for the same reasons, but here I failed too.

I'm sorry to annoy you with such a question, but I would really appreciate your help. Thanks in advance.



EDIT: In another attempt I tried to make an interface with ui.imagebutton to have realtime control over the background picture... I achieved to reposition the background image, when I copy it into the say screen as imagemap... but then I have no soft movement control... I can just "teleport" from one side to the other.

There must be a way to have realtime-control over the background image-position and movement... Or not?

EDIT2: Well yeah... guess you guys don't have an idea, huh?

[ISAWHIM]

This concept has to be revisualized. Not because there is anything wrong with it, but because it is demanding of something which is directly "impossible", by normal function.

What RenPy has coded for the background is a semi-static image. (I think there is code for panoramic functionality, but mouse-input will certainly still advance it.) {I believe it uses mouse-move as a positioning element, or transition-code. Since it doesn't actually capture the mouse, it will run into issues with mouse-move, as the mouse can move out of the screen.}

I would throw the thing you want as a "background", into an object that you want the "drag and drop" functionality. Since that is essentially what you want. Making the screen a "modal", should kill mouse-input for "click to continue". You can "drop it" into whatever place they drop it at, but you will have to setup the keyboard-input to simulate a "click", which triggers the hiding of that object which you are using as a background, or interprits the "drop position", to set the actual "background position", which will then allow the game to continue with the standard "click to continue", with the "modal" window/screen hidden.

Thus...

1: Show a modal screen with a drag-drop object (the background image as the drag-drop items background/image)
2: When being dragged, and dropped... Accept any drop-position as valid, updating the "position" of the drag-drop item's background/image position instead. (Limiting it to the screen resolution, which changes, by the way. Percentages may be better. 1.0 -> 0.01 etc...)
3: When they hit that keyboard-button (whatever you set to continue), you set the actual background-image to the position that the button was dropped. (so it is in the same exact position as the drag-drop item background).
4: Now, you "hide" that screen/window, so they see the actual positioned background and the dialogue-box/window, which will now "click to continue".

I would hijack the "GUI" overlay screen/window. Or simply insert your own named-layer, over the top-most layer that exists, which I believe is "GUI" or "overlay".

I would help with actual code... But I have never programmed the "drag-drop" function before.

However, I have had to deal with the nightmare of "tricks" related to attempting to "disable input", or "capture/intercept-input", for mouse and keyboard, so it does not "click to continue", and can be "managed" by our code. Unfortunately, this is not an actual "function" of RenPy, yet, and I suspect it will never be one. (Though there are literally thousands and thousands of requests for that to be a feature.)

[gas]

Now we solve it with ergonomics.
What exactly is the case of use?
'cause moving the background at will for the sole purpose of is anti-gaming.

[ISAWHIM]

I think you are missing a word in your last half-comment...
"for the sole purpose of is anti-gaming"... Sole purpose of _____ (what?) is anti-gaming.

Static backgrounds are anti-gaming, that is a book or a magazine. Games move and interact and portray the artists intentions. Anti-gaming is stagnant, immobile, and anti-creation limitation. I am not sure I understand that comment at all.

The case of use is obvious... To look around the environment in a normal/intuitive way, as we do with other games.

Click, hold, drag = Look left and right in the scenery. (Since there is no 3D-rotate/panoramic control, which requires capturing the mouse. A feature that Tom stated, "There is no need to capture the mouse." Correct, it is a want, not a need, and at the moment, it is an inability, except for the drag-drop function.)

The "drop", simply used to "lock-in" the position which you now face, in the scenery, when you stop looking around. (As opposed to returning to the centered image.)

As opposed to the horribly controlled and un-natural (Mouse-over-edge) AKA (Mouse-edge-scrolling) to look left/right, like the sims, which everyone disables. (Or here, which few use, and fewer even know it exists, when it is used. Because they rarely move the mouse in a click-to-continue window.)