RvEYoda

Thank you Moa, will check it out once im home on sunday evening. Thank you! :)

I plan on having keyboard input support yes, and you can use that with joysticks. Good idea about removing the frame. We can have that as a setting or button or something.

Basically it would be good to have the buttons look a bit nicer. So buttons and the panels around the display would need some nice shapes/picture. The dimension of the screen must be customizable. You can resize it to anything you want with any aspect without it becoming strange, but the button size themselves are fixed. (They only move with changing size of window)

Little new update to design changes. Also implemented network connection with lockon, so I can get the data I need ( but I just draw test shapes so far )

My data link works with global exports turned off. This is because I write my own datalink server. Each player gets only local lua data like "What is my position". Then each player logs into LEAVU data link server (separate software) and says "Hi, my name is Yoda, this is my position..."

:lol::pilotfly:

Leavu 2 has a button saying "Add MFD" which allows any number of MFDs to share the same data, so that the CPU work load is the same regardless of number of MFDs. The CPU load will increase with number of MFDs only because OpenGL requires one graphics engine and drawing thread per MFD. ( But they all share the same precached shapes, so load is quite ok. i get about 1-2% load per MFD on my 2.66 GHz machine at home when locking at 30 fps ) Just put it on a different cpu core than lockon and will have zero effect on game performance. This means to run multiple MFDs of different size works just fine. You just press "new mfd" here : , and you can resize each MFD independently of the others ( just drag like a normal window ) . Just add MFD and drag to the monitor you want it on. It should run on any operating system with a Java VM, and supports any screen aspect ratio without changes to settings or misshaped objects. No Global exports are needed, so even if lua export turned off it works 100% fine, since Leavu only uses information from your instruments. So it asks "what is on my radar", "what is my speed", "what is my position", "what is my colition". It does never ask "What is player GG's position"

I tested using JNA to get the HWND, but it succeeded only some times, some times it gave random integers and sometimes just zero :). You make some JNA call to get a pointer to the hwnd value, and then you call ptr.getLong() or ptr.getInt(), however since the pointer is ( my thought of the JNA problem ) returned as a 32bit value and my OS and JRE is 64bit the pointer value only works in some cases. (where the 32bits are lucky enough to fit the pointer value) If you can make JNA retrieve the HWND and or add WS_NO_ACTIVATE extended style to a java awt component however, that would be excellent. But make absolute sure it works 100% of the time in 64bit OS and 32bit OS, and works with both 64bit jre and 32bit jre. I have use JNA to enable OpenCL ( Open Compute language ) in java at work, and I believe JNA may have some issues with 64bit pointer values, at least as it is right now. JNI enables me to link statically and make sure all variables sent and returned are correct. ( for work I also switched to JNI for using OpenCL in Java. ) Also I think we can include both a 64bit and 32bit dll for the final release of LEAVU and have the library path be configured in some shortcut that is automatically set up. what is needed is the LEAVU.jar, the Java2Win32.dll (32 or 64 bit) that I wrote and jawt.dll (32 or 64 bit..i think) from the JDK lib directory. Like : LEAVU/LEAVU.jar LEAVU/LEAVU.bat (or similar) LEAVU/lib/win/X86/Java2Win32.dll LEAVU/lib/win/X86/jawt.dll LEAVU/lib/win/X86/jogl.dll LEAVU/lib/win/X86/gluegen-rt.dll LEAVU/lib/win/X64/Java2Win32.dll LEAVU/lib/win/X64/jawt.dll LEAVU/lib/win/X64/jogl.dll LEAVU/lib/win/X64/gluegen-rt.dll then either run the bat file to launch it or copy the dlls to windows PATH ( ie windows/system32/ ) IF you want to run on linux I will have some files under LEAVU/NATIVE where you must code your Java2Win32.cpp to make the Java2Win32.dll (yes maybe I should change the name of that file :)) You'll get my windows variant as a reference, but it will of course not compile under linux, so you must replace the hwnd and extended styles with whatever is necessary (or you can just have it do nothing if you dont care about WS_NO_ACTIVATE ) Little status update :

Implemented some hsd details, GLCanvas instead of Gljpanel (canvas is faster), AA and some other stuff..

