RvEYoda

Thanks, I'll have a look, but it's likely a little too expensive for me. From what I could tell the heli kit is also without a base? Does this come with electronics, I mean, USB or such? Or do they just sell the mechanics? Not much information on their site. It would be good to know what kind of internal mechanics/electronics they use to some extent if I'm going to spend that kind of money :) All other suggestions still more than welcome!

Looking to fly some heli sims for the first time in a while. This time though it would be good to have a proper collective, and that seems to make things difficult. Are there any companies like thrustmaster or Saitek making collectives for simmers? Perhaps there is some other product you could buy and "make it work" like a collective? I saw an example here of, well, basically a stick mounted to a CH sliding throttle. http://forums.eagle.ru/showthread.php?t=27119&page=4 Anybody got ideas on how to solve this the best way?. Alternatively, If I happen to get really lucky someone who has one but doesn't need it might see this and sell it to me? ;P

Some of us have set it up so that we actually move the head in 3d and then we just release/press a button to have it automatically switch to 2d (pointing at the same instruments/direction you were looking at in 3d). Game wise this allows you to click the pit like you would in a clickable 3d pit, but of course it is not really a 3d pit graphics wise :). We never use other methods than trackir to look around.

It is finished (v2). It works very well. There is no real money to be had in selling my software for enthusiasts. Much more fun to be had in having it open.

Yes you could pretty much clone my current mfd and just replace stuff :). It would work. There are some limitations right now that checks "if not F15, do not show mfd page X", but that is just a 1 line check anyone could remove in the open source code. Do you know any java or C/C++? If so I could probably show you how.

Leavu can run with any plane and ANY SIM. :). What is required: - Someone draws an instrument - Someone writes a proper data export (if it doesnt already exist) - It is a tool like touch buddy. We (me and GG) like flying F-15 in fc2, so, I made some basic instruments for it. We prefer having these INSTRUMENTS (not leavu! Leavu is not locked to sim or plane, even if the name still suggests it) for F-15 only, although we can never 100% ensure that never happens. Again this is not leavus fault, anybody can make their own instruments. Why should I make instrument for another plane or another sim I dont fly myself? - maybe if someone pays me :). But i leave the door completely open for someone else to do it if they want to, they can speak to me any day and I'll show them how. It's been like that since the first leavu release. If fact some have already made custom stuff for it. But so far nobody contacted me on MSN or PM saying "Hey I want to make mfds for the russian jets in fc2 with leavu". I asked people to do it, even some of the devs actually told me that they would think it would be great if someone did it. Someone I think posted on the forums "How do I do it?" so I answered please PM me about msn details and I can show you, and Im still hoping to hear from that person. It would be a lot of fun if Leavu got accepted online :). Finally: Leavu is a BAAAAAAD name. It is from a time when it was made for F-15 online (Lockon Eagle AVionics Upgrade) But it should be called something like General External Avionics Renderer.

Honestly, I would not mind either way. it would add some nice behaviour to the game that has yet to be explored :). It would be fun to try both sides flying with the same MFD capability, regardless of what plane they are flying. Realism? hardly. Fun? Yet to be explored!!!!! :pilotfly: But it doesn't really matter what leavu can do. Since fc2 can export own sensor data you can draw whatever you like from it. Like flying 3d bananas on a radar screen you prefer. It's up to you, just because leavu made mfds first doesn't mean you can't render something completely different. GAME exports DATA your app does ANYTHING WITH DATA Leavu = example of your app

I'm not sure I'm following you alpha or if you have seen what leavu is. Maybe you have. Leavu is just a software for external instruments. I can't change anything about how the game works. The game exports instrument/sensor data and then I display this on external monitors. I can't actually edit something that is in the ingame cockpit. Initially i did include a bit more capability than leavu currently has but a lot of people got frustrated since they felt it made the f-15 overpowered in the game. In order to emulate the behaviour of a datalink, I wrote a server software which my external instrument software could connect to, thus different leavu users could share their own instrument and sensor data. This can be made precise enough to 1 m (or better ;)) , but for the similar reasons as previously (people complained) I chose to have it update only 1/second. It should however be good enough for precision better than 0.5 nm. Possibly 0.1.

I'm not sure I'm following you alpha or if you have seen what leavu is. Maybe you have. Leavu is just a software for external instruments. I can't change anything about how the game works. I export own instrument (only) data from the game and then display on external monitors. I can't actually edit something that is in the ingame cockpit. Now maybe you already realized that, please send me a PM or contact me on msn if you think we could still work something out from that. (Forums = too slow and too much confusion)

