PROBLEM WITH SPAWNING ON LEVEL RELOAD: if i start Play-In-Editor i spawn at my player start with the correct floor height. but then when my character dies and the map reloads, i am stuck in the floor as though i had set my tracking origin to eye level. i tried messing around with the tracking origin stuff but i couldn’t fix it. once again, when i start play in editor initially everything is fine, but when the node fires to re-open the level, it freezes up for a long time and then i start in the floor. i have tested on multiple levels and tried many things already but no luck.
i want to say thanks. plugin has been extremely helpful. and you and the template has been extremely helpful in allowing me to learn a **** ton about coding for engine, as well as VR. and its a blast. thankyou.
can you by chance point me in the right direction to editing climing so that my grips dont go away when i grab whit the other hand. so i can properly 2 hand climb without my hands disconcerting unless i release the grip
Generally that would be just you locking the mesh in place for one hand. You can decide to run the offset logic in some sort of combination center point between the hands but I wouldn’t suggest it since they can seperate.
You can store both locations and only use the newest one for current grip logic, but it will pull your other hand with you. Think about how it would have to work otherwise, your hands aren’t actually rooted in place in the real world.
Its not a plugin issue, I don’t handle anything specific to re-spawning anywhere. You need to run through your possession code and see whats miss-firing.
Though I do know of something close to that is caused by the splash screen system if you are using a Rift. Some of the textures can lockup the Oculus SDK and you lose tracking, I had someone run into it with the stereo layers too.
i hear that from everyone when i ask about it. but i find it way more jarring when im squeezing a grip and its no longer holding the thing i grabbed. it may be different for vibe, but i know that on my oculus. most games grip and dont release. and to be expecting it to be gripped and held,and its not kills it for me.
and the game i have in mind is very much a climbing game. and every type of climbing game i’ve every played. except for “the climb”. only grips with one hand. and i feel like its bad in way because if you only grip with one hand you fall if you slip. even if im still holding the other hand gripped. the climb may separate your hands from reality. but i feel its better. plus i can do like some and if you get to far, and show a ghost of your hand and a line to point you back where you need to be. and probably give you a heavy vibration and a losing grip notification if you dont put it back where it needs to be.
is all of the climbing confined in the climbing functions.
ill probably try your suggestion on saving the last one and using the primary, and snapping back to the last if primary releases and secondary is still gripped.
I’ll be honest, I don’t think The Climb’s climbing mechanics are very good. More so for roomscale which it wasn’t originally designed for.
Even if you have indicators for correct hand position, the moment you actually start to pull yourself up that static point is lost as it has to shift with the movement. You can require that they use both hands to pull in order to actually move quickly (which would be a better solution and partially solve the issue, one hand = slow, both an the more together they are = fast). However in the end I feel most games go with one hand climb because it is the only method to get true 1:1 motion to movement, which is what makes it so easy to handle from a sickness perspective as well as so much fun.
However yea, you can modify the climbing logic at your will in those functions, the climbing movement move is just a direct movement mode, it doesn’t have to specifically be used for climbing so the logic for climbing in the template is all BP.
Excellent plugin. Being fairly new to UE4 / VR dev, I just have two questions:
1: Collision between an object and the headset - pushing it away, not sure how to disable . Sometimes it won’t collide until I take off the headset and put it back on, then bam, collisions.
2: Is there any plan for a template object that can be grabbed, “attached” to an object, and removed? It would be pretty helpful for kick-starting several things, such as gun magazine reloading, or constructing an object out of multiple pieces (maybe).
1: You can disable collision by either ignoring the collision channel that the object is in, having the object ignore the pawn collision channel, or by turning on WalkingCollisionOverride.
WalkingColllisionOverride sets a seperate collision check when walking in roomscale as opposed to locomotion movement, so you can say, ignore pushback with walls when walking around, but keep it for locomotion.
2: That is kind of gameplay oriented, its literally just an AttachTo node / Detach node. I am not aware of anything specific that I could bring to that outside of an abstracted “socket and bolt” system that is simple to setup and better off made custom in the first place.
I did add some adjustments for in engine attachment to the components and actors that I need to write about somewhere, there are some multiplayer bugs with attachment that I worked around for plugin users in my discord and haven’t done a tutorial video or write up about yet (maybe weekend?).
2.Ps: The template is primarily there to show how to implement plugin features, I reaaaaally like to avoid putting too many gameplay elements into it for several reasons.
- The Matrix Problem: I can’t anticipate every requirement that a game system would need, say if I commit to a gun system then I have to make it generic enough for any gun, and expandable, it is a project in itself to do correctly. Not to mention that there are several marketplace options that I would be shoving around by doing so. If there is an implementation available I would prefer to spend my time somewhere else, I was letting gesturing ride even because the marketplace option is capable, I only ended up implementing it because I felt I could solve some issues and bring some things to the table that other options didn’t. VR is considerably more open ended than most game platforms, I feel that a solid and generic as possible back end serves the greater good more than a well rounded but limited front end.
- Maintaining: Full game features have to be maintained, is just adding on to my limited time to support things that don’t technically have a place in the plugin.
- **Overbloating: **The plugin is already massive, the template is already massive, the more I add to them the harder it is to use or modify them to suite a custom purpose, I feel that I already should be pruning some things instead of adding new ones.
- **The Unity Problem / Setting a standard: **I don’t want to help a bunch of games use the exact same mechanics with the same feel to them, it stagnates progression and lowers creativity.
i agree. i as a new guy my self would even rather be forced to learn so that my game doesn’t feel the same as every other game. and beings im looking at making alot of gun code. i can say how much of the stock gun code i replaced or edited was most of it, just for tweaks but necessary to make the gun feel correct.
that being said im getting in to all stuff and i would like to put in a vote for that tutorial because i like knowledge. and you seem to have alot of it.
ok. so i am incredibly confused. im trying to cast from my climbable trigger to ether of the motion controllers. so far i can only get it to cast to the character. and so it only works if my collision mesh is touching the collision mesh that marks climable. then i can climb anything
Its not the motion controllers themselves overlapping your trigger, it is whatever colliding mesh or collision component you have attached to them.
Hey
You make awsome work, thank you for spending so much time for community.
I have a problem to fix that the controller grip on socket with grippable skeletal mesh, i tryed to fix it with different ways, like COM offset, Mesh/Bone socket, override the Interface function ClosestGripSlotInRange, with SetCenterOfMass or the DoNotSetCOMToGrip in different cobinations.
The hand jumps always to the COM.
My skills in C++ are growing but too small at the moment to fix it in code, in case i must work in BP.
I use UE 4.19 with vrexppluginexample-5b762dcb167d
Do you have a idea to fix issue?
Thank you
New video going over some recent changes and 4.19
Hi .
I wanted to request a small change to make the VR Slider components’ “current slider progress” variable blueprint editable. That is, if it isn’t a difficult change to make for any other reason. Right now you can only get the value from blueprint and not set it. I was wanting to set the slider current progress based on external settings from blueprint if possible.
That actually has been in now for a couple of weeks, but as a node.
https://.bitbucket.io/VRExpansionPlugin/VR/VRSliderComponent/nodes/SetSliderProgress.html
Believe that it is also back ported to 4.18 since it was more stable at the time.
You can actually manually move the slider and Recalculate as well, but is a safe method.
Pushed new commit to the plugin, would appreciate feedback about one if anyone runs into any issues, its a rather large overhaul of some core character functions.
Overrode default engine rollback / client correction code to now pass and verify a rotation
instead of directly accepting the clients rotation every movement.
allows me to rollback rotations and correct for packet loss with rotation based movements.
Something that is not very important in FPS games because rotation is at the zero point but
which is fairly important in offset HMD VR games as any minor rotation offset can cause pretty hefty
locational offsets.
**Added bUseClientControlRotation** to VRCharacterMovementComponent, allows the movement
component to use the legacy behavior of not rolling back rotations (FPS test pawns).
These changes are for the VRCharacter only, the SimpleVRcharacter does not need these
modifications to function. They also need some testing, vehicles specifically could use some testing.
Added MoveAction_SetRotation (For just changing the rotation) and changed the snap turn and teleport
move actions to pass in the end yaw and simulate the movement instead of taking just a location offset.
Added make and conversion nodes for FVector_Netquantize and its variants...since the engine is missing .
Hi,
I’m trying to use the skeletal mesh weapon from the epic templates.
In your example template you use a Static Mesh Actor as a gun.
I tried to duplicate code, however I think your AGrippableSkeletalMeshActor should never work.
At some point GripMotionControllerComponent.cpp calls method:
bool UGripMotionControllerComponent::GripActor( AActor* ActorToGrip, ...
method has check:
root->Mobility != EComponentMobility::Movable
However the root is a Skeletal Mesh Component, which can never be Movable.
I tried setting it Moveable in my blueprint On Construct & BeginPlay (using 's VictoryPlugin has a function for ).
Now that didn’t work, so instead I changed the check to: (did for both GripActor methods)
bool isSkeletalMesh = root->IsA(USkeletalMeshComponent::StaticClass()) || root->IsA(ASkeletalMeshActor::StaticClass()); // Has to be movable to work. Skeletal Mesh can't be movable.
if (!isSkeletalMesh && root->Mobility != EComponentMobility::Movable)
{
UE_LOG(LogVRMotionController, Warning, TEXT("VRGripMotionController tried to grip an actor set to static mobility and bAllowSetMobility is false"));
return false; // It is not movable, can't grip it
}
I also modified the Weapon so that the Skeleton bones are exactly the same as the Static Gun.
In the new skeleton I added the VRGrip sockets. Next to that I created a new Physics asset.
The current status is that the hand now grips the BP Actor that contains the Skeletal Mesh Actor and fire’s the weapon, however the weapon location and rotation are never updated (even though all settings are exact the same as the Static Mesh Gun.
The fire does seem to work.
Note: The drop seems to work, since when the motion controller is moved away the weapon stops fireing.
Concluding:
Grab animations work. (hand open / closed animations are being applied when hovering or grabbed)
Drop works (kinda, the weapon physics don’t seem to be applied (it keeps floating where it spawn), but it stops firing when moving to far from the weapon).
Fire weapon start/stop works.
Location / Rotation do not work for Grippable Skeletal Mesh Actors.
So:
-
Do you have an example using a Skeletal Mesh Weapon?
-
Where is the motion controller rotation/location applied to the grabbed actor?
-
Maybe there is another mobility check I missed.
–Other notes–
I noticed GrippedBoneName, OptionalBoneToGripName and OptionalSnapToSocketName is always None for both Gripable Static / Skeletal Mesh Actors, however socketTrans seems to be set so I guess it’s not really a problem.
I’m currently using VR Example Plugin template of 16-03-2018 (f62d5b04063c091e809a4664d4b5d3c4eabd0d0d)
Hi guys. I downloaded the latest VRExpPluginExample “4.18 locked” project from bitbucket repository and tryied to package it for my PS4 devkit and got critical error:
ERROR: UBT ERROR: Failed to produce item: C:\Users\Administrator\Desktop\VRExpPluginExample\Plugins\VRExpansionPlugin\VRExpansionPlugin\Binaries\PS4\VRExpPluginExample-VRExpansionPlugin-PS4-Shipping.a
Can anyone explain what I need to do to resolve ? Thanks!
EDIT. is was shipping build, on development I got:
ERROR: UBT ERROR: Failed to produce item: C:\Users\Administrator\Desktop\VRExpPluginExample\Plugins\VRExpansionPlugin\VRExpansionPlugin\Binaries\PS4\VRExpPluginExample-VRExpansionPlugin.a
Thank you for your big work!
I want to set custom skybox in the SteamVR (4.18.3).
I’m used OpenVRExpansionPlugin plugin - all is ok in Editor (a little issue with panorama upside down),
but in the packaged project instead any background dark screen.
Please, can you test it or give some advices?
Added a new game to the games list