It’s been a couple years since i looked at and it looks like it’s progressed a lot so nice work. However i never did end up using it as it seemed a bit bulky and confusing when all i wanted was a solid fps ready template. I was wondering if the guides could now be updated to be more clear and the plugin get more simple plug and play options for turning on and off features?
Am i supposed to compile the plugin and go through all visual basic setup and stuff or can it just run as a off the templete demo?
To be honest i miss some of the old templates we had as they were simple blueprints. The basic unreal vr template doesn’t do standard teleport (stick turning is weird) and comfort snapping otherwise id use it for basic projects. Though really id love it if now vr is more mature someone could create a solid template with most of the standard options, weapons and hand physics of half life alyx.
we started to use your plugin to develop a multiplayer VR game and even if we are still early in the development, I would like to thank you for the amazing work you put in the plugin.
I have one question though:
I created a character class which inherits from AVRCharacter and I updated your code to allow me to create a skeletal mesh, because we’d like to have a 3d rendering of the other players.
I attached that skeletal mesh to the VRRootReference component, and added a negative vertical offset to it so that the feet are at the bottom of the capsule.
The issue I face right now (using an oculus touch) is when I see in game another character, the capsule is correctly grounded, but the skeletal mesh is floating in the air.
Would you have any idea of what could be going on there?
Also not sure if is a bug on my end or in the plugin, but on the new 4.25, for some reason connecting clients cannot use any form of mouse input.
only happens after “on possess” is called … If the client joins as their own pawn it works fine…
But if they spawn clean, as just a controller, and spawn an actor to posses, then mouse input is permanently broken. At some point with enough fiddling, I managed to get a crash that pointed to line, which seems relevant (120) VRBaseCharacter.cpp
I am using the set tracking origin -> Stage (Centered Around Play Area)" which works perfectly to align a my ground plane to a real world play area with the exact dimensions - with oculus quest.
function gets called when entering the game and the players VR position matches the exact location in real world.
However, with the VR expansion character I noticed an offset after stepping out of the play area and re-entering it an so far the only way is to restart the game. (The boundary itself still matches perfectly but the level kind of drifted…)
did not happen with the UE standard pawn and I was wondering if might be related to the way of how the VR pawn actually moves while the standard pawn only moves it’s components?
Is there a way to prevent offset from happening?
Looks like the VR pawn keeps moving for a short distance before stopping / “leaving the game” and on re-entering the position kind of continues but with an offset…
Climbing function through hand succeeded in producing results above the intended level. But the problem is that the object, not the hand, is physics handling. The hand and object have different criteria to trigger on, and in the case of an object, the direction in which climbings should be allowed varies depending on the shape it occurs. Therefore, a very diverse number of cases must be considered. So I try to find a simpler solution other than one, but I don’t have a good idea. What do you think?
And how do I apply gravity in climbing mode? I tried to modify the code, but only the result of zero gravity came out.
I’m guessing that using the VR Expansion plugin is not really for beginners. I have looked at some of the videos, and quite frankly I’m confused. I managed to follow the first one, (after a lot of head scratching with why my copy of Visual Studio wouldn’t work), but then video 2 onwards were clearly meant for someone with a working knowledge of the system. For example in video 2. “4.24 Input changes”, I was lost as soon as he said he migrated things from his original project to the demo. I tried to copy that, it copied the folders over but not the contents, even if I selected the contents separately. (I have migrated things before but foxed me). For me, as a beginner, I would have put locomotion before gripping, simply so I could walk up to the objects first. I haven’t watched all the videos yet but I have seen nothing that explains to me how to prevent my character walking through walls, collision. A lot of info needed for a beginner was skipped over, I presume is because, as I said its not really for a beginner.
Don’t get me wrong, I’m not knocking what the plugin can do. I can see from the demo what it can achieve but trying to understand how to add those functions to my own scene/character is another matter. All I would like to achieve at the present time is to enable my character to move around, interact with things (like pick up a lamp), and NOT walk through walls. I had the plugin recommended to me because it could achieve those things, but as I said, I’m a beginner, and really is way over my head.
Lol. I guess I still need my hand holding while I learn. Eventually will all make sense to me and I will look back and say, “why was a problem?”, but until then, I guess Im not going to to solve how to not walk through walls or climb stairs. Sorry for my ramblings. I’m just frustrated I cant achieve what I thought should be an easy task
ok I think I found the issue but I am not sure why happens.
In 3d, my play area is about 20cm elevated and I set up a plane to prevent the player actor from falling down. I am not 100% sure but it looks like the VR expansion character gets stuck for a moment while returning to the play area and small “hang” generates the offset to previously matched play area. I removed the elevation and after the problem disappeared…
Yeah is the thing thats a little bit of a let down with great vr expansion it doesn’t have a plug and play mode or simple switching on and off features. Id really like to now see a half life alyx fps ready type template we can all easily use to get going without the complexity or needing to go though many guides which there are few of with one anyway.
The VRCharacter has its zero point at the floor, unlike normal characters which have their feet at waist height. is done because it makes more sense to handle roomscale that way, and because it makes more sense in general with VR. Just offset your mesh, also typically your mesh should be attached to the ParentRelativeComponent with it set to floor mode instead of the root capsule directly.
Shouldn’t have anything to do with the plugin unless I missed a super call somewhere, and then you would never have mouse input at all.
That line in VRBaseCharacter is unrelated as it is just casting the character type for future reference, though I would like a copy of that crash report if you get it again, cast shouldn’t crash there.
Don’t have the character movement component in “physwalking” or any mode that allows push back. The way it handles movement with CMC is it rewinds the HMD movements and plays them back during the actual walking cycle, leaving tracking entirely can offset the character since it will register the loss of tracking as invalid movement inputs and freeze the pawn for that duration.
Having the character in movement mode “none” will keep it locked 1:1 with the real world. Though at that point there isn’t much point to using the VRCharacter itself and a basic pawn with the grip controllers would do just as well.
You can manually lock the hand to the surface if you want and track the controller vs it, or use physical arms, or any other methods that you like.
As for gravity during climbing, just apply a offset with the custom movement addition as well to equal gravity. Though you have to be careful with that as it will offset your hand more and cause more of a correction the next tick, depending on how you handle the compensation logic.
You have been complaining about the same things with every single template in engine for YEARS now. Maybe its time for you to buckle down and either really learn the engine, or start modding Alyx with their mod tools. Expecting everything to be plug and play fully complete, with brand new game features matching AAA and without any learning curve is moderately ridiculous, and rather entirely against the entire point of why I (and others with their tools) choose to make flexible systems where a lot of interactions are possible, instead of focusing on blindly recreating the FOTM game.
My goal isn’t to make your games for you, it is to provide you with as many tools as I can so that making them is easier. I stay away from specific game play systems as much as possible as its limiting my work to the specific few that need them, and locking down innovation. Plug and play game systems are generally terrible, either too feature rich to handle any case (slow) or handling only one or two specific cases that the creator felt was needed (inflexible and limited).
I take care to mention decently often, no its not a beginners plugin, it taps into a hundred base engine classes and most parts of the engine at point. Its to help people with advanced interactions, either as an implementation example, or as a set of tools to use. That being said, its not beginner hostile, just has a bit of a curb to step up to.
The tutorial videos were made by a community member as he himself was learning the plugin, he documented his learning process by example. The text tutorial for basic gripping on the website, using the VRCharacter as your base pawn, and adding movement input like a normal character, would be enough to get off the ground with what features you described above.
I think you should hire a programer if you find it too difficult to code. The plugin itself is very good, it offers a lot of tools to help developers. You should stop complaining and focus on learning, because game development is really hard work. What’s more amazing when you have a free plugin, the plugin creator is always ready to answer questions and support, and you can go to the source code to read, to learn whenever you want.
It’s because the whole point of these is to make basic game play easy and mostly ready to use otherwise it kind of defeats the point surely?
It’s been done successfully before like UVRF handpresence for example so why can’t you here? Sadly many templates are now unsupported with bugs and are showing their age. If instead of replying to a hundreds of questions you instead created some proper guides you might not have to waste time as you seem to with comments like these. Other contributors on the forum manage to just fine and you’ve had years.
I think I’ve been reasonable in both praising and criticizing particular plugin and am just giving some fair feedback. Really if at the end of the day if you’re so great at coding such complex features then it can’t be hard to make some easy ready made modes and switches for what we’re asking?
If getting an epic grant and supporting the vr community was your goal then that should include non programmers and artists as well to be fair.
Like others I’ve been giving some reasonable feedback and im not a programmer nor would i hire one for little projects. If you think that’s the answer then it’s more a criticism on the creator not the users.
The Epic Grant, while appreciated, was not my goal, my goal was a robust back end for people to build on top of or reference for advanced VR projects. There is room for people to bake in easier front ends on top of that, but I don’t feel like that is my job or a requirement of me. I understand your frustration, I’ve had artists want to use it before that were confused, but I have limited free time (I have a full time job and family, is my hobby), and extending the core plugin and helping the majority of my users comes first, I also do not want to create game templates for people, and basic gameplay “ready and easy to use” is also not my goal.
Who defines “basic gameplay”? Is it the musical experience developer? The VR RTS developer? The FPS creator? What is your definition of “Basic gameplay”? Alyx? It would be arguable that there is a lot that is wrong with Alyx’s gameplay, story aside, and i’d rather that developers make up their own gameplay, tight and clean and only with what they need.
UVRF did bake a lot of prefab stuff into it, and thats cool and it helped a lot of developers out, but at the same time now a lot of them are stuck asking for additional features that the developer doesn’t have the time to add in himself, UVRF’s template IS UVRF, there is no backend and anything beyond what is exampled still needs to be implemented by the end user.
I’m still confused about exactly what you even want “done for you” here, the character is setup to perform much like a normal engine character in as many ways as I could do it.
Documentation is definitely somewhat lacking in areas, but you aren’t really asking for documentation of the plugin here, you are asking for tutorials for game mechanics and full prefab gameplay systems.
I could see the case for a “simple template” that is just basics implemented without multiplayer and without any extra mechanics. But then it also has to be maintained alongside the main one, and again where do you cutoff the feature list for that?
In the end I think your confusion comes from thinking of the “plugin” as a “template”, while I think of the plugin as an “SDK”, with the example template as examples of how to use the SDK.
I’ve been working on implementing a custom static mesh to your grasping alyx hands and have been running into issues similar to ones I’ve read on here before. I’ve got the right one working really well but the left one is giving me troubles. I’m aware of the issues with inversely scaled hands so I’ve been just trying to edit the GraspingHand_Left blueprint with my own custom meshes but not having luck.
What is the proper workflow for setting up a custom mesh with them? I saw that you had a community member mirror the hand, is something you can do in Engine or was the mesh mirrored in Blender or something and reimported as a whole new object? Would doing mirror the bones, animations, and collision physics?
Also I saw you mentioned before enabling mirroring on the left hand, I can’t seem to find that option anywhere.
I reverted back so I’m not sure i can get that specific crash again… I’ll let you know if I run into it again… For now I have duct taped a solution together… Works fairly well for now… Will let you know if anything else comes up…
Going back to melee weaponry…
Wanted your opinion on how you would handle weapon gripping on NPC’s… Since they shared the same character base as the vr character on our project, would it be viable to let them artificially use the inherited motion controllers attached to their hands, to “grip” their weapons, therefore allowing the player to parry their swords/melee weapons around…
However I was thinking the weapon would be gripped to the Hand, but the IK of the hand would also have to grip and follow the sword’s movement as it gets pushed around by the player, would cause an infinite loop between the two moving each other I’m guessing…
Was there a better way to handle ? I couldn’t find too much useful info on how Blade n Sorcery handled it on their end… The default way would be just to attach the object to their hand and set physics on, but it doesn’t sound like it would let the player push the enemies blade around.
Hi all,
may very well have been covered before in thread but it is very long and I haven’t been able to search for it effectively, so I apologize if it has been covered.
I’ve encountered plugin in a project I’m working on (I didn’t implement), and I am experiencing a problem with HMD position replicating across the network ( functions fine), causing the local position to jitter at high ping. I am under the impression from some of the code paths in UReplicatedVRCameraComponent that the sending client should not use replicated values, yet that does appear to be happening (the higher the ping the more jitter when laterally moving the headset). Turning off replication on the component results in no lateral movement of the HMD in the world. Is expected behaviour for the plugin? I would have expected the local player would always update using the transform given by the HMD. Could it be that there is some sort of authoritative HMD position flag somewhere?
Also the code is based on plugin version 4.22 and there have been modifications to it within the project, so fully willing to accept that is not a plugin issue, I just want to establish what the plugin *should *be doing, if possible.
If you aren’t using physical hands then it is a non issue, you can simply spawn another right hand with the scale inversed and it should work as is. Its when simulating that it gets to be a big deal since the engine incorrectly translates the collision and orientation of the object when constructing its simulating body.
I would consider using the animation mirroring plugin to make life easier for you, it should be able to work with a left hand setup if I read his feature list correctly. Other than that, yeah you would have to have a new AnimBP for a mirrored hand, the one in the template is actually incorrectly mirrored and has a bit of an offset and one of the animations is lined up incorrectly, mirroring the actual right hand over and keeping the same facing would probably work best.
In the end the seperate manniquin hand isn’t ideal in the first place since its pointing Y+ with some pitch, an X+ version would be easier to manage,
However i never did end up using it as it seemed a bit bulky and confusing when all i wanted was a solid fps ready template. I was wondering if the guides could now be updated to be more clear and the plugin get more simple plug and play options for turning on and off features?