RvEYoda

Yeah the issue seems to be that most devices don't necessarily report all their buttons ans DirectInput buttons (as you say cause DirectInput only supports 32 buttons and 8 axii per device!) For example my X52 throttle (which I use together with an fssb r2 cougar stick) reports some buttons as a mouse by default etc. But I should be able to get around that :) I think I would prefer coding the "reading part" on my own, but if jinput has good facilities for inputing stuff back that would be nice, but I am already able to emulate keyboard buttons freely, so the question is only if jinput can create a virtual joystick device and emulate input from it.. One of the problems with Jinput when I used it last time is that it does not detect global input for all devices (only joysticks), so for example the input coming from the saitek mouse (that is part on the x52 throttle) would not be registered when the UPP is minimized if I used Jinput. Update: New OO test code running which basically allows me to map any arbitrary C++ function to a key event. #include "stdafx.h" #include "DID_headers.h" using namespace Yoda_DID; const size_t bufferSize_numItems = 20; DinputInterface dinputInterface; vector<DID_Joystick> joysticks = vector<DID_Joystick>(); vector<DID_Mouse> mice = vector<DID_Mouse>(); vector<DID_Other> others = vector<DID_Other>(); BOOL CALLBACK enumJoystickCallback(InputDeviceID, LPVOID); BOOL CALLBACK enumMouseCallback(InputDeviceID, LPVOID); BOOL CALLBACK enumOtherCallback(InputDeviceID, LPVOID); void releaseAllDevices(); void testBtn1P() { cout << endl << "PR btn 1"; } void testBtn1H() { cout << endl << "HL btn 1"; } void testBtn1R() { cout << endl << "RL btn 1"; } int _tmain(int argc, _TCHAR* argv[]) { // The DirectInput interface DirectInput8Create(GetModuleHandle(NULL), DIRECTINPUT_VERSION, IID_IDirectInput8, (void**)&dinputInterface, NULL); // Create the DirectInput devices dinputInterface->EnumDevices(DI8DEVCLASS_GAMECTRL, enumJoystickCallback, NULL, DIEDFL_ATTACHEDONLY); // Test some input joysticks[1].button(0).assignCallback_onKeyDown(&testBtn1P); // test callback to be displayed when button is first pressed down joysticks[1].button(0).assignCallback_onKeyHeld(&testBtn1H); // test callback to be displayed while button is held down (maybe someone needs this? ) joysticks[1].button(0).assignCallback_onKeyReleased(&testBtn1R); // test callback to be displayed when button is released bool toRun = true; while (toRun) { for (size_t i = 0; i < joysticks.size(); i++) { DID_Joystick& dev = joysticks[i]; dev.updateState(); if (dev.button(20).isPressed() && dev.button(23).isPressed()) { toRun = false; } } Sleep(1); } releaseAllDevices(); dinputInterface->Release(); _getch(); return 0; } void releaseAllDevices() { for (size_t i = 0; i < joysticks.size(); i++) { joysticks[i].release(); } for (size_t i = 0; i < mice.size(); i++) { mice[i].release(); } for (size_t i = 0; i < others.size(); i++) { others[i].release(); } } BOOL CALLBACK enumJoystickCallback(InputDeviceID id, LPVOID pvRef) { joysticks.push_back(DID_Joystick(dinputInterface, id, bufferSize_numItems)); return DIENUM_CONTINUE; } BOOL CALLBACK enumMouseCallback(InputDeviceID id, LPVOID pvRef) { mice.push_back(DID_Mouse(dinputInterface, id, bufferSize_numItems)); return DIENUM_CONTINUE; } BOOL CALLBACK enumOtherCallback(InputDeviceID id, LPVOID pvRef) { others.push_back(DID_Other(dinputInterface, id, bufferSize_numItems)); return DIENUM_CONTINUE; } and the output is _GUID DATA_ iguid.d1: 2519117328 iguid.d2: 63399 iguid.d3: 4574 iguid.d4: 0017F390 pguid.d1: 67109967 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0017F3A0 _DEVICE DATA_ devtype: 66068 prodname: Thrustmaster HOTAS Cougar instancename: Thrustmaster HOTAS Cougar _GUID DATA_ iguid.d1: 3723248736 iguid.d2: 25704 iguid.d3: 4576 iguid.d4: 0017F390 pguid.d1: 3008431183 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0017F3A0 _DEVICE DATA_ devtype: 66076 prodname: F16 MFD 1 instancename: F16 MFD 1 _GUID DATA_ iguid.d1: 3723248736 iguid.d2: 25704 iguid.d3: 4576 iguid.d4: 0017F390 pguid.d1: 3008496719 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0017F3A0 _DEVICE DATA_ devtype: 66076 prodname: F16 MFD 2 instancename: F16 MFD 2 _GUID DATA_ iguid.d1: 3833754032 iguid.d2: 48150 iguid.d3: 4574 iguid.d4: 0017F390 pguid.d1: 123471523 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0017F3A0 _DEVICE DATA_ devtype: 66328 prodname: Saitek X52 Flight Control System instancename: Saitek X52 Flight Control System PR btn 1 HL btn 1 HL btn 1 HL btn 1 HL btn 1 HL btn 1 HL btn 1 HL btn 1 RL btn 1

