Moa

Haven't managed to stop activation being switched yet, even using JNA calling SetWindowPos (in Windows' user32.dll). Top get the HWND of the the JFrame I'm made this method which uses the undocumented call WComponentPeer.getHWnd(), since ever since Java 1.4 they disabled the Toolkit.getDefaultToolkit().getNativeWindowHandleFromComponent(component) way of getting it. Maybe I'm not getting the right HWND? I guess the way to test is to try render/print text to that hwnd. /** * Returns the Windows handle of the user-interface component. * * @param component the component to get the handle of. * * @return the Windows handle of the component. */ public long getWindowHandleFromComponent(Component component) { ComponentPeer peer = component.getPeer(); WComponentPeer win32Peer = (WComponentPeer) peer; long hwnd = win32Peer.getHWnd(); return hwnd; } I should check my assumptions: get mouse input without changing keyboard focus or z-order for LockOn?

Started using JNA. Very easy to call into native libraries. Just have to dig up some old code getting HWND from Java component to supply the HWND we need to give to SetWindowPos ....

Yeah, I'm looking into it tonight when i get home from work (can't wait!) - last night could not as had to do computer fixit for a mate - you know how it is. Netbeans has a profiler which helps sort out performance bottlenecks in your code (I think Eclipse may have one as well now, but I prefer Netbeans).

I couldn't see a Java way of getting focus without activating a window (there is plenty of focus/input support in the JDK but not activation management). Rather than start with custom JNI I thought I might try out the JNA library (which is cross platform). See https://jna.dev.java.net/ Incidentally, it is a shame you got bad performance with sounds. I would suggest JOAL as a solution but haven't used it myself. Will get back to you to let you know how it goes.

In Java you call System.gc() This is advisory only (the runtime can choose to run the gc or not). Depending on how recent the Java version is it can either cause a big or small pause (the brand new G1 collector is quite good). C# is derived from a prototype language called 'Cool' that was essentially MS's Java implementation. So the similarity is not accidental. Ok, I'll look into how to do input to window without grabbing focus (JNI if need be) ... will get back to you within 24-hrs from now. If your C++ is working well enough (no leaks) then I can't see a reason to change - I was just suggesting in case you were looking at a change (eg. if you had threading issues).

Let's not start a flamewar, but INRIA (the French scientific supercomputing dudes) disagree with you. http://blogs.sun.com/jag/entry/current_state_of_java_for http://hal.inria.fr/inria-00312039/en Plus, what Yoda wants is OpenGL not HPC, in which case JoGL is a thin wrapper. It is a different performance domain GG. I agree Java is not perfect, but it is faster to get stuff done than C and fast enough performance if you know what you're doing.

What are the flags you need to SetWindowPos? Do you want "always on top behaviour" for a window? You don't need JNI for that. If you want always on top then use java.awt.Window.setAlwaysOnTop(true). This works for Swing's JFrame as well (which is derived from awt.Window). If you use Swing you can also use the very attractive Nimbus theme and provided the client's JRE is 1.6.10 or later then it is all accelerated on the video card. Then you get yourself a JoGL rendering context and you're doing OpenGL. All the calls of OpenGL are available. So you're getting Swing for the nice Nimbus themeing, button handling etc (so you don't have to do that work yourself) and integration with JoGL. Plus, with Java, you can have multiple threads going on and you won't leak resources all over the place. Java has come a very long way in client-side support in the last year. Netbeans (free IDE from www.netbeans.org) has a graphical GUI builder and a plugin for JoGL that does syntax highlighting of GLSL (the OpenGL Shading Language, called 'slang'). Is Java fast enough? Well, I believe 90% of IL-2 was written in Java and the JVMs today are now very much faster (beating C and approaching Fortran for speed). But if you still wanna stick with C++, no worries. Oh yeah, congratulations on making the ED Testers Team. Its good to see your hard work recognised.

Cool. Well, if you ever want JNI done I can get it done it'd be no problem.

I don't know much Direct X but I do know OpenGL pretty well (although I haven't done WGL for a very long time), so can help a little if you post questions here. First thing to decide is which OpenGL model you'll program to, 1.0 (fixed function pipeline), 2.0 (programmable vertex and fragment[pixel] shaders), or the spanking new 3.0 (which doesn't have great support yet). However, I'm surprised you want to use a 3D library for what appears to be essentially a 2D application. If you want to learn how to do 3D that's one thing, but won't it slow you down getting LEAVU out the door, since it seems there is plenty of other stuff to do? Also, I'll re-iterate that the Java 2D library does very advanced compositing (it was designed by Adobe as well as Sun) - also, ever since Java 1.6.10 it fully and transparently hardware accelerated (DirectX on Windows and OpenGL shaders on all other platforms) - even for stuff like filtering/convolutions etc. I'm not suprised the ATI Radeon HD works better than the GTXes. That's my experience as well (with LockOn at least). Not only fewer visual defects with ATI but also hassle-free ALT-TAB as well. I never miss the opportunity to remind Crunch he should have bought a HD 4870 for less money than his GTX. Ain't you lucky, eh Crunch? :)

