Hello. I am making an open map game that has vehicles. How would I make it so the player can only move the vehicle when they are in it?
I guess the simplest way would be with logic bricks and a bool property, lets just say its called “isInside” and for the vehicle to move isInside would have to be true and the movement key would need to be pressed, so for each controller you would have the property sensor connected plus the keyboard sensor
I would set up the vehicle with logic bricks, then create a code to make it so that, when activated, the player is parented to the vehicle, and control work only once activated. I don’t know of an existing code, and this actually could be done solely in the Logic Editor:
Use a collision sensor so when the player touches the object, you are prompted to get into the vehicle.
Using the same bricks and prompt (Let’s use P as an example) so when the player presses P while next to the vehicle, they are not parented to that object, but setup a duplicate object and setup your vehicle settings in its Logic Editor instead. Place this object in another scene.
When you press P, it should be set up with an Edit Object actuator, set to Replace Object, instead of Add Object.
As for getting out of the vehicle, that’s a different story.
Here is a example !
R = enter car
W= Drive car (no ASD yet!)
60 frames later
E= Exit car
CarEnterAndExit.blend (508 KB)
In my current project my character will shoot a rayCast along the z minus axis of the camera to detect objects that he can interact with. If there is something hit by the ray that has a function called “interact” and the character presses E, this function will be called. In case of the vehicle, it will parent the character to the vehicle. Once the character has a parent object, it will run its “control” function every frame which will actually let me drive the vehicle. Also the character is always checking whether it has a parent, if yes it won’t do anything except for controlling the parent, if not it control itself (movement etc.)
Hope that helps you at least a bit!
Sounds a bit like wasting processing time.
I suggest - similar to the suggestions above - to but different states to the behavior of the character and the vehicle. Rather than constantly checking it is sufficient enough the change state on according events only.
walking, entering, driving
character is walking + near a vehicle + player requests to enter the car --> character changes to entering vehicle opens door or so
character is entering + finished entering -> character changes to driving and vehicle changes to driving too
Actions of the states
Character walking: player input + playing walkcycle animation + motion
Character entering: playing entering animation
Character driving: does nothing (maybe play steering animation)
Vehicle waiting: does nothing
Vehicle driving: player input + motion + animation
You need to discover a way to synchronize Character and Vehicle that they change state at the same time (+ only these two and not any other character/vehicle).
This method encapsulates the behavior of each state. This allows you to focus on the logic of a single state at the time.
I hope it helps
Did you see my example monster?
Its pretty lean right?
I know I could do better labels,
Here is a not so quick but working demo.
It made a bit more work than I expected. Please be patient with the quality of the models ;).
Switch controls or How to enter a vehicle
This was supposed to be a demo that shows an option to enter and leave a vehicle.
Unfortunately it is a bit out of control. Nevertheless it is working as expected.
The little alien (thanks to Josip Kladaric) can walk around with:
<w> or <arrow up> - forward
<a> - turn left
<d> - turn right
when the alien is near the entry (left side of the vehicle) it can activate the entry:
<space> - activate entry when near
When entering the alien can’t move anymore. But it can leave the vehicle with:
<l> - leave
When the alien entered the vehicle, you can drive the vehicle (not the alien):
<w> or <arrow up> - power
<a> - left turn
<d> - right turn
<space> - brake
<l> - leave
You might notice that little alien is sitting in a strange position after entering the car. I leave it up to you to correct it’s position.
After the alien left the vehicle - the vehicle will be in parking state => brake will be on.
How does it work:
The Alien has … many states:
1 - init
2 - search entry + 17 - user walking
3 - walk to entry
4 - entering
5 - driving
6 . leaving
I think you can look at them by yourself. Hopefully you can guess what happens in the states
The vehicle … is a modified VehicleWrapperWrapper. The simple controls are modified to have two states:
1 - parking
2 - driving
The states can be switched by setting the property “control” to True/False. Messages would make all vehicles react at the same time. This is something we do not want here.
The properties will be set by vehicle.entry.helper. It knows about the vehicles structure and how to find the controls to activate/deactivate them. This will be done with the Python modules:
vehicleControl (bge callable) and
_vehicleControl (non-callable implementation details).
The alien knows the vehicle.entry.helper after it found it. The communication is via properties again for the same reasons. This requires a bit of Python code:
alien (bge callable)
_alien (implementation details)
be aware the alien knows the entry helper but it does not know the vehicle controls.
The remaining Python files are the files from the VehicleWrapper (see my profile at blenderartists.org)
You control the alien and the vehicles via messages. The message are mapped from keyboard input with object UI.keyboard. This allows:
- to add more keyboard input (see forward)
- to add other objects e.g. buttons to clicked or joystick input
- to control more objects at the same time (e.g driving two cars )
You can change the UI if you like. E.g. using <space> for leave too (but you should use a different key for braking)
The vehicles are set up in scene Cars.
This simple steering has no limits for the wheels. If you hold the turn button the wheels steeting will continue even when the wheels do not follow. Be aware you need to steer the whole way back before the wheels turn into the other direction. If you want you can add a steeing limit (should not be that hard).
This demo use the same character model outside and inside of the vehicle. This is usually not the case. As the character is not fully visible when in the vehicle and it does not has that much to do, there is usually a simpler placeholder that only locks like the character. This allows for example to skip the legs ;). The alien is a very simple character. There is no armature and no hooks. A typical character would be much more complicated. The principles would be the same. But it would allow you much nicer animations e.g. when walking to the entry, and the entry animation. Additional objects can help to let the character face the driving direction.
The demo has two vehicles. You can add more if you like.
I hope you enjoy a driving alien
SwitchControlsDemo.blend (684 KB)
Wow Monster, that looks like a lot of work you have done there for us, thank you!
Some post before you mentioned that it would be a waste of processing time to check if the character has a parent, but this should really not be the problem since it is only one simple condition (if not self.parent). I think doing that with states needs actually more processing time and a lot of code.
I just used
Property ‘On’=True-------and------Do stuff
Added some stuff,
I need his Monsters “get in the car” action system but…
wsad = move
R= enter vehicle if touching car and doors are open.
HoverCArEnterExitDoorsOpen.blend (786 KB)
The important word was “constantly” checking ;). This is because if you get notified of the parent/unparent event, you can assume that there will be no change without a notification. So it is more efficient to remember what the relationship is after the last event.
I think this will not be a problem on itself. Using such polling behavior can quickly add up. Therefore I recommend to avoid it as long as there is no other reason to use polling. Changing it later can be a real pain.
It needs more code as you need to manage states. The code overhead is really limited. Using states saves processing time as all logic that does not belong to an active state will not be executed.
When using the build-in state system, you can even save processing time on sensors which are not connected to a controller in an active state. This can save that much processing time that it might be worth to use states just for reducing processing time (e.g. when using radar sensors). But this is a different topic and does not belong to parenting/unparenting.
I will for sure start making everything have a On state and a off state, at the very least.
I would like to have access to camDistance in the LOD patch…
thanks man it works