RvEYoda

I found this for JNA http://ochafik.free.fr/Java/src/jna/ Theck windowutils.java if you want to try it has some utilities for handles and native calls etc If you were wondering, #define WS_EX_NOACTIVATE 0x08000000L

Ok furthermore, I am now implementing DirectInput to detect keyboard (and soon also could be joystick) input globally. I read the keyboard even when the application has no focus. Remember this has to be done at close to driver level (like directinput) since lockon assumes control over the keyboard. I have no clue how to make an equivalent in Java. I actually found some ways earlier to read keyboard globally by importing a DLL, but like above it didnt do it enough low level, as lockon hooked/stole the keyboard. To make a window not activate for example a forms application you can use afxwin.h and : HWND get_HWND(IntPtr& _handle) { return reinterpret_cast<HWND>(_handle.ToPointer()); //convert void* to HWND, hopefully.. } void Set_NOACTIVATE(Control^ myControl) { CWnd::FromHandle(get_HWND(myControl->Handle))->ModifyStyleEx(0,WS_EX_NOACTIVATE,1); } Maybe there is similar control for Java JNA? For the moment, development is continuing in C++ ;). You will also need the application instance in windows to bind directinput to it (if using that road), for a forms app it can be retreived using for example. (some dangerous casts here) hInstance = (HINSTANCE)(GetWindowLongPtr( cwin, GWLP_HINSTANCE )); if (hInstance!=NULL ) { cout << endl << "Application HINSTANCE was retrieved"; } where cwin is my HWND

I just realized my old reverse/empirically engineered algorithm for these things work almost identically with what is seen in your link Case. Ill see if I can compare them more in detail my old algo has about 0.5 deg precision (but does only work in the black sea area)

Thanks Case, I will try it later. Im sure it will give good range values, but im worried about bearings, ill see what happens

The lockon LUA export can provide me a LAT and LONG value of any object. However I need to calculate the distance and bearing from point A to point B, and here I run into a problem. I am using what is described here :http://www.movable-type.co.uk/scripts/latlong.html But when calculating the bearing, I get an error of something like 3-5 degrees. I have checked and rechecked both the numbers and algorithms, rewritten them, in multiple languages, but still get these errors. So I must assume that the lockon world is not curved in a manner that allows me to use these calculations. I really need to find some way of calculating bearing between two lockon Lat/Long coordinates with maximum 1 degree error ------- When I calculate distance between A->B I have an error of about 1%, but in this case I only require about 2-3% precision so that is not a problem. However, I really need some way of calculating bearings better. If anyone knows an algorithm that allows me to calculate the bearing from point A->B with the exported coordinates from lockon, that would be great. //Yoda

Sounds were not the reason I had bad performance in java And irrklang engine now supports java so I would use that. (its a really cool sound engine ;)) Regardless, ill see what this JNA is. Oh, and if you have time looking into it. What i need to do is to modify the window to have that extended window style. (see above post). If you can do that in Java, then bling, I might go java again :P. (my two main probs are then solved : no window activation when clicking and access to gc)

both threads and memory management in the current cpp version work fine.

No I need a window that does not assume focus when clicked. (Works fine in current leavu cpp version) This is so we can have leavu on a diff monitor and click it(touch screen) without lockon minimizing. Honestly im not sure if setwíndowpos is the one that can do this. I made a Cwindow (MFC) out of my window and added the extended style : from afxwin.h I use CWnd::FromHandle(get_HWND(myControl->Handle))->ModifyStyleEx(0,WS_EX_NOACTIVATE,1) the "myControl" object refers to the .net FORM that I used to make the app. and get_HWND is a bad hack ;) : HWND get_HWND(IntPtr& _handle) { return reinterpret_cast<HWND>(_handle.ToPointer()); //get HWND from IntPtr, hopefully.. } Don't know about Java performance though. I had bad results when I did the minor version of LEAVU (just the RWR sound system). Now I have like 4-5 systems instegrated here in cpp with 3d engine and sound system also, and getting nice performance. However what I did enjoy with java was the simplicity of creating threads, and it actually working according to documentation, instead of the .net threads I made (yes i was lazy and didnt look for other wierd thread libraries, shame on me!) .NET feels like *Microsoft Java*, just that half the shit isnt there ;), and if it's there it doesnt go by the documentation ...ouch!

yes pls. SetWindowpos is basically all i need from Win.

Its just that I really like doing it from the bottom up sometimes. I make a principle way of drawing a line, triangle, box and circle, and then I make variants of these and make it further high level. Also I want it to use as little CPU power as possible. And I think its fun to learn the low level controls of these things :). Mostly what worries me in gui systems is performance. With a HW accellerated 3D engine I was thinking "if this system can handle thousands of surfaces on screen at the same time, then just a few 10s should be piece of cake low CPU" (and yes the gui part of leavu currently is below 1% cpu ;)) Also I will not switch from cpp at this point. It would be too much work rewriting the entire thing. Also I dont have a clue on how to work with JNI which I would need to create the necessary window styles. I tried some tutorial of it, but honestly I couldnt even understand half of it . now if you accidently helped me so I wouldnt need to worry about the JNI part, I MIGHT go back to java for newer versions . But at the same time, given that I need to use JNI it will be platform dependent anyway (unless someone makes a library I can load on a diff platform)....so :P.....Tbh......i'd just like to keep cpp Moa, catch me on msn or ICQ if you got time!

