VR Expansion Plugin

[Starkium]

whats the benefit of 4.17 right now?

[mordentral]

whats the benefit of 4.17 right now?

The spectator / mixed reality / async multiplayer features.

Knuckles support

Some fixes

[Curs0]

If you are using 4.16 for 4.17 I don't think the project should even compile though, I had to change multiple things.

Nope, got latest 4.17 sources from master branch yesterday and same result from VS or ue build tool

2>EXEC : warning : Plugin 'AdvancedSessions' does not list plugin 'OnlineSubsystem' as a dependency, but module 'AdvancedSessions' depends on 'OnlineSubsystem'.
2>EXEC : warning : Plugin 'AdvancedSessions' does not list plugin 'OnlineSubsystemUtils' as a dependency, but module 'AdvancedSessions' depends on 'OnlineSubsystemUtils'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystem' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystem'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystemUtils' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystemUtils'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'AdvancedSessions' as a dependency, but module 'AdvancedSteamSessions' depends on 'AdvancedSessions'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystemSteam' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystemSteam'.

Any suggestions?
thx!

[MaSe87]

Just modify the .uplugin file from AdvancedSession and AdvancedSteamSession to add the module dependencies. This is a warning as inter-module dependencies where added in 4.17.

I modified it to silence those warnings:

{    "FileVersion" : 3,
 
    "FriendlyName" : "Advanced Sessions",
    "Version" : 1.9,
    "VersionName": "1.9",
    "Description" : "Adds new blueprint functions to handle more advanced session operations.",
    "Category" : "Advanced Sessions Plugin",
    "CreatedBy" : "Joshua Statzer",
    "CreatedByURL" : "N/A",


  "Modules": [
    {
      "Name": "AdvancedSessions",
      "Type": "RunTime",
      "LoadingPhase": "PreDefault"
    }
  ],
  "Plugins": [
    {
      "Name": "OnlineSubsystem",
      "Enabled": true
    },
    {
      "Name": "OnlineSubsystemUtils",
      "Enabled": true
    }
  ]
}

[mordentral]

Nope, got latest 4.17 sources from master branch yesterday and same result from VS or ue build tool

2>EXEC : warning : Plugin 'AdvancedSessions' does not list plugin 'OnlineSubsystem' as a dependency, but module 'AdvancedSessions' depends on 'OnlineSubsystem'.
2>EXEC : warning : Plugin 'AdvancedSessions' does not list plugin 'OnlineSubsystemUtils' as a dependency, but module 'AdvancedSessions' depends on 'OnlineSubsystemUtils'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystem' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystem'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystemUtils' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystemUtils'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'AdvancedSessions' as a dependency, but module 'AdvancedSteamSessions' depends on 'AdvancedSessions'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystemSteam' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystemSteam'.

Any suggestions?
thx!

Yeah a file had missed the commit, I added it back in last night, you can re-download.

Just modify the .uplugin file from AdvancedSession and AdvancedSteamSession to add the module dependencies. This is a warning as inter-module dependencies where added in 4.17.

I modified it to silence those warnings:

Yeah I had it fixed on my end since preview 1, but the uplugin didn't get committed. Its in there now.

The pre-packaged binaries should be without the warning as they were off of my local copy.

[mordentral]

Pushed a new commit to the repository

Some VRDial component fixes / re-implementations, should be functional now and out of 
"beta".

Likely needs some additional features and clean-up in the future.
This makes it: Button, Lever, Dial being at least initially done remaking to c++.

[Ecnassianer]

I'm using the Procedural Bridges Template to create bridges for the player to walk over. The bridges are a core part of my project, so I don't want them to be simple static meshes. The Procedural Bridges are made of a bunch of meshes linked together by physics constraints. Each mesh plank simulates physics and you end up with an awesome wobbly rope bridge.

I'm using VivePawn from the template, and in order to get the pawn to stand on the bridges, I have to disable Ignore Simulating Components. Unfortunately this causes the pawn to jitter while it's on the bridge. It's not too extreme to make it unplayable, but I'd like to fix it. Is there a way to resolve this jitter without ignoring interactions with simulated components?

[mordentral]

I'm using the Procedural Bridges Template to create bridges for the player to walk over. The bridges are a core part of my project, so I don't want them to be simple static meshes. The Procedural Bridges are made of a bunch of meshes linked together by physics constraints. Each mesh plank simulates physics and you end up with an awesome wobbly rope bridge.

I'm using VivePawn from the template, and in order to get the pawn to stand on the bridges, I have to disable Ignore Simulating Components. Unfortunately this causes the pawn to jitter while it's on the bridge. It's not too extreme to make it unplayable, but I'd like to fix it. Is there a way to resolve this jitter without ignoring interactions with simulated components?

I mean...you are placing a character on a "wobbly" surface and trying to have them walk across it. Character movement components don't simulate physics through the physics scene, so they approximate the floor/surface they are standing on and the other physics object is supposed to move out of the way. You are always going to get some unpredictability with simulating components and a movement component, you can try increasing the strength of the constraints so they hold the players mass better and it doesn't have to adjust to the surface as often. Its made worse by the fact that the capsule retains Z up orientation so when the bridge tilts the character does not.

Sounds like a true vomit simulator though having a swaying bridge.

You can try using the "flat bottom" setting on the movement component, it doesn't treat the bottom of the capsule as a radius's cylinder, you may get less jitter that way.