Success :) I can now read any axis and any button of any device Sample output: _GUID DATA_ iguid.d1: 2519117328 iguid.d2: 63399 iguid.d3: 4574 iguid.d4: 0033F6F4 pguid.d1: 67109967 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0033F704 _DEVICE DATA_ devtype: 66068 prodname: Thrustmaster HOTAS Cougar instancename: Thrustmaster HOTAS Cougar _GUID DATA_ iguid.d1: 3723248736 iguid.d2: 25704 iguid.d3: 4576 iguid.d4: 0033F6F4 pguid.d1: 3008431183 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0033F704 _DEVICE DATA_ devtype: 66076 prodname: F16 MFD 1 instancename: F16 MFD 1 _GUID DATA_ iguid.d1: 3723248736 iguid.d2: 25704 iguid.d3: 4576 iguid.d4: 0033F6F4 pguid.d1: 3008496719 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0033F704 _DEVICE DATA_ devtype: 66076 prodname: F16 MFD 2 instancename: F16 MFD 2 _GUID DATA_ iguid.d1: 3833754032 iguid.d2: 48150 iguid.d3: 4574 iguid.d4: 0033F6F4 pguid.d1: 123471523 pguid.d2: 0 pguid.d3: 0 pguid.d4: 0033F704 _DEVICE DATA_ devtype: 66328 prodname: Saitek X52 Flight Control System instancename: Saitek X52 Flight Control System Pressing button nr: 22 Pressing button nr: 22 Pressing button nr: 22 Pressing button nr: 20 Pressing button nr: 20 Pressing button nr: 20 Pressing button nr: 19 Pressing button nr: 29 Pressing button nr: 29 Pressing button nr: 29 Pressing button nr: 29 Pressing button nr: 29 Pressing button nr: 29 Pressing button nr: 6 Pressing button nr: 6 Pressing button nr: 6 Pressing button nr: 6 Test code below. Going to start working on buffered reading later or tomorrow: #include "stdafx.h" #include "conio.h" #include "iostream" #include "dinput.h" #include "vector" using std::vector; using std::cout; using std::wcout; using std::endl; typedef LPDIRECTINPUT8 DinputInterface; typedef LPCDIDEVICEINSTANCE InputDeviceID; typedef LPDIRECTINPUTDEVICE8 InputDevice; const size_t bufferSize_numItems = 20; HWND thisWindow; DinputInterface dinputInterface; BOOL CALLBACK addDevice(InputDeviceID device, LPVOID pvRef); vector<InputDevice> devices = vector<InputDevice>(); int _tmain(int argc, _TCHAR* argv[]) { // Check our app's window thisWindow = GetActiveWindow(); // The DirectInput interface const HRESULT res1 = DirectInput8Create(GetModuleHandle(NULL), DIRECTINPUT_VERSION, IID_IDirectInput8, (void**)&dinputInterface, NULL); if (FAILED(res1)) { cout << endl << "Creation of dx interface failed"; _getch(); return 0; } // Get the DirectInput deviceIDs const HRESULT res2 = dinputInterface->EnumDevices(DI8DEVCLASS_GAMECTRL, addDevice, NULL, DIEDFL_ATTACHEDONLY); if (SUCCEEDED(res2)) { // Create a device for each deviceID for (size_t i = 0; i < devices.size(); i++) { InputDevice dev = devices[i]; while (i==3) { dev->Poll(); DIJOYSTATE curState; dev->GetDeviceState(sizeof(DIJOYSTATE), &curState); /* cout << endl << curState.lX; cout << endl << curState.lY; cout << endl << curState.lZ; cout << endl << curState.lRx; cout << endl << curState.lRz;*/ // cout << endl << curState.lRy; if (curState.rgbButtons[21]) { break; } for (size_t i = 0; i < 32; i++) { if (curState.rgbButtons[i]) { cout << endl << "Pressing button nr: " << i; } } Sleep(1); } } // Release all memory and references for (size_t i = 0; i < devices.size(); i++) { devices[i]->Release(); } devices.clear(); } else { cout << endl << "Creating Device IDs failed"; } dinputInterface->Release(); _getch(); return 0; } BOOL CALLBACK addDevice(InputDeviceID id, LPVOID pvRef) { InputDevice dev = NULL; const HRESULT resDev = dinputInterface->CreateDevice(id->guidInstance, &dev, NULL); devices.push_back(dev); if(SUCCEEDED(resDev)) { wcout << endl << "_GUID DATA_"; wcout << endl << "iguid.d1: " << id->guidInstance.Data1 << endl << "iguid.d2: " << id->guidInstance.Data2 << endl << "iguid.d3: " << id->guidInstance.Data3 << endl << "iguid.d4: " << id->guidInstance.Data4; wcout << endl << "pguid.d1: " << id->guidProduct.Data1 << endl << "pguid.d2: " << id->guidProduct.Data2 << endl << "pguid.d3: " << id->guidProduct.Data3 << endl << "pguid.d4: " << id->guidProduct.Data4; wcout << endl << "_DEVICE DATA_"; wcout << endl << "devtype: " << id->dwDevType << endl << "prodname: " << id->tszProductName << endl << "instancename: " << id->tszInstanceName; wcout << endl; DIPROPDWORD dipdw; dipdw.diph.dwSize = sizeof(DIPROPDWORD); dipdw.diph.dwHeaderSize = sizeof(DIPROPHEADER); dipdw.diph.dwObj = 0; dipdw.diph.dwHow = DIPH_DEVICE; dipdw.dwData = bufferSize_numItems; dev->SetCooperativeLevel(thisWindow, DISCL_NONEXCLUSIVE | DISCL_BACKGROUND); dev->SetDataFormat(&c_dfDIJoystick); dev->SetProperty(DIPROP_BUFFERSIZE, &dipdw.diph); dev->Acquire(); } else { cout << endl << "Failed to create device"; } return DIENUM_CONTINUE; }