honestly, all my friends with nvidia cards that tried LEAVU used GT..2..0 series, so I cannot tell. But remembering the tests we did, Crunch, you and me, It would seem any basic Dx9 engine on a second monitor will cause GT..2..0 series from nvidia to display black flicker in Lo. Another possibility is that instanciation of Dx9 devices from different programs simply isn't possible if one of them is in full screen. (Note though that the single app may create multiple devices), or something along these lines. http://msdn.microsoft.com/en-us/library/bb147220(VS.85).aspx Regardless....I am now almost certain I will switch to OpenGL EDIT: Before fully going OpenGL I ask if anyone has any ideas or if some dev just accidently saw this page and had any ideas. IF anyone has any suggestions this is how I initialize the device : DXengine::DXengine(HWND hWnd, const int& _resX, const int& _resY, int* _aaptr): oldAA(0), //Memorize previously selected AA level thisWindow(hWnd),//The window handle of our d3d sub window (may update with other calls) resX(_resX), //Resolution of our d3d sub window resY(_resY), //Resolution of our d3d sub window AAptr(_aaptr) { //User will select new AA levels from time to time, here to access that info make_edge_RECTs(); //Creates the rectangles holding menu names initD3D(); //Initializes the d3d object(=interface?) and d3d device } void DXengine::initD3D() { d3d = Direct3DCreate9(D3D_SDK_VERSION); // create the Direct3D interface ZeroMemory(&d3dpp, sizeof(d3dpp)); // clear out the struct for use d3dpp.Windowed = TRUE; // program windowed, not fullscreen d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; // discard old frames d3dpp.hDeviceWindow = thisWindow; // set the window to be used by Direct3D d3dpp.BackBufferFormat = D3DFMT_X8R8G8B8; d3dpp.BackBufferWidth = resX; d3dpp.BackBufferHeight = resY; update_device(); } This function is called when the device is created/unminimized/resolution changed void DXengine::update_device() { // Default to no AA bool SupportsAA = false; d3dpp.MultiSampleType = D3DMULTISAMPLE_NONE; if (*AAptr==2 && SUCCEEDED(d3d->CheckDeviceMultiSampleType( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL , D3DFMT_X8R8G8B8, TRUE, D3DMULTISAMPLE_2_SAMPLES, NULL ) ) ) { d3dpp.MultiSampleType = D3DMULTISAMPLE_2_SAMPLES; SupportsAA = true; } else if (*AAptr==4 && SUCCEEDED(d3d->CheckDeviceMultiSampleType( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL , D3DFMT_X8R8G8B8, TRUE, D3DMULTISAMPLE_4_SAMPLES, NULL ) ) ) { d3dpp.MultiSampleType = D3DMULTISAMPLE_4_SAMPLES; SupportsAA = true; } else if (*AAptr==8 && SUCCEEDED(d3d->CheckDeviceMultiSampleType( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL , D3DFMT_X8R8G8B8, TRUE, D3DMULTISAMPLE_8_SAMPLES, NULL ) ) ) { d3dpp.MultiSampleType = D3DMULTISAMPLE_8_SAMPLES; SupportsAA = true; } d3d->CreateDevice(D3DADAPTER_DEFAULT, // create a device class using this information and the info from the d3dpp stuct //D3DCREATE_SOFTWARE_VERTEXPROCESSING, D3DCREATE_HARDWARE_VERTEXPROCESSING D3DDEVTYPE_HAL, thisWindow, D3DCREATE_HARDWARE_VERTEXPROCESSING, //HARDWARE,SOFTWARE,D3DCREATE_HARDWARE_VERTEXPROCESSING,D3DCREATE_SOFTWARE_VERTEXPROCESSING &d3dpp, &d3ddev); //Some fonts of mine for mfds D3DXCreateFont(d3ddev, 14, 0, 650, 1, false, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH | FF_DONTCARE, L"Verdana", &menufont_normal); D3DXCreateFont(d3ddev, 12, 0, 450, 1, false, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH | FF_DONTCARE, L"Verdana", &screenfont_normal); D3DXCreateFont(d3ddev, 15, 0, 1000, 1, false, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH | FF_DONTCARE, L"Verdana", &screenfont_large); if (SupportsAA && d3ddev!=NULL) { d3ddev->SetRenderState(D3DRS_MULTISAMPLEANTIALIAS,TRUE); } //Activate AA } And this is how I draw a frame // this is the function used to render a single frame void DXengine::render_frame(void) { if (d3ddev==NULL) return; //Initialize new back buffer d3ddev->BeginScene(); // begins the 3D scene d3ddev->SetFVF(CUSTOMFVF); DXengine* me = this; //Cause the following functions are overloaded by DXengine_MPCD class me->paint_black(); // This currently makes one call : d3ddev->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 0), 1.0f, 0); me->paint_backuffer(); //overload this function to draw bottom layer, this function starts the active MFD page's own draw calls //Finish drawing this frame d3ddev->EndScene(); // ends the 3D scene d3ddev->Present(NULL, NULL, NULL, NULL); // displays the created frame on the screen } Also replaced the rendering with : (which also gave same gt 260,280 issues) // this is the function used to render a single frame void DXengine::render_frame(void) { if (d3ddev==NULL) return; //Initialize new back buffer d3ddev->BeginScene(); // begins the 3D scene d3ddev->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 0), 1.0f, 0); //As you see it doesnt draw anything, just clears buffers, screen, makes it ready for hte next frame //problem persists even if I remove the above line write my own naive Clear method that just draws a black // square over the bb to clear it. ANY operatinon BB seems to mess with gt 260 280 in lockon //Finish drawing this frame d3ddev->EndScene(); // ends the 3D scene d3ddev->Present(NULL, NULL, NULL, NULL); // displays the created frame on the screen }

