UE3 - UT3 check for keypress in Kismet
- Thread starter Shivan Hunter
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
I know you can play a trigger (or a trigger volume) in your map, select the trigger, go to Kismet, right click and choose... "New event using trigger_#", then on the sub-menu, choose "Touch". The name of your trigger will be different, so I added the "#" to represent a number.
In the Trigger node's property (in Kismet), if you don't want the player to aim at the trigger, uncheck bAimToInteract". Be sure to adjust the InteractDistance and set MaxTriggerCount to 0 if you want it to be triggered an infinite amount of times.
In the Trigger node's property (in Kismet), if you don't want the player to aim at the trigger, uncheck bAimToInteract". Be sure to adjust the InteractDistance and set MaxTriggerCount to 0 if you want it to be triggered an infinite amount of times.
touch checks for the player colliding with the trigger and entering the volume. I am, in fact, going to use a triggervolume with this event, but I want to check if a player is pressing the [use] key while in the volume.
Also, bAimToInteract... seems to be broken. You don't need to be looking directly at the trigger, but you still need to have it in your 180 degree field of view. This is a far cry from the "simple radius check" that the tooltip says it does.
Also, bAimToInteract... seems to be broken. You don't need to be looking directly at the trigger, but you still need to have it in your 180 degree field of view. This is a far cry from the "simple radius check" that the tooltip says it does.
Last edited:
How late was it when I posted my original response?
I meant to type "Used", forgive my whatever...
Yes, but as I said, bAimToInteract doesn't completely work. It will not fire if the trigger is behind me (that is, my 180 degree FOV), only if it is in front of me.
So, I need to detect keypresses without a trigger (or possibly something like a "UseTriggerVolume"- fires if a player inside it presses the use key).
What I'm trying to do is have teleporters that need to be used, that will be invisible until the player enters them. A PostProcessVolume will tell the player he is inside the teleporter, and he can press the use key to teleport.
The problem is, a trigger with a use event is the only way to check for keypresses of the use key. TriggerVolumes can't be 'used'. I need to check if: the player is in the PostProcessVolume (which can be done using an identical TriggerVolume with a touch event), and if he's pressing the use key.
at the moment the only way to do this is to place triggers around the volume, and check for both conditions (in volume & using trigger). Mathematically, the minimum I could use, so that the player can see at least one at all times from inside the volume, is four: forming a tetrahedron with the spherical TriggerVolume inscribed inside it. Four triggers for each teleporter (actually eight- they're two-way) is doable but it takes a lot of Kismet. I'm hoping there's a tidier way I can do this- it should not be so hard to check for keypresses with a system as powerful as Kismet!
I've checked, and it seems like the easiest way to do this is make a custom Event using Uscript, which triggers every time a player presses the [use] key, and passes the player into Kismet as the instigator variable.
Holy crap, I didn't realize I'd written so much. Sorry 'bout that.
So, I need to detect keypresses without a trigger (or possibly something like a "UseTriggerVolume"- fires if a player inside it presses the use key).
What I'm trying to do is have teleporters that need to be used, that will be invisible until the player enters them. A PostProcessVolume will tell the player he is inside the teleporter, and he can press the use key to teleport.
The problem is, a trigger with a use event is the only way to check for keypresses of the use key. TriggerVolumes can't be 'used'. I need to check if: the player is in the PostProcessVolume (which can be done using an identical TriggerVolume with a touch event), and if he's pressing the use key.
at the moment the only way to do this is to place triggers around the volume, and check for both conditions (in volume & using trigger). Mathematically, the minimum I could use, so that the player can see at least one at all times from inside the volume, is four: forming a tetrahedron with the spherical TriggerVolume inscribed inside it. Four triggers for each teleporter (actually eight- they're two-way) is doable but it takes a lot of Kismet. I'm hoping there's a tidier way I can do this- it should not be so hard to check for keypresses with a system as powerful as Kismet!
I've checked, and it seems like the easiest way to do this is make a custom Event using Uscript, which triggers every time a player presses the [use] key, and passes the player into Kismet as the instigator variable.
Holy crap, I didn't realize I'd written so much. Sorry 'bout that.
Last edited:
Hmmm, since I originally state the wrong type of Trigger Event, I presumed you tried it with at "Touch" event.
But with a "Used" event, it works just fine (at least in my test map). In the tool tips, if it's "False" or unchecked, the simple radius of the trigger (either the actor a volume) will be used, which is correct.
So, I need to detect keypresses without a trigger (or possibly something like a "UseTriggerVolume"- fires if a player inside it presses the use key).
What I'm trying to do is have teleporters that need to be used, that will be invisible until the player enters them. A PostProcessVolume will tell the player he is inside the teleporter, and he can press the use key to teleport.
The problem is, a trigger with a use event is the only way to check for keypresses of the use key. TriggerVolumes can't be 'used'. I need to check if: the player is in the PostProcessVolume (which can be done using an identical TriggerVolume with a touch event), and if he's pressing the use key.
at the moment the only way to do this is to place triggers around the volume, and check for both conditions (in volume & using trigger). Mathematically, the minimum I could use, so that the player can see at least one at all times from inside the volume, is four: forming a tetrahedron with the spherical TriggerVolume inscribed inside it. Four triggers for each teleporter (actually eight- they're two-way) is doable but it takes a lot of Kismet. I'm hoping there's a tidier way I can do this- it should not be so hard to check for keypresses with a system as powerful as Kismet!
I've checked, and it seems like the easiest way to do this is make a custom Event using Uscript, which triggers every time a player presses the [use] key, and passes the player into Kismet as the instigator variable.
Holy crap, I didn't realize I'd written so much. Sorry 'bout that.
LOL, I don't mind the verbiage, as long as you are communicating.
Depending on how exact you need to have the space in which the player must stand in to activate the teleport, try this...
1. Place 1 standard trigger. Open it's properties, expand the Collision section, then CollisionComponent. Scroll down and adjust CollosionHeight and CollisionRadius as needed (hopefully this will allow you to tweak it to fit well enough into your PP volume). You can press the "C" key to seee the actual radius in the editor.
2. Select the actor, go to Kismet and add a "New Event Using Tigger_#", then select "Used" from the sub-menu.
3. In the event trigger node's properties you just created, uncheck bAimToInteract, set MaxTriggerCount to "0" if you want it to be triggered forever and you might have to adjust the value for InteractDistance. I don't know if this will over ride the actual collision radius of the trigger.
Keep in mind that if you check bAimToInteract, I think your crosshairs have to actually be aiming at the trigger. This is used if you have a control panel type mesh that you want the player to "use" to activate the trigger.
Hopefully, I am clear and accurate and that it helps.
I've been trying to get this to work for two weeks now, and even with bAimToInteract disabled, i definitely have to be "looking" at the trigger.
bAimToInteract certainly makes a difference; if it's enabled, I need to have it roughly in the center of my screen. But even when it's disabled, the trigger won't fire if it's behind my 180 degree field of view, like so:
This has nothing to do with the radius, as I set the collision radius and InteractDistance to 1024. This is definitely caused by a problem with the trigger being behind the player.
Crap, it's 4 AM again, I need sleep...zzzzzzz
bAimToInteract certainly makes a difference; if it's enabled, I need to have it roughly in the center of my screen. But even when it's disabled, the trigger won't fire if it's behind my 180 degree field of view, like so:
This has nothing to do with the radius, as I set the collision radius and InteractDistance to 1024. This is definitely caused by a problem with the trigger being behind the player.
Crap, it's 4 AM again, I need sleep...zzzzzzz
I've been trying to get this to work for two weeks now, and even with bAimToInteract disabled, i definitely have to be "looking" at the trigger.
bAimToInteract certainly makes a difference; if it's enabled, I need to have it roughly in the center of my screen. But even when it's disabled, the trigger won't fire if it's behind my 180 degree field of view, like so:
This has nothing to do with the radius, as I set the collision radius and InteractDistance to 1024. This is definitely caused by a problem with the trigger being behind the player.
Crap, it's 4 AM again, I need sleep...zzzzzzz
LOL, nice diagram. After more careful testing (as you have already done), it seems like that Kismet node isn't working as advertised. In my initial testing, I couldn't see the trigger visibly, but I wasn't facing 180 away (like in your picture).
Unless there is another way, I guess you will have to use multiple triggers will a carefully selected radius and positioning.
Yep. Unfortunately, Kismet has no way to check in the middle of one event whether another event has been triggered; so my four-trigger-tetrahedron approach is long, complicated and probably full of bugs. It seems like I'll need some UScript after all.