“In 2D, I have a function setup so that if I am not specifically launching in VRPreview then it uses a copy of my character with the head and hands locked (ie acts like a normal character).”
Yeah I get what you are saying, we have a similar “KMS mode” setup that runs if HMD is not connected. Is yours available in the template/example project that’s currently available?
“See above but set client or server to non vr mode, can launch from uproject without packaging for local testing”
You mean running the editor from the cmd like “…UE4Editor.exe” “C:\Users\vr\Documents\Unreal Projects\NextStep\myproject.uproject” 10.100.102.2 -game -fullscreen -log -nosteam"?
And do you actually run your multiplayer testing way as well, having clients/server all run on a single workstation?
“You appear to have some more complicated movement systems in your game”
Even though it comes off as being complicated, I’m hoping it should be not too complicated to pull off in multiplayer, since it’s mostly navigation which by itself is predictable and should be able to run almost completely on the client side (once a path has been calculated on the server).
However since I’ve completely ignored the character movement component in my implementation (I mainly use the “set location along spline” + “Set actor location”, more or less) and so completely ignores not only physics (which we handle artificially), it will also not be able to take advantage of the built in network features such as correction etc.
Needless to say, I manually handle the whole syncing of the “character location relative to camera/HMD offset location etc.” logic myself.
That’s why I was looking in to your implementation as it seems to almost magically combine the best of both worlds. Correct me if I’m wrong but using the “navigation” locomotion option you displayed I could achieve a similar result, at least for walking around.
For the jumping I would have to choose between the physics approach which you use and a “spline movement” approach which we currently make use of
In any case I’ve downloaded the example project along with the plugin and will be trying it out and playing around with it asap.
Yeah you can connect to local machine servers with -nosteam and Open command or lan sessions.
The navigation setup I have is a bit different, you likely use an AI controller, I don’t, I just moved some of the AI controller functions into the player character so that I could navigate in there. However something you would want to consider is that with the default navigation in engine the navigation is server sided only. In my plugin I specifically send an additional variable to the server from the movement component so that client sided navigation is also possible in engine.
Quick question: I have a bow in my game and until recently I was able to modify the rotation of the bow (while gripped in “Physics Only”) just by setting the world and local rotation in the bow blueprint every tick, but since 4.16.2 won’t work anymore. It’s like the grip is resetting the rotation every tick. The blueprint object is just a static mesh actor.
Do you have any idea what might be happening? In grip mode “Hybrid” it applies the rotation correctly.
The only reason that worked is because the tick order of the controllers was before the tick event you were using in blueprint, so your tick ordering is off. There is nothing specific to the grip that changed on my end that would effect that and even if epic changed something I am not aware on in 4.16.2 you should still be able to overwrite rotation when the tick happens after the initial movement.
You have a few options
Switch the primary tick of the blueprint to post physics (controllers are pre-physics so they tick prior to that)…not the best option as any physics collisions would be 1 tick behind.
Add a TickPrerequisite of the controller to the object after it is gripped (forces it to tick after the controller), you would then get reliable tick ordering, is easy and you could keep your current logic.
Use the AdditionTransform to handle the rotation directly in the gripping system and without having to overwrite anything.
Edit I just remembered that the tick preres is already automatically being set on grip so that actor tick has the correct locations, so that should already be working.
I will also note that there is little to no reason to even be using a managed grip if you are already setting the location and rotation on each tick, you would be better off using the “Custom” grip type and moving the bow in the TickGrip event. would bypass all of the logic that you are already throwing out making it less intensive and also giving you complete control over the movements.
Actually I just use the navmesh to calculate the waypoints then I handle the navigation myself instead of using the engine’s NavMeshWalking - I do it by generating a spline from the waypoints and walking it as my path.
Tickgrip event is in the object itself that has the interface implemented. That way people can do the exact same logic they used with epics grip but using plugin.
Also were you doing something weird like attching the bow manually or something?the grip function should be adding that tick preres automatically.
Edit Actually are you gripping the bow as a component and moving it in the actors tick? That would explain it actually as I only set the tick pre-res for the gripped object.
Oh Ok, I just found it thanks! I will try to change the current approach and change it to a custom grip, it’s a much cleaner solution.
The bow is a static mesh actor, and I grip it with the grip motion controller component in my pawn using the “Grip Actor” Function. Then in the tick event of the bow actor, I change the world location of the static mesh root component. The reason is that I want to align the bow with both hands while maintaining an upright position. I’m pretty sure there’s a better way to do it though
Is there something I can do (a function or setting) to keep the grip settings “stiff” after I scale down, then up, a gripped actor? Right now the grip becomes loose on the physics constraint after scaling down then back up.
How are you scaling it? Though the addition transform or something else? It sounds like you are some how moving the center of mass. I need to know the steps you are taking so I can see whats going on.
*Edit* also what version / date are you on? I had to fix a bug with the new COM on grip setting and scaled objects.
Version is the 4.17, whatever was latest as of yesterday.
I was just scaling it using the regular scaling node (Set Actor Scale 3D on the gripped actor) - should I use the additional transform thing instead?
Edit: Weirdly I changed it to re-enable collision after a 0.2s delay instead of immediately after leaving the trigger and it seems to keep the grip settings.
Hey, so there is definitely something off in 4.17 regarding physics bodies. The scaling grip is also running into some weird behaviors that feel like thread sync issues when its a physics grip.
It may be that their changes to the Async collision setup in UBodySetup is causing these problems, as the exact same code in 4.16 has no such problem. Having to delay to re-grip correctly would actually make some sense if the new physics task batching was getting in the way (hasn’t been processed yet).
I’ll check out the new console command they added and see what it changes.
Edit Yeah…so confirmed, the new console command p.BatchPhysXTasks is interfering. Since it is delaying physics tasks until later its not actually resizing the mesh until after you are re-gripping, thats why if you delay the grip it works as expected. Even setting the console command to 1 or 0 (defaults to 1 then) it still behaves worse than in 4.16 as well…
Good to know I’m not crazy. For now the delay is working fine at handling the problem, and the grip stays stiff as expected.
I’ve been having a different problem which is when I have any reference to my backpack blueprint (a grippablestaticmesh) in other blueprints like the player, or vice versa, it causes a crash before the scene loads.
It crashes before a crash log can be made, and it happens if there’s any reference to the backpack BP (so even if it’s just a get all actors of class, or even a child component).
Is there a way to entirely disable the feature that stops you from putting your head through a wall which causes the entire environment to move away from you?
Also is there maybe a way to make the screen go black instead of moving the whole environment? I feel like the whole area moving might cause some motion sickness in other people.
bUseWalkingCollisionOverride lets you control it to only happen when moving with artificial movement. Also it is controlled by the pawn channel so you could just set pawn channel to default overlap and it would never happen period.
As for making the screen go black, yeah you can do that on impact, i’m also adding a boolean next update that you can check for “is currently impacting” as wall or object and do whatever you want with the screen.