I'll note that the package you are using has the option to turn off simulation, that may be better.

*Edit* A video of the jitter you are experiencing would be helpful, you never know, maybe I can do something about it. Did you try it with an FPS character as well and see if it had similar behavior?

Also you could try playing with the "Impart Velocity" settings for the character movement components

Public variable	uint32 : 1 	bImpartBaseAngularVelocity	If true, impart the base component's tangential components of angular velocity when jumping or falling off it.
Public variable	uint32 : 1 	bImpartBaseVelocityX	If true, impart the base actor's X velocity when falling off it (which includes jumping)
Public variable	uint32 : 1 	bImpartBaseVelocityY	If true, impart the base actor's Y velocity when falling off it (which includes jumping)
Public variable	uint32 : 1 	bImpartBaseVelocityZ	If true, impart the base actor's Z velocity when falling off it (which includes jumping)

*ReEdit*

Yeah I was curious enough to check the base project you are using, even third / first person characters are effected, the bridge is not in any way stable and has some massive jitter from badly set physics constraints.

The blueprints and/or method being used needs some changes, though flat based movement component for find floor DOES help, it doesn't fix the most unstable parts of the bridge (upswing / downswing jitter from low damping constraints). Also the extra rope "bridges" are conflicting / colliding at one point in the default one making the second to last planks jitter very badly.

Its likely that you just didn't notice the jitter before being in VR because it wouldn't seem as extreme on the monitor, while in VR that up/down motion is going to be very noticeable.

[Curs0]

Yeah a file had missed the commit, I added it back in last night, you can re-download.

no warnings at all, many thanks

[mordentral]

I have a few sweeping changes that I would like to make to the plugin to make it more fluid. I have been holding back on them because it would cause people to have to re-do parts of their projects in order to switch to the new setups. Figured I would throw what I would "like" to do in here, with the up and downsides to it and then get feedback on if its worth the pain of transitioning projects to the new methods.

All of these are things that can totally stay "as is" without hurting things too much, however I keep them on my personal list of "Hate" due to either being outdated with new features that have been added, or just not being as robust as I would like now that the plugin has matured more.


#1: Switch the Interface OnUsed / EndUsed / OnUsed Secondary / EndUsed Secondary events into a singular event instead with enums and more flexibility.

OnUsedEvent - Type Of use (Start, Stop, ect) - Identifier (Primary, Secondary, Custom1, ect).

Upsides:
More input possibilities into interfaced objects without custom interfaces or casting,
more flexibility,
a smaller less bloated interface signature (one event instead of 4)

Downsides:
All current uses of OnUsed and OnEndUsed would have to be switched over to the new format.



#2: Switch the bIsInteractible boolean into a custom nested struct

Upsides:
During initial grip info replication none of the interactible settings would replicate unless the boolean is ticked to true, this would save on load up bandwidth,
I could more directly control replication of these items,

Downsides:
All interactible objects would need to have references to the boolean re-set as it would move,
All interactible settings would need to be re-made




#3: Change Initial/Min/Max interactible settings location variables to a compressed form

Upsides:
Would greatly lower bandwidth when sending them

Downsides:
I already tried this once, the editor does not recognize them as being the same base type and all current settings are lost and would have to be re-entered.


*Note: If done at once, #2 and #3's downsides would all happen at once since they overlap and would be less painful *




#4 (Extreme, not likely, but wishful): Entirely remove the interaction settings

Why:
Now with the custom grip and the c++ Button, Dial, Lever there is actually very little reason to retain the old interactible settings, they are essentially outdated.
All of their functionality can be re-created with a custom grip, and with more fine grained control over how they behave (though requiring some more work).


Upsides:
Far less grip structure bloat,
Far less replicated variables,
A faster tick on the Motion controllers as they don't have to check for bIsInteractible every time using an interface call,
I would be forced to basically finish the c++ versions and make slides / drawers and the like to cover what would be then missing.

Downsides:
No more entering a few variables for working drawers and sliders, would have to use base classes that I make or make your own using the custom grip (not hard to do though),
All current objects that rely on interactible settings would need re-made.

[Curs0]

#1: Switch the Interface OnUsed / EndUsed / OnUsed Secondary / EndUsed Secondary events into a singular event instead with enums and more flexibility.

We're using only core functionalities of your plugin and that would be a lot of rework with no pros at all
If you u plan to upgrade it, pls keep current interface alive

[mordentral]

We're using only core functionalities of your plugin and that would be a lot of rework with no pros at all
If you u plan to upgrade it, pls keep current interface alive

As in you don't use the Onused events? Or as in you don't need the extra options the re-work would provide?

Because if I did "upgrade it" I can't keep the current interface as is, it would be besides the point.




If you don't use the OnUsed events, and you don't have c++ classes implementing the interface, then it would be no work at all.

[Curs0]

we definitely use "on used/end used/etc" events and we don't need extra function that new interface would provide
this our opinion btw

[IslandPlaya]

I'm in-between projects which gives me the luxury of a little time. I fully support Mordentral making all 4 of the proposed changes.
No pain, no gain.

[Lobohotpants]

I'm trying to create my own grippable actor and I'm having trouble with the socket snapping. Everything else works and I can't seem to figure out where and how to apply the socket information. I read the wiki and I don't understand where the grip function happens. With context sensitive on the grip function doesn't appear for any of the components I try to add it to. Did I miss an example in the project? Can anybody point me in the right direction?