I'm curious, what sorts of instrument would you use to display the data? The current datalink in leavu, any specific reason you would like a tacan-ish implementation instead? (the datalink is much more powerful :)

Very cool idea! I would gladly help you do this, but first I think we should effectively make the data export part from lua to java a bit standardized, so that we can retrieve all data that we need. Then we probably should look to make leavu slightly more efficient and move its 3d (yes leavu does in fact render 3d instruments) to JOGL 2 (from JOGL1), which is essentially an OpenGL wrapper for Java. We should ask others who wants to help out in the process, so that we could make some general walkthrough on teamspeak/skype/msn or something like that, explaining to everyone how I made it previously and how we could make a new version for many people to work on. I suggest we might want to create a new thread and list the different instruments and pages we want for the different planes, then we can work out what we need together. I have not been able to answer or read your posts lately, cause I have been on a work/business trip in Russia the entire week. Now I finally got my internet connection working here in Moscow so tonight (now) I'll answer some questions if there are any. This monday I was in Moscow but moving through customs took 5 hours, so I was very tired that night :), then on tuesday we flew to Ulyanovsk, and now today I'm back in Moscow. Tomorrow I head back to Sweden but it is possible I will be back in Moscow for MAKS air show, we will see what my boss decides :pilotfly:.

For sure. just because 1v1 one is better it doesnt mean the composition is. There are parts of the engagement envelopes where the ET is clearly preferable to the aim120, just like you mount 9x missiles instead of 120Cs for close quarter fights. but PLEASE read the sentence in its context. I am NOT protesting or saying putting r77s on flankers is bad. I'm only saying that claiming it doesnt affect balance is wrong. If you really want to be hardcore balance fanatics, you should look at how its done in Starcraft/Starcraft2 As for export.lua security issues: I am aware of 2 main ones. - There exists a bug/limitation in the own-sensor radar data export that it exports position of targets that are actually using ecm but arent burned through. (theoretically fixeable in a patch by ED). This is/was the basis for the ecm range estimation emulation code. - all own sensor data can be exported to external applications (intended behaviour), but, external applications can of course not be controlled by the lua engine/fc. Thus the external applications may for example share data among themselves (without having anything to do with the lua/fc engine). This was the basis for creating leavu. Some consider this a security flaw, but it is an unavoidable fact if you implement any sort of data export methods whatsoever. It is not related to lua or the game, just the principle of being able to export own-sensor data. The same is possible for any sim. Falcon, dcs, you name it. They can all share the same leavu/otherApp datalink. A pretty cool idea would be to build a "datalink commander" application for this, created from the commander's input and planes own-sensor data.

Also another quick note on why ED didnt implement a working mfd in the F-15. Ask yourselves why similar functionality in other planes were not implemented, or an entire F-16 wasnt :). They implemented the stuff they considered necessary, however, we (me<->ED) had very good discussions on ironing out some lua export bugs and added new features to the lua export, and these discussions effectively was what made leavu even possible for fc2. Maybe it's a bad idea of me to make these posts, as some people feel like they are losing the fun in the game when the game balance changes. But they should then also expect the same in return when the other side feels threatened as R77s are placed on Su27s. Saying this does not affect game balance...wah. We might just add R-27ETs then to F-15s :). Cause they are still the same missile, right :P Everyone wants to make the game more fun right? For me and some others it means implementing some cool systems. For others it might be giving planes new capabilities in other ways.

Pardon me but this is incorrect. Whether you enable leavu or not is not a big deal for me though since I dont play fc anymore, but it would still be good to let people know. You can forbid tacview but enable leavu and keep file integrity check, because leavu uses only own-sensor data while tacview uses global export functions. To do this use file specified integrity check and remove "export.lua" from the checked files. effectively this means every file except export.lua is integrity checked, and tacview cannot export any data cause that is by default disabled in config.lua (global exports off)

I guess, just adding such a replacement dll (and therefor digging up all the exported functions) might actually be some breach of their IP, if that's so we shouldn't even try it. If we ask them if it's ok we replace some dll, that might still not be so easy if the function parameters are of ED classes etc, having to reverse engineer that hmm..Then finding the right place where to actually do the drawing/painting .....:P........not so easy ^^ Anyway, Im off for a week. Going to russia to drink Vodka ^^

perhaps it would be possible to inject a replacement dll but likely starforce would not permit running the game then

Question: are you able to draw whatever u like on the mfds and hud? Waypoints, targets etc? I'm really interested, if there is such a possibility I'd like to implement some stuff

