Open-source macro programming library

Advanced search

Help us keep Viperpit alive !

[lightning]

Is that kind of what you guys are doing? 

That would be one possible application of a macro toolkit...though that would be simpler to do using a batch file unless you need to interact with dialog boxes, etc. in the process of loading the program...in which case you can download any of a million freeware Windows macro recorders that will let you record keystrokes and mouse movements and script application launches, etc...that'd be the best type of tool for that particular job.

The macro toolkit I'm working on is not really specifically designed for that type of job -- there's plenty of tools out there that do that sort of thing already, and that do it well. The toolkit I'm building has the goal of bringing powerful scripting capabilities to cockpit hardware and simulations in general.  

Today, most gaming hardware will let you generate keystrokes or mouse movements, but that's about the limit of things...and for a lot of us, that is no big deal, for many things, that's all the power we really need.  But there are times when you want to do more.  

If you want your scripts to be aware of and respond to values that are present in the simulation (like those that can be found in the shared memory), you are not going to get that with the simplistic keystroke and mouse emulation tools that are out there.  Today, you get to write your own tool to do that.

Also, if you want to control the actual analog axis and digital "button"/switch values that the sim sees, right now, in most cases, you are pretty limited in that regard as well-- the sim either sees an analog axis directly, or it doesn't see it at all.

This brings up an interesting concept, which is that of "virtualization".  Essentially, what I mean when I say virtualization is that, in general, the sim should never see the cockpit hardware directly.  Instead, the sim sees inputs that it *thinks* are physical, but which are actually being generated by a software program.  That software program, in turn, sees the actual physical hardware (switches, knobs, lights, etc.).  This gives you an incredible amount of control over what the sim actually sees.

Today, to get that level of control, you have to be a programmer.  And many programmers in this community have built such tools for interfacing with EPIC, etc.  But these kinds of tools tend to be fairly limited, in that they are a.) tied to one particular piece or brand of hardware, and b.) aren't very customizable.  If you want to do something with those tools that the designer didn't think of, you're generally screwed.

There are hardcore guys in this community that create their own custom software to control their own pits, but most of that software is 100% tied to the specific hardware that they are using, and so it can't be easily re-used by others who are running different stuff.

We should be able to go one better than that, as a community, if enough people are using a common framework for writing those kinds of programs.  And those are what I'm calling "macros", for lack of a better word, since any of the really dirty work programming should be taken care of by the tools framework itself, leaving a very simple job for the programmer who just glues together little parts of code to make a simple, shareable, program that anyone can run on their own setup.  

And, the thought goes, you, the user, should be able to customize this stuff, infinitely, to your own tastes.

Anyway, I'm probably doing a lousy job of articulating the vision for this project, which extends quite a bit further than the cockpit building community and into the space of automation products and robotics, in general, but that's another story for another time.  

[kdittyr]

We have to use a gazillion log in screens and accounts to get to one application at work.  I have a macro setup on my PC that lets me just do one click and it does everything else.  Is that kind of what you guys are doing?  I had thought about using a macro that would start up my F4IM, Falcon, G15 Viper, FalconGauges etc.... at one click of a button and that would take some of the PITA out of firing everything up to get in a sortie.....that is if I can make it work....

I actually hardcoded one for myself a few weeks ago...  It loads up trackIR, then G15 Viper (thanks Airdance) and then OF.  The only thing it doesn't do is setup my x52.  The reason I did it was because I kept starting OIF and realizing that I forgot one of the other programs that I always use.

I do agree with lightning that a batch file would be just as easy to do, though.

Or if you have a G15 (I imagine you might because I see g15 viper in your lineup) you can LUA script a macro and have it do all of the mouse movements and button clicks that you might require.

As a matter of fact, you can use the shift, alt, ctrl keys in many different configurations along with the G buttons.  I mean you can script the G1 key to raise your gear, then hit shift+G1 to do a completely different keystroke.  Then if you multiply that with the M buttons you can see that you can really start racking up the number of keystrokes that you can achieve with the G keys.  I actually use my G keys (in OF) to handle modifier keys... I hated trying to fly and hit shift+alt+ctrl+a or whatever so I made the modifiers a one key press and then I just hit the other key that I need. 

If you want an example of multiplying your G keys let me know and I will post an example.

[Jarrod66]

 :lolsign:I can tell that I made myself sound much smarter than I am...LOL....the application at work has a built-in macro generator and it is as easy as one two three.....

I really like the batch file Idea....Could you post a copy of your batch file Bruce, just to give us a direction to create one?

[AiRdAncE]

I have a G15 keyboard which has it's own programmable macro's....

Just kidding guys, ignore my comment

[kdittyr]

Jarrod66, you could do something simple like this:

