Source code to VRboost.dll?

[jimrandomh]

The source code that's in git doesn't seem to generate a VRboost.dll or a VRboost64.dll, and there are some strings in there which suggest that there are source files missing too, not just a build-script issue. What is VRboost.dll exactly, and where (if anywhere) does its source code live?

(There's an experiment I want to try that alters the interplay between position-tracking and head rotation. I'm not sure which DLL the relevant code lives in, but I suspect it's in there.)

[jimrandomh]

After a bit more googling, I found an old blog post which says that VRboost is closed-source and proprietary. There is no mention of this in the readme, the vireio main page, or the vireio downloads page. Given that there's a copy of the GPLv3 in the root of the repository, and that VRboost has no identity apart from Vireio, this is not legally kosher.

Would you please reconsider and open source this component? I got a bit of a start on development in my own branch, but now I'm reconsidering.

[JoshC2k]

I'm not sure where the ownership lies on that codebase anymore, but I doubt we'll be able to open source it (unless things have changed since I last looked).

[jimrandomh]

I hope the original authors are still around; it would be unfortunate if it stayed closed-source just because they couldn't be identified and contacted.

Looking more closely at the headers on files, it looks like almost everything is LGPL, which can be linked to proprietary components without (legal) issue. However, the FreeTrack library appears in the git repository, and is licensed under GPLv2, which is incompatible. I don't know what the relation is between vireio and freetrack

The bigger issue is that vireio is presented as open-source software, but it has a vital proprietary component that isn't advertised as such. That needs to be called out on http://www.mtbs3d.com/new-vireio-site, in the readme, and in the online manual, all of which create the impression that VRboost is a feature, not a separate project with a separate license.

[jimrandomh]

Much more important: The Donate page at http://www.mtbs3d.com/donate says "Vireio Perception is non-commercial open source, and is put together by volunteers." A reasonable person would interpret that statement as meaning that all of Perception is open source, VRboost included. So, that statement can't be there.

[DrBeef]

Licence issues/concerns aside, I am not actually sure what difference having the VRBoost source would make.

Vireio simply uses it as a tool to apply HMD orientation into the game directly, rather than using the mouse. You can use the latest version of VRBoost from the 2.1.4 release and it will work no problem; the meat of the VRBoost implementation is simply finding the addresses the game uses for orientation, and from your original requirement that seems superfluous to your requirements. If VRBoost isn't present then Vireio works fine but just uses mouse emulation, so Vireio isn't dependent on VRBoost.

If you look in the D3DProxyDevice::HandleTracking method, you can see where the HMD orientation is set in the VRBoostAxis array, that is then passed into VRBoost and applied to the appropriate memory locations. This is probably all you need to use, based on what you said originally.

On 20 March 2015 at 05:41, jimrandomh notifications@github.com wrote:

Much more important: The Donate page at http://www.mtbs3d.com/donate says "Vireio Perception is non-commercial open source, and is put together by volunteers." A reasonable person would interpret that statement as meaning that all of Perception is open source, VRboost included. So, that statement can't be there.

— Reply to this email directly or view it on GitHub https://github.com/cybereality/Perception/issues/52#issuecomment-83921149 .

[baggyg]

This is an odd way to go about asking to see the VR Boost code, or just making some changes. Is your concern here licensing, or would you like to add something or join the project? You say you have your own branch, could you please provide an overview of what you are trying to achieve and maybe we can help.

Whether I agree or not VR Boost was developed in isolation to Vireio with a closed source license as a separate project:

/*** VRboost : Virtual Reality immersion boost technology. Copyright © 2013 Denis Reischl Copyright © 2013 Neil Schneider Productions Inc. File and Class : Copyright © 2013 Denis Reischl V1.1 Memory Scanner Modifications - 2014 by Simon Brown and Grant Bagwell This code is private and MUST NOT be set public for any reason. This code is intended to be used, changed, compiled and its build published only by members of the Meant-To-Be-Seen-Development-Team, an unconsolidated association of people representing the site http://www.mtbs3d.com/. Except where otherwise noted, this work is licensed under : http://creativecommons.org/licenses/by-nc-nd/3.0/deed.en_US. ****/

Vireio Perception uses this as an external library, and is not dependent on it to function. At no point has it been stated that VR Boost is part of Vireio, in the same way that we don't state the Oculus SDK is part of Vireio. In my lay opinion I do not believe there is a licensing issue. VR Boost is always stated differently to Vireio (see the downloads Vireio Perception + VR Boost). It has been stated on multiple occasions that it is set up this way. Vireio Perception is Open Source as stated.

Freetrack has the following declaration in the Git:

The file FreeTrackClient.dll bears the GNU GENERAL PUBLIC LICENSE (Version 2), as described in gpl.txt. It is free to redistribute in whole or in part, both as source and as a binary, so long as a reference to the original source is provided. Here is is:

http://www.free-track.net/english/freetrack/telechargement.php

If you have licensing concerns or legality of donations about the project please contact Neil Schneider at neils@mtbs3d.com who manages the project and was also there when the original VR Boost was developed.

[jimrandomh]

Authors of VRBoost, was it your intention that it be licensed under CC-BY-NC-ND? The header comment says so, but the FAQ at http://www.mtbs3d.com/index.php?option=com_content&view=article&id=13610 says "The VRBoost and game profiler components are completely closed-source. It is free to download and use, but it's also the property of MTBS and the authors. Mirroring this without approval would be considered a form of computer piracy". The actual downloads bundle Perception and VRBoost together and contain no license and no attribution for the VRBoost part.

CC-BY-NC-ND is a license I could live with. As it currently stands, however, MTBS3D could withdraw the free version of VRBoost and make it payware.

Vireio Perception uses this as an external library, and is not dependent on it to function. At no point has it been stated that VR Boost is part of Vireio, in the same way that we don't state the Oculus SDK is part of Vireio. In my lay opinion I do not believe there is a licensing issue. VR Boost is always stated differently to Vireio (see the downloads Vireio Perception + VR Boost). It has been stated on multiple occasions that it is set up this way. Vireio Perception is Open Source as stated.

That may have been your intention, but that is not what happened. Neither Perception nor VRBoost have download packages which do not contain the other. Some of the download pages have no licensing information, but those that do - such as http://www.mtbs3d.com/downloads-section/viewdownload/17/62 - simply say "GNU/LGPL" for the whole thing. VRBoost does not have a separate readme, license, or credits. The separate labelling is missing from v2.0.3-2.1.1, but they do contain vrboost.dll. The Perception manual talks about both, and VRBoost does not have a manual of its own.

This is an odd way to go about asking to see the VR Boost code, or just making some changes. Is your concern here licensing, or would you like to add something or join the project? You say you have your own branch, could you please provide an overview of what you are trying to achieve and maybe we can help.

I actually started out thinking there was some build-script issue causing vrboost.dll to not be generated, then opened this thread thinking someone had forgotten a "git add" or there was another repository elsewhere on github.

I need to wait until I have more free time before doing any real development, but there are a few specific issues I was planning to eventually look into. First, fixing the interaction between head-tracking rotation and translation. Currently, if you translate your head and then rotate, the translation vector is also rotated. I think it would work better if it took the angle between the rotational origin and the current head rotation, and applied the inverse rotation to the translation vector. (I now think the relevant code is probably not inside VRBoost, but I didn't know that when I opened this thread). Second, hotkey configuration; the combination of Skyrim, Skyrim mods, an AutoHotkey script rebinding all the XBox controller buttons onto the keyboard, and Perception's large number of hotkeys, makes for a huge mess of conflicts. And third - VRBoost's scan fails to find the right addresses about half the time when I start Skyrim, and once it's failed it won't succeed at retries until I quit to desktop and restart. And finally, I was thinking of attempting to implement a tank mode (head rotation decoupled from character rotation), and that's something where the interplay between Perception and VRBoost and SKSE is likely to require changes to all three.

[baggyg]

I will leave all licensing questions to Neil at MTBS3D as he is far more qualified to handle. I agree it could be clearer, but considering that both devs on the project work full time and can only commit a limited amount of time to VP, you can understand that making sure license readmes are perfect is not really a high priority compared to getting releases out / games supported / adding features and fixing bugs. Not making excuses, just explaining the pragmatic approach developers take when contributing to a project that has had many. I am sure Neil has some thoughts on how this could be clearer to stop potential devs labouring under a false pretense that something is wrong with their git.

MTBS could start charging for VRBoost but in reality I don't see how this would be possible. MTBS3D is the official portal designated by the original dev when first handing over VP to open source. However all of the developers (including Simon and I who maintain the Vr Boost code now) have no link or vested interest in MTBS3D itself. We have worked very hard to make the project as open as possible and despite offers of money have only set up the donation system in a way that allows us to add steam games that people would like support for. As far as I am concerned I donate my time to forward the project and the reward is just having game sI can play in VR.

To me the key feature is that anyone can fork VP and distribute a separate version for their own purposes (and it will work without issue albeit without memory modification / VR Boost). Distribution of VR Boost is through official MTBS forums although people could still use it as library as long as they don't distribute. I won't put forward arguments for and against this as I was not on the project when it was decided and won't speak for anyone else. Memory modification is significantly different to the core function of Virtual Reality driver injection, so I think a conceptual difference is there. The fact that these have been distributed together, is out of convenience to the end user.

Regarding moving forward I would also suggest talking to Neil to contribute. If your work is to forward the core version of VP than we would be more than happy for the help and make sure we do everything to facilitate you including providing access to otherwise restricted code.

The only other comment I offer is about Skyrim. We haven't used the scanner version of VR Boost Skyrim for a couple of releases now. The logic of which pointers to use is completely open for people to amend, and requires no internal knowledge of VR Boost. It is more a case of identifying where the values are in memory (found using Cheat Engine) and comparing that to the VR Boost profile. If you are able to do this, and can send a list of the various addresses it resides in (after multiple restarts) we should be easily able to help you construct a scanner profile that worked 100% of the time for your machine. Once you have done it once it is pretty easy to apply to any game you fancy. Certainly no internal knowledge of VR Boost code is required to add support to a new game (and create a VR boost profile)

[jimrandomh]

Regarding Skyrim in particular, the situation is a bit more complicated than that. Skyrim has an internal scripting language, which sometimes overrides the camera position (for menus, riding, and some quest-specific triggers) in a way that moves the relevant addresses at runtime. So VRBoost gets 90% of the way there, but misses a bunch of corner cases. But, the problem looks tractable from a different angle: Skyrim Script Extender (SKSE) has a hook for camera changes, is open source, and has a header file (GameCamera.h) which seems to have reverse-engineered most of Skyrim's camera-related data structures and exposed them to modders. So, if I did take a swing at this (and again, this has to wait until I finish with more urgent responsibilities), the thing I'd be looking for is a mechanism for SKSE plugins to notify VRBoost or Perception that there are new addresses to use. (SKSE plugins are DLLs written in C++ and loaded into Skyrim's process).

[EisernSchild]

Hi Guys !

This is Denis, original author of VRBoost. The VRBoost licence is that one Grant told you in the email before : /*** VRboost : Virtual Reality immersion boost technology. Copyright © 2013 Denis Reischl Copyright © 2013 Neil Schneider Productions Inc. File and Class : Copyright © 2013 Denis Reischl V1.1 Memory Scanner Modifications - 2014 by Simon Brown and Grant Bagwell This code is private and MUST NOT be set public for any reason. This code is intended to be used, changed, compiled and its build published only by members of the Meant-To-Be-Seen-Development-Team, an unconsolidated association of people representing the site http://www.mtbs3d.com/. Except where otherwise noted, this work is licensed under : http://creativecommons.org/licenses/by-nc-nd/3.0/deed.en_US. ****/

The licence is shared with the meant-to-be-seen dev team currently led by Grant Bagwell. All modifications to VRBoost are also permitted by my person but the source code will stay closed source for various security reasons. If the licence is not included in any of the current Vireio Perception releases i will instantly ask Grant to do so in future.

Feel free to ask at my email address (eisernschild@gmail.com) for anything regarding VRBoost.

Kind Regards Denis Reischl

2015-03-20 19:29 GMT+01:00 jimrandomh notifications@github.com:

Regarding Skyrim in particular, the situation is a bit more complicated than that. Skyrim has an internal scripting language, which sometimes overrides the camera position (for menus, riding, and some quest-specific triggers) in a way that moves the relevant addresses at runtime. So VRBoost gets 90% of the way there, but misses a bunch of corner cases. But, the problem looks tractable from a different angle: Skyrim Script Extender (SKSE) has a hook for camera changes, is open source, and has a header file (GameCamera.h) which seems to have reverse-engineered most of Skyrim's camera-related data structures and exposed them to modders. So, if I did take a swing at this (and again, this has to wait until I finish with more urgent responsibilities), the thing I'd be looking for is a mechanism for SKSE plugins to notify VRBoost or Perception that there are new addresses to use. (SKSE plugins are DLLs written in C++ and loaded into Skyrim's process).

— Reply to this email directly or view it on GitHub https://github.com/cybereality/Perception/issues/52#issuecomment-84095003 .

[baggyg]

In response to Skyrim I also use SKSE and haven't had any issues. I can see what you are saying however but need to know more specifics to test this end, to see what is happening to the memory addresses as it does this. To be honest I would have thought if we have a DLL controlling the camera it may be better to just link the two together rather than trying to use a middle man approach with VR Boost. When you do have chance to investigate and provide information, open a different issue on github or contact Simon and I directly and we can see what can do.

[baggyg]

P.s. The game regularly changes the definitive address of the orientation. Using the older method of VR Boost we use a pointer instead of the actual address to keep track of it. So just being informed that it has moved doesn't really help. As I said send me a replicable example and I am sure we can get to the bottom of it!

[Enterfrize]

Hi Guys!

Boy! One question and the Internet explodes! ;-)

Denis: Great seeing you again. How have you been keeping?

Jim: While VR Boost is freeware software, it's closed source. We did this because the nature of VR Boost is that it goes into the direct memory registers of games and game engines, and is a basic template for cheats, hacks, and nasty things that go beyond the scope of VR should the source code be out in the open. Some argue that there are ample cheat engines and tools readily available, but there is no justification or benefit for Vireio to help add to the pile. We've also been getting software donations; some from developers and vendors to help make the drivers possible, so we have to be cautious about this type of code.

I wish to underscore that the software is completely free, and the remaining portions are open source. It's just the VR Boost plug-in / element that carries the security concerns and limitations for the reasons I've already stated. We have no interest in making it a commercial venture or charging for the feature, though we do accept donations for game purchases, hardware, etc.

If you wish to participate with the development team, you are most welcome to. I'm doing some traveling this week, but I'd be happy to connect when I get back. Or you are welcome to catch up with Simon and Grant to get a grasp of how to best work together if there is interest. Each of the team has their strengths, and it's been fun for everyone. We're a merry bunch!

Feel free to email me at neils@mtbs3D.com.

Regards, Neil

[jimrandomh]

Thanks guys! Having this clarified puts my mind at ease, as does having a clearer picture of what VRBoost does.

I'm going to put Perception aside for at least a few weeks to work on things with deadlines. After that I'll send a few emails to discuss ideas and plans with the rest of you.

[jimrandomh]

And let me add: Thanks for doing the hard parts to get Perception working! It looks like the remainder of what's left is polish and corner cases, and I know a ton of effort went into getting it this far.

[Enterfrize]

Excellent! Looking forward to touching base soon.

[EisernSchild]

Hi Neil !

Thx for asking ! I did quite well and planned to contact you this week. So -hopefully tomorrow and at the latest on friday- i will give you personally an extensive summary of my work for the last year.

Kind Regards, Denis

2015-03-21 23:02 GMT+01:00 Enterfrize notifications@github.com:

Excellent! Looking forward to touching base soon.

— Reply to this email directly or view it on GitHub https://github.com/cybereality/Perception/issues/52#issuecomment-84460601 .

[Relys]

As a professional security researcher I think linking to a binary blob is a higher security risk compared to releasing code which hooks the game process. There are a billion better tools directly suited towards cheating in games. I hope you will reconsider your stance on this.

Anyways, thanks for your work on this project! :)

[Enterfrize]

Thank you for your input. Since firming up this hybrid license years ago, it has protected the hard work of the developers more than once and it has made it possible for us to receive software and hardware donations we wouldn't have otherwise so we could continue development. While we are committed to maintaining the entire package as freeware so everyone can enjoy the service (and we have demonstrated this commitment for years), the VR Boost licensing must remain as it is.