FreePIE official thread

[CyberVillain]

Yes, consumer IMU's all suffer from drift, but you can minimize it. I have played Alien Isolation a little bit with my HTC M8 and the drift is pretty ok.
The problem is mouse emulation, I do not want to run around with my weapon up high all the time (My arm gets tired). So I tried to strap my girlfriends HTC One X to my torso, and used that as primary sensor for mouse emulation, then when I brought up the "weapon" (I'm using a gamepad for crude weapon simulation) to shoot I press a button and the phone strapped to the gamepad takes over mouse emulation, but the gap between the two is really noticeable. So you will never get perfect VR with mouse titles, thats just a fact :/

edit: The problem with mouse controlled games are that head, body and weapon movement are all combined into a single controller
edit: Our only hope are that games like Arma get mainstream after STEM or systems like it hit the market

[konstantin_lozev]

I do not want to run around with my weapon up high all the time (My arm gets tired).

Ah, that sounded weird, JK
Anyway, I don't understand what you meant by "the gap between the two (phones IMUs)". My idea is that the best approximation for standard shooters is to switch to weapon tracking (or at least give 90% weight to the weapon's IMU readings) only when it is up your face. In normal shooting scenarios (like with real kalashnikovs) at that moment your sight is always aligned to the gun's iron sights. I think the disconnect would be when you do not raise the gun at your face but try to "cheat" by pressing only a button. Of course, the crosshair shall go away and that's possible in many games.
I have implemented similar "switching" script with a wii that switches the code when you have iron sights vs on hip. I have it in the description of this youtube video https://www.youtube.com/watch?v=8OcXppj ... Jn8O351BPw
Of course, the calibration between the HMD and the gun and the in-game sensitivity when in iron sights and on hip shall be right too...
I am not able to verify yet since my homebrew HMD has a severe lag over the home wifi (need to implement virtual network with the PC, or theder, problem is I got Kindle Fire HDX as the screen and that's nowhere near being rootable...)
But well, I'll post when I manage to get the streaming and the "hybrid" script right.
I needed to implement the touchpad as the only trigger for the iron sights button (maybe with an additional threshold for a small difference in the HMD and wii-gun orientation) in order to see whether that won't give you less disconnect.
I guess your point and the biggest problem is when in VR you have little idea where your hands/gun are in real life...

[CyberVillain]

I only tried with a simplescript, problem is that when you take aim and switch sensor you create some jitter, I tried to ease that out with a simple filter, still noticable.

[CyberVillain]

Checked your video quickly, cant see that you rest the "weapon" at any time in that video?

With rest I mean like letting it hang in the sling like a real soldier would do

[konstantin_lozev]

Checked your video quickly, cant see that you rest the "weapon" at any time in that video?

With rest I mean like letting it hang in the sling like a real soldier would do

Hi, no, this script is not meant to do that, since it relies only on one IMU (wiimote) for looking around (when in-game gun is on hip) and aiming (iron sights). So your gun has to be up at all moments, the wiimote simply acts as a "looking device" when gun is on hip in-game and as "shooting device" when in iron sights. I linked it to show that transitioning from one control scheme (looking) to another (aiming) is still very much playable, at least in that scenario. I have to say I understand that scenario has differences with the VR scenario and I will only know how big it is when I test relatively lag-free.
From testing, I think the scenario in the youtube video works so naturally because at the time of switching to iron sights your gun is already pretty near to the center of the screen (due to the "looking device" control scheme). My guess would be that you will need the same alignment between the HMD and the gun at point of transition (my guess is touch detection for the gun's stock to your shoulder combined with tight threshold for alignment of the orientations of the two IMUs readings) to achieve the smooth transition.
But I can also see the potential pitfalls - (1) the tolerance to jittery view is much lower for VR and (2) you can't see your hands extending, i.e. it will be more difficult to align the gun to your HMD. Bugger...
Will report when I manage to test.

[CyberVillain]

come to think about it, maybe there is no point in having tracking on the gun in a mouse controllerd game, I will try tonight just to use the gun as a trigger for shooting and let the headtracker do the work of aiming (The head follows the gun anyway).

In games like Half life 2 VR were the gun is moving seperate from the head its more point to have actual gun tracking

[NeoTokyo_Nori]

come to think about it, maybe there is no point in having tracking on the gun in a mouse controllerd game, I will try tonight just to use the gun as a trigger for shooting and let the headtracker do the work of aiming (The head follows the gun anyway).

In games like Half life 2 VR were the gun is moving seperate from the head its more point to have actual gun tracking

While it is of course possible to have the headtracker do the work of aiming, I think you will find out that it becomes an uncomfortable experience to have to aim with your head, especially when accuracy is important. Our heads and neck can make "broad" movements easily, but I think trying to make constant fine adjustments will give you a stiff neck in a short time and also "Bird head" syndrome

I have been using the method of turning on and off mouse control by the gun for a while,
and I think it works fairly decently for now, rather than try to get the hardware/software to be perfect all the time. As far as separate head, body, gun movements, I guess we will have to wait for fps games that are made for VR

[konstantin_lozev]

Hi Neo, fully agree with you on this. I have had this weird feeling of shooting with my nose in some of the Dive demos. Does not bring too much immersion, tbh... That's why it's important to test with differennt sensitivity and threshold settings lag free.
Edit: tested without the DIY HMD on (video latency still high) only with the two IMUs (the tablet and wiimote) the threshold idea of activating the iron sights while the two are aligned. The yaw drift between the two over time invalidates that approach

[konstantin_lozev]

come to think about it, maybe there is no point in having tracking on the gun in a mouse controllerd game, I will try tonight just to use the gun as a trigger for shooting and let the headtracker do the work of aiming (The head follows the gun anyway).

In games like Half life 2 VR were the gun is moving seperate from the head its more point to have actual gun tracking

While it is of course possible to have the headtracker do the work of aiming, I think you will find out that it becomes an uncomfortable experience to have to aim with your head, especially when accuracy is important. Our heads and neck can make "broad" movements easily, but I think trying to make constant fine adjustments will give you a stiff neck in a short time and also "Bird head" syndrome

I have been using the method of turning on and off mouse control by the gun for a while,
and I think it works fairly decently for now, rather than try to get the hardware/software to be perfect all the time. As far as separate head, body, gun movements, I guess we will have to wait for fps games that are made for VR

Neo, on separate head vs body controls in games, I think there could be a workaround. For games that support gamepads, the left stick direction could be corrected with the yaw difference beteen the IMU that measures your head position and the IMU that measured your shoulder position. Now, there is the issue of drift between the two over time, maybe a button or time event that zeroes that drift could fix that.
For games that do not support gamepads there could also be a workaround in the time w vs d button is made to be held down.

[CyberVillain]

Most games that support gamepads do not have stepless speed only full speed when the axis leave the deadzone. :/
But yeah for the games that really have stepless control that should work

[konstantin_lozev]

Most games that support gamepads do not have stepless speed only full speed when the axis leave the deadzone. :/
But yeah for the games that really have stepless control that should work

Hi, CyberVillain, I am not sure what you mean by stepless speed, is it that your movement is either full speed or you stay put? That would be a problem indeed, since you need fine control of your movement on each axis to replicate the correct angle of your yaw direction. Otherwise, you essentialy have 8 orientations for walking hard-coded in game, which is just as bad as wasd
The only workaround that I can think of is making the axis that must travel e.g. half-speed to activate only for half of the frames the main movement axis is active. That's only theory though, will have to test to confirm...

[CyberVillain]

Yes many games have "digital" (on/off only) movement even with gamepad

[konstantin_lozev]

Hi Neo, fully agree with you on this. I have had this weird feeling of shooting with my nose in some of the Dive demos. Does not bring too much immersion, tbh... That's why it's important to test with differennt sensitivity and threshold settings lag free.
Edit: tested without the DIY HMD on (video latency still high) only with the two IMUs (the tablet and wiimote) the threshold idea of activating the iron sights while the two are aligned. The yaw drift between the two over time invalidates that approach

Update on the HMD/gun aligment, it is not dead yet I just finished a driftless pitch script in GlovePIE. So, in essence, the activation can still be made in theory checking only the driftless pitch of the two IMUs.

[CyberVillain]

New version out! MIDI and some other stuff

[NeoTokyo_Nori]

New version out! MIDI and some other stuff

Hi CV, thanks for the update.
I tried to download it but,
A. Adblock goes wild and the count goes up to 1000+ Ads blocked.
B. Google chrome automatically blocks the download
so I thought I should double check with you that it is safe.

Now, In the change log you mention.
"Some small fixes like removing unused update event from mouse and keyboard plugin (They wont fire)"

I have been having several situations where the keyboard.setKeyDown(Key) does not fire, no matter
what I try, and it has been driving me nuts trying to figure out what is going wrong.
So will this update be related to those situations possibly?

p.s.what is the reason that you have deleted the reference page?
https://github.com/AndersMalmgren/FreeP ... /Reference

cheers.

[CyberVillain]

I use mega as host, I dont think they should be unsafe,but a better hosting server would be nice.

The fix is that mouse.update and keyboard.update is removed because it will never fire. so if you have a script mouse.update += update the update function will never fire.

keyboard.setKeyDown(Key) should work, BUT it does not work in programs like notepad for some reason, but in game it works

I deleted the reference becaue it was outdated and I have by mistake deleted the program that generates it, I need to have better routines for that. In the meantime use the code completion in FreePIE

[NeoTokyo_Nori]

Hmm, chrome wont even give the option to ignore the warning... I will try IE.

Just out of curiousity
Have you had any situations where
keyboard.setKeyDown(Key)
keyboard.setPressed(Key)
does not fire as expected. Or has the reason for not firing, always been something else ?

Also, I am thinking of using Python Tools for Visual Studio
http://pytools.codeplex.com/
and see if it will help me dubug the code better..

[CyberVillain]

To debug FreePIE all you need is Visual studio and the source code from github.

I must admit that I havent used setKeydown that much, only setKey and it works from within games, but not in notepad for some reason

[CyberVillain]

Small update to get FreePIE working with latest vjoy driver
Also fixed a comestic bug causing code completion popup missalign in Windows 8

[CyberVillain]

Due to a human error (me) the latest SDK for vjoy did not find its way into the latest release, sorry for that, will fix!

[CyberVillain]

New release with vjoy fix this time ALso migrated file hosting to Github releases.

[Keling]

New release with vjoy fix this time ALso migrated file hosting to Github releases.

The new build appears to be throwing function missing errors in Microsoft Scripting plugin on my Win7 system.

Code: Select all

"System.Collection.Generic.IEnumerable\1<!!0> Microsoft.Scripting.Utils.ReflectionUtils.GetCustomAttributes(System.Reflection.Assembly, Boolean)"

BTW, the new vJoy release added initial support for FFB. Is this implemented in FreePIE at the moment?

[CyberVillain]

I updated the python engine for 1.8 probably has todo with that, but it did work on the machines that I tested (win7 x64 and w8 x64).
Will look into it

I have missed that they have Force feedback support, but what good does that do when its a virtual stick?

edit: aha, you want to send the signal somewere else offcourse.

[Keling]

I updated the python engine for 1.8 probably has todo with that, but it did work on the machines that I tested (win7 x64 and w8 x64).
Will look into it

I have missed that they have Force feedback support, but what good does that do when its a virtual stick?

edit: aha, you want to send the signal somewere else offcourse.

I used the installer to overwrite the old version directly and something leftover confused the new version. Did a clean install, everything is fine now.

Sorry about the false alarm.


As for FFB in a virtual controller, I'm thinking about using vJoy/FreePIE as the middle man to modify FFB on the fly before passing onto a real FFB device, filtering effects in ways the application itself doesn't support. It's also possible to add FFB controlled behavior to non-FFB physical controller setups. Think about using mouse steer in a driving game with the FFB causing the wheel to shake for example.

[CyberVillain]

Do you know where the docs are for FFB? Didnt find anything on vjoy page (Just looked quick since Im at work). I guess there most be a API for getting FFB data and antoher API to send it to a real joystick?

edit: Hmm, or sending it to the real joystick should offcourse be the joystick plugin, it does not support FFB so thats has to be fixed too

[Keling]

Do you know where the docs are for FFB? Didnt find anything on vjoy page (Just looked quick since Im at work). I guess there most be a API for getting FFB data and antoher API to send it to a real joystick?

edit: Hmm, or sending it to the real joystick should offcourse be the joystick plugin, it does not support FFB so thats has to be fixed too

Not sure about doc but you can take a look at the FFB Monitor Demo, which seems to be quite self-explanatory. The discussion here and here will also help.

Yeah, FreePIE would have to handle FFB output on its own. vJoy only provides FFB input from source application.

[CyberVillain]

I'm busy as hell, but I will add it to the todo list (Hint, we need more devs!)

https://github.com/AndersMalmgren/FreePIE/issues/48

[CyberVillain]

What is the software with the smallest footprint to test force feedback with? A game demo, some kind of utility etc?

[Keling]

What is the software with the smallest footprint to test force feedback with? A game demo, some kind of utility etc?

Demo against full game would only reduce download time and hard drive usage. Is that what you want to achieve?

If you want a very controllable FFB input for debugging, an in-game spring effect would be close to idea. You only have to hold your controller at different positions (A vJoy device controlled by the feeder demo will do. No need for a physical FFB device.) and the FFB input would change accordingly. I'll see if I can find a small game which supports that.

[CyberVillain]

Yes, I dont want to install a huge game on my dev.machine, plus its a virtual machine so it cant do hefty graphics.

Anyway, FFB support in vJoy is not released, its still in the experimental branch. Plus the C# wrapper SDK does not have the support yet.

I have a Logitech gamepad with rumble feature, I guess that uses the FFB interface so could use that to test FFB with the joystick-plugin

[BOLL]

Just got into FreePIE and Python It's fun! But, as mentioned above I also have problem with keyboard.setKeyDown(), I'll explain

Looping over setKey works for emulating WSAD with a stick (running xbox360 controller), but looping over it for things like the start button makes menus jump up and down frantically.

This is when I looked to use setKeyDown so I can just simulate holding a key, but. If I keep setKeyDown in the loop it acts as setKey and presses the key every cycle.
If I add a global state it only presses the key once, then it doesn't hold it down. In notepad it only becomes the one character it never starts repeating. So to me it seems like it's acting exactly like setKey o.O Hmm?

I can post code if you want to, but would have to slim it down a bit probably

Edit: Uhoh, discovered the start button on an Xbox360 pad spams in notepad (and games) but not the back button, apparently the different buttons act differently o____O huh... weird. Easily fixed with a function though.

Code: Select all

def singlePress(control, key, state):
	global b
	if( control and not b[state] ):
		keyboard.setKey(key, 1)
		b[state] = 1
	elif( not control ):
		b[state] = 0

Sure are some quirks to this, haha.

[DrDim]

Hi there! I have a small request!

There was a page on the wiki that contained a reference for basically "everything" FreePIE. That used to be very helpful for creating scripts.
For some reason I can't find that page anymore. Maybe it got pulled from the wiki, because it was outdated? Anyway I pledge for a new "dump" of all FreePIE inputs for reference.

[CyberVillain]

Just got into FreePIE and Python It's fun! But, as mentioned above I also have problem with keyboard.setKeyDown(), I'll explain

Looping over setKey works for emulating WSAD with a stick (running xbox360 controller), but looping over it for things like the start button makes menus jump up and down frantically.

This is when I looked to use setKeyDown so I can just simulate holding a key, but. If I keep setKeyDown in the loop it acts as setKey and presses the key every cycle.
If I add a global state it only presses the key once, then it doesn't hold it down. In notepad it only becomes the one character it never starts repeating. So to me it seems like it's acting exactly like setKey o.O Hmm?

I can post code if you want to, but would have to slim it down a bit probably

Edit: Uhoh, discovered the start button on an Xbox360 pad spams in notepad (and games) but not the back button, apparently the different buttons act differently o____O huh... weird. Easily fixed with a function though.

Code: Select all

def singlePress(control, key, state):
	global b
	if( control and not b[state] ):
		keyboard.setKey(key, 1)
		b[state] = 1
	elif( not control ):
		b[state] = 0

Sure are some quirks to this, haha.

Yes FreePIE does not emulate keyboard outside of games perfect, I never have the time to investigate into it :/ We use

setKey on the global (the object accessible from script) is doing this

Code: Select all

        public void setKey(Key key, bool down)
        {
            if (down)
                plugin.KeyDown((int) key);
            else
                plugin.KeyUp((int) key);
        } 

KeyDown on the plugin does

Code: Select all

        public void KeyDown(int code)
        {

            if (!MyKeyDown[code])
            {
                //System.Console.Out.WriteLine("keydown");
                MyKeyDown[code] = true;
                int scancode = ScanCodeMap[code]; // convert the keycode for SendInput

                var input = new MouseKeyIO.INPUT[1];
                input[0].type = MouseKeyIO.INPUT_KEYBOARD;
                if (ExtendedKeyMap[code])
                    input[0].ki = KeyInput((ushort)scancode, MouseKeyIO.KEYEVENTF_EXTENDEDKEY);
                else
                    input[0].ki = KeyInput((ushort)scancode, 0);

                MouseKeyIO.SendInput(1, input, Marshal.SizeOf(input[0].GetType()));

            }
        }

So it looks like KeyDown is allready doing what you are doign from script?

[CyberVillain]

Hi there! I have a small request!

There was a page on the wiki that contained a reference for basically "everything" FreePIE. That used to be very helpful for creating scripts.
For some reason I can't find that page anymore. Maybe it got pulled from the wiki, because it was outdated? Anyway I pledge for a new "dump" of all FreePIE inputs for reference.

Yes, I forgot to check that code into GIT thats why, need to rewrite it, until then, press ctrl+space in the editor in FreePIE and the same reference will be presented

[DrDim]

Hi there! I have a small request!

There was a page on the wiki that contained a reference for basically "everything" FreePIE. That used to be very helpful for creating scripts.
For some reason I can't find that page anymore. Maybe it got pulled from the wiki, because it was outdated? Anyway I pledge for a new "dump" of all FreePIE inputs for reference.

Yes, I forgot to check that code into GIT thats why, need to rewrite it, until then, press ctrl+space in the editor in FreePIE and the same reference will be presented

Ah! That will do it as well! Thank you!

[CyberVillain]

Here it is also https://github.com/AndersMalmgren/FreeP ... /Reference

[BOLL]

So it looks like KeyDown is allready doing what you are doign from script?

Yeah, setKey() seems to work as intended on all buttons except the Start button (which I mentioned in passing) on the Xbox360 pad. The Start button just keeps repeating the input it's bound to like if it had auto-fire enabled, not sure if that is just how the controller works or if it's a glitch in the plugin... ? O.o Well, I've worked around it anyway

[CyberVillain]

There is a difference between your code and the freepie native code, you also check if control is set (is a bool telling if Control key i pressed?).

[BOLL]

Ah, that is just an in parameter to the function, I've since renamed it 'button' :p I've made this to work with an Xbox360 controller, I will post my entire script on my blog as soon as I've finished writing up the project page

Edit: here it is!

[CyberVillain]

Its been way to long since last release. Sorry for that. Here is a new version. Biggest addition is Tobii EyeX support