Well if I develop a new version it will be a highly experimental one with VERY overpowered features (take it as far as possible with the data given), so mostly for special coop and pre-decided events/special servers. I doubt normal servers would allow it :) The previous versions of leavu were very toned down compared to what u could make of pure own-sensor data, in the attempt to make some online servers accept it, but since that didn't cut it anyway for public servers..... Maybe it's time to make something with a bit of power! I would probably also screw around with weapon ranges/radar numbers if I can find any files that allow me to do such. (Such modifications however would not work on any online servers even if u tried to, so theyre only for private/coops/events) http://forum.jogamp.org/Crash-when-creating-more-than-15-jogl-awt-windows-td3054540.html bottom 5 posts

When you say you have fully functional mfds. Have you implemented new systems so you can you click the buttons, change pages and such similar to the 10c? If so, how would you best access these interactive graphics and make modifications?

Problem solved. Now got 150 or so opengl windows through jogl2 from 1 single application. There might yet be hope for some new development...

Moa try this below: (change number of windows if you like, 25 should be enough for a crash in JOGL 2). In JOGL 1 I can do about 50 windows. Memory is not the issue, you can give the vm as much as u want and it wont change a thing. In C++/D3D I could do well above 100 and it still wasn't anywhere near crashing. /************ HELLOJOGL.java *********/ package hellojogl; import javax.media.opengl.GLCapabilities; import javax.media.opengl.GLProfile; public class HelloJogl { public static void main(String[] args) throws InterruptedException { GLProfile.initSingleton(false); final GLCapabilities glcapabilities = new GLCapabilities(GLProfile.getDefault()); for (int i = 0; i < 25; i++) { new OneTriangleAWT(glcapabilities); } } } /******** OneTriangleAWT.java*******/ package hellojogl; import javax.media.opengl.GLAutoDrawable; import javax.media.opengl.GLEventListener; import javax.media.opengl.GLCapabilities; import javax.media.opengl.awt.GLCanvas; import java.awt.Frame; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import javax.media.opengl.GL; import javax.media.opengl.GL2; import javax.media.opengl.glu.GLU; public class OneTriangleAWT { final GLCanvas glcanvas; public OneTriangleAWT(final GLCapabilities glcapabilities) { glcanvas = new GLCanvas(glcapabilities); glcanvas.addGLEventListener(new GLEventListener() { @Override public void reshape(GLAutoDrawable glautodrawable, int x, int y, int width, int height) { OneTriangle.setup(glautodrawable.getGL().getGL2(), width, height); } @Override public void init(GLAutoDrawable glautodrawable) { } @Override public void dispose(GLAutoDrawable glautodrawable) { } @Override public void display(GLAutoDrawable glautodrawable) { OneTriangle.render(glautodrawable.getGL().getGL2(), glautodrawable.getWidth(), glautodrawable.getHeight()); } }); final Frame frame = new Frame("One Triangle AWT"); frame.add(glcanvas); frame.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent windowevent) { frame.remove(glcanvas); frame.dispose(); System.exit(0); } }); frame.setSize(640, 480); frame.setVisible(true); } public static class OneTriangle { protected static void setup(GL2 gl2, int width, int height) { gl2.glMatrixMode(GL2.GL_PROJECTION); gl2.glLoadIdentity(); GLU glu = new GLU(); glu.gluOrtho2D(0.0f, width, 0.0f, height); gl2.glMatrixMode(GL2.GL_MODELVIEW); gl2.glLoadIdentity(); gl2.glViewport(0, 0, width, height); } protected static void render(GL2 gl2, int width, int height) { gl2.glClear(GL.GL_COLOR_BUFFER_BIT); gl2.glLoadIdentity(); gl2.glBegin(GL.GL_TRIANGLES); gl2.glColor3f(1, 0, 0); gl2.glVertex2f(0, 0); gl2.glColor3f(0, 1, 0); gl2.glVertex2f(width, 0); gl2.glColor3f(0, 0, 1); gl2.glVertex2f(width / 2, height); gl2.glEnd(); } } }

By pure java I mean not having to include any other jar/dlls than what comes with the standard oracle jres. It's not a load issue moa, Just creating blank AWT+JOGL2 windows will cause JOGL to crash above 15-20 or so windows on a high end machine. I just used the most basic example, see the post I linked to above. (just copy paste the code and try it :)) I am thinking java2d can be a decent choice and then limit 3d windows to let's say 5 or 10 for JOGL stuff.

