whats the benefit of 4.17 right now?
Announcement
Collapse
No announcement yet.
VR Expansion Plugin
Collapse
X
-
Originally posted by Starkium View Postwhats the benefit of 4.17 right now?
Knuckles support
Some fixes
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Originally posted by mordentral View PostIf you are using 4.16 for 4.17 I don't think the project should even compile though, I had to change multiple things.
Code: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'.
thx!
Comment
-
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:
Code:{ "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 } ] }
Comment
-
Originally posted by Curs0 View PostNope, got latest 4.17 sources from master branch yesterday and same result from VS or ue build tool
Code: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'.
thx!
Originally posted by MaSe87 View PostJust 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.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Pushed a new commit to the repository
Code: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++.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
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?
Comment
-
Originally posted by Ecnassianer View PostI'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?
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
Code: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)
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.Last edited by mordentral; 08-11-2017, 09:14 AM.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
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.
Code:OnUsedEvent - Type Of use (Start, Stop, ect) - Identifier (Primary, Secondary, Custom1, ect).
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.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Originally posted by mordentral View Post#1: Switch the Interface OnUsed / EndUsed / OnUsed Secondary / EndUsed Secondary events into a singular event instead with enums and more flexibility.
If you u plan to upgrade it, pls keep current interface alive
Comment
-
Originally posted by Curs0 View PostWe'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
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.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
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?
Comment
Comment