However, you can take Home-on-Jam shots at opponents who leave their ECM on. So be careful not to leave your own jammer on.

Sorry, my current day job is software consulting and development for large corps and government. I was merely trying to point out how reasonably foolproof security would be done on an industrial scale. If that's not what you need then cool - but be aware your 'good-enough' security mindset has failed for the last five years and will continue to fail unless you get serious about it. It does affect gameplay (since some have advantage that others don't) which is why it keeps coming up in these fora. Looking at the unreliable log output from LockOn I'd say correctness and security were not a priorities (understandable with limited resources) and probably never will be so I'll STFU. Perhaps I should instead whinge at the Free Falcon folk. Lag will always be an issue no matter where you compute it. Fortunately missiles are deterministic and their flight paths can be evaluated ahead of time much better than bullets. Worrying about lag is inconsequential to things like the fact that seeker fields of view are not properly modeled, so I guess that is much more of a priority. Interesting about CS doing it victim-side, although that effectively worsens the relative lag for the attacker, yeah?. Thanks for pointing that out. No worries Yoda, I won't touch the 169 export.

You cannot trust the client's PC, so having missile intercepts on the victim's PC is not sensible. Have them on the 'neutral' server (or so one would hope). > As for ED's mission editing lockout, that's all it's meant to do. It's also not encryption so er no, why would anyone be serious about that? If you're not going to do it right, then why bother? > Uh ... so you want some sort of CPU-eating image recognition (which is also just not bloody feasible, or at the least a huge waste of time) and waste my bandwidth too? WTF? I disagree. Given the server can reconstruct the frame display of a single image in hardware at random times for players why would this be a problem? At the moment the server is producing frames at a far faster rate, since at present all LockOn server instances produces graphics at full frame rates. All I'm suggesting is to occasionally set the viewpoint to a random player, get the players graphic settings, and compare with a screenshot streamed (slowly if need be) from the players game instance. Most of the time the server should not be doing this (which would mean it ran faster than the current system that unnecessarily renders graphics 100% of the time). This would work and would catch cheats (although mods might cause false positives) who only change textures. The server would then do a simple diff between images and warn an admin if there was significant variation. Since this would be done randomly with a low frequency this should cause negligible impact on the game relative to a headless server (you could even assign one of those hyperthreaded quad-cores to do it while the game logic ran uninterupted on the other cores :)). Case I didn't mean to belittle your important contribution (and I hope it didn't sound like it). I was hoping to point out that something stronger ought to be considered for the future (eg DCS).

That's what I was thinking. It would be nice to let the player's aircraft information through in real-time tho' for the sim pit builders. An 'export proxy' would be able to do this. I've been thinking of doing this but have been busy chasing down race conditions and distributed transaction issues in the beta 169 stats.

The only way to avoid significant cheating is to control missile intercepts etc on the (multiplayer) server. That would also fix lag issues, since the server's record of events would be authoritative. You can sometimes see the effects of lag in TacView recordings. A dedicated server should have enough processing time to do this, since time wouldn't be wasted doing graphics. I also think you're right A.S. about being prepared to make your in-game tracks public. If you're prepared to supply others with your tracks (as soon as you land) then there's not enough time to change stuff and people get an idea of what you were able to see. The 51sts 'encryption' tool was a nice gift to the community but I must say the protection is very, very weak. Anyone who has a little bit of programming experience could break this and run TacView in real-time. No-one else would be able to tell. For example, it is an hour's work for me to easily defeat this 'protection' but choose not to (which shows in my crappy A2A stats, lol). Incidentally, I easily reverse-engineered ED's weak password protection on mission files (disclaimer, I was building a dynamic campaign engine, now on hold, and needed to read and write that field) - if you are going to do encryption you ought to do it right. Therefore, I think that until some of the calculations are handled on the server there will always be the worst cheats (I'm hoping this is an idea ED might consider for DCS). The way to handle graphics cheating might be for the program to save a few snapshots of the screen buffer in memory and automatically forward them to the game server once a player is dead or disengaged. The server software could easily (automatically) detect graphics anomalies. Exported game data should be delayed by 60 seconds for all aircraft except the player's. That would fix that particular problem. I won't ask about other squadrons but I do know that the 169 takes its motto of "Play hard, play fair" very seriously. In my year there I've never heard an exploit being privately suggested for use there and I don't think it would be tolerated if it was. That's one reason we're very grateful for all Yoda's hard work in trying to defeat some of the known exploits and increase the realism of the sim.

