, do you think it would be worthwhile adding some more chaperone components?
To my understanding, at the moment blueprint exposes the 4x vectors of the Chaperone tracked area.
What if the VRexpansionPlugin had a few more components:
-Chaperone ground plane
-Chaperone Wall north
-Chaperone Wall east
-Chaperone wall south
-Chaperone wall west
By north, east, etc, i mean the wall that faces X in positive direction, wall that is along X in negative direction, etc.
The components could be added to the VR pawn and render a plane that is the correct size for that boundary.
I suppose is a very easy task for a programmer to manually create these components based off the chaperone bounds and the height of the base stations, I thought it might be a good addition to the plugin to make user’s lives easier. And is a feature many inexperienced VR developers might find useful in the plugin.
To my understanding, users of the VRExpansionPlugin’s VR Pawns need to account for the way the HMD moves in order to continuously set the Chaperone boundaries in the right location
If users had these components, the users have an easy way to get, parent and place objects on those areas of the chaperone system.
I have one more request regarding the template project on Github.
Could you rearrange the template’s content folder so that everything exists within one top-level folder?
That would match the way projects and assets are delivered on the marketplace and the "Allar ue4-style-guide specs.
That way it’s very straightforward for anyone to migrate the template into a new project. Especially after pulling any updates from Github.
They can just sync with the latest template, and migrate the main top-level folder to their production project, overwriting any assets.
Yeah I intend to get around to that, when starting the template I just imported some of my folders from my demo world and they were split up.
If saving the tracked points / lines out to serialization its possible to keep them between sessions and in the editor yes. I am still mulling over how best to do it, a full procedural mesh or line batches to define areas.
I’ll agree that needs to exist, however I would prefere the full bounds of the tracked space drawn with the controller, not the “square” that is generated as a “safe terrain”. I will have to look into if openVR still provides the HardBounds output or if they locked it to just the softbounds.
Specialized functions like that by the way are likely to only be fleshed in for OpenVR, I do not have the ability to test on the OculusSDK.
I think I have a basic setup for LAN multiplayer done? My team is going to demo our build at SXSW so it wouldn’t need a server browser.
Would you mind if I posted some screenshots of what we did on networking and see if it makes sense/would work?
Use the template blueprint code for switching between fps and VR pawns. It lets you test at least one side of it with a single HMD as long as you have two computers or filter it by server/client as to who uses the HMD. I checked a lot of my multiplayer tests using my wife computer before I packaged it out to friends with vives.
If it has the interface there is an “OnGrip” event that is triggered that passes in the controller gripping it that could be checked for owning actor and/or stored. Otherwise no you’d have to manually check.
Its supposed to be fairly abstract as that is something that I assume the user to know how to handle best for their case and I didn’t want to force base actors.
Merry Christmas ! Just wanted to share a quick video using your plugin. Extremely basic stuff so far but the plugin has made interactions so intuitive. Have learnt heaps so far and hoping to make a lot of progress during holiday break. Thanks again for the fantastic plugin!
Hi , I am spawning an actor on server and on the same frame I grab it with the grip motion controller. works fine on server but on client the attachment never takes place. If I add a a delay after the spawning of the actor the attachment works on clients as well. Am I doing something wrong?
The client may not have the replicated object yet when you are saying that it has been gripped. Replication isn’t guaranteed to be in the order you send them in and the object has to be initialized first. is expected behavior with non attachment “grips”. The client side “GripNotify” function is probably failing due to the object not existing on the client yet.
Thats really cool, looks like you have the grip detection pretty smooth since you were cycling pretty fast there without issues.
Just to be sure, for a game that a client can join at any time and objects are already beign held from other players I should use “attach to” instead of the VrGrip if I want them to be visible as held in that client?
No, if the object is already replicated my plugin checks the array of held objects when it is updated over the network and if it finds a new grip (like if connecting in) then it sets up the grip.
Your issue with instantly spawning and calling grip is that the array of gripped items is probably sent before the actual object is sent over so the client can’t actually grip anything.
Edit I could technically add a flag and check held items for if they have been processed yet every frame but I think gripping after the replication is better (or spawning the object client side instead for things that don’t need to be server side, generally side arms and the like won’t need to be).
Our client is unable to grab anything. Based on our particle effects not showing as well (particle system and light attached to our VRcharacter) Work’s otherwise tho, it tracks the players movement and controllers.
Are you able to grab things client side?
either attached to your client player/spawned in the world
