OTHGMars

Have you seen: and Depending on your engine version, you may be able to use much of that.

There are still a few too many moving pieces with the 4.0 template to do the update and script port at the same time. I updated the original branch so the new features could be tested there before porting the scripts to 4.0. That code is here: https://github.com/OTHGMars/Torque3D/tree/ovr_1168_wip The ResetZeroPose command has been moved from IVRSystem to IVRChaperone, so the chaperone interface has been added. With static and cursor overlays available, the offscreen canvas has been separated from the overlay to simplify overlay creation. An offscreen canvas can still be attached. The script demo has been updated to use the new format. It also provides a better example of virtual keyboard activation and input handling.

@Atomic Walrus Thanks for the detailed feedback. If you have your code for interacting with overlays via touch in a branch, I would really like to see how you've implemented that. The scrolling options added in 1.2.10 make it sound like that is going to become a standard feature. The LOD issue you pointed out is a known issue and I believe it's been fixed it the Preview_40 branch. It had to do with the LOD calculation using screen pixels and aspect ratios that are very different between the screen and VR eye viewport. I read through the release notes on the updates and it sounds like there have been many useful improvements. I have started a branch (https://github.com/OTHGMars/Torque3D-1/tree/ovr_1168_wip) to port this up to T3D Preview_40 and update to the current OpenVR release. Currently it has the bare minimum changes required to build against openvr 1.16.8. I have not started implementing any of the new features or porting the demo scripts yet. Now that T3D has assimp integrated, we should be able to get rid of the intermediate step to create collada models for the hand meshes and load them directly from their fbx source art. Getting rid of the HQ overlays (1.7.15) and standardizing is nice for us as it removes several confusing overlay setup options. There have been several changes to IVROverlay and IVRInput that sound very intriguing. The additional cursor control and feedback for input binds are nice features. The compositor skinning (https://github.com/ValveSoftware/openvr/wiki/Compositor-Skinning) option added at 1.9 should overcome (or at-least minimize) the lag and grey-room issue that was (imo) the biggest deterrent to trying to use T3D for VR games. If that works as advertised, it will be possible to create a VR template that launches directly to the mainmenu in VR. That would certainly be a fun experiment to try. If you have any features you would like added, don't hesitate to share ideas or PR changes. The 'Full' game template no longer exists, so a big portion of the work is going to be porting and updating the scripted demos to work with the 'BaseGame' template and 'FPSGameplay' module. Any thoughts or ideas on how that should be approached would be greatly appreciated.

SDL will be adding SDL_OpenURL() in version 2.0.14. It's still pre-release, but it checks out on Win10 (opens url in default browser not IE). If it works on all supported platforms after the next SDL release, all of the platform specific openWebBrowser() calls can be eliminated and replaced with a single SDL call. https://hg.libsdl.org/SDL/rev/d0348dab7c0f See line 3.45.

// Initial data %npcPosition = %talkingNPC.getPosition(); %playerPosition = %clickingPlayer.getPosition(); %interactionDistance = 4; // Get the vector between the NPC and the player %separationVector = VectorSub(%playerPosition, %npcPosition); // Eliminate the z component of the vector (only because OP says '2D vectors') %separationVector.z = 0; // Normalize to a length of 1 %unitVector = VectorNormalize(%separationVector); // Scale the unit vector by %interactionDistance %interactVector = VectorScale(%unitVector, %interactionDistance); // Add %interactVector to the NPC position to get the target player position %targetPosition = VectorAdd(%npcPosition, %interactVector);

1) I have tested with an Oculus Rift and HTC Vive and both work. In theory it should also support WMR devices, but I have no knowledge of anyone testing with WMR yet. 2) There is some script setup required, examples are included in the branch. 3) Yes, there is support for floating overlays and the OpenVR dashboard so you can render T3D guis directly in the headset. 4) It will be updated for the new e/c player controllers, but it's unlikely that will happen before T3D 4 releases. Hopefully shortly after though.

@Duion Be the change that you want to see! That's the beauty of an open source project. There is nothing stopping anyone from forking the engine, renaming it (optional step here), forming their own steering committee and taking the development in whatever direction and at whatever pace they so choose. You could even define the methods of communication for your steering committee so an aversion to Discord would not make you feel isolated and out-of-the-loop. Who knows, a little competition might spur development...or it could kill both engines...but you won't know unless you try. It is bound to be more productive than trying to tell others how to behave through messages in this forum though.

There is a branch that updates T3D to build with the latest OpenVR release and adds support for the new IVRInput Interface and Hand Skeletons. The branch is here: https://github.com/OTHGMars/Torque3D/tree/OVR_1017f Build instructions and branch notes are here: https://github.com/OTHGMars/Torque3D/blob/OVR_1017f/Templates/Modules/ovrModule/branchNotes.md All of the scripts used when creating the videos below are included.