Began coding the stuff, but I've run into a strange problem. I've tried as best as I can to follow the directinput guides out there, here is what I have so far: #include "stdafx.h" #include "conio.h" #include "iostream" #include "dinput.h" #include "vector" using std::vector; using std::cout; using std::wcout; using std::endl; typedef LPDIRECTINPUT8 DinputInterface; typedef LPCDIDEVICEINSTANCE InputDeviceID; typedef LPDIRECTINPUTDEVICE8 InputDevice; BOOL CALLBACK addDevice(InputDeviceID device, LPVOID pvRef); vector<InputDeviceID> deviceIDs = vector<InputDeviceID>(); vector<InputDevice> devices = vector<InputDevice>(); HWND thisWindow; int _tmain(int argc, _TCHAR* argv[]) { // Check our app's window thisWindow = GetActiveWindow(); // The DirectInput interface DinputInterface dinputInterface; const HRESULT res1 = DirectInput8Create(GetModuleHandle(NULL), DIRECTINPUT_VERSION, IID_IDirectInput8, (void**)&dinputInterface, NULL); if (FAILED(res1)) { cout << endl << "Creation of dx interface failed"; _getch(); return 0; } // Get the DirectInput deviceIDs const HRESULT res2 = dinputInterface->EnumDevices(DI8DEVCLASS_GAMECTRL, addDevice, NULL, DIEDFL_ATTACHEDONLY); if (!FAILED(res2)) { // Create a device for each deviceID for each(InputDeviceID id in deviceIDs) { InputDevice dev = NULL; const HRESULT resDev = dinputInterface->CreateDevice(id->guidInstance, &dev, NULL); if (!FAILED(resDev)) { /*dev->SetDataFormat(&c_dfDIJoystick); dev->SetCooperativeLevel(thisWindow, DISCL_NONEXCLUSIVE | DISCL_BACKGROUND); dev->Acquire(); dev->Poll(); DIJOYSTATE curState; dev->GetDeviceState(sizeof(DIJOYSTATE), &curState); cout << endl << curState.lZ; devices.push_back(dev);*/ } else if(DIERR_DEVICENOTREG == resDev) { cout << endl << "Failed to create device"; } } // Release all memory and references for each (InputDevice dev in devices) { dev->Release(); } devices.clear(); } else { cout << endl << "Creating Device IDs failed"; } deviceIDs.clear(); dinputInterface->Release(); // Wait for test window to close _getch(); return 0; } BOOL CALLBACK addDevice(InputDeviceID id, LPVOID pvRef) { deviceIDs.push_back(id); GUID instanceGuid = id->guidInstance; GUID productGuid = id->guidProduct; wcout << endl << "_GUID DATA_"; wcout << endl << "iguid.d1: " << instanceGuid.Data1 << endl << "iguid.d2: " << instanceGuid.Data2 << endl << "iguid.d3: " << instanceGuid.Data3 << endl << "iguid.d4: " << instanceGuid.Data4; wcout << endl << "pguid.d1: " << productGuid.Data1 << endl << "pguid.d2: " << productGuid.Data2 << endl << "pguid.d3: " << productGuid.Data3 << endl << "pguid.d4: " << productGuid.Data4; wcout << endl << "_DEVICE DATA_"; wcout << endl << "devtype: " << id->dwDevType << endl << "prodname: " << id->tszProductName << endl << "instancename: " << id->tszInstanceName; wcout << endl; return DIENUM_CONTINUE; } It fails on "dinputInterface->CreateDevice(...." and I have no idea why. It says DIERR_DEVICENOTREG, or "Device not Registered", but I have absolutely no idea what that means, if a device is registered or not :P. The devices are all connected and working fine. The program outputs: _GUID DATA_ iguid.d1: 2519117328 iguid.d2: 63399 iguid.d3: 4574 iguid.d4: 001FF864 pguid.d1: 67109967 pguid.d2: 0 pguid.d3: 0 pguid.d4: 001FF84C _DEVICE DATA_ devtype: 66068 prodname: Thrustmaster HOTAS Cougar instancename: Thrustmaster HOTAS Cougar _GUID DATA_ iguid.d1: 3723248736 iguid.d2: 25704 iguid.d3: 4576 iguid.d4: 001FF864 pguid.d1: 3008431183 pguid.d2: 0 pguid.d3: 0 pguid.d4: 001FF84C _DEVICE DATA_ devtype: 66076 prodname: F16 MFD 1 instancename: F16 MFD 1 _GUID DATA_ iguid.d1: 3723248736 iguid.d2: 25704 iguid.d3: 4576 iguid.d4: 001FF864 pguid.d1: 3008496719 pguid.d2: 0 pguid.d3: 0 pguid.d4: 001FF84C _DEVICE DATA_ devtype: 66076 prodname: F16 MFD 2 instancename: F16 MFD 2 _GUID DATA_ iguid.d1: 3833754032 iguid.d2: 48150 iguid.d3: 4574 iguid.d4: 001FF864 pguid.d1: 123471523 pguid.d2: 0 pguid.d3: 0 pguid.d4: 001FF84C _DEVICE DATA_ devtype: 66328 prodname: Saitek X52 Flight Control System instancename: Saitek X52 Flight Control System Failed to create device Failed to create device Failed to create device Failed to create device Update: AHA. Apparently MS has decided that you can only run CreateDevice inside the callback given at the enumerate-call (else u get the error above). Either that or I miss something else. What my guess is that the call to enumerate is blocking, and then some "CreateDevice"-allowed DX thread actually runs the callback instead of the main thread, and only it has the permissions to create a device......regardless....problem solved.