You would create a new text file and then copy and paste this into it.  Then rename it as a .bat file (test.bat or something like that)

Code:

START c:\WINDOWS\notepad.exe
START c:\WINDOWS\system32\calc.exe
cd c:\Program Files\Windows NT
START pinball.exe

This simple bat file will open up notepad, then calc and then pinball (if you are using XP these should all work for you).  You will notice the first two exes are being called directly and the last one has a cd (change directory) in it... that is because I wanted to show you how to get to a folder that has spaces in it.  I know there is a little easier way, but it has been so long since I played with bat files that I don't remember much about them.  Oh yeah, you can only rename the text file to a bat file if you have enabled windows to show file extensions (My Computer -> Tools -> Folder Options -> View -> Uncheck – “Hide Extensions for Known File Types”)

Then if you want to make changes to the bat file just right click and then click "edit".

Anyway, if you need more help PM me and I will write it for ya.

[PapaJ]

Hi all,
i made my batch file today to start diff progs all together.
Thx for that batch programming instructions kdittyr. I always thought it would be hard stuff and never tried it before.

My question now:
is it possible to launch some buttons after exe start via batch?
For example is it possible to start File=>Open=>Profiles=> select profile and so on in Shoot via easy batch programming?

Thx PapaJ

[lightning]

Not using regular batch files, no. You can download a freeware Windows macro recorder and that should do the trick.  I can't recommend a good one, but feel free to download a few and try 'em out and see what works best for your tastes.

[Ka-Bar03]

If you can load the profile via a command line, a batch file should work, ie.. c:\shoot.exe_profile_falcon4

not sure if Shoot allows you load a profile this way

[lightning]

Here's an open-source Falcon keyfile reader/writer library for .NET & COM.  When I get some time I'll add inline Sandcastle/NDoc documentation.  It's almost too simple to really need it...

The main class is F4KeyFile.KeyFile, which has  Load() and Save() methods on it which read from or save to a Falcon keystrokes.key file.  The KeyFile class provides a Bindings collection, each entry of which corresponds to a single line in the loaded Falcon keystrokes.key file. 

A Binding can be either a KeyBinding, a DirectInputBinding, or a CommentLine.  Any of the Binding's .ToString() methods will produce a string that can go in a keyfile; the .Parse() methods take a string from the keystrokes.key file, and return the respective type of Binding object. 

You can, Load() a file, programmatically make changes to its Bindings (add, edit, or remove them), and then Save() the new file somewhere.  Additionally, the library provides an enumeration of all the relevant Falcon keycodes as well as an enumeration of all the known Falcon callback names across versions (quite long, over 1000 entries; not used internally, for version safety reasons).