I've tried all sorts of workarounds and different rendering modes, but there seems to be an issue with Gtx280 and gtx260 cards. When running lockon on primary monitor and creating a dx9 engine on a second monitor, these graphics cards show black flickering ingame. hd4870s and other ATi cards dont seem to show it. RIght now there is no obvious solution. This could be a driver or architecture issue or something else. Im basically just creating the dx9 device like instructed in the MIcrosoft DIrectX SDK documentation. I will probably switch to an OpenGL implementation of LEAVU eventually to avoid things like this tbh....but that might also cause issues if we are unlucky :P. Right now the advice I have for people with gtx260 or 280 is to run LEAVU on a different machine (like your laptop) and lockon on the main machine. I'm also having trouble recording a video on ingame action. I havent found any software that lest me record the second monitor at the same time as fraps records the primary monitor. well....I found one, but it records wrong colors ;P

Looks very nice

Here is a little tech demo. Not showing ingame action, just fooling around with AA, resolution and menu settings. Just to give people an idea of what it is. I dont claim that it's realistic to have gray buttons. I dont claim that it is realistic for a mark point to be green on the MPCD or that it is even in the same shape or triggered by the same button. This is a proof of concept, sort of, and a useful interface imo. http://yoda.reservoirselite.com/LEAVU/demo1.avi Will release an ingame demo later and then also a datalink demo

You got PM Ells228 :). I can explain to you on msn how it works in lo right now

Yes it wont help you see them farther out, well you could, but give me a PM about it. It can be misused for cheating. I can pm you some instructinos on how to set up realistic ranges

You can use the modellod.txt file Chola, I have done this. With a few text edits you can produce close to realistic visibility results

