FreePIE Console

[brantlew]

I added a console version of FreePIE to the project at GitHub that eschews the GUI in favor of a simple command line interface. It's not released as a binary so you will have to compile it if you want to use it. The benefits of this interface are simplicity and stability.

FreePIEConsole.jpg

I stopped using FreePIE in favor of GlovePIE a few months ago because of a lot of strange behavior that seemed connected to the GUI. In particular I notice the following non-repeatable issues while I am running a game:

- loss of polling updates when I minimized the FreePIE window and then a return of updates when the window was restored.
- mouse "capture" behavior where the mouse emulator would move extremely slowly as a moved the mouse across the FreePIE window and then back to normal speed as I moved out of the window bounds
- worst of all - CRASHES! Lots of them.

FreePIE uses a nebulous black-box window framework called Caliburn Micro for the GUI, which in-turn utilizes another equally nebulous architecture called WPF. There is a complicated dance of interactions between these software layers which is difficult for me to trace, but my understanding is that WPF hooks into DirectX and contends for graphic resources. So maybe it's clashing with the game that is also using DirectX? I don't know? Whatever is going on - I finally just decided to try and skip all those issues and remove the GUI. After all, FreePIE is at its heart - a simple polling loop and device interface. Once your scripts are written, the GUI editor is not necessary.

So with the console version you just need to type "FreePIE.Console myscript.lua" and it will execute your script. To stop the script just hit Ctrl-C and it will gracefully close. No fuss. BUT...the implementation is incomplete and there are still some nagging issue.

1. There is currently no way to set properties. For example, if you need to configure a COM port number there is no way to do it now. Eventually this will just be a command line parameter but it's unimplemented now.

2. There is no graceful exception handling yet, so if your script fails you won't know about it. It's better to develop your scripts in the editor and run them once they are stable.

3. I still notice some wacky mouse "capture" behavior when running the console. But at least now it's repeatable. So basically mouse emulation scaling acts totally different if you run a script from the GUI versus the console version. I have no idea why and I haven't investigated yet - but I just want to throw it out there so you will know that scripts developed in the editor will not operate the mouse exactly the same when you run them in console. Eventually the polling architecture needs to be redesigned and completely decoupled from the GUI. We should have proper polling threads running at constant frequencies that make scripts act the same on different machines and different environments. I consider this a massive flaw in the FreePIE design and will fix it eventually when I get some time.

[CyberRascal]

Sounds good. It makes a lot of sense to be able to run FreePIE as a command line application. Have you removed the GUI project completely from your fork? I think it might be worthwhile to add the command line utility to the main FreePIE fork and maintain it simultaniously with the core project.

I would like to look closer at the mouse polling issues you are having. If you still experience the issues when running a console app, it seems like the problem might lie in our code and not actually be caused by WPF.

We've managed to trace a issue that causes FreePIE to crash. Running a script that does nothing but update the UI crashes FreePIE after a variable amount of time, generally within a minute. It's unlikely that the fault is WPF's, since calling the same callback from managed code does not crash the process.

I am assuming that either the LuaInterface library has flawed marshalling of callbacks to unmanaged code, or the issues lies in a subtle mistake in using the API. That the crash only occurs when running WPF is probably because the WPF code is relatively large, and the buffer overrun manages to overwrite vital data (or marker bytes).

Because of these issues, I am currently exploring other script languages... I am actually looking at C# right now. I'll make a separate thread about that in due time.

Also: good work.

[brantlew]

I just checked it in as another sub-project of the main solution so it's on the main trunk. There's really nothing to it, so it will be easy to keep in sync with the GUI version. It just manually invokes all the magic interface creation and hooking code, and launches a polling thread.

The mouse thing is really strange to me. It acts differently when DirectX is activated versus when it's not. For example, I get ultra-slow mouse movement when in the desktop, but if I Alt-Tab to a game window the mouse goes full speed. Really strange. Maybe it's SlimDX related?

[cybereality]

This could come in handy, but it seems more of a stop-gap til those serious bugs are fixed in the FreePIE GUI.

[CyberVillain]

This could come in handy, but it seems more of a stop-gap til those serious bugs are fixed in the FreePIE GUI.

My plan is to fix so that scripts can be autoloaded into the GUI and started, but first we need to fix the stability problems.
Sadly it looks like we have to change script engine because the Lua wrapper we uses has some serious problems. We are looking into using managed code for scripting (C# or VB) CyberRascal will create a thread about it.

@Brantlew Nice work dude, you could move all code into a host class and use the IoC to inject the dependencies into the constructor of that class, that way you abstract the IoC from the actual code.
About the mouse are you writing to the mouse? That uses the win32 API right? Not SlimDX? Anyway, if its reading the mouse maybe try different capture levels?

[werther]

hi guys, I had to jump into this.
I am trying to run a script through a CMD like way. I mean I don't want to load the script only; I want to execute it directly and (if possible only) on cli.
As far as I see loading is possible but couldn't make it without GUI.

Any suggestion?
The console version as long as I understand should work like CLI only? If so, forgive me but I couldn't make it through and please guide me.

Thanks in advance.