Moa

The mission file format is different in BS (FC2) compared to FC1.1.2. In BS the mission is a zip compressed set of LUA files. In FC1.1.2 the mission is an XML file with some (undocumented) binary pieces thrown in at certain byte offsets (yukk!!). DoctorK was a master for figuring out where those binary chunks where and how to modify them. In summary, this mission generator will not work without a lot of modification.

I use Ubuntu, Windows and Mac OS X. It should run without modification on all three and I'm sure it'll be tested it on all of them (it is Java although uses the JoGL Java OpenGL plugin that has native code on those platforms [and Solaris]).

Most servers allow cannon or A2G for vulching, just not air-to-air. Cratering bombs don't directly kill player aircraft so are usually allowed. Note that when a player exits a mission and comes back in they don't see the craters anymore (just as crashed aircraft on the runway are re-set for them).

Perhaps it is worth enumerating the gauges to be produced? Then we have a concrete goal to aim for and can estimate how many are needed to contribute.

I messaged DoctorK some time ago with questions about the LockOn mission file format. Unfortunately he didn't respond (I hope he's still about, please post in this thread if you are watching DoctorK). In the meantime I reverse engineered the RamGen code since I wanted to re-implement parts of it in a server-side Java dynamic campaign system I'm working on. I won't make the source code available yet since I want to give DoctorK a chance to tell me not to, if he has other plans in the works or wants to release his code instead.

Hi Yoda, Have you looked at the OpenGL Texture Mapping FAQ? http://www.opengl.org/resources/faq/technical/texture.htm That might help with your texture mapping (which the com.sun.opengl.util.j2d.TextRenderer will be done under the covers) Section "21.030 Why doesn't lighting work when I turn on" might be useful. You should also consider learning how to use texture-mapping. It is very very fast to do (consumer-grade cards are principaly optimised for texture mapping). texture mapping?

Flanker is also outnumbered by more expensive aircraft (in absolute terms) as well. This is because the US economy was vastly larger than the Soviet economy, which meant despite individual aircraft being more expensive a lot more could be purchased while still spending a smaller proportion of GDP on defense. This fact is a lost on a lot of folk who only seem to consider 1 vs 1 or small unit tactics. There is an old saying that "Amatuers talk tactics, professionals talk logistics". In this case there is no doubt that in the Cold War the Flanker was far too expensive for the diminutive Russian economy - something that arguably contributed to the collapse of that economy and the unravelling of the associated political system. The US both had the industrial and financial capacity to produce larger numbers of Eagles. So, my point is, despite being more expensive than the Flanker there are over 1500 Eagles built of all types vs under 700 Flankers. Coupled a higher availability rate for the Eagle the Flankers would almost always be outnumbered.

Mach number depends on altitude (more specifically the air temperature, which varies with altitude). If you are high the Mach number will increase for a given airspeed. One interesting thing is that fighter engines are designed so that they can be run at higher thrust at a particular higher altitude (they can overheat at full power at lower altitudes but run nicely at full power higher up).

Please look for Lock On Virtual Panel either in these fora or at LockOnFiles. There is a very interesting project being produced by =RvE= Yoda (with a little help from myself and others) called LEAVU2 which has a long thread on these ED fora. It already does what you want (although it requires the upcoming Flaming Cliffs 2.0).

