OTHGMars

@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.

New script calls and callback from ISteamUtils added with this commit. SteamAPI::isOverlayEnabled () SteamAPI::isSteamInBigPictureMode () SteamAPI::isSteamRunningInVR () SteamAPI::setOverlayNotificationPosition (SteamNotificationPositions position) SteamAPI::setOverlayNotificationInset (S32 xOffset, S32 yOffset ) SteamAPI::showGamepadTextInput (SteamGamepadInputMode inputMode, SteamGamepadInputLineMode lineMode, const char* description, U32 maxLength, const char* existingText ) onSteamTextInputDismissed(bool wasTextSubmitted, const char* newText, U32 textLength)

I've been working on updating AlterVerse to x64. After a couple times pulling in a branch, regenerating the project and having to link the Steamworks API to the build manually, I realized I needed a cmake file to eliminate that tedium. I placed that cmake file and my basic steamworks console wrapper into a branch that hopefully others can benefit from. If you're setting up a T3D build for steam, even if you don't use any of the code in this branch, the cmake file may save you some time. I only use a couple functions from the steamworks API for getting the steam ID and display name for the current user. Thanks to @Steve_Yorkshire sharing his achievement code here, I was able to get console functions added for achievements. Even so, this barely scratches the surface of the functions the Steamworks API makes available. The files are located at https://github.com/OTHGMars/Torque3D/tree/steamWrap. This is setup as a Module and static engine class so all interaction is through script and no existing engine source files are changed. UsageYou will need to download and extract the steamworks sdk and have an App ID for your game. The new cmake options are: TORQUE_STEAMWORKS – Check this to have steamworks added to the build. TORQUE_STEAMWORKS_APPID – Enter the App ID for your game. TORQUE_STEAMWORKS_REQUIRED – If this is checked, a distributed build of your game will not launch without steam running. An attempt to launch the game from the exe will exit, launch the steam client, then relaunch the game through steam with a logged in user. See here and here for more details. TORQUE_STEAMWORKS_SDKPATH – Point this to the sdk directory within the extracted steamworks package. Once configured, cmake will add the include directory, link the library, copy the correct .dll or .so and generate your steam_appid.txt file. Console FunctionsBecause the static engine class is named SteamAPI, all function calls through script must be prefixed with SteamAPI::. Unless you know you're running a distributed build and have steamworks set to required, you should call SteamAPI::isSteamRunning() before calling any of the other functions. See the Steamworks API Reference and the console docs with the function declarations for more info. SteamAPI::isSteamRunning() - Returns true if Steam is running and the Steamworks API has been initialized. SteamAPI::getUserId() - Returns the steam ID for the currently logged in steam user.. SteamAPI::getPersonaName() - Returns the local players name. SteamAPI::areStatsLoaded() - Returns true if a requestCurrentStats command has successfully completed for the current user. SteamAPI::requestCurrentStats() - Requests an asynchronous stats load. SteamAPI::setAchievement(name) - Unlocks an achievement. SteamAPI::clearAchievement() - Resets the unlock status of an achievement. SteamAPI::storeStats() - Upload stats to steam. SteamAPI::getNumAchievements() - Get the number of achievements. SteamAPI::getAchievementName(index) - Gets the 'API name' for an achievement. SteamAPI::getAchievement(name) - Gets the unlock status of the Achievement. SteamAPI::getAchievementDisplayAttribute(name, key) - Get general attributes for an achievement. SteamAPI::resetAllStats(achievementsToo) - Resets the current users stats and, optionally achievements. CallbacksSee https://github.com/OTHGMars/Torque3D/blob/steamWrap/Engine/source/steamworks/steamCallbacks.cpp#L30-L56 for complete callback descriptions. Example Script function onSteamUserStatsReceived(%success) { %text = "The user stats load " @ (%success ? "Succeeded" : "Failed"); echo(%text); if (%success) listSteamAchievements(); } function onSteamGameOverlayActivated(%isActive) { %text = "The steam game overlay is " @ (%isActive ? "Active" : "Inactive"); echo(%text); } function listSteamAchievements() { if (!SteamAPI::isSteamRunning()) { echo("Steam is not running"); return; } echo("Steam User: " @ SteamAPI::getPersonaName() @ ", Steam ID: " @ SteamAPI::getUserId()); if (!SteamAPI::areStatsLoaded()) { echo("No Stats Loaded Yet!"); return; } %numAchievements = SteamAPI::getNumAchievements(); for (%i = 0; %i < %numAchievements; %i++) { %apiName = SteamAPI::getAchievementName(%i); %achieved = SteamAPI::getAchievement(%apiName); %dispname = SteamAPI::getAchievementDisplayAttribute(%apiName, "name"); %dispdesc = SteamAPI::getAchievementDisplayAttribute(%apiName, "desc"); %hidden = SteamAPI::getAchievementDisplayAttribute(%apiName, "hidden"); %achievedText = %achieved ? ", Unlocked" : ", Locked"; %hiddenText = %hidden ? ", Hidden" : ""; echo(%i SPC %apiName @ ": " @ %dispname @ ", " @ %dispdesc @ %hiddenText @ %achievedText); } } if (SteamAPI::isSteamRunning()) SteamAPI::requestCurrentStats();