Do something when right click is released in python

I’m using python to manipulate the camera in my game and I need it to zoom in and change the sensitivity when the player right clicks, but the problem comes in when the player releases right click and returns the zoom and sensitivity to normal. I don’t want it to constantly change the zoom when right click isn’t held down, I just want it to adjust it once in the instant it was released. I’d like to do this entirely in python, but worst comes to worse I can make a logic brick sensor and access it through python. I’d really like to not do that though xD thanks in advance!

I actually decided on a different way to handle this mechanic in game, so I won’t need this method, but if there is a way to detect this I’d really like to know, so please answer!

Right Click --------and-----Add 1 to X

Right click inverted----and------Set property “Fire” 1
X > 1-----------------------/ ------X=0

if “Fire”=1---------and-----do stuff
______________-------“Fire”=0

?

Attachments

ClickIt.blend (420 KB)

If I understand you right, when pressing a key (right mouse key) you want to change some parameter of the camera. When you release the key you want them set back.
In extension if the key is pressed again it should use parameters from before the last key release.

It sounds like you need to store the values of the parameters somewhere and retrieve them back. The best is to store them in according properties. This is pretty simple:


from bge.logic import getCurrentController

# internal property names
PzoomFactor = "zoomFactor"

# default values
DEFAULT_ZOOM_FACTOR = ...

# BGE entry points
def continueZoom():
   if allSensorsPositive():
      restoreZoom()     
   else:
      storeZoom()
      setDefaultZoom()

# internal 
def storeZoom():
    storage = getOwner()
    storage[PzoomFactor] = getZoomFactorFromTheCamera() # or however you get the zoom

def restoreZoom():
    storage = getOwner()
    zoomFactor  = storage.get(PzoomFactor, DEFAULT_ZOOM_FACTOR)
    setZoomFactorAtTheCamera(zoomFactor) # or however you set the zoom

def setDefaultZoom():
     setZoomFactorAtTheCamera(DEFAULT_ZOOM_FACTOR) # or however you set the zoom

def getOwner():
   return getCurrentController().owner

def allSensorsPositive():
   for sensor in getCurrentController().sensors:
      if not sensor.positive:
         return False
   return True

As you see the sensor(s) are just configurable input. The code is independent from the sensors type.
With a little change you can even store/restore the default zoom.

Why not?

If you really need that you need a pure Python game engine like panda 3D. It forces … sorry allows you to do everything in Python. No need to fiddle with any supportive configuration GUI ;).

and a version where it uses X to “Do stuff”

Apply force :smiley:

Attachments

ClickIt (1).blend (473 KB)

You can always try something like:

if (mouse.events[bge.events.RIGHTMOUSE] == active):
camera.fov = 32
mouseScale = 0.001
else:
mouseScale = 0.6
camera.fov = 120

Attachments

Forest 002.blend (1.02 MB)

that is exagerate, start a new engine without a bit of UI is painful. :eek:

what about this :

if bge.logic.keyboard.events[bge.events.LEFTMOUSE] == 3 :

you can write:


import bge
if bge.logic.mouse.events[190] == 3:

This and the code above might be correct (I can’t tell off-hand), but you should use the key constant variables rather than the values themselves. That line of reasoning should be fine for executing code when a mouse button is released, however.

My silly logic demo counts how long you held the key :smiley:

and from that emerged this…

:smiley:

Mouse move = Apply forces to ball

Right Click = Hold to jump

Left click = stick to map

this + normal gravity and a few physics launchers, suckers, blowers and enemies =It’s a game in a can!

END

Attachments

RollingThunderp.blend (611 KB)

@Monster This project is a lot more about me learning python than it is about making a functional game, forcing myself to do it python just helps me realize what I can and can’t do and different ways to approach problems in it. Panda would probably be a better test of that honestly, but I’m too biased toward Blender to use it :stuck_out_tongue:

@BluePrintRandom You’ve helped me out a couple times before I think, and once again those blend files were super helpful. They were a little overboard on what I was asking about though! Thanks a bundle!

@MarcolT and Retsnom that’s pretty much all I was asking for, just a simple way to access the mouse being released :stuck_out_tongue:

@SolarLune I do actually have all the inputs stored as variables in my script, it’s good advice I didn’t know about during my first game in blender xD also Valchion looks really great, I saw it the other day

When I said for you to use the key constant variables, I meant using the official ones from the BGE API, not just ones that you’ve made a note of and stored in variables. Just wanted to let you know in case they change that number in the future.

Also, thanks for that - I’m glad others seem to like my game in production.

Oh ok, I see what you mean. I’ve generally found keycodes obnoxious in the long run because of things like that, and because I can never remember them. I was forced to use them back when I was working in ActionScript for Flash though.

What I want to say is - it is better to focus on the things you really need rather than to recreate things that already exist.

When you focus on the “store/restore” topic you can completely ignore the keyboard evaluation as it is something separate.

If you unnecessarily mix such things you will get a hard time to reuse what you did. Imagine you want to do a similar thing when two objects are colliding, or you want to use a joystick button. You would need to change the store/restore code just for another trigger or even more worse you copy that code. As much purpose you add as much more complex it will become.

Just something to think about ;).

Thanks for the advice, I’ll definitely keep it in mind