I started work on a dynamic campaign for LockOn. I finished the work for analysing battles (now an online pilot stat system) and was working my way through the undocumented LockOn mission format (mostly XML but some binary stuff in there too). With DCS the mission format has changed (all text, actually LUA code, but this is also undocumented). I hope to get my mission creation software done this year (yes, it takes a long time, plus I've been distracted by LEAVU2 etc) and bolt it on to the software I have for analysing battles. This is what gives you a dynamic campaign system :)

I don't really want to continue a long discussion about this but suggest readers re-examine the Red Flag data that is available. The scenarios usually F-15s are seriously outnumbered in most engagements (and have to block fighter-bombers while dealing with many fighters) as that is how the US likes to train. Please ignore the breathless hype regarding the US 'defeats' in newspapers and read the slightly more detailed (but not by much) reports about the actual excercises. Although there is no doubt the Indian airforce gave good account of themselves (and the USAF too, of course). Both sides also didn't use all of their ECM/ECCM/radar options (the Indians are contractually obliged not to use the 'war reserve' modes by their Russian suppliers). So the Red Flag exercises are definitively indicative of combat performance. If anyone wants to debate this then by all means start a new thread elsewhere. Otherwise, can we please move on.

Hi Crunch, I had the same problem with the Win7 release candidate running on my server. I fixed it by finding the LockOn folder in the Explorer and getting the path from the title bar as text. Then pasting it into the path in Hyperlobby. I noticed changes of case from some items in the path, although I'm reluctant to believe this to be the source of the problem. Perhaps Hyperlobby doesn't escape the space in the file name properly but the Win7 Explorer does. Anyway it's ironic, since I asked you for help for this since I didn't know how to force Hyperlobby to re-check the path so I could set it properly. You helped me and we fixed it. Nice to be able to return the favour. Yes, you also do need to run as Admin and do the stuff to fix the "..." relative path instances in the Hyperlobby config files or graphics will not be drawn properly. Cheers, Moa

Yes it is possible, you can paste any bitmap into an existing DirectX context. Think of how Fraps does it. It is composition at the last stage of rendering. I don't know how to capture keypresses and mouse clicks from the composited context anyway so it is a bit moot.

Yeah, you would have to enter simulated user keypresses to slew the radar until the cursor moved over the target and then submit a lock command.

A hyperlobby replacement if you will (no more having to patch Vista/7 to make Hyperlobby to work right). Would be nice if it let you see who was flying what, that way you know whether to spawn as fighter or attack aircraft.

Not only "broad daylight", LEAVU2 is Free Software (more than Open Source) under the Gnu General Public License v2 (or later). You can read the source code yourself at any time at: http://kenai.com/projects/leavu2 http://kenai.com/projects/leavu2/sources/subversion/show No more "heaped coals" for Yoda please. Enjoy, Moa

There are a couple of topics I'd like to add: The LEAVU2 software uses a binary protocol for communication. Yoda has given me clearance to add a SOAP webservice interface. This would make hooking up external stuff easier (since SOAP webservices are standardised). Now I just have to find the time to do it .... I want to re-iterate. The real-time TacView software I'm using it for statistics purposes and because I can't run TacView on Linux after a battle (whereas my Java TacView-esqu software will run on platform). However, I feel the need to state that I do not use the display in flight, ever. Not for training, not for ordinary flight, not for tournaments (similarly to what etherealN pointed out about himself, I'm more interested in air-to-surface and my a2a also sucks). I would love to publish the source code for others to use since I don't want them to waste the time I've already spent developing it but I just can't trust that if I put it out there it won't be abused. I'm happy to share with any other developers on request though. Back to the security debate. I did want to point out that the client side of the system can never, ever be trusted. If the client gets the information then there is always some way of breaking into it. However, there is a way to fix that that is too much hassle for event the most talented cheaters to break. That is to get the server to encrypt the (small) packets of data streaming from it. You have to request the the server's one-time decryption key or the data makes no sense to your application. Therefore the server is in the driver's seat and controls who sees what. Sounds ok, but won't the performance suffer? No it won't since most folks have at least two CPU cores and even with DCS/BS many have two busy and two idle. Simply run the decryption in real time on another core. Even if another core was not available the time to decrypt the small packets is completely negligible compared to the 50-300 ms network latency to the server. Only down side to this is that it has to be done server side in the data originating from the server (since the server is always a point of trust), and would require ED to do it (hint, hint). Could also encrypt different levels of data with different keys (allowing some data to be decrypted by some people and not by others [admins]). Also, can I put in a feature request? Would be lovely if a LockOn server could have different settings than the clients. For example, it is nice to have external view or map on server (so you can watch someone for cheating) even when you want to force clients to have external views off. Before someone pipes up and says "that'll allows admins to cheat" - well, if you have a dishonest admin you're buggered anyway, so let's instead just make it easier for admins to catch the real cheaters please.

It seems to me that some of the fans of Russian birds are upset that LEAVU2 doesn't show MFD in a Russian style. Yes? Can't program to fix it yourself? That's cool. In that case please post what (non-copyright, non-classified) information, pictures you have and someone might get around to implementing it. Better yet, you could take the time to learn how to Gimp/Photoshop the textures etc yourself. An excellent example of this is the post Panzertard made. There he provided useful references that meant that some developer with the motivation to do the Russian birds gets a good starting point. It takes sooooo much time to do any of this development that any help is appreciated. It is a far more useful to provide references of how things work in the real-world than complain that LEAVU2 doesn't work the same way as the picture in your mind. An example of this is the radio line-of-sight debate. Lots of argument on how broken things were but were missing one crucial point. Fortunately Yoda pointed out (I couldn't my router was broken) that satellite can be used and so line-of-sight doesn't always apply (although it might sometimes when satellites are overloaded as they have been in the two Gulf Wars).

Just because the 'helper' was written in Java and uses JAVA APIs doesn't mean that the SUN JVM is required. The Java can be compiled to native using GNU GCJ to produce a native executable (can even statically link libraries to reduce the chance of tampering or deployment problems, eg. the niceness that is the monolithic Putty SSH program).

It is possible to get the location of a loaded class (I knew it must be possible since the JVM classloader is designed with security in mind, another reason I like Java). URL url = MFD.class.getProtectionDomain().getCodeSource().getLocation(); Once you have the URL you can compute a digest and send it to the server. The classloader also verifies signed and sealed JARS when loading. Someone would have to be pretty determined to go through all the hassle to defeat this, and still only end up with the same information about their own aircraft as if they'd written a local LUA script.

The problem isn't signing the JAR or taking a checksum/hash. It is making sure that the JAR being checked is indeed the JAR in use. I have to do some homework on this.

Usually it is done with encryption keys (yes, just like the real datalink). There are many ways to use them for authentication/authorization, but you need support on the server (or a proxy) to do this. Are we able to modify the game server? Each player has a public/private key pair generated for them and stored on their machine. During handshake they submit their public key (which they share freely). The server encrypts something with that key and sends it to the player. Only that player has the private key that can decrypt that token. The player uses that token to authenticate with the server (which can register a token to the client IP/port). Variations on this can be used to allow/deny communications between client and server.

Will do tonight (6 hours from now).

For the Gripen and F-18 mods :)