Page 10 of 11

Re: FreePIE official thread

Posted: Wed Dec 03, 2014 1:55 am
by 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

Re: FreePIE official thread

Posted: Wed Dec 03, 2014 12:03 pm
by konstantin_lozev
CyberVillain wrote: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...

Re: FreePIE official thread

Posted: Thu Dec 04, 2014 3:53 am
by 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.

Re: FreePIE official thread

Posted: Thu Dec 04, 2014 3:56 am
by 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

Re: FreePIE official thread

Posted: Thu Dec 04, 2014 6:36 am
by konstantin_lozev
CyberVillain wrote: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.

Re: FreePIE official thread

Posted: Thu Dec 04, 2014 8:57 am
by 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

Re: FreePIE official thread

Posted: Thu Dec 04, 2014 9:12 am
by NeoTokyo_Nori
CyberVillain wrote: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 :)

Re: FreePIE official thread

Posted: Thu Dec 04, 2014 2:55 pm
by 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 :(

Re: FreePIE official thread

Posted: Sat Dec 13, 2014 3:04 am
by konstantin_lozev
NeoTokyo_Nori wrote:
CyberVillain wrote: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.

Re: FreePIE official thread

Posted: Sun Dec 14, 2014 4:59 am
by 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

Re: FreePIE official thread

Posted: Mon Dec 15, 2014 12:48 am
by konstantin_lozev
CyberVillain wrote: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...

Re: FreePIE official thread

Posted: Mon Dec 15, 2014 2:01 am
by CyberVillain
Yes many games have "digital" (on/off only) movement even with gamepad

Re: FreePIE official thread

Posted: Tue Dec 23, 2014 2:47 pm
by konstantin_lozev
konstantin_lozev wrote: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.

Re: FreePIE official thread

Posted: Wed Jan 21, 2015 2:36 pm
by CyberVillain
New version out! MIDI and some other stuff

Re: FreePIE official thread

Posted: Fri Jan 23, 2015 4:10 am
by NeoTokyo_Nori
CyberVillain wrote:New version out! MIDI and some other stuff
Hi CV, thanks for the update. 8-)
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.

Re: FreePIE official thread

Posted: Fri Jan 23, 2015 6:17 am
by 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

Re: FreePIE official thread

Posted: Fri Jan 23, 2015 7:00 am
by 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..

Re: FreePIE official thread

Posted: Fri Jan 23, 2015 7:08 am
by 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

Re: FreePIE official thread

Posted: Mon Jan 26, 2015 2:57 pm
by CyberVillain
Small update to get FreePIE working with latest vjoy driver
Also fixed a comestic bug causing code completion popup missalign in Windows 8

Re: FreePIE official thread

Posted: Tue Jan 27, 2015 3:19 am
by 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!

Re: FreePIE official thread

Posted: Tue Jan 27, 2015 2:28 pm
by CyberVillain
New release with vjoy fix this time :D ALso migrated file hosting to Github releases.

Re: FreePIE official thread

Posted: Wed Jan 28, 2015 1:19 am
by Keling
CyberVillain wrote:New release with vjoy fix this time :D 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?

Re: FreePIE official thread

Posted: Wed Jan 28, 2015 1:53 am
by 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? :D

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

Re: FreePIE official thread

Posted: Wed Jan 28, 2015 2:13 am
by Keling
CyberVillain wrote: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? :D

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.

Re: FreePIE official thread

Posted: Wed Jan 28, 2015 2:26 am
by 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

Re: FreePIE official thread

Posted: Wed Jan 28, 2015 3:13 am
by Keling
CyberVillain wrote: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.

Re: FreePIE official thread

Posted: Wed Jan 28, 2015 3:30 am
by 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

Re: FreePIE official thread

Posted: Thu Jan 29, 2015 6:20 am
by CyberVillain
What is the software with the smallest footprint to test force feedback with? A game demo, some kind of utility etc?

Re: FreePIE official thread

Posted: Thu Jan 29, 2015 6:51 pm
by Keling
CyberVillain wrote: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.

Re: FreePIE official thread

Posted: Fri Jan 30, 2015 3:37 am
by 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

Re: FreePIE official thread

Posted: Sat Feb 14, 2015 6:16 am
by BOLL
Just got into FreePIE and Python :P It's fun! But, as mentioned above I also have problem with keyboard.setKeyDown(), I'll explain :D

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 :P

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.

Re: FreePIE official thread

Posted: Sat Feb 14, 2015 10:13 am
by 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.

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 5:44 am
by CyberVillain
BOLL wrote:Just got into FreePIE and Python :P It's fun! But, as mentioned above I also have problem with keyboard.setKeyDown(), I'll explain :D

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 :P

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?

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 5:48 am
by CyberVillain
DrDim wrote: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

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 6:46 am
by DrDim
CyberVillain wrote:
DrDim wrote: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!

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 8:02 am
by CyberVillain

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 9:51 am
by BOLL
CyberVillain wrote: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 :P

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 10:46 am
by 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?).

Re: FreePIE official thread

Posted: Sun Feb 15, 2015 11:28 am
by 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 :D

Edit: here it is! :P

Re: FreePIE official thread

Posted: Fri Aug 21, 2015 2:26 am
by CyberVillain
Its been way to long since last release. Sorry for that. Here is a new version. Biggest addition is Tobii EyeX support