True, but at least you will eliminate the maddoggers that don't know where the enemy is and simply launch to see where it goes. Or launch outside the missile's seeker cone, since this is not properly modeled. Having an lock, using launch override and launching over maximum range is a flaw in the missile kinematics not the seeker code (and easily defeated by even a partial angle-off turn).

It's my understanding that the LockOn internal state maintans what type of lock an aircraft has on another. Isn't maddog simply a launch without a valid lock? Therefore I've always thought that stopping maddogs was a simple matter of looking at that data. See: -- Weapon Control System LoGetTargetInformation() -- (args - 0, results - 1 (table of current targets tables)) LoGetLockedTargetInformation() -- (args - 0, results - 1 (table of current locked targets tables)) this functions return the table of the next target data target = { ID , -- world ID (may be 0 ,when ground point track) type = {level1,level2,level3,level4}, -- world database classification country = , -- object country position = {x = {x,y,z}, -- orientation X ort y = {x,y,z}, -- orientation Y ort z = {x,y,z}, -- orientation Z ort p = {x,y,z}} -- position of the center velocity = {x,y,z}, -- world velocity vector m/s distance = , -- distance in meters convergence_velocity = , -- closing speed in m/s mach = , -- M number delta_psi = , -- aspect angle rad fim = , -- viewing angle horizontal (in your body axis) rad fin = , -- viewing angle vertical (in your body axis) rad flags = , -- field with constants detemining method of the tracking -- whTargetRadarView -- whTargetEOSView -- whTargetRadarLock -- whTargetEOSLock -- whTargetRadarTrack -- whTargetEOSTrack -- whTargetNetHumanPlane = 0x0200; -- whTargetAutoLockOn = 0x0400; -- whTargetLockOnJammer = 0x0800; reflection = , -- target cross section square meters course = , -- target course rad isjamming = , -- target ECM on or not start_of_lock = , -- time of the beginning of lock forces = { x,y,z}, -- vector of the acceleration units updates_number = , -- number of the radar updates } specified at: http://lockon.co.uk/index.php?lang=en&end_pos=567&scr=default This would require adding some info to the lua export. Perhaps record to a socket or another file rather than the file that TacView uses (that is, so TacView still works). Sorry Yoda, I don't have time to follow up on this (or the DirectX overlay stuff at the moment). Hoping things will quiet down soon an I can give you a bit more of a hand with some of this stuff.

I run a LockOn FC server on Win7 (my regular gaming rig uses Win XP). Besides the StarForce patch once you install Flaming Cliffs you need to tell it to run in "Compatibility Mode" (right click on its icon) for "Windows XP Service Pack 3" and also run as Administrator. If you don't run in Compatibilty Mode then you might get lots of graphics problems (I had them with my Nvidia GTX 8800 on my testbed machine). I had problems with drivers for my Thrustmaster Cougar Hotas. The Vista driver works (after a bit of wrestling) but the programmable functions (the 'foxy' program) aren't supported. Other folks from 169 Sqn had issues with Win7 mostly related to sound drivers. In short, you can run LockOn FC but it depends a lot on your hardware drivers being available (Linux has much better hardware support than Win7 at the moment, lol).

Anisotropic filtering (AF) is designed to produce better textures effects at different distances. This is the key to graphics problems which get worse with increasing distance. Anti-aliasing (AA) helps improve the appearance of lines (especially if they've been rendered with a fast approximation such as Bresenham's algorithm). It helps at any depth of field.

Vee is an old formation not used much due to a lack of flexibility. The current basic formation is a two ship element usually formed joined with another pair (that is, two two-ship elements make a four-ship flight). This is was originally developed by the German ace Werner Molders in the Spanish Civil War and the two-ship was called a "Rotte" and the four-ship was a "Schwarm". This was eventually adapted by other airforces during World War II (read: The Great Patriotic War for some of you) and was often called 'Finger Four' (the aircraft positions were similar to the spacings of your finger tips - but only four of the fingers on the one hand if you come from Alabama, lol). Within each two-ship element there is a designated leader and wingman. In combat though they dynamically change roles between 'shooter' and 'cover' (engaged and free fighter). While one aircraft engages the second maneuvers for their next attack while clearing the attacking aircraft of rear quarter threats. The shooter and cover exchange roles throughout the fight as they progressively deplete the total energy state (and maneuvering options) of their opponent. When traveling in hostile airspace the basic pair formation is the 'combat spread' (line abreast with some horizontal separation and one aircraft 1000 foot higher). The formation dissolves when fighters maneuver for their meeting engagement (left, right, hook, drag etc), subsequent maneuvering (box etc) and resume combat spread after the engagement. Note that attack aircraft use different formations when engaging a target (often attacking from different directions) - if they don't have stand-off weaponry. For reading I suggest the F-16 or F-18 flight manuals (USAF and USN have slightly different emphasis and names for things). They also have excellent descriptions on how to maneuver as a formation (simple turns are harder to coordinate than you think when multiple aircraft are involved!). Robert Shaw's book "Fighter Combat:Tactics and Maneuvering" is an excellent (although slightly technical) read for the engagement phase.