Moa its done SHooter side, not victim Side in CS. I was just giving it as an example where it was not done server side. Most games have moved away from a completely server centralized setup because doing these things on a preferred client has very significant lag/delay improvements. It Is one of the most major points in multiplayer games in my opinion, and doing it on the defender's side you can really make it consistent for the defender and attacker how a shot will perform. We don't want the falcon setup where the missile explodes 100m behind you on your screen and then you die *for no reason* because on the server it exploded on you. This makes for terrible learning experience when it comes to defenses. You risk having it become totally inconsistent. And worst of all it will vary depending on your network ping to the server. Such a net code would at least, for me, completely ruin gameplay. And as many other games already do this a preferred client, i'm srue they have also figured out viable ways to iron out cheating and similar things, being as hugely popular as they are.

I believe missile intercepts should be done on target machine. Dispite server safety, the delays are too big for objects flying 1000 m/s (And closure even larger!) where 50 ms delay to server can create a 50 m difference in position, could easily mean the difference between life and death. Think then of 300 ms ping and we are up in *=)(/#%&. Anything that cannot at least guarantee a +-1 m precision for the defenders point of view will be trouble. It requires a lot of work to get it safe, YES. and we can have the server confirm all flight paths, but primarily I think the defender should do these calculations. The server should just verify them within good limits. This choice was made for many shooter games a few years back. In its early days CS( counter strike) used the server based method, but later switched over to one based on the shooter's machine. The last thing I want is a game where server/client response rate/times will decide how I need to time my defenses. Also Moa please do not delay the universal exports right now. All LRM (and other stuff as well) will fail cause currently the lockon radar exports (among other scripts) have bugs in certain AC modes. Im talking about the export functions provided by ED having bugs. Some give blank data exported if the plane is in certain modes.

Why not just have the Tacview export script keep the data in RAM for 1-2 minutes before saving it to a file? Ofc, assuming everyone is using the same (new?) tacview, or the server enforcing some built in tacview.

Hey I recognize these numbers ;)

Im all for delayed universal exports, given that the "playerplane" exports are fixed. Currently for example the radar export doesnt export updates in F-15 TWS mode, along with a few other issues. This is partially why my scripts are much longer than could first be thought necessary. Simply cause I need to use global object data to produce the avionics data backwards. For example TWS follows target would not work without it.

oo not hitting. Well lockon's most effective way of getting an ER kill is probably HOJ or firing LAO and waiting until last second to lock stt. Same with amraam u unlock right before pitbull to induce a maddog state just before pitbull range and deny rwr warning until last second. It's kind of cheap, but it is what people do online :/

the issue is they reacquire the new target way too easy. Remember the "searchlight" of the radar is only about 2 degrees wide. Moving this do look for new targets is not very efficient or fast irl (as compared to lockon where it is SUper fast and accurate, but we all know this, this is the same as the classical *I see +-90 right left r77/aim120* issue ;)) Also many AC radars would not "keep" the necessary radar signature after a relock. And the missiles will be assuming certain paramaters about range, closure, etc. It will like they say likely not work irl for targets with very different closure for example. Reason is the missile is launched with some data, and keeps some data in memory, calculated and approximated from the returns or dlink MCUs it has already received, to have a picture of what it should track. As such it also will not track the wrong target if two targets are found within the same searchlight/search cone, unless they are very similar on these parameters. For an active missile such differentiation is even more important. Now likely the older missiles you are using, the less they will differentiate such parameters.

Believe what you want. I tested this in 1v1 vs Crunch with and without mods. we both had it I also spoke to (i cant remember who) in 51st who confirmed it, said it had been there for a long time Fyi I havent edited a single code line of lockon, guess why? the code is closed, the source is closed, we don't have access to it. The only thing you can do is run a parallell LUA script. The only thing lua scripts can do to affect lockon are : 1. Ask for flight, sensor or object data (like coordinates, positions, fuel), universal object data is only available if config.lua export is set to true or 2. Do math on these data (calculate ranges and such) or 3. Send LUA input as stated by ED here : http://lockon.co.uk/index.php?lang=en&end_pos=567&scr=default Nr 3 can send commands like "power up left engine" or "Pitch down" or "move cursor". They can do the same thing as a pilot can, but cannot, I say again CANNOT actually change the game in any way that the pilot cannot do with buttons himself. The only difference is that it can be made automatic OR inputed by external sources like a built cockpit.