Hi! This is my first post here, and I was wondering if anyone could help me.
So, I am making a program that is supposed to toggle between two views, each where the camera is at a precise spot. I want to be able to press B to go into “body view” and F to go into “face view.” When I tried on my own, it zoomed out randomly and didn’t go back in. I tried following a logic gate tutorial on toggling, but it’s different from what I needed so I was having trouble adapting it. Here is a screenshot of what I have now, I know it’s messed up, but I was just tired of fooling around with it. If you can help I really appreciate it. Thanks in advance!
This screenshot is really hard to read.
What you want is pretty simple and straight forward:
switch to body view:
Keyboard sensor "set body view" -> AND -> Scene Actuator "set body camera"
Key: <B> Mode: Set Camera
Camera Object: Camera.Body
No need to set any Level Triggering, Level or Tap.
How does this work:
The sensor is listening to key <B>. When it gets pressed the AND controller gets triggered. The triggered AND controller activates the scene actuator which switches the the configured camera.
As long as you hold the <B> key, the sensor will not trigger the AND controller again.
switch to face view:
Keyboard sensor "set face view" -> AND -> Scene Actuator "set face camera"
Key: <F> Mode: Set Camera
Camera Object: Camera.Face
Implementation:
Setting the camera is independent from the object performing this logic. Any object can do this. The camera always belongs to the scene the executing object resides in.
This allows you a few options.
A) single object to switch cameras. This means you setup both operations at the same object.
B) different objects to switch cameras. Typically you assign the switching logic to the according cameras.
In your case it does not matter what option you chose. This might be different on other requirements.
You can also use python to change the cameras. Add an integer [int] property in a camera
from bge import logic as g, events, render as r
c = g.getCurrentController()
o = c.owner
scene = g.getCurrentScene()
#objects in scene
emp = scene.objects[‘emp_player’]
cam_player_one = cena.objects[‘Camera-player_one’]
cam_player_two = cena.objects[‘Camera-player_two’]
#keyboard events
k = g.keyboard.events
f = k[events.FKEY]
#using in game
if f in [1,4]:
o[‘int’] +=1
if o[‘int’] >1:
o[‘int’] = 0
if o[‘int’] ==0:
scene.active_camera = cam_player_one
else:
scene.active_camera = cam_player_two
That’s all. I hope be this you want.
I suggest to split the code much more. Just now it looks like a mess that tries to rules the world.
A) The camera contains network logic. Isn’t it better when a separate objects focus on such operations? I mean cameras are expected to do … camera thingies. Establishing network connections seem not to fit really well.
B) I suggest to use module mode for bettwer isolation of the various network operations (listening, connect, disconnect, send …).
C) Nested function definitions make the code harder to read. How does it look when these function definitions are not inside another function? How does it look like when these function definitions are encapsulated into a separate module (and then imported)?
D) Short variable names are nice, within a very close context. Wouldn’t it be more comprehensible when the variable has a meaningful name? When a variable name can easily lead to misunderstandings (short names always fit do that category) wouldn’t it be better to see how it is assigned without the need to page up and analyse code?
E) You still have a thread. As written above, this is not the best idea within the BGE.
F) The endless while loop is dangerous as it has a high potential to hold the BGE game loop. How about a security check that ensures the processing does not exceed a certain time frame?
G) Are you sure you want to slow down the processing in a nearly-realtime environment via sleep()? The idea of non-blocking is that you read all messages that are already received rather than to wait for more. Therefore there is no need to wait.
H) Wouldn’t your network code easier to maintain, when you isolate it from command processing (formatting and parsing commands)? I mean it is not very likely that your network code will be extended in future. But it is very likely that you will introduce new commands.
a suggestion for above screenshot, i would remove 1 property actuator and change the other one into toggle.
Why you toggle? Terrabyten wrote he wants <B> and <F> to explicit a certain view.
well i saw the Title and screenshot and he told it like a toggle type setup, so i wondered why not use the toggle function.
anyway, for b and f its rather easy,
2 keyboard sensors
2 and
2 scene- set camera
all you need for it to switch camera’s.