Yes, I could definitely use a hand. Either from anyone that knows JAVA ( I have an svn rep at kenai called leavu2 ), or if you can provide pictures of MFDs, MFD pages etc. Or if anyone wants to contribute with artwork that would be cool. Naturally anyone making a contribution would also get the author/dev/contributor stamp :)

yeah, but it will be a while before we can use the new version, for many reasons. Primarily cause im doing it all again from scratch...:P

Just to let you know I am currently moving the project to Java and OpenGL through JOGL. it is so far in very early development and cannot do much more than switch between and configure different blank mfd pages, but I got the graphics running, clicks detected and I was able to wrap my C functions in JNI so that the window does not steal focus from lockon when clicked... Prototype looks something like this : For JNI I used this as a source : http://stackoverflow.com/questions/386792/in-java-swing-how-do-you-get-a-win32-window-handle-hwnd-reference-to-a-window but that is for old java and I needed to update it like this : #define _AFXDLL #include "afxwin.h" #include "windows.h" #include "Java2Win32.h" #include "jawt.h" #include "jawt_md.h" JNIEXPORT jlong JNICALL Java_leavu_Win32_setNoActivate (JNIEnv *env, jclass cls, jobject comp) { HMODULE _hAWT = 0; HWND hWnd = 0; typedef jboolean (JNICALL *PJAWT_GETAWT)(JNIEnv*, JAWT*); JAWT awt; JAWT_DrawingSurface* ds; JAWT_DrawingSurfaceInfo* dsi; JAWT_Win32DrawingSurfaceInfo* dsi_win; jboolean result; jint lock; //Load AWT Library _hAWT = LoadLibrary(L"jawt.dll"); if(_hAWT) { PJAWT_GETAWT JAWT_GetAWT = (PJAWT_GETAWT)GetProcAddress(_hAWT, "JAWT_GetAWT"); if(JAWT_GetAWT) { awt.version = JAWT_VERSION_1_4; // Init here with JAWT_VERSION_1_3 or JAWT_VERSION_1_4 //Get AWT API Interface result = JAWT_GetAWT(env, &awt); if(result != JNI_FALSE) { ds = awt.GetDrawingSurface(env, comp); if(ds != NULL) { lock = ds->Lock(ds); if((lock & JAWT_LOCK_ERROR) == 0) { dsi = ds->GetDrawingSurfaceInfo(ds); if(dsi) { dsi_win = (JAWT_Win32DrawingSurfaceInfo*)dsi->platformInfo; if(dsi_win) { hWnd = dsi_win->hwnd; CWnd::FromHandle(hWnd)->ModifyStyleEx(0,WS_EX_NOACTIVATE,1); } else { hWnd = (HWND) -1; } ds->FreeDrawingSurfaceInfo(dsi); } else { hWnd = (HWND) -2; } ds->Unlock(ds); } else { hWnd = (HWND) -3; } awt.FreeDrawingSurface(ds); } else { hWnd = (HWND) -4; } } else { hWnd = (HWND) -5; } } else { hWnd = (HWND) -6; } } else { hWnd = (HWND) -7; } return (jlong)hWnd; } Argument is any AWT component. ( I use AWT only, no swing ) Got it running on 64bit jre currently

ah yes that would be the problem. From what I can tell, the Lofc lua cannot afaik directly export what plane you are actually flying, only a text string with your name and plane. This is how in LRM the plane type is determined, i think. You can edit that function planetoInt (and there is likely a findplanetype function that takes a string in there somewhere also) to suit your needs or edit the name parameter for the mirage in the meinit...i think....it should solve that issue. I think the string parsing function is the one your should be looking at, where it is first determined. I think this is during load-in somewhere by LuaExportStart. is there something like a global parameter g_planeType or similar? I think it only goes on the numbers in the plane type. Like the "15" at string positions [2] and [3] in "F-15", or maybe if LUA starts with index 1 (i cannot remember) With a planetype=-1 it likely wont know what to do... There should be a few positive integers that it knows about