Yeah, same, I think it is too much work for most people. However if the program I/we make initially supports only virtual mouse and keyboard emulation, we can then later expand it to also a virtual joystick for those running test mode.

Looking at it more closer now, I have solved part 1 but am still working on part 2, which is turning out to be quite difficult... 1. So detecting multiple controller input and creating conditions on when to react on each turns out to be fairly simple 2. But actually inputing something back is more difficult than I expected. :/. What I would like to do is to create three virtual inputs: virtual mouse input, virtual keyboard input and virtual joystick input. The first two are not too hard as windows has decent methods for doing this, however creating a virtual joystick seems to be harder than I expect. It seems like u actually have to make windows believe that you have connected a new hardware HID/usb device and then have that device give input. If anyone has some programming suggestions on how to create a virtual joystick for emulated input, then that would solve the last problem. So far I have not found anything for it but I'm still looking. update: This guy here has done part 2 http://ppjoy.blogspot.com/, but the code is not open source and from what I can tell there is no plan to make it so. Also what is worse is that creating a virtual joystick device means you must create a device driver, which for windows 7 in turn has to be (unless you specifically boot windows 7 into test mode) digitally signed......and for that you must pay microsoft a yearly fee :P. So it looks like my first go with this software will only allow: 1. Read and conditionalize events from all directinput devices (by using directinput http://msdn.microsoft.com/en-us/library/ee418273(v=vs.85).aspx) 2. Input virtual mouse and keyboard events (by using windows functions SendInput http://msdn.microsoft.com/en-us/library/ms646310(v=vs.85).aspx) (2b. Later, I wish to also be able to create virtual joystick input, see text above to see why it's not possible to make atm.) Google found a neat demonstration on how to use the SendInput function in a forum post :) (http://stackoverflow.com/questions/3726812/how-to-send-unicode-keys-with-c-keybd-event) KEYBDINPUT kb={0}; INPUT Input={0}; // down kb.wScan = 0x00c5; kb.dwFlags = KEYEVENTF_UNICODE; Input.type = INPUT_KEYBOARD; Input.ki = kb; ::SendInput(1,&Input,sizeof(Input)); // up kb.wScan = 0x00c5; kb.dwFlags = KEYEVENTF_UNICODE|KEYEVENTF_KEYUP; Input.type = INPUT_KEYBOARD; Input.ki = kb; ::SendInput(1,&Input,sizeof(Input));

Ill see if I can make a prototype after LLTM next weekend :P

You would not need any other profiling software, not even necessarily programming different devices in different tabs - all the devices can be programmed in the same code (and you can for example use a button on an x52 as a modifier for a functionality on your CH pedals etc). It would be a direct programming approach instead of wrapping it in a semi-programmable profiler application. You would get access to each of the devices' *states* and could write simple conditional statements as if you were doing very basic programming. The thing is that you don't need to replace or rewrite any of the functionality. You only need to Give access to 1. Read current state 2. Input virtual keystrokes ( that your game reads) These two things are what I mean will be only a few hundred lines (in fact it might even be below 100 lines of code, much shorter than my previous projects). What would require more work would be simplifications of profiles and GUIs, that could be a lot more code.

Been away from the forum for a while but I read up on things every now and then. Some of you might know me, but most probably don't. Long story short: I got an idea for a new hotas/keyboard/*anything* programming/profiler tool/utility. (wow thats a lot of slashes!). We all sit with tons of different sim gear like throttle, stick, pedals (wheels anyone? ;)) and the list goes on. Some of these things come with decent programming/profiling tools, but seriously, none are really that powerful, and worst is that in almost every setup there are different tools for each hardware, they get non-backwards-compatible upgrades (for the profiles). On top of that the hardware don't play too well together. For example 1. Can my new game really support N number of devices? 2. Can my new game let different hardware act as modifiers for each other etc?. Now why can't normal profiler software support basic gestures like "double-clicking" or acting on different time-dependant conditions? MAYBE some do, maybe some obscure ones for parts of your hardware. ---------------- Ok so if you actually have read all the above without getting tired or bored, what is the point of this post? Let's say we make a new software (or more correctly named some kind of utility programming library), compatible with ALL directx devices (keyboard, mice, joysticks, wheels etc). How to do this? It is likely simpler than one would expect. My idea (that I need advice on and hopefully more devs) is this: 1. ask DirectX (DirectInput) what *real* devices are present 2. create a single *virtual* device for sending back commands 3. ask directinput to notify our program on any changes in the *real* devices we want to check. 4. act on arbitrary changes as if they were just normal program events. 5. send desired commands on *virtual* device Creating a hotas cougar profile in c++...lovely :). (Or maybe C#, I normally prefer Java but for low level global controller access then... maybe later we can wrap it in JNI) Example of multiple devices acting together: if (x52.throttle.slider(1).accelleration()< a && hCougar.stick.button(5).isDown()) // airbrakesOut(); or as a callback if preferred void onChange(Event& e) { globalState.update(e); Interface * interface = e->getDevice()->getInterface(); MappingList * activeMappings = mappings.getMappings(interface); if (activeMappings->length()>0) respond(globalState, MappingList); } I estimate such a program would be really short, maybe a few hundred lines (tops) for the actual framework. Then if anyone nice wants to add a GUI (boring... ) and profile file reader/writer that would be cool as well. ---------- END RANT Suggestions? Want to help? Post!

Check this, might work. (probably the latest dll source code) Honestly I did a lot of things wrong there (I'm not a c++ coder), so feel free to correct the stuff: http://kenai.com/projects/leavu2/sources/subversion/content/LEAVU/Lua%20Export/src/luaKeys.cpp?rev=742 //Simple DLL for lockon to see if a key is pressed #define LUA_BUILD_AS_DLL #define LUA_LIB #include "Windows.h" extern "C"{ #pragma comment( lib, "lua.lib" ) // Compiled earlier #include "lua.h" #include "lauxlib.h" #include "lualib.h" } // Lua will see the returned variables as a value or nil static int has_been_pressed(lua_State *L) { if (GetAsyncKeyState((int)luaL_checknumber(L, 1))!=0) return 1; return 0; } static const luaL_reg testlib[] = { {"has_been_pressed", has_been_pressed}, {NULL, NULL} }; extern "C"{ LUALIB_API int init_libs(lua_State *L) { luaL_openlib(L, "kb_fcns", testlib, 0); return 1; } } I also experimented back then with creating DIRECTX stuff this way through LUA, but it didn't go so well :P. WARNING: GetAsyncKeyState is not thread safe or afaik even multi-app safe! Only 1 app can use it at the same time cause every time you ask the OS "has this button been pressed this the last time I asked", will cause it to *clear* the state. I used this function because lockon blocks all "normal" ways to access OS global keyboard input in the background. (DirectInput/DirectX with callbacks does work though, but I kept failing to create any DX devices :( in a dll accessible by lua ) Oh and as a sidenote, keep working on this stuff u think is fun. I actually got to show LEAVU at a job interview (lol) and it got me a job working on the real thing. Details err...classified ;)

No I wrote it myself, but I misplaced my source code :P It's a quite ugly solution which relies on this http://msdn.microsoft.com/en-us/library/ms646293(v=vs.85).aspx

aha my old crappy dll :). Yes that works, but if u get a 64bit version of dcs or fc2 in the future, then that dll wont work anymore Im afraid, so maybe we should make a new clean one that we can compile 2 versions of :P

nice :). How did you check the keypress btw? Did you import some dll that ur lua script could access?