Been thinking a bit about making a new (far more capable mostly for coop) leavu and migrating to JOGL 2, however JOGL 2 seems to have the same multi-window issues as JOGL 1 (but even worse!) http://forum.jogamp.org/Crash-when-creating-more-than-15-jogl-awt-windows-td3054540.html An option tbh would be to use a pure-java rendering canvas for all 2d instrument and only use jogl for 3d. Another option would be to use C++/d3d like I did a long time ago, but that would be a pain for data serialization, compatibility, byte orders, threading, yada yada..

Solved the last piece of the puzzle. I can now read x52, cougar, mfds 100% :). Going back to work on the implementation now. It is not meant to be a scripting software, more like a static c++ and/or java library so that you can write conditions in low level programming language Basically what I've had to do is to dynamically generate the device data formats during program runtime, given what directinput reports on the device capabilities, (cause some, for example the x52 hotas have buttons that exceed the standard DirectInput data formats). I'm in the process of testing the new formats, basically dynamically generated structs at runtime (and with dyn generated I mean different amount of members and types), so working for filling in bytes here and there :P Update: So basically everything works now. Input, profiles, output. games detect my mappings just fine. There is just one total gamebreaker....... I'm unable to block the DX input to games. I can receive it myself, i can generate the keystrokes I want, but the games also receive the original DX input. This is a problem since some games does not allow me to unmap for example POV hats (damn u f4AF), while in lockon/dcs this isnt a problem. So unless someone knows a way how to block selective directinput information going to other applications, then I'm putting this project on hold for the moment. (Like it said everything is working, it's just that I cannot get the apps to get "double information") This is what my game profile looked like :P. At least I can use it to map my thrustmaster MFDs I guess XD //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///// Thrustmaster MFDs ////////////////////////////////////////////////// // Special buttons which do not have modifiers int L_mfd_btn[3*20] = { 0, 0, 0, 1, VK_ADD, 0, 2, 0, 0, 3, 0, 0, 4, 0, 0, 5, VK_HOME, 1, 6, 0, 0, 7, 0, 0, 8, 0, 0, 9, 0, 0, 10, 0, 0, 11, VK_F6, 0, 12, VK_F7, 0, 13, 0, 0, 14, 0, 0, 15, VK_F8, 0, 16, VK_MULTIPLY,0, 17, VK_DIVIDE, 1, 18, 0, 0, 19, VK_PRIOR, 1 }; int R_mfd_btn[3*20] = { 0, 0, 0, 1, VK_END, 1, 2, 0, 0, 3, 0, 0, 4, 0, 0, 5, 0, 0, 6, 0, 0, 7, 0, 0, 8, 0, 0, 9, 0, 0, 10, 0, 0, 11, 0, 0, 12, 0, 0, 13, 0, 0, 14, 0, 0, 15, 0, 0, 16, 0, 0, 17, 0, 0, 18, 0, 0, 19, 0, 0 }; void tapAfMfd(int mod1, int mod2, int bNum) { if (bNum<10) { tripleTap(mod1, mod2, number(oneToTenKeys(bNum))); } else if (bNum>=10 && bNum<20) { tripleTap(mod1, mod2, numpad(oneToTenKeys(bNum-10))); } } void stdTapLeftMfd(int bNum) { tapAfMfd(VK_LCONTROL, VK_LMENU, bNum); } void stdTapRightMfd(int bNum) { tapAfMfd(VK_LSHIFT, VK_LMENU, bNum); } // Mapping Thrustmaster left mfd void tapLeftMfdButton(int bNum) { if (isSimpleMapped(bNum, 3, L_mfd_btn)) { keyTap(getMapping(bNum, 3, L_mfd_btn), isExtended(bNum, 3, L_mfd_btn)); } else { stdTapLeftMfd(bNum); }; } // Mapping Thrustmaster right mfd void tapRightMfdButton(int bNum) { if (isSimpleMapped(bNum, 3, R_mfd_btn)) { keyTap(getMapping(bNum, 3, R_mfd_btn), isExtended(bNum, 3, R_mfd_btn)); } else { stdTapRightMfd(bNum); } } void assignMfds() { for (size_t i=0; i < mfd1->getNumButtons(); i++) mfd1->getButton(i).assignCallback_onKeyDown(&tapLeftMfdButton); for (size_t i=0; i < mfd2->getNumButtons(); i++) mfd2->getButton(i).assignCallback_onKeyDown(&tapRightMfdButton); } //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///// HOTAS COUGAR ////////////////////////////////////////////////// // Simple mappings: buttonNumber, vkey, extended state const int simpleCougarMappings[3*18] = { 0, VK_DELETE, 1, // first detent 1, VK_SPACE, 0, // pickle 2, 0, 0, // round pinky 3, 0, 0, // paddle 4, 0, 0, // nws 5, VK_INSERT, 1, // second detent 6, 0, 0, // tms u 7, 0, 0, // tms r 8, 0, 0, // tms d 9, 0, 0, // tms l 10, 0, 0, // dms u 11, 0, 0, // dms r 12, 0, 0, // dms d 13, 0, 0, // dms l 14, 0, 0, // cms fwd 15, 0, 0, // cms up/right 16, 0, 0, // cms back 17, 0, 0 // cms down left }; const int simplePov[3*8] = { 0, 0, 0, 1, 0, 0, 2, VkKeyScanA('l'), 0, 3, 0, 0, 4, VK_ADD, 0, 5, 0, 0, 6, VkKeyScanA('n'), 0, 7, 0, 0 }; void simpleCougarmappings(int bNum) { if (isSimpleMapped(bNum, 3, simpleCougarMappings)) { int key = getMapping(bNum, 3, simpleCougarMappings); bool isEx = isExtended(bNum, 3, simpleCougarMappings); if (cougar->getButton(bNum).isPressed()) { keyDown(key, isEx); } else { keyUp(key, isEx); } } } void cougarPovChange(int dirIndex) { if (dirIndex == 0) { if(cougar->getButton(2).isPressed()) { tapRightMfdButton(1); } else { tapLeftMfdButton(16); } } else{ keyTap(getMapping(dirIndex, 3, simplePov), isExtended(dirIndex, 3, simplePov)); } cout << endl << "Pov changed"; } void assignCougar() { for (size_t i=0; i < cougar->getNumButtons(); i++) { if (isSimpleMapped(i, 3, simpleCougarMappings)) { cougar->getButton(i).assignCallback_onKeyDown(&simpleCougarmappings); cougar->getButton(i).assignCallback_onKeyReleased(&simpleCougarmappings); } else { cougar->getButton(i).assignCallback_onKeyDown(&keyIdentifier); } } cougar->getPov(0).getPovButton(0).assignCallback_onKeyDown(&cougarPovChange); cougar->getPov(0).getPovButton(2).assignCallback_onKeyDown(&cougarPovChange); cougar->getPov(0).getPovButton(4).assignCallback_onKeyDown(&cougarPovChange); cougar->getPov(0).getPovButton(6).assignCallback_onKeyDown(&cougarPovChange); } //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///// General ////////////////////////////////////////////////// void assign() { assignMfds(); assignCougar(); } Update: Working F4Af profile, going to make a Fc2 profile later :P. 2xTM mfds, Hotas cougar and saitek x52 throttle now profiled with single software ^^ :: the profile (v1) -> http://gigurra.se/ProfilerTest.txt .

I've run into a problem.. Hotas cougar: can map everything fine Thrustmaster mfds: all fine Saitek X52 (i use the throttle): All axii except mouse ok, all buttons except mouse ok, all povs ok. It seems as Saitek has written som nasty driver here. As soon as any application creates a DirectInput device of the X52, then the saitek "magic mouse" is activated, and the buttons that control it are no longer readable as DirectInput buttons. So as soon as you start your own software or the saitek panel, BLING! Mouse activated. The worse problem is that the saitek magic mouse doesnt register as a directx device! Even if I uninstall the saitek profiling software, and there is no more magic mouse.....the buttons still dont show as dx input :( This means, effectively, that I cannot read it. Well I can read it through the global mouse input but that is pointless. :( ------- Update: There might be an evil way of getting raw data from the device and going from there...Investigating http://msdn.microsoft.com/en-us/library/microsoft.directx_sdk.reference.diobjectdataformat(v=VS.85).aspx :D Update 2: Through looking at the device's raw data sent I've been able to ask DirectInput to send me data from mouse controller on the x52 without having to use it as mouse :P. Now I just need to read those extra buttons... Getting close! Basically just need to define a custom data format for devices (like x52 but not cougar or TM mfds) that behave evil. Update 3: Now able to read all x52 states EXCEPT the mouse buttons (even though the mouse and profiling software is uninstalled). The cursor stick itself I can read, but not the buttons... hmm They do not send any dx information EXCEPT if the x52 control panel is opened, then they suddenly become DirectInput compatible buttons.....hm....evil drivers...