The library will handle any flavor of keystrokes.key file, ranging from the original Falcon 4.0 flavor, to BMS, to F4AF, to OpenFalcon, but you will need to make sure to handle the format differences in your own code (specifically, in Allied Force, the DirectInput bindings have GUIDs indicating which joystick on the system the binding applies to, whereas non-Allied Force Falcon versions use the ButtonIndex property to determine which joystick the binding applies to (0-31 is the first joystick, 32-63 is the second joystick, etc.).

Here is the Visual Studio 2005 project containing the source code (C#) and binaries.

Edit: New version v1.1 is now CLS-compliant and COM-visible.  It can be used not just from .NET languages but from COM languages such as VB6, etc. as well.  Static .Parse() methods on Binding objects have been converted to non-static methods to allow use from COM. Unsigned integer enumerations have been changed to signed integer enumerations to allow for CLS compliance.  Public default constructors now exist on all classes to allow for COM visibility. 

edit:Removed attachment from this thread, as it is now hosted on my Assembla workspace.

[lightning]

Here's an open-source reader for the Textures Shared Memory as available in OpenFalcon.  Supports .NET- and COM-compliant programming languages.  Comes with a Windows Forms-based tester program that reads the bitmap from shared memory and displays it in a form, updating the image every 20ms.  The bitmap itself contains the HUD, the left and right MFDs, and the DED.

Very easy to use, you just create an instance of the F4TexSharedMem.Reader class, then loop until the .IsDataAvailable property becomes true, indicating that Falcon has entered the 3D pit and has placed a bitmap in shared memory.  Then read the .FullImage property or call the  .GetImage method to get a Bitmap object that you can assign to a PictureBox in a Windows Forms application.  To update the image, just call the .Refresh() method on the PictureBox as often as you want.  It's that simple. 

Notes:

* When used with a PictureBox control, there's no need to continually re-read the .CurrentImage property to update the Bitmap, as the Bitmap will update itself when the PictureBox is Refresh()ed. 

* The F4TexSharedMem.Reader class implements IDisposable, so you should make sure to call the .Dispose() method on the Reader when you're done using it, so that the shared memory handle can be released. 
    -- In C#, you can use a

     using (F4TexSharedMem.Reader reader = new F4TexSharedMem.Reader())
   {
   }

 block to ensure that the Reader gets disposed properly.  (In a Windows Forms application, you would normally call .Dispose() in the form's Closing event handler.)

* Don't Dispose() of the Reader while you still want your Bitmap to update itself -- the memory it uses is within the shared memory area and if you close/Dispose() the Reader, your bitmap won't have any source data and you'll probably get an AcessException.

This is only known to work in OpenFalcon (your mileage may vary!)  For this to work, the textures shared memory area must be enabled in the FalconBMS.cfg file by adding the following lines to the end of the file:

Code:

set g_nRTTExportBatchSize 9
set g_bExportRTTTextures 1

g_nRTTExportBatchSize must be set to >=2 and bExportRTTTextures must be set to 1 for this to work. 

Higher values for the g_nRTTExportBatchSize option will result in better in-game FPS rates with fewer updates being made made by Falcon to the textures shared memory.  Lower values will worsen the in-game Falcon performance, but the shared memory textures will be updated by Falcon more frequently.

Also, this only works when the user is in the 3D pit.  When the user exits the 3D pit, no further image data is placed in the shared memory until the user re-enters the 3D pit.  At that point, you'll most likely retrieve the last image that was placed into the shared memory.

Enjoy

Edit: Removed attachment from the thread, as all my downloads and tools are now hosted on my Assembla workspace. 

[bismond]

Lightning
             I love hearing you scraping that hud 3d and of course the mfd's. I have a question slightly off topic. How can I pull ded data using c# with your macro program? I want to feed it to this

https://www.littlepcbsolutions.com/uUSB-CE5.html

which I guess uses a series of simple commands and hex values. Thanks

[lightning]

Lightning
             I love hearing you scraping that hud 3d and of course the mfd's. I have a question slightly off topic. How can I pull ded data using c# with your macro program? I want to feed it to this

https://www.littlepcbsolutions.com/uUSB-CE5.html

which I guess uses a series of simple commands and hex values. Thanks

First, use my F4TexSharedMem .DLL to grab the bitmaps that you want from shared memory (using the .FullImage property or the .GetImage() method [the latter requires specifying a rectangle to extract from the equivalent .FullImage])

You can then serialize the bitmap to a byte array by creating a System.Io.MemoryStream object, and calling the Bitmap's .Save() method to save the Bitmap to the MemoryStream.

Now, the particular device you mentioned actually shows up to the PC as a standard COM port, so you don't have to mess around with the USB HID stuff at all.  It's much easier. 

To send the byte array over the serial port, use the System.Io.Ports.SerialPort object described here:

http://msdn2.microsoft.com/en-us/library/system.io.ports.serialport.aspx

You'll, of course, need to send any protocol-specific data across the wire first to whatever the receiving device is, in the format that the receiving device expects it to be in. 

To write your image data to the serial port, you'll want to use the .BaseStream property on the SerialPort object to write the bytes from your MemoryStream(you can wrap the SerialPort's .BaseStream in a StreamWriter to make it easier).

[bismond]

Thanks for the info. Now what if I wanted just the raw data values in falcon ie com freqs fuel to home plate ect that are displayed on the ded simular to what fsuipc does in MS flightsim instead of a bitmap?

[lightning]

Thanks for the info. Now what if I wanted just the raw data values in falcon ie com freqs fuel to home plate ect that are displayed on the ded simular to what fsuipc does in MS flightsim instead of a bitmap?

For that, you'll want to use the original (non-textures) Shared Memory Reader library.  Create a F4SharedMem.Reader class, then get the .DEDLines[] array which is just an array of strings, one entry per line on the DED.  Also, there's another array called .Invert[], which matches the DEDLines[] array, and which specifies which characters on each DED line are to be shown in an inverted color. 

Let's say we're looking at the first DED line (i.e., DEDLines[ 0 ]).  Then, if, say, the 5th character in the Invert[ 0 ] string is hex value 0x02, then the 5th character of the first DED line is to be shown in an inverted color.

The same concept applies to the PFLLines[] and PFLInvert[] arrays. 

One other thing to note, as far as the DEDLines[] and PFLLines[]  arrays are concerned, there are some special characters that can show up there like the up/down symbol, etc. 

The DED strings are mostly plain old strings, except for two things:
In cases where a star-like character is drawn to highlight a selection, one that can be edited for example, the game places a 0x02 (hex two) value to represent that. In Falcon's weird fonts, that appears to be the star-like glyph. Secondly, where you would ordinarily see the up/down arrow thingy that indicates a value that can be changed with the rocker that has the up and down arrows on it, you will see a 0x01 (hex one). Again in Falcon's font that means that particular up/down arrow glyph.
These values of 0x01 and 0x02 are obviously not printing characters in the usual sense. Thus the DED lines cannot be treated as straight strings (as you would for printf() arguments or something) without either: a) fixing them up first; or b) rendering them char by char as opposed to via string handling routines.
The inverted lines are yet odder. For reasons that aren’t clear, even after inspecting the code, the only thing you care about is where you see a 0x02 (two) value: this means the corresponding char in the DEDlines array is to be rendered reverse video. Anything else you see in the invert lines (nulls or spaces; don't ask me why spaces..perhaps someone changed their minds halfway through coding this in the original game or something), you can safely ignore.

Now I've already done the work, right inside the Shared Memory Reader, of cleaning up the Invert and PFLInvert lines so the only values you'll find in those lines are either 0x02 characters or space characters. 

As far as sending this data over the serial port, you'll have to take into account the data protocol that the device attached to the other side of your RS232 link wants you to use...I'm going to assume you're using a character-based LCD there.  In this case, you'll have to parse the DEDLines[] and PFLLines[]  arrays manually, taking into account the values in the Invert[] and PFLInvert[] arrays, to determine what commands to send to the character LCD.  Those commands will typically just be byte values that you pass along to the System.Io.Ports.SerialPort via the .BaseStream.

You'll probably also need to, first, initialize the LCD screens with a font that can render those special characters in the DEDLines and PFLLines strings.  Every LCD manufacturer has their own protocol for setting up fonts and for sending text to the screens...all that info would be in the data sheet for the particular LCD screen you're using.

[lightning]

Got a bunch of little updates to make here to the programming tools and libraries -- the uploads will happen over the next couple hours.
Edit: Everything's live now.

 None of the changes made here should break any of your code that you may have built around these libraries, but you will need to update to the latest versions and re-link to the new versions in your projects.  The only breaking changes should be where static methods have been made non-static and where unsigned integer enums have been changed to signed integer enums to support CLS-compliance and COM-visibility.

* I've updated the F4 Shared Memory Reader Library to finally read the OSB labels from OpenFalcon correctly.  The new release also now reads the rpm2, ftit2, nozzlePos2, and oilPressure2 values correctly as well.

* I've expanded the F4 Textures Shared Memory Reader Library to allow reading the individual separate images for the HUD, DED, and left and right MFDs as well as the combined image.  This allows for greater flexibility and performance for reader applications, and makes it a bit easier to use, as well.  You just specify a rectangle to extract from the within the main shared memory image (or you can get the FullImage, if you want that)

* I realized that several of the various libraries would have issues, as compiled, when running on 64-bit platforms.  So for now, those libraries are released only in their 32-bit forms.  I've recompiled all of them so that they specify this directly in the assembly's metadata.  That means that if you use any of them in your own code, your executables should also specifically target 32-bit platforms.  Later updates may include explicit 64-bit support.  All of these latest releases should *work* on 64-bit platforms, but they will run as 32-bit executables.  This does *not* create performance problems, it solves compatibility problems.

* I've made all the libraries (except the Beta Innovations SDK .NET Wrapper Library) CLS-compliant, which means you can use them from any .NET language, not just C# or VB.NET.  In addition, I've made all the libraries (except the Beta Innovations SDK .NET Wrapper Library) COM-visible. 

This means you can use these libraries from old-school COM languages like good old VB6, or any COM-compliant programming language, not just .NET languages.   

I didn't make the BetaInnovations SDK .NET wrapper COM-visible, because the Beta Innovations SDK ships with enough samples for VB6 and C++ (the two major COM development languages) that it's not really needed -- you just call the BISDK.DLL directly in those cases.  It's also not CLS-compliant because of the use of unsigned integer types.  Despite this, VB.NET should still be able to use the Beta Innovations SDK .NET wrapper just fine.  Some obscure .NET languages may not be able to.

The 2 applications, JoyMapper and the Falcon MFD Extractor, that are currently built using these libraries, will be updated to use the newer versions at the next release cycle for each of those applications, both of which are expected to happen very soon.

Also, the code library which was the subject of this thread initially, the macro programming library, has had its release delayed for a bit, as I've been quite busy with the MFD Extractor and that is a priority at the moment as well as creating a code library to support the PHCC hardware. 

The latest versions of everything can be found in Lightning's Free Tools and Utilities.

19:39 UTC
September 03,2010

Bones308th (41)

Ka-Bar03 (5074)
AiRdAncE (3955)
Crease-Guard (2725)
Nigel (2387)
Red Dog (2330)
Kneeling Warrior (2326)
Nikolas_A (2148)
lightning (2126)
101-Douxx (2024)
Flareless (1708)