Try voice->LoadEffect(&reverb) before return voice; but after voice = new SFXALVoice... Load effect should be non-static in that case.

Official docs are here. I found them through here.

Check that you have a ModuleDatabase.scanModules call being executed. It's in main.cs in the templates. See: https://github.com/GarageGames/Torque3D/blob/development/Engine/source/module/moduleManager_ScriptBinding.h#L37-L41. If the argument is empty, the default will be game/ and your modules will need to be located there. After that the call to ModuleDatabase.LoadGroup( "Game" ); should load and execute the create() function (if it's in group=”Game”).

The joystick branch now includes a keyboard event refactor that eliminates keycode and modifier conversions. This opens the possibility of supporting ANSI and ISO keyboards in any layout that SDL recognizes. Help is needed in order to get this properly tested and working in time for 4.0. If you use a non US keyboard layout or have any type of gaming input device, please see testing below and post your results. Testing To test, pull in the joystick branch and test module (install BaseGame with one of the Gameplay and inputTest modules). It will allow you to see events that would otherwise require you to set binds & breakpoints or use the remap gui. Test every standard key on your keyboard. Any keys bound in the global action map like the Grave Accent on US layout will execute that function instead of appearing in the input monitor. You can still see an event generated by using a modifier key with them. If any key does not produce an event name in the monitor, open the console and there will be an error message ("ActionMap::getKeyString: no string for action %d") in the console. Please post the number printed, the key pressed, your layout and OS in this thread. The action number will correspond to this enumeration. No, we don't support every scancode in the USB standard so there's no bind for the mute function etc. of modern keyboards. If you find any key that you think should be added, please bring it up. The text input of all printable characters can be tested in the console gui. When initially testing a joystick device, open the settings window (f2 from the monitor) and turn the deadzone up past half-way. That makes it easier to verify the individual axis events in the monitor. New Joystick Options POV Hat data is provided as a 4 bit mask value and interpreted to produce the standard upov, dpov, lpov and rpov events. Set pref::Input::JoystickPOVMask true to receive a povmask event with the current hat state every time it changes. This defaults to false so standard behavior is consistent with the previous direct input event handling. A joystick device that only has 4 axes will always report axes 0-3. In torque mapping this becomes xaxis, yaxis, zaxis and rxaxis. There's an option, pref::Input::JoystickSplitAxesLR, that if true will map axes 2/3 to rxaxis/ryaxis instead of zaxis/rxaxis. This option only affects 4 axis joysticks. Checkboxes have been added to the settings gui in the test module so you can see the effects of these settings without needing to type them out in the console. My Test Results US keyboard layout, all keys and modifier combinations produced the correct bindable event. The only other devices I have are a Logitech RumblePad 2 (c2007) and an Xbox One controller. SDL has built-in controller mapping for the logitech so I was able to open both as joystick or gamepad. Both devices produced the correct events for all inputs. The Logitech was not detected as a haptic device (it is) and the wired/battery status returned unknown. Every feature of the Xbox controller was detected correctly.

Check out the VectorLen function https://github.com/GarageGames/Torque3D/blob/development/Engine/source/math/mathTypes.cpp#L937-L962. It's not the sum of the axes components, but will give you the speed of a velocity vector.

Have you checked UAC settings or tried running as administrator on the systems that are a problem? We found we had to code-sign the exe and dlls to reliably load on windows 10. If it's working on 20/22 systems, it's unlikely anything wrong with the dll name or path.

ISteamController InterfaceThere is now an addon for the steamWrap branch that enables all features of the ISteamController interface. You can get it here. If you're unfamiliar with the capabilities of Steam Input, I highly recommend the Dev Days presentation and Case-Study linked here for an eye-opening overview of the input tools available through Steamworks. This branch contains the scripts and .vdf file needed to get started using SteamInput with the 'Full' template. To test: 1. Clone devhead and pull the steamInput branch. 2. Configure cmake as described in OP and select the additional TORQUE_STEAMWORKS_INPUT option. 3. Generate and build the project. 4. Rename the /Templates/Modules/controller_config/game_actions_T3D.vdf replacing “T3D” with your AppID. 5. Copy the controller_config directory to your steam install directory e.g. C:/Program Files/Steam/controller_config. Note: this will not affect your published game even if you have a published IGA. 6. Create a default configuration as described here. 7. Launch the game with steam running. You can access the bindings panel at any time by entering SteamInput::showBindingPanel(0); into the console or activating the input you have bound to 'Bindings Panel' on the device. The video below shows the code in action. It would be completely unremarkable except the keyboard or mouse were not touched even once while recording. All of the game input is coming from an xbox 360 controller. k6B9dik6fJE Without true controller (or even keyboard) navigation of guis, it will be hard to meet the requirements for the Steam Big Picture Icon and associated promotions. This is a small step in that direction though.