As Chuck Yeager said, "It's the man, not the machine". This is the reason pilots such as yourself, Ice, MoGas, Crunch, Zerol etc can whip most other pilots no matter what you are flying (just this month MoGas has a lot of a2a kills against fighters when flying the Su-25T). The F-15 pilots in the USAF are the best it has to offer, same with the Eagle drivers in the IDF etc. The Eagle is a great ship but its the pilots that really make the difference - they get more flight hours and simulated air-to-air combat than any other group of pilots in history. I'm sure there are great Russian pilots, and equally others in other airforces such as China etc. However, if we now quote Josef Stalin, "Quantity has a quality of its own". In this area the USAF has all other airforces beaten hands down (apart from the USN). The other factor which has not yet been fully tested is quality of electronics and software. We can only speculate on this but I'm guessing the balance must be tilted in the same direction. Anyway, arguing aircraft based on paper specifications seems a bit moot. It is the rest of the battle environment (start, support, fuel state, numbers etc) that makes more of a difference.

Sure cold is good if you are only considering the combustion part. You also get throttle valve sticking when descending through cold, can cause engine failure. Curtains for you. Therefore you need to keep the engine reasonably warm. No point having super efficient cool engine if there are ice problems in fuel lines (low throttle setting) and unable to adjust throttle when needed (throttle freezing). Carnot cycle combustion engines are ubiquitous but not that efficient. Rotary engines are better (although they have other disadvantages). Hydrogen power is a problem (either as fuel-cell or combustion source) because the electrolysis to produce it requires electrical power (eg. from gas turbine or nuclear power station). Hydrogen is more like an energy storage option rather than energy source itself. Hydrogen itself is very bad for existing engines (destroying rubber seals etc) so engines using it for combustion are more expensive. Hydrogen will not solve the worlds energy demands.

Are you on Vista or XP? In Vista you need to run in "Compatibility Mode" for "Windows XP Service Pack 3" and also "Run as Administrator".

Too cold and lubricant viscosity is too high (not slippery enough). There is an optimum temperature range which you must be always consider, in piston-powered aircraft at least. A descent at low engine power can easily cool the engine too much and cause problems with fuel freezing and insufficient lubrication. During a long descent engine power must occasionally be increased to prevent problems, particularly if the decent is to land since if you abort and need full throttle then fuel icing could seriously ruin your day (or life!).

Ok. It's nearly the weekend here (timezone +12) so I'll do some homework on whether its possible to compositing to another application's direct3d window. Incidentally, we do fullscreen video at 70+ fps using JNI (we have a Java application using open-source ffmpeg library [used in vlc and others] running on Windows, Linux and OS X). It is possible to get it going fast, you have to make sure you minimise or eliminate buffer copying. We also don't call Win32 directly. Wrote a native C library wrapper for the things we need that internally handles the Win32 types and Java/JNI just calls the nice POSIX-compliant C interface instead of Win32's macro mess.

I would make your drawing surface full-screen and fully transparent apart from your little window in the position your want (bottom right, or perhaps user-configurable). You'd then need to set the 'Z-order' of this window to be higher than of LockOn. As a quick hack you could simply use ALT-Tab to place your (mostly) transparent fullscreen window over LockOn and leave it there. In Win32 the z-order of a window can be changed with SetWindowPos. You might be able to use this on the application window you render Direct3D into. The hard part is then passing all mouse and keyboard events through your mostly transparent window to LockOn below (not so bad once you get the window handle of the lower window). I'd suggest you always leave the transparent window on top (so it intercepts keypresses) and your 'hide' key merely shows or hides your instrument panel within your glass pane. If you lower your glass pane below LockOn you'll lose your key interception (which means you won't be able to re-show your window as easily). I'm sure there are plenty of dodgy hackers out there with code to log keypresses and pass them through to other windows, just ask the eastern european mafias or cantonese triads :) Incidentally, doing this kind of stuff with Java Swing + JoGL (Java OpenGL) is a quite easy and also very easy to set your 'glass pane' to always-on-top. That's why I suggested using OpenGL some-time back (plus you can re-use the parts of the same code on multiplatform, Android, iPhone etc). I guess you're using DirectX so no point changing now. ps. Thanks Crunch for pointing out this thread. pps. With this 'compositing' method you could actually overwrite the *entire* cockpit display of lockon and just have the external environment (rendered by LockOn) showing through. That is, you could make a completely *custom* cockpit (not just re-skinned) if you grabbed the aircraft performance data from the export.lua in real time! Shame I'm too busy to do this myself :(