I'm curious, how did you separate unintentional unlocks from intentional ones?

well, I have both trackir 4 and 5. The 5 is significantly smoother in some situations (like if you are very zoomed in), but in normal use you won't see much of a difference unless you have tried both a lot. If you're completely new to trackir then there's definitely no need for tir5, just get the 4 and u'll be happy, I know I was "wooooah" when I got mine a couple of years back :)

Yeah but the new JOGL 2-api is completely different......from what I understand remade from scratch :P...... Maybe better to leave leavu as it is, due to the low demand.

I'm also hoping to get away from old JOGL1 unsupported(by original devs) dlls, who knows what will happen in the future. Whether it's swing or awt i dont really care much about tbh :). Also the JOGL1 stuff doesnt run well with either AWT or swing once you reach a lot of open windows (starts being a problem at 20-100 depending on what kind of system you are running, even with the simplest helloWorld JOGL+swing/awt windows)

I think we really need to replace the graphical engine of leavu2...it is getting too messy :). Users shouldnt have to mess around with dlls... Especially since the system it was developed for (JOGL 1) is no longer maintained by its developers If anybody has any suggestions for a fast 2d or 3d system which can be placed in an AWT window then that would be where we could start. Basically what i need to be able to do is : - For 2d instruments: 2D rendering with the ability to draw primitives - For 3d instruments: 3D rendering similar to OpenGL or Direct3D, ability to draw primitives, basic shadows and lighting - Being able to run very high fps (60+) with low cpu hit (<1% cpu for 50-100 objects on screen) - Not having to load any dlls explicitly (tiring for the installation and annoying with 64bit JVMs!) - 2d and 3d renderers can be entirely different, we can replace the 2d one to begin with. - Must run on linux and windows.