If it is a payload issue, it will write a log file in /temp/illegalweapons.log (or similarly named file, i don't remember) Inside that file it will say what payload it thinks is illegal. You can then copy paste that line into the export.lua where the other payload settings are to make that payload legal. I do not develop LRM at this point as I am mostly working on things related to beta project(s). // Yoda

The coolest maddog is the R-77. Nobody expects it. They start kicking flares when they see the trail and when they get a warning? oops, too high, too late, and out of speed after the idle throttle from ET evasion.. did I say that out loud? Some more funny things is when you fire 4 ERs (all maddogged and never with a lock) to completely deplete the enemy's flares. Then when he gets closer ET away and dead he is. *Somebody please close this thread*

You can mod the game on server end so that it enforces 0 mods on client ends ;) ( I think someone was working on this already, did they give up ? ) Well you can enforce a script from server so that on client side it runs CRC checksums on whatever files you want to test and bang if it fails you just do LoSetCommand(-eject-) or whatever you want EDIT : HMm....Modding automated ECM is super easy and has already been done. I have made my own variant of it in several pieces, but have not used it online. You can mod some funny stuff in here. Like I made an autopilot for lockon to test certain airplane accelleration and climb performance. It uses lua IO to perform basic test flights at higher precision than a player can perform. It reads speed/pitch/aoa/etc and compares to what its "goals" are, then determines what input to give (like pitch up, throttle up, well, right now it has only 1 goal ;) ). I think it works similar to a normal autopilot.

*My Lips are sealed* Anyway, Thread is too old. Lock it up :). Someone lock this thread? Now, To Borchi, like you say, ECM is both offensive and defensive manual and automated in real life and uses far more technologies that can be listed in any thread. Let's assume some future sim is able to somewhat summarize 1960-70s ECM? that is probably not going to happen. All I know it is not realistic that the outcome of aircombat is based on who can press E fastest ^^. Sure ta real pilot can do that. Maybe there is a situation where this will actually be favorable, but, it will not act in the same way that is displayed in lo. If you do not want to believe we have talked to pilots of different air forces, ground crew, mechanics, engineers etc and that they can actually reveal decent information, then that is your decision. I have no intention of "proving" my claims here or revealing any sources. You believe what you want.

You make a mistake here : There is nothing wrong with the assumption that the universe is a perpetuum mobil if it is a closed system. In fact ANY closed system must be a perpetuum mobile to adhere to the conservation law. (This is also seen in electrodynamics in various ways). However human technology cannot create a true closed system : Hence : we cannot make a perpetuum mobile:)

There is a list of "god proofs" which includes this question and others. My answer is. Why do you assume things must have a beginning or end? Having a beginning or end imo is just a human simplification of a continous situation, Q ph guys call it a collapse of wavefunctions.

Try putting in full sentences and less "....." in your posts AS ;P. I have to read each post about 5 times to understand it. I'm not defending either side here, but I belive that energy is not destroyed. Not because of some law - no. I believe so because I have my own definition of energy

Well there is a problem there. The "higher classes" probably abstract things simply out of you cant create or kill energy, just transform. So it is the main point the classes start out of. How do disprove our definition by theory based on it? ;). We cannot. you cant create or kill energy, just transform - may be false? I dont know. But certainly every single device seen and produced in the world so far has worked according to it. Just means it is a good model so far :P. I dont think you can actually prove an empiric law...(it is one right?). but...go ahead. you can try to finda working solution for it. I dont know . If you make it you are rich, but so far everybody failed

That looks really good :). I will for sure use it in some mods as well.

Tried it, just making phi=atan(y/x) gives variable error in bearing up to +-7 degrees at the edges of the map. I will need something more accurate. I think the conversion algorithm here for x & y are accurate, however, since bearings do not correspond to actual x/y (draw bearing lines in map editor and you will se why). I will need something more accurate that takes the curvature of the lockon Lat/long lines mapped on the flat lockon world surface into account. For the moment I will stick with my own weird algorithms for making the bearing calculation. But I cannot mathematically motivate/prove my own stuff. The way I made my own stuff is ; I just tried some random 1st-3rd degree polynomials of "myLatLongAlt" and "hisLatLongAlt" and varied the coefficients until it gave good results in all directions tested in positions around map. That said, the linked algorithm can be used with good results for getting the range

Crap. Well I guess I have to stick with an algorithm specific for Lo's Black sea then. I was hoping of doing something completely general :P Thanks for your answers everyone

cool, yeah if you can get those basic things working it java it sure is faster to develop a java app ;)