You're not supposed to have very good turn capability at 25.000 ft :). If you want to know exactly how much you should have there are some aircraft flight manuals available around here somewhere. The devs did their best to match these known performance charts for all the aircraft when developing the game, but if you want something really precise you will need to wait for plane specific flight model simulation in DCS. Pulling 9Gs without losing speed is something you can really only expect if you aren't carrying anything :), being at 450 kts or so at sealevel with not too much fuel.

Unfortunately no, leavu's entire graphics engine is based on OpenGL 3D. Btw i didn't answer the earlier poster's question here because I did in a PM instead :). However I do not quite understand why it cannot display it: Does it not have a dvi or vga cable? is it ONLY usb?

links fixed, my webserver was down

So, just curious about how you do this. You replaced some ingame 3d engine dll with one of your own, and can access d3d variables and export textures etc? (and inject ur own ones?). This has some cool potential ;)

I think it is the complexity of its design that makes it difficult for people to grasp what it is. It is really, building instruments from scratch and displaying output from raw data, coordinated between several different threads. It isnt dependent on what sim you run, here is where most people lose it I think because they don't see that the data export is a completely separate part from leavu itself. Export thread(game lua) -> leavu receiving/internal state updating thread -> rendering thread I think maybe if id had some more experience with programming java/lua when i started the project it could have been made simpler to understand and more simply programmed. This was my first experience programming an openGL engine and also virtually my first java application beyond the ordinary java tutorials. The original Leavu 1 was my second experience with cpp after AMRACT (server side triggers in Fc1), and with leavu2 I switched to java for the cuts in development times Unfortunately I think most people that know 3d modelling in this community are not into programming, so having to work with actual code could have scared them. Example: The Leavu RWR. It is a fully functional rwr module built into the leavu program. It doesn't just display data exported from lockon - it has its own actualy rwr state and makes threat assesments. Then it just uses whatever data source you provide it with. Currently it doesn't do much more than just replicate the ingame rwr(with diff backgrounds possible) and give you the possibility of threat type specific sounds (for example mig29 sounds different than f-15). It could however in theory easily be integrated with the leavu FCR (which is not just a display, but an actual instrument maintaining its own state) I halted my own development with eri/leavu partly because parts of the community got too scared, otherwise maybe we'd have f-22 avionics by now :)

most moves have some usefulness. The trick is knowing when the move is useful, and when it is not. The "hit the breaks and he'll fly right by" does have some uses, though you aren't going to see them very often :).

Not directly, but you can save your instrument setup as a preset (it is then coded as a text file), which you can edit positions and resolutions in if you want to fine tune it afterwards.

The short answer is: you can't. The long answer: All the data leavu requires isnt available from fc1 exports. You can "fake" some of the data by using global exports, but then again that wont work online. To do this you would need to code your own custom output script and connect to the leavu through tcp sockets.